draft-ietf-tsvwg-emergency-rsvp-14.txt   draft-ietf-tsvwg-emergency-rsvp-15.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft J. Polk Internet-Draft J. Polk
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: May 29, 2010 K. Carlberg Expires: September 9, 2010 K. Carlberg
G11 G11
November 25, 2009 March 8, 2010
Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority
draft-ietf-tsvwg-emergency-rsvp-14.txt draft-ietf-tsvwg-emergency-rsvp-15.txt
Abstract Abstract
Some applications require the ability to provide an elevated Some applications require the ability to provide an elevated
probability of session establishment to specific sessions in times of probability of session establishment to specific sessions in times of
network congestion. When supported over the Internet Protocol suite, network congestion. When supported over the Internet Protocol suite,
this may be facilitated through a network layer admission control this may be facilitated through a network layer admission control
solution that supports prioritized access to resources (e.g., solution that supports prioritized access to resources (e.g.,
bandwidth). These resources may be explicitly set aside for bandwidth). These resources may be explicitly set aside for
prioritized sessions, or may be shared with other sessions. This prioritized sessions, or may be shared with other sessions. This
document specifies extensions to the Resource reSerVation Protocol document specifies extensions to the Resource reSerVation Protocol
(RSVP) that can be used to support such an admission priority (RSVP) that can be used to support such an admission priority
capability at the network layer. capability at the network layer.
Based on current security concerns, these extensions are targeting Based on current security concerns, these extensions are intended for
applicability within a single administrative domain. use in a single administrative domain.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
3. Overview of RSVP extensions and Operations . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3.1. Operations of Admission Priority . . . . . . . . . . . . . 6 4. Overview of RSVP extensions and Operations . . . . . . . . . . 5
4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7 4.1. Operations of Admission Priority . . . . . . . . . . . . . 7
4.1. Admission Priority Policy Element . . . . . . . . . . . . 7 5. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 9 5.1. Admission Priority Policy Element . . . . . . . . . . . . 9
4.2. Application-Level Resource Priority Policy Element . . . . 10 5.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10
4.2.1. Application-Level Resource Priority Modifying and 5.2. Application-Level Resource Priority Policy Element . . . . 11
Merging Rules . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Application-Level Resource Priority Modifying and
4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 11 Merging Rules . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12
5.1. Use of RSVP Authentication between RSVP neighbors . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.2. Use of INTEGRITY object within the POLICY_DATA object . . 13 6.1. Use of RSVP Authentication between RSVP neighbors . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.2. Use of INTEGRITY object within the POLICY_DATA object . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples of Bandwidth Allocation Model for Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 18 Admission Priority . . . . . . . . . . . . . . . . . 19
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 18 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 20
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 22 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 24
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 25 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 27
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 28 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Some applications require the ability to provide an elevated Some applications require the ability to provide an elevated
probability of session establishment to specific sessions in times of probability of session establishment to specific sessions in times of
network congestion. network congestion.
Solutions to meet this requirement for elevated session establishment Solutions to meet this requirement for elevated session establishment
probability may involve session layer capabilities prioritizing probability may involve session layer capabilities prioritizing
access to resources controlled by the session control function. As access to resources controlled by the session control function. As
skipping to change at page 5, line 10 skipping to change at page 5, line 10
Elements allowing the admission priority to be conveyed inside RSVP Elements allowing the admission priority to be conveyed inside RSVP
signaling messages so that RSVP nodes can enforce selective bandwidth signaling messages so that RSVP nodes can enforce selective bandwidth
admission control decision based on the session admission priority. admission control decision based on the session admission priority.
Appendix A of this document also provides examples of bandwidth Appendix A of this document also provides examples of bandwidth
allocation models which can be used by RSVP-routers to enforce such allocation models which can be used by RSVP-routers to enforce such
admission priority on every link. A given reservation may be admission priority on every link. A given reservation may be
signaled with the admission priority extensions specified in the signaled with the admission priority extensions specified in the
present document, with the preemption priority specified in [RFC3181] present document, with the preemption priority specified in [RFC3181]
or with both. or with both.
Based on current security concerns (discussed in Section 5), these
extensions are targeting applicability within a single administrative
domain.
1.1. Terminology 1.1. Terminology
This document assumes the terminology defined in [RFC2753]. For This document assumes the terminology defined in [RFC2753]. For
convenience, the definition of a few key terms is repeated here: convenience, the definition of a few key terms is repeated here:
o Policy Decision Point (PDP): The point where policy decisions are o Policy Decision Point (PDP): The point where policy decisions are
made. made.
o Local Policy Decision Point (LPDP): PDP local to the network o Local Policy Decision Point (LPDP): PDP local to the network
element. element.
o Policy Enforcement Point (PEP): The point where the policy o Policy Enforcement Point (PEP): The point where the policy
decisions are actually enforced. decisions are actually enforced.
o Policy Ignorant Node (PIN): A network element that does not o Policy Ignorant Node (PIN): A network element that does not
explicitly support policy control using the mechanisms defined in explicitly support policy control using the mechanisms defined in
[RFC2753]. [RFC2753].
2. Requirements Language 2. Applicability Statement
A subset of RSVP messages are signaled with the Router Alert Option
(RAO)([RFC2113],[RFC2711]). The security aspects and common
practices around the use of the current IP Router Alert option and
consequences on the use of IP Router Alert by applications such as
RSVP are discussed in [I-D.rahman-rtg-router-alert-considerations].
Based on those, the extensions defined in this document are intended
for use within a single administrative domain. Thus, in particular,
the extensions defined in this document are not intended for use end
to end on the Internet.
3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Overview of RSVP extensions and Operations 4. Overview of RSVP extensions and Operations
Let us consider the case where a session requires elevated Let us consider the case where a session requires elevated
probability of establishment, and more specifically that the probability of establishment, and more specifically that the
preference to be granted to this session is in terms of network layer preference to be granted to this session is in terms of network layer
"admission priority" (as opposed to preference granted through "admission priority" (as opposed to preference granted through
preemption of existing sessions). By "admission priority" we mean preemption of existing sessions). By "admission priority" we mean
allowing the priority session to seize network layer resources from allowing the priority session to seize network layer resources from
the engineered capacity that has been set-aside for priority sessions the engineered capacity that has been set-aside for priority sessions
(and not made available to normal sessions), or alternatively (and not made available to normal sessions), or alternatively
allowing the priority session to seize additional resources beyond allowing the priority session to seize additional resources beyond
skipping to change at page 7, line 23 skipping to change at page 7, line 33
then be encoded inside the Preemption Priority Policy Element of then be encoded inside the Preemption Priority Policy Element of
[RFC3181]. [RFC3181].
Appendix B provides examples of various hypothetical policies for Appendix B provides examples of various hypothetical policies for
prioritized session handling, some of them involving admission prioritized session handling, some of them involving admission
priority, some of them involving both admission priority and priority, some of them involving both admission priority and
preemption priority. Appendix B also identifies how the Application- preemption priority. Appendix B also identifies how the Application-
Level Resource Priority needs to be mapped into RSVP policy elements Level Resource Priority needs to be mapped into RSVP policy elements
by the PDPs to realize these policies. by the PDPs to realize these policies.
3.1. Operations of Admission Priority 4.1. Operations of Admission Priority
The RSVP Admission Priority policy element defined in this document The RSVP Admission Priority policy element defined in this document
allows admission bandwidth to be allocated preferentially to allows admission bandwidth to be allocated preferentially to
prioritized sessions. Multiple models of bandwidth allocation MAY be prioritized sessions. Multiple models of bandwidth allocation MAY be
used to that end. used to that end.
A number of bandwidth allocation models have been defined in the IETF A number of bandwidth allocation models have been defined in the IETF
for allocation of bandwidth across different classes of traffic for allocation of bandwidth across different classes of traffic
trunks in the context of Diffserv-aware MPLS Traffic Engineering. trunks in the context of Diffserv-aware MPLS Traffic Engineering.
Those include the Maximum Allocation Model (MAM) defined in Those include the Maximum Allocation Model (MAM) defined in
skipping to change at page 8, line 5 skipping to change at page 8, line 15
and do not represent a recommended course of action. and do not represent a recommended course of action.
We can see in these examples how the RSVP Admission Priority can be We can see in these examples how the RSVP Admission Priority can be
used by RSVP routers to influence their admission control decision used by RSVP routers to influence their admission control decision
(for example by determining which bandwidth pool is to be used by (for example by determining which bandwidth pool is to be used by
RSVP for performing its bandwidth allocation) and therefore to RSVP for performing its bandwidth allocation) and therefore to
increase the probability of reservation establishment. In turn, this increase the probability of reservation establishment. In turn, this
increases the probability of application level session establishment increases the probability of application level session establishment
for the corresponding session. for the corresponding session.
4. New Policy Elements 5. New Policy Elements
The Framework document for policy-based admission control [RFC2753] The Framework document for policy-based admission control [RFC2753]
describes the various components that participate in policy decision describes the various components that participate in policy decision
making (i.e., PDP, PEP and LPDP). making (i.e., PDP, PEP and LPDP).
As described in Section 3 of the present document, the Application- As described in Section 4 of the present document, the Application-
Level Resource Priority Policy Element and the Admission Priority Level Resource Priority Policy Element and the Admission Priority
Policy Element serve different roles in this framework: Policy Element serve different roles in this framework:
o the Application-Level Resource Priority Policy Element conveys o the Application-Level Resource Priority Policy Element conveys
application level information and is processed by PDPs application level information and is processed by PDPs
o the emphasis of Admission Priority Policy Element is to be simple, o the emphasis of Admission Priority Policy Element is to be simple,
stateless, and light-weight such that it can be processed stateless, and light-weight such that it can be processed
internally within a node's LPDP. It can then be enforced internally within a node's LPDP. It can then be enforced
internally within a node's PEP. It is set by PDPs based on internally within a node's PEP. It is set by PDPs based on
skipping to change at page 8, line 39 skipping to change at page 9, line 5
The POLICY_DATA object contains one or more of Policy Elements, each The POLICY_DATA object contains one or more of Policy Elements, each
representing a different (and perhaps orthogonal) policy. As an representing a different (and perhaps orthogonal) policy. As an
example, [RFC3181] specifies the Preemption Priority Policy Element. example, [RFC3181] specifies the Preemption Priority Policy Element.
This document defines two new Policy Elements called: This document defines two new Policy Elements called:
o the Admission Priority Policy Element o the Admission Priority Policy Element
o the Application-Level Resource Priority Policy Element o the Application-Level Resource Priority Policy Element
4.1. Admission Priority Policy Element 5.1. Admission Priority Policy Element
The format of the Admission Priority policy element is as shown in The format of the Admission Priority policy element is as shown in
Figure 1: Figure 1:
0 0 0 1 1 2 2 3 0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type = ADMISSION_PRI | | Length | P-Type = ADMISSION_PRI |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved | | Flags | M. Strategy | Error Code | Reserved |
skipping to change at page 10, line 10 skipping to change at page 10, line 15
o Reserved: 24 bits o Reserved: 24 bits
* SHALL be set to zero on transmit and SHALL be ignored on * SHALL be set to zero on transmit and SHALL be ignored on
reception reception
o Adm. Priority (Admission Priority): 8 bits (unsigned) o Adm. Priority (Admission Priority): 8 bits (unsigned)
* The admission control priority of the flow, in terms of access * The admission control priority of the flow, in terms of access
to network bandwidth in order to provide higher probability of to network bandwidth in order to provide higher probability of
session completion to selected flows. Higher values represent session completion to selected flows. Higher values represent
higher priority. A given Admission Priority is encoded in this higher priority. Bandwidth allocation models such as those
information element using the same value as when encoded in the described in Appendix A are to be used by the RSVP router to
"Admission Priority" field of the "Admission Priority" achieve increased probability of session establishment. The
parameter defined in [I-D.ietf-nsis-qspec]. In other words, a
given value inside the Admission Priority information element
defined in the present document or inside the
[I-D.ietf-nsis-qspec] Admission Priority field refers to the
same admission priority. Bandwidth allocation models such as
those described in Appendix A are to be used by the RSVP router
to achieve increased probability of session establishment. The
admission priority value effectively indicates which bandwidth admission priority value effectively indicates which bandwidth
constraint(s) of the bandwidth constraint model in use is(are) constraint(s) of the bandwidth constraint model in use is(are)
applicable to admission of this RSVP reservation. applicable to admission of this RSVP reservation.
Note that the Admission Priority Policy Element does NOT indicate Note that the Admission Priority Policy Element does NOT indicate
that this RSVP reservation is to preempt any other RSVP reservation. that this RSVP reservation is to preempt any other RSVP reservation.
If a priority session justifies both admission priority and If a priority session justifies both admission priority and
preemption priority, the corresponding RSVP reservation needs to preemption priority, the corresponding RSVP reservation needs to
carry both an Admission Priority Policy Element and a Preemption carry both an Admission Priority Policy Element and a Preemption
Priority Policy Element. The Admission Priority and Preemption Priority Policy Element. The Admission Priority and Preemption
Priority are handled by LPDPs and PEPs as separate mechanisms. They Priority are handled by LPDPs and PEPs as separate mechanisms. They
can be used one without the other, or they can be used both in can be used one without the other, or they can be used both in
combination. combination.
4.1.1. Admission Priority Merging Rules 5.1.1. Admission Priority Merging Rules
This section discusses alternatives for dealing with RSVP admission This section discusses alternatives for dealing with RSVP admission
priority in case of merging of reservations. As merging applies to priority in case of merging of reservations. As merging applies to
multicast, this section also applies to multicast sessions. multicast, this section also applies to multicast sessions.
The rules for merging Admission Priority Policy Elements are defined The rules for merging Admission Priority Policy Elements are defined
by the value encoded inside the Merge Strategy field in accordance by the value encoded inside the Merge Strategy field in accordance
with the corresponding IANA registry. The merge strategies (and with the corresponding IANA registry. This registry applies both to
associated values) defined by the present document are the same as the Merge Strategy field of the Admission Priority Policy Element
those defined in [RFC3181] for merging Preemption Priority Policy defined in the present document and to the Merge Strategy field of
Elements (see "IANA Considerations" section). the Preemption Priority Policy Elements defined in [RFC3181]. The
registry initially contains the values already defined in [RFC3181]
(see "IANA Considerations" section).
The only difference from [RFC3181] is that this document does not The only difference from [RFC3181] is that this document does not
recommend any merge strategies for Admission Priority, while recommend a given merge strategy over the others for Admission
[RFC3181] recommends the first of these merge strategies for Priority, while [RFC3181] recommends the first of these merge
Preemption Priority. Note that with the Admission Priority (as is strategies for Preemption Priority. Note that with the Admission
the case with the Preemption Priority), "Take highest priority" Priority (as is the case with the Preemption Priority), "Take highest
translates into "take the highest numerical value". priority" translates into "take the highest numerical value".
4.2. Application-Level Resource Priority Policy Element 5.2. Application-Level Resource Priority Policy Element
The format of the Application-Level Resource Priority policy element The format of the Application-Level Resource Priority policy element
is as shown in Figure 2: is as shown in Figure 2:
0 0 0 1 1 2 2 3 0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type = APP_RESOURCE_PRI | | Length | P-Type = APP_RESOURCE_PRI |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// ALRP List // // ALRP List //
skipping to change at page 12, line 22 skipping to change at page 12, line 22
o ALRP Value: (Application-Level Resource Priority Value): 8 bits o ALRP Value: (Application-Level Resource Priority Value): 8 bits
(unsigned) (unsigned)
* Contains the priority value within the namespace of the * Contains the priority value within the namespace of the
application-level resource priority. This value is encoded as application-level resource priority. This value is encoded as
per the "Resource Priority Priority-Value" IANA registry. (See per the "Resource Priority Priority-Value" IANA registry. (See
IANA Considerations section for the request to IANA to extend IANA Considerations section for the request to IANA to extend
the registry to include this numerical value). the registry to include this numerical value).
4.2.1. Application-Level Resource Priority Modifying and Merging Rules 5.2.1. Application-Level Resource Priority Modifying and Merging Rules
When POLICY_DATA objects are protected by integrity, LPDPs should not When POLICY_DATA objects are protected by integrity, LPDPs should not
attempt to modify them. They MUST be forwarded as-is to ensure their attempt to modify them. They MUST be forwarded as-is to ensure their
security envelope is not invalidated. security envelope is not invalidated.
In case of multicast, when POLICY_DATA objects are not protected by In case of multicast, when POLICY_DATA objects are not protected by
integrity, LPDPs MAY merge incoming Application-Level Resource integrity, LPDPs MAY merge incoming Application-Level Resource
Priority elements to reduce their size and number. When they do Priority elements to reduce their size and number. When they do
merge those, LPDPs MUST do so according to the following rule: merge those, LPDPs MUST do so according to the following rule:
o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST
contain all the ALRPs appearing in the ALRP List of an incoming contain all the ALRPs appearing in the ALRP List of an incoming
APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than
once. In other words, the outgoing ALRP List is the union of the once. In other words, the outgoing ALRP List is the union of the
incoming ALRP Lists that are merged. incoming ALRP Lists that are merged.
As merging applies to Multicast, this rule also applies to Multicast As merging applies to Multicast, this rule also applies to Multicast
sessions. sessions.
4.3. Default Handling 5.3. Default Handling
As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes
(PINs) implement a default handling of POLICY_DATA objects ensuring (PINs) implement a default handling of POLICY_DATA objects ensuring
that those objects can traverse PIN nodes in transit from one PEP to that those objects can traverse PIN nodes in transit from one PEP to
another. This applies to the situations where POLICY_DATA objects another. This applies to the situations where POLICY_DATA objects
contain the Admission Priority Policy Element and the ALRP Policy contain the Admission Priority Policy Element and the ALRP Policy
Element specified in this document, so that those can traverse PIN Element specified in this document, so that those can traverse PIN
nodes. nodes.
Section 4.2 of [RFC2750] also defines a similar default behavior for Section 4.2 of [RFC2750] also defines a similar default behavior for
policy-capable nodes that do not recognized a particular Policy policy-capable nodes that do not recognized a particular Policy
Element. This applies to the Admission Priority Policy Element and Element. This applies to the Admission Priority Policy Element and
the ALRP Policy Element specified in this document, so that those can the ALRP Policy Element specified in this document, so that those can
traverse policy-capable nodes that do not support these extensions traverse policy-capable nodes that do not support these extensions
defined in the present document. defined in the present document.
5. Security Considerations 6. Security Considerations
As this document defines extensions to RSVP, the security As this document defines extensions to RSVP, the security
considerations of RSVP apply. Those are discussed in [RFC2205], considerations of RSVP apply. Those are discussed in [RFC2205],
[RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches
for addressing those concerns are discussed further below. for addressing those concerns are discussed further below.
A subset of RSVP messages are signaled with the Router Alert Option A subset of RSVP messages are signaled with the Router Alert Option
(RAO)([RFC2113],[RFC2711]). The security aspects and common (RAO)(,[RFC2711]). The security aspects and common practices around
practices around the use of the current IP Router Alert option and the use of the current IP Router Alert option and consequences on the
consequences on the use of IP Router Alert by applications such as use of IP Router Alert by applications such as RSVP are discussed in
RSVP are discussed in [I-D.rahman-rtg-router-alert-considerations]. [I-D.rahman-rtg-router-alert-considerations]. As discussed in
As mentioned earlier, based on current security concerns (some of Section 2, the extensions defined in this document are intended for
them associated with RAO), the extensions defined in this document use within a single administrative domain.
are targeting applicability within a single administrative domain.
[I-D.rahman-rtg-router-alert-considerations] discusses router alert
protection approaches for Service Providers. These approaches can be
used to protect a given network against the potential risks
associated with the leaking of router alert packets resulting from
the use of the present extensions in another domain. Also, where
RSVP is not used, by simply not enabling RSVP on the routers of a
given network, that network can generally isolate itself from any
RSVP signaling that may leak from another network that uses the
present extensions (since the routers will then typically ignore RSVP
messages). Where RSVP is to be used internally within a given
network, the network operator can activate, on the edge of his
network, mechanisms that either tunnel or drop incoming RSVP messages
in order to protect the given network from RSVP signaling that may
leak from another network that uses the present extensions.
The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in
this document are signaled by RSVP through encapsulation in a Policy this document are signaled by RSVP through encapsulation in a Policy
Data object as defined in [RFC2750]. Therefore, like any other Data object as defined in [RFC2750]. Therefore, like any other
Policy Elements, their integrity can be protected as discussed in Policy Elements, their integrity can be protected as discussed in
section 6 of [RFC2750] by two optional security mechanisms. The section 6 of [RFC2750] by two optional security mechanisms. The
first mechanism relies on RSVP Authentication as specified in first mechanism relies on RSVP Authentication as specified in
[RFC2747] and [RFC3097] to provide a chain of trust when all RSVP [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP
nodes are policy capable. With this mechanism, the INTEGRITY object nodes are policy capable. With this mechanism, the INTEGRITY object
is carried inside RSVP messages. The second mechanism relies on the is carried inside RSVP messages. The second mechanism relies on the
INTEGRITY object within the POLICY_DATA object to guarantee integrity INTEGRITY object within the POLICY_DATA object to guarantee integrity
between RSVP Policy Enforcement Points (PEPs) that are not RSVP between RSVP Policy Enforcement Points (PEPs) that are not RSVP
neighbors. neighbors.
5.1. Use of RSVP Authentication between RSVP neighbors 6.1. Use of RSVP Authentication between RSVP neighbors
RSVP authentication can be used between RSVP neighbors that are RSVP authentication can be used between RSVP neighbors that are
policy capable. RSVP Authentication (defined in [RFC2747] and policy capable. RSVP Authentication (defined in [RFC2747] and
[RFC3097]) SHOULD be supported by an implementation of the present [RFC3097]) SHOULD be supported by an implementation of the present
document. document.
With RSVP authentication, the RSVP neighbors use shared keys to With RSVP authentication, the RSVP neighbors use shared keys to
compute the cryptographic signature of the RSVP message. compute the cryptographic signature of the RSVP message.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key
provisioning methods as well as their respective applicability. provisioning methods as well as their respective applicability.
5.2. Use of INTEGRITY object within the POLICY_DATA object 6.2. Use of INTEGRITY object within the POLICY_DATA object
The INTEGRITY object within the POLICY_DATA object can be used to The INTEGRITY object within the POLICY_DATA object can be used to
guarantee integrity between non-neighboring RSVP PEPs. This is guarantee integrity between non-neighboring RSVP PEPs. This is
useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). useful only when some RSVP nodes are Policy Ignorant Nodes (PINs).
The INTEGRITY object within the POLICY_DATA object MAY be supported The INTEGRITY object within the POLICY_DATA object MAY be supported
by an implementation of the present document. by an implementation of the present document.
Details for computation of the content of the INTEGRITY object can be Details for computation of the content of the INTEGRITY object can be
found in Appendix B of [RFC2750]. This states that the Policy found in Appendix B of [RFC2750]. This states that the Policy
Decision Point (PDP), at its discretion, and based on destination Decision Point (PDP), at its discretion, and based on destination
skipping to change at page 14, line 38 skipping to change at page 15, line 5
conceptually similar to the use of key shared across multiple RSVP conceptually similar to the use of key shared across multiple RSVP
neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying].
We observe also that this issue may not exist in some deployment We observe also that this issue may not exist in some deployment
scenarios where a single (or low number of) PDP is used to control scenarios where a single (or low number of) PDP is used to control
all the PEPs of a region (such as an administrative domain). In such all the PEPs of a region (such as an administrative domain). In such
scenarios, it may be easy for a PDP to determine what is the next hop scenarios, it may be easy for a PDP to determine what is the next hop
PDP, even when the next hop PEP is not known, simply by determining PDP, even when the next hop PEP is not known, simply by determining
what is the next region that will be traversed (say based on the what is the next region that will be traversed (say based on the
destination address). destination address).
6. IANA Considerations 7. IANA Considerations
As specified in [RFC2750], Standard RSVP Policy Elements (P-type As specified in [RFC2750], Standard RSVP Policy Elements (P-type
values) are to be assigned by IANA as per "IETF Consensus" policy values) are to be assigned by IANA as per "IETF Consensus" policy
following the policies outlined in [RFC2434] (this policy is now following the policies outlined in [RFC2434] (this policy is now
called "IETF Review" as per [RFC5226]) . called "IETF Review" as per [RFC5226]) .
IANA needs to allocate two P-Types from the Standard RSVP Policy IANA needs to allocate two P-Types from the Standard RSVP Policy
Element range: Element range:
o one P-Type to the Admission Priority Policy Element o one P-Type to the Admission Priority Policy Element
o one P-Type to the Application-Level Resource Priority Policy o one P-Type to the Application-Level Resource Priority Policy
Element. Element.
In section 3.1, the present document defines a Merge Strategy field In Section 5.1, the present document defines a Merge Strategy field
inside the Admission Priority policy element. IANA needs to create a inside the Admission Priority policy element. This registry is to be
registry for this field and allocate the following values: specified as also applicable to the Merge Strategy field of the
Preemption Priority Policy Elements defined in [RFC3181]. Since it
is conceivable that, in the future, values are added to the registry
that only apply to the Admission Priority Policy Element or to the
Preemption Priority Policy Element (but not to both), IANA needs to
list the applicable documents for each value. IANA needs to allocate
the following values::
o 1: Take priority of highest QoS o 0: Reserved
o 2: Take highest priority o 1: Take priority of highest QoS [RFC3181] [RFC-XXX]
o 3: Force Error on heterogeneous merge o 2: Take highest priority [RFC3181] [RFC-XXX]
o 3: Force Error on heterogeneous merge [RFC3181] [RFC-XXX]
Following the policies outlined in [RFC5226], numbers in the range Following the policies outlined in [RFC5226], numbers in the range
4-127 are allocated according to the "IETF Review" policy, numbers in 4-127 are allocated according to the "IETF Review" policy, numbers in
the range 128-240 as "First Come First Served" and numbers between the range 128-240 as "First Come First Served" and numbers between
241-255 are reserved for "Private Use". Value 0 is Reserved (for 241-255 are reserved for "Private Use".
consistency with [RFC3181] Merge Strategy values).
In section 3.1, the present document defines an Error Code field In Section 5.1, the present document defines an Error Code field
inside the Admission Priority policy element. IANA needs to create a inside the Admission Priority policy element. IANA needs to create a
registry for this field and allocate the following values: registry for this field and allocate the following values:
o 0: NO_ERROR Value used for regular ADMISSION_PRI elements o 0: NO_ERROR Value used for regular ADMISSION_PRI elements
o 2: HETEROGENEOUS This element encountered heterogeneous merge o 2: HETEROGENEOUS This element encountered heterogeneous merge
Following the policies outlined in [RFC5226], numbers in the range Following the policies outlined in [RFC5226], numbers in the range
3-127 are allocated according to the "IETF Review" policy, numbers in 3-127 are allocated according to the "IETF Review" policy, numbers in
the range 128-240 as "First Come First Served" and numbers between the range 128-240 as "First Come First Served" and numbers between
241-255 are reserved for "Private Use". Value 1 is Reserved (for 241-255 are reserved for "Private Use". Value 1 is Reserved (for
consistency with [RFC3181] Error Code values). consistency with [RFC3181] Error Code values).
The present document defines an ALRP Namespace field in section 3.2 The present document defines an ALRP Namespace field in Section 5.2
that contains a numerical value identifying the namespace of the that contains a numerical value identifying the namespace of the
application-level resource priority. The IANA already maintains the application-level resource priority. The IANA already maintains the
Resource-Priority Namespaces registry (under the SIP Parameters) Resource-Priority Namespaces registry (under the SIP Parameters)
listing all such namespace. However, that registry does not listing all such namespace. However, that registry does not
currently allocate a numerical value to each namespace. Hence, this currently allocate a numerical value to each namespace. Hence, this
document requests the IANA to extend the Resource-Priority Namespaces document requests the IANA to extend the Resource-Priority Namespaces
registry in the following ways: registry in the following ways:
o a new column should be added to the registry o a new column should be added to the registry
skipping to change at page 16, line 17 skipping to change at page 16, line 37
o allocate an actual numerical value to each namespace in the o allocate an actual numerical value to each namespace in the
registry and state that value in the new "Namespace numerical registry and state that value in the new "Namespace numerical
Value *" column. Value *" column.
A numerical value should be allocated immediately by IANA to all A numerical value should be allocated immediately by IANA to all
existing namespaces. Then, in the future, IANA should automatically existing namespaces. Then, in the future, IANA should automatically
allocate a numerical value to any new namespace added to the allocate a numerical value to any new namespace added to the
registry. registry.
The present document defines an ALRP Priority field in section 3.2 The present document defines an ALRP Priority field in Section 5.2
that contains a numerical value identifying the actual application- that contains a numerical value identifying the actual application-
level resource priority within the application-level resource level resource priority within the application-level resource
priority namespace. The IANA already maintains the Resource-Priority priority namespace. The IANA already maintains the Resource-Priority
Priority-values registry (under the SIP Parameters) listing all such Priority-values registry (under the SIP Parameters) listing all such
priorities. However, that registry does not currently allocate a priorities. However, that registry does not currently allocate a
numerical value to each priority-value. Hence, this document numerical value to each priority-value. Hence, this document
requests the IANA to extend the Resource-Priority Priority-Values requests the IANA to extend the Resource-Priority Priority-Values
registry in the following ways: registry in the following ways:
o for each namespace, the registry should be structured with two o for each namespace, the registry should be structured with two
skipping to change at page 17, line 12 skipping to change at page 17, line 33
A numerical value should be allocated immediately by IANA to all A numerical value should be allocated immediately by IANA to all
existing priorities. Then, in the future, IANA should automatically existing priorities. Then, in the future, IANA should automatically
allocate a numerical value to any new namespace added to the allocate a numerical value to any new namespace added to the
registry. The numerical value must be unique within each namespace. registry. The numerical value must be unique within each namespace.
For the initial allocation, within each namespace, values should be For the initial allocation, within each namespace, values should be
allocated in decreasing order ending with 0 (so that the greatest allocated in decreasing order ending with 0 (so that the greatest
priority is always allocated value 0). For example, in the drsn priority is always allocated value 0). For example, in the drsn
namespace, "routine" would be allocated numerical value 5 and "flash- namespace, "routine" would be allocated numerical value 5 and "flash-
override-override" would be allocated numerical value 0. override-override" would be allocated numerical value 0.
7. Acknowledgments 8. Acknowledgments
We would like to thank An Nguyen for his encouragement to address We would like to thank An Nguyen for his encouragement to address
this topic and ongoing comments. Also, this document borrows heavily this topic and ongoing comments. Also, this document borrows heavily
from some of the work of S. Herzog on Preemption Priority Policy from some of the work of S. Herzog on Preemption Priority Policy
Element [RFC3181]. Dave Oran and Janet Gunn provided useful input Element [RFC3181]. Dave Oran and Janet Gunn provided useful input
into this document. Ron Bonica, Magnus Westerlund, Cullen Jennings, into this document. Ron Bonica, Magnus Westerlund, Cullen Jennings,
and Ross Callon provided specific guidance for the applicability Ross Callon and Tim Polk provided specific guidance for the
statement of the mechanisms defined in this document. applicability statement of the mechanisms defined in this document.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
skipping to change at page 18, line 22 skipping to change at page 18, line 42
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006. RFC 4412, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
8.2. Informative References 9.2. Informative References
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-17 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), October 2009. (work in progress), January 2010.
[I-D.ietf-nsis-qspec]
Bader, A., Ash, G., Kappler, C., and D. Oran, "QoS NSLP
QSPEC Template", draft-ietf-nsis-qspec-22 (work in
progress), November 2009.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] [I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security", Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009. progress), June 2009.
[I-D.rahman-rtg-router-alert-considerations] [I-D.rahman-rtg-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage", Faucheur, F., "IP Router Alert Considerations and Usage",
draft-rahman-rtg-router-alert-considerations-03 (work in draft-rahman-rtg-router-alert-considerations-03 (work in
skipping to change at page 20, line 38 skipping to change at page 21, line 6
If the non-priority traffic load reaches the maximum bandwidth If the non-priority traffic load reaches the maximum bandwidth
available for non-priority, no additional non-priority sessions can available for non-priority, no additional non-priority sessions can
be accepted even if the bandwidth reserved for priority traffic is be accepted even if the bandwidth reserved for priority traffic is
not currently fully utilized. not currently fully utilized.
With the Maximum Allocation Model, in the case where the priority With the Maximum Allocation Model, in the case where the priority
load reaches the maximum bandwidth reserved for priority sessions, no load reaches the maximum bandwidth reserved for priority sessions, no
additional priority sessions can be accepted. additional priority sessions can be accepted.
As illustrated in Figure 4, an operator may map the MAM model onto As illustrated in Figure 4, an operator may map the MAM to the
the Engineered Capacity limits according to different policies. At Engineered Capacity limits according to different policies. At one
one extreme, where the proportion of priority traffic is reliably extreme, where the proportion of priority traffic is reliably known
known to be fairly small at all times and where there may be some to be fairly small at all times and where there may be some safety
safety margin factored in the engineered capacity limits, the margin factored in the engineered capacity limits, the operator may
operator may decide to configure the bandwidth available for non- decide to configure the bandwidth available for non-priority use to
priority use to the full engineered capacity limits; effectively the full engineered capacity limits; effectively allowing the
allowing the priority traffic to ride within the safety margin of priority traffic to ride within the safety margin of this engineered
this engineered capacity. This policy can be seen as an economically capacity. This policy can be seen as an economically attractive
attractive approach as all of the engineered capacity is made approach as all of the engineered capacity is made available to non-
available to non-priority sessions. This policy is illustrated as priority sessions. This policy is illustrated as (1) in Figure 4.
(1) in Figure 4. As an example, if the engineered capacity limit on As an example, if the engineered capacity limit on a given link is X,
a given link is X, the operator may configure the bandwidth available the operator may configure the bandwidth available to non-priority
to non-priority traffic to X, and the bandwidth available to priority traffic to X, and the bandwidth available to priority traffic to 5%
traffic to 5% of X. At the other extreme, where the proportion of of X. At the other extreme, where the proportion of priority traffic
priority traffic may be significant at times and the engineered may be significant at times and the engineered capacity limits are
capacity limits are very tight, the operator may decide to configure very tight, the operator may decide to configure the bandwidth
the bandwidth available to non-priority traffic and the bandwidth available to non-priority traffic and the bandwidth available to
available to priority traffic such that their sum is equal to the priority traffic such that their sum is equal to the engineered
engineered capacity limits. This guarantees that the total load capacity limits. This guarantees that the total load across non-
across non-priority and priority traffic is always below the priority and priority traffic is always below the engineered capacity
engineered capacity and, in turn, guarantees there will never be any and, in turn, guarantees there will never be any QoS degradation.
QoS degradation. However, this policy is less attractive However, this policy is less attractive economically as it prevents
economically as it prevents non-priority sessions from using the full non-priority sessions from using the full engineered capacity, even
engineered capacity, even when there is no or little priority load, when there is no or little priority load, which is the majority of
which is the majority of time. This policy is illustrated as (3) in time. This policy is illustrated as (3) in Figure 4. As an example,
Figure 4. As an example, if the engineered capacity limit on a given if the engineered capacity limit on a given link is X, the operator
link is X, the operator may configure the bandwidth available to non- may configure the bandwidth available to non-priority traffic to 95%
priority traffic to 95% of X, and the bandwidth available to priority of X, and the bandwidth available to priority traffic to 5% of X. Of
traffic to 5% of X. Of course, an operator may also strike a balance course, an operator may also strike a balance anywhere in between
anywhere in between these two approaches. This policy is illustrated these two approaches. This policy is illustrated as (2) in Figure 4.
as (2) in Figure 4.
Figure 5 shows some of the non-priority capacity of this link being Figure 5 shows some of the non-priority capacity of this link being
used. used.
----------------------- -----------------------
^ ^ ^ | | ^ ^ ^ ^ | | ^
. . . | | . . . . | | .
Total . . . | | . Bandwidth Total . . . | | . Bandwidth
. . . | | . Available . . . | | . Available
Engi- . . . | | . for non-priority use Engi- . . . | | . for non-priority use
skipping to change at page 23, line 35 skipping to change at page 24, line 31
Figure 8: Partial non-priority load & Full priority load Figure 8: Partial non-priority load & Full priority load
A.2. Admission Priority with Russian Dolls Model (RDM) A.2. Admission Priority with Russian Dolls Model (RDM)
This section illustrates operations of admission priority when a This section illustrates operations of admission priority when a
Russian Dolls Model (RDM) is used for bandwidth allocation across Russian Dolls Model (RDM) is used for bandwidth allocation across
non-priority traffic and priority traffic. A property of the Russian non-priority traffic and priority traffic. A property of the Russian
Dolls Model is that priority traffic can use the bandwidth which is Dolls Model is that priority traffic can use the bandwidth which is
not currently used by non-priority traffic. not currently used by non-priority traffic.
As with the MAM model, an operator may map the RDM model onto the As with the MAM, an operator may map the RDM onto the Engineered
Engineered Capacity limits according to different policies. The Capacity limits according to different policies. The operator may
operator may decide to configure the bandwidth available for non- decide to configure the bandwidth available for non-priority use to
priority use to the full engineered capacity limits; As an example, the full engineered capacity limits; As an example, if the engineered
if the engineered capacity limit on a given link is X, the operator capacity limit on a given link is X, the operator may configure the
may configure the bandwidth available to non-priority traffic to X, bandwidth available to non-priority traffic to X, and the bandwidth
and the bandwidth available to non-priority and priority traffic to available to non-priority and priority traffic to 105% of X.
105% of X.
Alternatively, the operator may decide to configure the bandwidth Alternatively, the operator may decide to configure the bandwidth
available to non-priority and priority traffic to the engineered available to non-priority and priority traffic to the engineered
capacity limits; As an example, if the engineered capacity limit on a capacity limits; As an example, if the engineered capacity limit on a
given link is X, the operator may configure the bandwidth available given link is X, the operator may configure the bandwidth available
to non-priority traffic to 95% of X, and the bandwidth available to to non-priority traffic to 95% of X, and the bandwidth available to
non-priority and priority traffic to X. non-priority and priority traffic to X.
Finally, the operator may decide to strike a balance in between. The Finally, the operator may decide to strike a balance in between. The
considerations presented for these policies in the previous section considerations presented for these policies in the previous section
skipping to change at page 27, line 12 skipping to change at page 28, line 8
bandwidth for priority sessions and preclude the utilization of bandwidth for priority sessions and preclude the utilization of
this bandwidth by normal sessions in normal situations this bandwidth by normal sessions in normal situations
o even in congestion periods where priority sessions may be more o even in congestion periods where priority sessions may be more
heavily used, those always still represent a fairly small heavily used, those always still represent a fairly small
proportion of the overall load which can be absorbed within the proportion of the overall load which can be absorbed within the
safety margin of the engineered capacity limits. Thus, even if safety margin of the engineered capacity limits. Thus, even if
they are admitted beyond the engineered bandwidth threshold, they they are admitted beyond the engineered bandwidth threshold, they
are unlikely to result in noticeable QoS degradation. are unlikely to result in noticeable QoS degradation.
As with the MAM and RDM model, an operator may map the Priority As with the MAM and RDM, an operator may map the Priority Bypass
Bypass model onto the Engineered Capacity limits according to model onto the Engineered Capacity limits according to different
different policies. The operator may decide to configure the policies. The operator may decide to configure the bandwidth limit
bandwidth limit for admission of non-priority traffic to the full for admission of non-priority traffic to the full engineered capacity
engineered capacity limits; As an example, if the engineered capacity limits; As an example, if the engineered capacity limit on a given
limit on a given link is X, the operator may configure the bandwidth link is X, the operator may configure the bandwidth limit for non-
limit for non-priority traffic to X. Alternatively, the operator may priority traffic to X. Alternatively, the operator may decide to
decide to configure the bandwidth limit for non-priority traffic to configure the bandwidth limit for non-priority traffic to below the
below the engineered capacity limits (so that the sum of the non- engineered capacity limits (so that the sum of the non-priority and
priority and priority traffic stays below the engineered capacity); priority traffic stays below the engineered capacity); As an example,
As an example, if the engineered capacity limit on a given link is X, if the engineered capacity limit on a given link is X, the operator
the operator may configure the bandwidth limit for non-priority may configure the bandwidth limit for non-priority traffic to 95% of
traffic to 95% of X. Finally, the operator may decide to strike a X. Finally, the operator may decide to strike a balance in between.
balance in between. The considerations presented for these policies The considerations presented for these policies in the previous
in the previous sections in the MAM and RDM contexts are equally sections in the MAM and RDM contexts are equally applicable to the
applicable to the Priority Bypass Model. Priority Bypass Model.
Figure 13 illustrates the bandwidth allocation with the Priority Figure 13 illustrates the bandwidth allocation with the Priority
Bypass Model. Bypass Model.
----------------------- -----------------------
^ ^ | | ^ ^ ^ | | ^
. . | | . . . | | .
Total . . | | . Bandwidth Limit Total . . | | . Bandwidth Limit
(1) (2) | | . (on non-priority + priority) (1) (2) | | . (on non-priority + priority)
Engi- . . | | . for admission Engi- . . | | . for admission
 End of changes. 45 change blocks. 
157 lines changed or deleted 176 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/