draft-ietf-tsvwg-emergency-rsvp-11.txt   draft-ietf-tsvwg-emergency-rsvp-12.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: August 22, 2009 K. Carlberg Expires: November 29, 2009 K. Carlberg
G11 G11
February 18, 2009 May 28, 2009
Resource ReSerVation Protocol (RSVP) Extensions for Emergency Services Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority
draft-ietf-tsvwg-emergency-rsvp-11.txt draft-ietf-tsvwg-emergency-rsvp-12.txt
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 22, 2009. This Internet-Draft will expire on November 29, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
An Emergency Telecommunications Service (ETS) requires the ability to Some applications require the ability to provide an elevated
provide an elevated probability of session establishment to an probability of session establishment to specific sessions in times of
authorized user in times of network congestion (typically, during a network congestion. When supported over the Internet Protocol suite,
crisis). When supported over the Internet Protocol suite, this may this may be facilitated through a network layer admission control
be facilitated through a network layer admission control solution, solution that supports prioritized access to resources (e.g.,
which supports prioritized access to resources (e.g., bandwidth). bandwidth). These resources may be explicitly set aside for
These resources may be explicitly set aside for emergency services, prioritized sessions, or may be shared with other sessions. This
or they may be shared with other sessions. document specifies extensions to the Resource reSerVation Protocol
(RSVP) that can be used to support such an admission priority
This document specifies extensions to the Resource reSerVation capability at the network layer.
Protocol (RSVP) that can be used to support such an admission
priority capability at the network layer. Note that these extensions
represent one possible solution component in satisfying ETS
requirements. Other solution components, or other solutions, are
outside the scope of this document.
The mechanisms defined in this document are applicable to controlled Based on current security concerns, these extensions are targeting
environments. applicability within a single domain.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Related Technical Documents . . . . . . . . . . . . . . . 7 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview of RSVP extensions and Operations . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 8 3.1. Operations of Admission Priority . . . . . . . . . . . . . 7
3. Overview of RSVP extensions and Operations . . . . . . . . . . 8 4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 8
3.1. Operations of Admission Priority . . . . . . . . . . . . . 10 4.1. Admission Priority Policy Element . . . . . . . . . . . . 8
4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10
4.1. Admission Priority Policy Element . . . . . . . . . . . . 12 4.2. Application-Level Resource Priority Policy Element . . . . 11
4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 14
4.2. Application-Level Resource Priority Policy Element . . . . 14
4.2.1. Application-Level Resource Priority Modifying and 4.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 15 Merging Rules . . . . . . . . . . . . . . . . . . . . 12
4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 16 4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. Use of RSVP Authentication between RSVP neighbors . . . . 17 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 13
5.2. Use of INTEGRITY object within the POLICY_DATA object . . 17 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples of Bandwidth Allocation Model for Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 24 Admission Priority . . . . . . . . . . . . . . . . . 19
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 24 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 28 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 31 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 34 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
[RFC3689] and [RFC3690] detail requirements for an Emergency Some applications require the ability to provide an elevated
Telecommunications Service (ETS), which is an umbrella term probability of session establishment to specific sessions in times of
identifying those networks and specific services used to support network congestion.
emergency communications. Deployed examples of these types of
networks are the Government Emergency Telecommunications Systems
(GETS) and the Government Telephone Preference System (GTPS) [NCS]
[RFC4190]. Both of these examples represent enhancements to publicly
accessible systems instead of walled garden or private networks.
An underlying goal of [RFC3689] and [RFC3690] is to present
requirements that elevate the probability of session establishment
from an authorized user in times of network congestion (presumably
because of a crisis condition). In some extreme cases, the
requirement for this probability may reach 100%, but that is a topic
subject to policy and most likely local regulation (the latter being
outside the scope of this document).
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
an example, entities involved in session control (such as SIP user an example, entities involved in session control (such as SIP user
agents, when the Session Initiation Protocol (SIP) [RFC3261], is the agents, when the Session Initiation Protocol (SIP) [RFC3261], is the
session control protocol in use) can influence their treatment of session control protocol in use) can influence their treatment of
session establishment requests (such as SIP requests). This may session establishment requests (such as SIP requests). This may
include the ability to "queue" session establishment requests when include the ability to "queue" session establishment requests when
those can not be immediately honored (in some cases with the notion those can not be immediately honored (in some cases with the notion
skipping to change at page 4, line 46 skipping to change at page 4, line 33
controls, and alternate routing. controls, and alternate routing.
Solutions to meet the requirement for elevated session establishment Solutions to meet the requirement for elevated session establishment
probability may also take advantage of network layer admission probability may also take advantage of network layer admission
control mechanisms supporting admission priority. Networks usually control mechanisms supporting admission priority. Networks usually
have engineered capacity limits that characterize the maximum load have engineered capacity limits that characterize the maximum load
that can be handled (say, on any given link) for a class of traffic that can be handled (say, on any given link) for a class of traffic
while satisfying the quality of service requirements of that traffic while satisfying the quality of service requirements of that traffic
class. Admission priority may involve setting aside some network class. Admission priority may involve setting aside some network
resources (e.g. bandwidth) out of the engineered capacity limits for resources (e.g. bandwidth) out of the engineered capacity limits for
the emergency services only. Or alternatively, it may involve the prioritized sessions only. Or alternatively, it may involve
allowing the emergency related sessions to seize additional resources allowing the prioritized sessions to seize additional resources
beyond the engineered capacity limits applied to normal sessions. beyond the engineered capacity limits applied to normal sessions.
This document specifies the necessary extensions to support such This document specifies the necessary extensions to support such
admission priority when network layer admission control is performed admission priority when network layer admission control is performed
using the Resource reSerVation Protocol (RSVP) ([RFC2205]). using the Resource reSerVation Protocol (RSVP) ([RFC2205]).
IP telephony "calls" are one form of "sessions" that can benefit from [RFC3181] specifies the Signaled Preemption Priority Policy Element
the elevated session establishment probability discussed in this that can be signaled in RSVP so that network node may take into
document. Video over IP and Instant Messaging are other examples. account this policy element in order to preempt some previously
For the sake of generality, we use the term "session" throughout this admitted low priority sessions in order to make room for a newer,
document to refer to any type of session. higher priority session. In contrast, this document specifies new
RSVP extensions to increase the probability of session establishment
1.1. Applicability without preemption of existing sessions. This is achieved by
engineered capacity techniques in the form of bandwidth allocation
The mechanisms defined in this document are applicable to controlled models. In particular this document specifies two new RSVP Policy
environments formed by either a single administrative domain or a set Elements allowing the admission priority to be conveyed inside RSVP
of administrative domains that closely coordinate their network signaling messages so that RSVP nodes can enforce selective bandwidth
policy and network design. The mechanisms defined in this document admission control decision based on the session admission priority.
can be used for a session whose path spans over such a controlled Appendix A of this document also provides examples of bandwidth
environment where network layer admission control mechanisms are allocation models which can be used by RSVP-routers to enforce such
used, in order to elevate the session establishment probability admission priority on every link. A given reservation may be
through the controlled environment (thereby elevating the end to end signaled with the admission priority extensions specified in the
session establishment probability). Let us consider the end to end present document, with the preemption priority specified in [RFC3181]
environment illustrated in Figure 1 that comprises three separate or with both.
administrative domains, each with 2 endpoints and each with Session
Border Controller (SBC) elements ([I-D.ietf-sipping-sbc-funcs])
handling session handover at the domain boundaries.
+----------+ +----------+ +----------+
|Endpoint 1| |Endpoint 3| |Endpoint 5|
+----------+ +----------+ +----------+
| | |
| | |
+----+ +----+ +----+
|SBC | |SBC | |SBC |
,| |--. ,-| |-. ,| |-.
,' +----+ `. ,' +----+ ` . ,' +----+ \
/ ISP \ / ISP \ / ISP `.
/ Domain +----+ +----+ Domain +----+ +----+ Domain \
( A |+----+ |+----+ B |+----+ |+----+ C )
\(Controlled)||SBC |--||SBC |(Controlled)||SBC |--||SBC |(Controlled)/
\ +| | +| | +| | +| | /
`. +----+ +----+ +----+ +----+ .'
'+----+--' `. +----+ .' '--+----+--'
| | '--| |--' | |
|SBC | |SBC | |SBC |
+----+ +----+ +----+
| | |
| | |
+----------+ +----------+ +----------+
|Endpoint 2| |Endpoint 4| |Endpoint 6|
+----------+ +----------+ +----------+
Figure 1: Example End to End Environment
Each domain is operating as a separate controlled environment and may
deploy a given combination of network mechanisms and network policies
within the given domain. For example, ISP Domain A , ISP Domain B
and ISP Domain C may each deploy a different Differentiated Services
([RFC2475]) policy in-between their own SBCs. As another example,
ISP Domain B may elect to deploy MPLS Traffic Engineering ([RFC2702])
within its domain while ISP Domain A and C may not. Similarly, each
domain administrator can make its own decision about whether to
deploy network layer admission control within his domain. If one
domain elects to do so, this can be achieved using RSVP signaling
between the ingress and egress SBC elements of that domain (i.e.,
RSVP signaling operates edge-to-edge and not end-to-end). With this
approach, network layer admission control may be deployed in one
domain regardless of whether it is deployed in the other domains on
the end to end path of sessions. Also, deploying network layer
admission control within one domain does not require any
collaboration or even pre-agreement with other domains since it
operates transparently from other domains (the only externally
visible impact might be on quality of service offered to the sessions
that transit through that domain). The mechanisms defined in this
document are applicable within a controlled environment that elects
to deploy network layer admission control using RSVP and handles
emergency communications. For example, ISP domain A and ISP domain C
may elect to use RSVP and the extensions defined in this document
within their respective domain while ISP domain B may not deploy
network layer admission control within his domain. In that case, a
session between Endpoint 1 and Endpoint 6 would benefit from network
layer admission control and resource reservation through domain A
network and domain C network. If that session is an emergency
session, the extensions defined in this document increase the
probability of admission of that particular session through domain A
and domain C, thereby increasing the end-to-end session establishment
probability.
As another example, all three domains shown in Figure 1 may elect to
deploy RSVP admission control and the extensions defined in this
document within their own domain. This would ensure that emergency
sessions are protected by resource reservation and elevated session
establishment probability through every domain on the end to end
path. But even in that case, RSVP signaling and the extensions
defined in this document need not operate end-to-end; rather they are
expected to operate edge-to-edge within each domain only (with RSVP
being terminated by the egress SBC on the egress edge of one domain
and regenerated by the ingress SBC on the ingress edge of the next
domain).
1.2. Related Technical Documents
[RFC4542] is patterned after [ITU.I.225] and describes an example of
one type of prioritized network layer admission control procedure
that may be used for emergency services operating over an IP network
infrastructure. It discusses initial session set up, as well as
operations after session establishment through maintenance of a
continuing call model of the status of all sessions. [RFC4542] also
describes how these network layer admission control procedures can be
realized using the Resource reSerVation Protocol [RFC2205] along with
its associated protocol suite and extensions, including those for
policy based admission control ([RFC2753], [RFC2750]), for user
authentication and authorization ([RFC3182]) and for integrity and
authentication of RSVP messages ([RFC2747], [RFC3097]). The Diameter
QoS Application ([I-D.ietf-dime-diameter-qos]) allows network
elements to interact with Diameter servers when allocating QoS
resources in the network and thus, is also a possible method for
authentication and authorization of RSVP reservations in the context
of emergency services.
[RFC4542] describes how the RSVP Signaled Preemption Priority Policy Based on current security concerns, these extensions are targeting
Element specified in [RFC3181] can be used to enforce the session applicability within a single domain.
preemption that may be needed by some emergency services. In
contrast to [RFC4542], this document specifies new RSVP extensions to
increase the probability of session establishment without preemption.
Engineered capacity techniques in the form of bandwidth allocation
models are used to satisfy the "admission priority" required by an
RSVP capable ETS network. In particular this document specifies two
new RSVP Policy Elements allowing the admission priority to be
conveyed inside RSVP signaling messages so that RSVP nodes can
enforce selective bandwidth admission control decision based on the
session admission priority. Appendix A of this document also
provides examples of bandwidth allocation models which can be used by
RSVP-routers to enforce such admission priority on every link.
1.3. 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.
skipping to change at page 8, line 42 skipping to change at page 5, line 39
[RFC2753]. [RFC2753].
2. Requirements Language 2. 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 3. Overview of RSVP extensions and Operations
Let us consider the case where a session requiring ETS type service Let us consider the case where a session requires elevated
is to be established, and more specifically that the preference to be probability of establishment, and more specifically that the
granted to this session is in terms of network layer "admission preference to be granted to this session is in terms of network layer
priority" (as opposed to preference granted through preemption of "admission priority" (as opposed to preference granted through
existing sessions). By "admission priority" we mean allowing that preemption of existing sessions). By "admission priority" we mean
priority session to seize network layer resources from the engineered allowing the priority session to seize network layer resources from
capacity that have been set-aside and not made available to normal the engineered capacity that has been set-aside for priority sessions
sessions, or alternatively by allowing that session to seize (and not made available to normal sessions), or alternatively
additional resources beyond the engineered capacity limits applied to allowing the priority session to seize additional resources beyond
normal sessions. the engineered capacity limits applied to normal sessions.
As described in [RFC4542], the session establishment can be Session establishment can be conditioned to resource-based and
conditioned to resource-based and policy-based network layer policy-based network layer admission control achieved via RSVP
admission control achieved via RSVP signaling. In the case where the signaling. In the case where the session control protocol is SIP,
session control protocol is SIP, the use of RSVP-based admission the use of RSVP-based admission control in conjunction with SIP is
control by SIP is specified in [RFC3312]. specified in [RFC3312].
Devices involved in the session establishment are expected to be Devices involved in the session establishment are expected to be
aware of the application-level priority requirements of emergency aware of the application-level priority requirements of prioritized
sessions. Again considering the case where the session control sessions. For example, considering the case where the session
protocol is SIP, the SIP user agents can be made aware of the control protocol is SIP, the SIP user agents may be made aware of the
resource priority requirements in the case of an emergency session resource priority requirements of a given session using the
using the Resource-Priority Header mechanism specified in [RFC4412]. "Resource-Priority" header mechanism specified in [RFC4412]. The
The end-devices involved in the upper-layer session establishment end-devices involved in the upper-layer session establishment simply
simply need to copy the application-level resource priority need to copy the application-level resource priority requirements
requirements (e.g. as communicated in SIP Resource-Priority Header) (e.g. as communicated in SIP "Resource-Priority" header) inside the
inside the new RSVP Application-Level Resource-Priority Policy new RSVP Application-Level Resource Priority Policy Element defined
Element defined in this document. in this document.
Conveying the application-level resource priority requirements inside Conveying the application-level resource priority requirements inside
the RSVP message allows this application level requirement to be the RSVP message allows this application level requirement to be
mapped/remapped into a different RSVP "admission priority" at every mapped/remapped into a different RSVP "admission priority" at a
administrative domain boundary based on the policy applicable in that policy boundary based on the policy applicable in that policy area.
domain. In a typical model (see [RFC2753]) where PDPs control PEPs In a typical model (see [RFC2753]) where PDPs control PEPs at the
at the periphery of the policy domain (e.g., in border routers), PDPs periphery of the policy area (e.g. on the first hop router), PDPs
would interpret the RSVP Application-Level Resource-Priority Policy would interpret the RSVP Application-Level Resource Priority Policy
Element and map the requirement of the emergency session into an RSVP Element and map the requirement of the prioritized session into an
"admission priority" level. Then, PDPs would convey this information RSVP "admission priority" level. Then, PDPs would convey this
inside the new Admission Priority Policy Element defined in this information inside the new Admission Priority Policy Element defined
document. This way, the RSVP admission priority can be communicated in this document. This way, the RSVP admission priority can be
to downstream PEPs (i.e. RSVP Routers) of the same policy domain, communicated to downstream PEPs (i.e. RSVP Routers) of the same
which have LPDPs but no controlling PDP. In turn, this means the policy domain, which have LPDPs but no controlling PDP. In turn,
necessary RSVP Admission priority can be enforced at every RSVP hop, this means the necessary RSVP Admission priority can be enforced at
including all the (many) hops which do not have any understanding of every RSVP hop, including all the (possibly many) hops which do not
Application-Level Resource-Priority semantics. have any understanding of Application-Level Resource Priority
semantics. It is not expected that the RSVP Application-Level
As an example of operation across multiple administrative domains, a Resource Priority Header Policy Element would be taken into account
first domain might decide to provide network layer admission priority at RSVP-hops within a given policy area. It is expected to be used
to sessions of a given Application Level Resource Priority and map it at policy area boundaries only in order to set/reset the RSVP
into a high RSVP admission control priority inside the Admission Admission Priority Policy Element.
Priority Policy Element; while a second domain may decide to not
provide admission priority to sessions of this same Application Level
Resource Priority and hence map it into a low RSVP admission control
priority.
As another example of operation across multiple administrative
domains, we can consider the case where the resource priority header
enumerates several namespaces, as explicitly allowed by [RFC4412],
for support of scenarios where sessions traverse multiple
administrative domains using different namespace. In that case, the
relevant namespace can be used at each domain boundary to map into an
RSVP Admission priority for that domain. It is not expected that the
RSVP Application-Level Resource-Priority Header Policy Element would
be taken into account at RSVP-hops within a given administrative
domain. It is expected to be used at administrative domain
boundaries only in order to set/reset the RSVP Admission Priority
Policy Element.
The existence of pre-established inter-domain policy agreements or
Service Level Agreements may avoid the need to take real-time action
at administrative domain boundaries for mapping/remapping of
admission priorities.
Mapping/remapping by PDPs may also be applied to boundaries between Remapping by PDPs of the Admission Priority Policy Element from the
various signaling protocols, such as those advanced by the NSIS Application-Level Resource Priority Policy Element may also be used
working group. at boundaries with other signaling protocols, such as the NSIS
Signaling Layer Protocol (NSLP) for QoS Signaling
([I-D.ietf-nsis-qos-nslp]).
As can be observed, the framework described above for mapping/ As can be observed, the framework described above for mapping/
remapping application level resource priority requirements into an remapping application level resource priority requirements into an
RSVP admission priority can also be used together with [RFC3181] for RSVP admission priority can also be used together with [RFC3181] for
mapping/remapping application level resource priority requirements mapping/remapping application level resource priority requirements
into an RSVP preemption priority (when preemption is indeed needed). into an RSVP preemption priority (when preemption is indeed deemed
In that case, when processing the RSVP Application-Level Resource- necessary by the priotized session handling policy). In that case,
Priority Policy Element, the PDPs at boundaries between when processing the RSVP Application-Level Resource Priority Policy
administrative domains (or between various QoS signaling protocols) Element, the PDPs at policy boundaries (or between various QoS
can map it into an RSVP "preemption priority" information. This signaling protocols) can map it into an RSVP "preemption priority"
Preemption priority information comprises a setup preemption level information. This Preemption priority information comprises a setup
and a defending preemption priority level. This preemption priority preemption level and a defending preemption priority level that can
information can then be encoded inside the Preemption Priority Policy then be encoded inside the Preemption Priority Policy Element of
Element of [RFC3181] and thus, can be taken into account at every [RFC3181].
RSVP-enabled network hop as discussed [RFC4542]. Appendix B provides
examples of various hypothetical policies for emergency session Appendix B provides examples of various hypothetical policies for
handling, some of them involving admission priority, some of them prioritized session handling, some of them involving admission
involving both admission priority and preemption priority. Appendix priority, some of them involving both admission priority and
B also identifies how the Application-Level Resource Priority need to preemption priority. Appendix B also identifies how the Application-
be mapped into RSVP policy elements by the PDPs to realize these Level Resource Priority needs to be mapped into RSVP policy elements
policies. by the PDPs to realize these policies.
3.1. Operations of Admission Priority 3.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 an allows admission bandwidth to be allocated preferentially to
authorized priority service. Multiple models of bandwidth allocation prioritized sessions. Multiple models of bandwidth allocation MAY be
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
[RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127] and [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127] and
the Maximum Allocation model with Reservation (MAR) defined in the Maximum Allocation model with Reservation (MAR) defined in
[RFC4126]. These same models MAY however be applied for allocation [RFC4126]. These same models MAY however be applied for allocation
of bandwidth across different levels of admission priority as defined of bandwidth across different levels of admission priority as defined
in this document. Appendix A provides an illustration of how these in this document. Appendix A provides an illustration of how these
bandwidth allocation models can be applied for such purposes and bandwidth allocation models can be applied for such purposes and also
introduces an additional bandwidth allocation model that we term the introduces an additional bandwidth allocation model that we term the
Priority Bypass Model (PrBM). It is important to note that the Priority Bypass Model (PrBM). It is important to note that the
models described and illustrated in Appendix A are only informative models described and illustrated in Appendix A are only informative
and do not represent a recommended course of action. and do not represent a recommended course of action.
We can see in these examples, that the RSVP Admission Priority may We can see in these examples how the RSVP Admission Priority can be
effectively influence the fundamental admission control decision of used by RSVP routers to influence their admission control decision
RSVP (for example by determining which bandwidth pool is to be used (for example by determining which bandwidth pool is to be used by
by RSVP for performing its fundamental bandwidth allocation). In RSVP for performing its bandwidth allocation) and therefore to
that sense, we observe that the policy control and admission control increase the probability of reservation establishment. In turn, this
are not separate logics but instead somewhat blended. increases the probability of application level session establishment
for the corresponding session.
4. New Policy Elements 4. 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 2 of the present document, the Application- As described in Section 3 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 12, line 17 skipping to change at page 8, line 42
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 4.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 2: 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 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved |Adm. Priority| | Reserved |Adm. Priority|
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Figure 2: Admission Priority Policy Element Figure 1: Admission Priority Policy Element
where: where:
o Length: 16 bits o Length: 16 bits
* Always 12. The overall length of the policy element, in bytes. * Always 12. The overall length of the policy element, in bytes.
o P-Type: 16 bits o P-Type: 16 bits
* ADMISSION_PRI = To be allocated by IANA (see "IANA * ADMISSION_PRI = To be allocated by IANA (see "IANA
Considerations" section) Considerations" section)
o Flags: Reserved o Flags: Reserved
* 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 Merge Strategy: 8 bits (only applicable to multicast flows) o Merge Strategy: 8 bits (applicable to multicast flows)
* values are defined by corresponding registry maintained by IANA * values are defined by corresponding registry maintained by IANA
(see "IANA Considerations" section) (see "IANA Considerations" section)
o Error code: 8 bits (only applicable to multicast flows)
o Error code: 8 bits (applicable to multicast flows)
* values are defined by corresponding registry maintained by IANA * values are defined by corresponding registry maintained by IANA
(see "IANA Considerations" section) (see "IANA Considerations" section)
o Reserved: 8 bits o Reserved: 8 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 Reserved: 24 bits o Reserved: 24 bits
skipping to change at page 13, line 18 skipping to change at page 10, line 4
o Reserved: 8 bits o Reserved: 8 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 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. A given Admission Priority is encoded in this
information element using the same value as when encoded in the information element using the same value as when encoded in the
"Admission Priority" field of the "Admission Priority" "Admission Priority" field of the "Admission Priority"
parameter defined in [I-D.ietf-nsis-qspec], or in the parameter defined in [I-D.ietf-nsis-qspec]. In other words, a
"Admission Priority" parameter defined in given value inside the Admission Priority information element
[I-D.ietf-dime-qos-parameters]. In other words, a given value defined in the present document or inside the
inside the Admission Priority information element defined in [I-D.ietf-nsis-qspec] Admission Priority field refers to the
the present document, inside the [I-D.ietf-nsis-qspec] same admission priority. Bandwidth allocation models such as
Admission Priority field or inside the those described in Appendix A are to be used by the RSVP router
[I-D.ietf-dime-qos-parameters] Admission Priority parameter, to achieve such increased probability of session establishment.
refers to the same admission priority. Bandwidth allocation The admission priority value effectively indicates which
models such as those described in Appendix A are to be used by bandwidth constraint(s) of the bandwidth constraint model in
the RSVP router to achieve such increased probability of use is(are) applicable to admission of this RSVP reservation.
session establishment. The admission priority value
effectively indicates which bandwidth constraint(s) of the
bandwidth constraint model in use is(are) 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 4.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 is only priority in case of merging of reservations. As merging applies to
applicable to multicast, this section also only applies to multicast multicast, this section also applies to multicast sessions.
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. The merge strategies (and
associated values) defined by the present document are the same as associated values) defined by the present document are the same as
those defined in [RFC3181] for merging Preemption Priority Policy those defined in [RFC3181] for merging Preemption Priority Policy
Elements (see "IANA Considerations" section). Elements (see "IANA Considerations" section).
The only difference with [RFC3181] is that this document does not The only difference with [RFC3181] is that this document does not
recommend any merge strategies for Admission Priority, while recommend any merge strategies for Admission Priority, while
[RFC3181] recommends the first of these merge strategies for [RFC3181] recommends the first of these merge strategies for
Preemption Priority. Note that with the Admission Priority (as is Preemption Priority. Note that with the Admission Priority (as is
the case with the Preemption Priority), "Take highest priority" the case with the Preemption Priority), "Take highest priority"
translates into "take the highest numerical value". translates into "take the highest numerical value".
4.2. Application-Level Resource Priority Policy Element 4.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 3: 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 //
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Figure 3: Application-Level Resource Priority Policy Element Figure 2: Application-Level Resource Priority Policy Element
where: where:
o Length: o Length:
* The length of the policy element (including the Length and * The length of the policy element (including the Length and
P-Type) is in number of octets (MUST be a multiple of 4) and P-Type) is in number of octets (MUST be a multiple of 4) and
indicates the end of the ALRP list. indicates the end of the ALRP list.
o P-Type: 16 bits o P-Type: 16 bits
skipping to change at page 15, line 4 skipping to change at page 11, line 32
o Length: o Length:
* The length of the policy element (including the Length and * The length of the policy element (including the Length and
P-Type) is in number of octets (MUST be a multiple of 4) and P-Type) is in number of octets (MUST be a multiple of 4) and
indicates the end of the ALRP list. indicates the end of the ALRP list.
o P-Type: 16 bits o P-Type: 16 bits
* APP_RESOURCE_PRI = To be allocated by IANA (see "IANA * APP_RESOURCE_PRI = To be allocated by IANA (see "IANA
Considerations" section) Considerations" section)
o ALRP List: o ALRP List:
* List of ALRP where each ALRP is encoded as shown in Figure 4. * List of ALRP where each ALRP is encoded as shown in Figure 3.
ALRP: ALRP:
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
+---------------------------+-------------+-------------+ +---------------------------+-------------+-------------+
| ALRP Namespace | Reserved |ALRP Priority| | ALRP Namespace | Reserved |ALRP Value |
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Figure 4: Application-Level Resource Priority Figure 3: Application-Level Resource Priority
where: where:
o ALRP Namespace (Application-Level Resource Priority Namespace): 16 o ALRP Namespace (Application-Level Resource Priority Namespace): 16
bits (unsigned) bits (unsigned)
* Contains a numerical value identifying the namespace of the * Contains a numerical value identifying 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 Namespaces" IANA registry. (See per the "Resource Priority Namespaces" 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).
o Reserved: 8 bits o Reserved: 8 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 ALRP Priority: (Application-Level Resource Priority Priority): 8 o ALRP Value: (Application-Level Resource Priority Value): 8 bits
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 4.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 list o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST
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 is only applicable to Multicast, this rule only applies to As merging applies to Multicast, this rule also applies to Multicast
Multicast sessions. sessions.
4.3. Default Handling 4.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 this document. traverse policy-capable nodes that do not support thes extensions
defined in the present document.
5. Security Considerations 5. 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]. [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches
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]). However, some network administrators (RAO)([RFC2113],[RFC2711]). The security aspects and common
activate mechanisms at the edge of their administrative domain to practices around the use of the current IP Router Alert option and
protect against potential Denial Of Service (DOS) attacks associated consequences on the use of IP Router Alert by applications such as
with RAO. This may include hiding of the RAO to downstream interior RSVP are discussed in [I-D.rahman-rtg-router-alert-considerations].
routers in the domain (as recommended by default over an MPLS network As mentioned earlier, based on current security concerns (some of
in [I-D.dasmith-mpls-ip-options]) or complete blocking of packets them associated with RAO), the extensions defined in this document
received with RAO at the administrative boundary. As the mechanisms are targeting applicability within a single domain.
defined in this document rely on RSVP, their usage assume that such
protection against RAO packets are not activated in a way that
prevents RSVP processing on relevant interfaces or routers of the
controlled environments electing to deploy these mechanisms.
Nonetheless, it is recommended that protection mechanisms be
activated against potential DOS attacks through RAO even when RAO
message are processed. This may include rate limiting of incoming
RAO packets (e.g. at interface and/or router level). This may also
include deploying an RSVP architecture whereby interior routers are
not exposed to any RSVP messages associated with end to end
reservations (such as the architecture defined in
[I-D.ietf-tsvwg-rsvp-l3vpn]). We observe that the risks and security
measures associated with processing of RAO messages at an
administrative domain edge are fundamentally similar to those
involved with other forms of control plane interactions allowed at
administrative domain edges, such as routing or multicast routing
interactions allowed between a customer and his Internet Service
Provider, MPLS VPN ( [RFC4364] Service Provider , [RFC4659]) or MPLS
MVPN ([I-D.ietf-l3vpn-2547bis-mcast]) Service Provider.
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 5.1. Use of RSVP Authentication between RSVP neighbors
This mechanism can be used between RSVP neighbors that are policy RSVP authentication can be used between RSVP neighbors that are
capable. The RSVP neighbors use shared keys to compute the policy capable. RSVP Authentication (defined in [RFC2747] and
cryptographic signature of the RSVP message. [RFC3097]) SHOULD be supported by an implementation of the present
document.
With RSVP authentication, the RSVP neighbors use shared keys to
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 5.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. guarantee integrity between non-neighboring RSVP PEPs. This is
useful only when some RSVP nodes are Policy Ignorant Nodes (PINs).
The INTEGRITY object within the POLICY_DATA object MAY be supported
by an implementation of teh 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
PEP/PDP or other criteria, selects an Authentication Key and the hash PEP/PDP or other criteria, selects an Authentication Key and the hash
algorithm to be used. Keys to be used between PDPs can be algorithm to be used. Keys to be used between PDPs can be
distributed manually or via standard key management protocol for distributed manually or via standard key management protocol for
secure key distribution. secure key distribution.
Note that where non-RSVP hops may exist in between RSVP hops, as well Note that where non-RSVP hops may exist in between RSVP hops, as well
skipping to change at page 19, line 23 skipping to change at page 15, line 41
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 3.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 Namespace 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
o the title of the new column should be "Namespace Numerical Value o the title of the new column should be "Namespace Numerical Value
*" *"
o in the Legend, add a line saying "Namespace Numerical Value = the o in the Legend, add a line saying "Namespace Numerical Value = the
unique numerical value identifying the namespace" unique numerical value identifying the namespace"
o add a line at the bottom of the registry stating the following "* o add a line at the bottom of the registry stating the following "*
: [RFCXXX] " where XXX is the RFC number of the present document : [RFCXXX] " where XXX is the RFC number of the present document
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 namespace. Then, in the future, IANA should automatically existing namespace. 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
skipping to change at page 20, line 48 skipping to change at page 17, line 18
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 7. 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. Thanks to Magnus Westerlund, Cullen Jennings and into this document. Ron Bonica, Magnus Westerlund, Cullen Jennings,
Ross Callon for helping clarify applicability of the mechanisms and Ross Callon provided specific guidance for the applicability
defined in this document. statement of the mechanisms defined in this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[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.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[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.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", [RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000. RFC 2750, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001. RFC 3181, October 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
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 8.2. Informative References
[I-D.dasmith-mpls-ip-options] [I-D.ietf-nsis-qos-nslp]
Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
"Requirements for Label Edge Router Forwarding of IPv4 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16
Option Packets", draft-dasmith-mpls-ip-options-01 (work in (work in progress), February 2008.
progress), October 2008.
[I-D.ietf-dime-diameter-qos]
Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,
and G. Zorn, "Diameter Quality of Service Application",
draft-ietf-dime-diameter-qos-07 (work in progress),
December 2008.
[I-D.ietf-dime-qos-parameters]
Korhonen, J., Tschofenig, H., and E. Davies, "Quality of
Service Parameters for Usage with Diameter",
draft-ietf-dime-qos-parameters-09 (work in progress),
January 2009.
[I-D.ietf-l3vpn-2547bis-mcast]
Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work
in progress), July 2008.
[I-D.ietf-nsis-qspec] [I-D.ietf-nsis-qspec]
Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
Template", draft-ietf-nsis-qspec-21 (work in progress), Template", draft-ietf-nsis-qspec-21 (work in progress),
November 2008. November 2008.
[I-D.ietf-sipping-sbc-funcs]
Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen,
A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments",
draft-ietf-sipping-sbc-funcs-08 (work in progress),
January 2009.
[I-D.ietf-tsvwg-rsvp-l3vpn]
Davie, B., Faucheur, F., and A. Narayanan, "Support for
RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-01
(work in progress), November 2008.
[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-02 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-04 (work in
progress), November 2008. progress), March 2009.
[NCS] "GETS Home Page", <http://gets.ncs.gov>. [I-D.rahman-rtg-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage",
draft-rahman-rtg-router-alert-considerations-01 (work in
progress), March 2009.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
and W. Weiss, "An Architecture for Differentiated February 1997.
Services", RFC 2475, December 1998.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2711, October 1999.
RFC 2702, September 1999.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, for Policy-based Admission Control", RFC 2753,
January 2000. January 2000.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S., and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for
Emergency Telecommunication Service (ETS)", RFC 3689,
February 2004.
[RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
for Emergency Telecommunication Service (ETS)", RFC 3690,
February 2004.
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic Constraints Model for Diffserv-aware MPLS Traffic
Engineering", RFC 4125, June 2005. Engineering", RFC 4125, June 2005.
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic Constraints Model for Diffserv-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126, Engineering & Performance Comparisons", RFC 4126,
June 2005. June 2005.
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering", Model for Diffserv-aware MPLS Traffic Engineering",
RFC 4127, June 2005. RFC 4127, June 2005.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005. Properties", RFC 4230, December 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency
Telecommunications Service (ETS) for Real-Time Services in
the Internet Protocol Suite", RFC 4542, May 2006.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006.
Appendix A. Examples of Bandwidth Allocation Model for Admission Appendix A. Examples of Bandwidth Allocation Model for Admission
Priority Priority
Sections A.1 and A.2 respectively illustrate how the Maximum Sections A.1 and A.2 respectively illustrate how the Maximum
Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM) Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM)
([RFC4127]) can be used for support of admission priority. The ([RFC4127]) can be used for support of admission priority. The
Maximum Allocation model with Reservation (MAR) ([RFC4126]) could Maximum Allocation model with Reservation (MAR) ([RFC4126]) could
also be used in a similar manner for support of admission priority. also be used in a similar manner for support of admission priority.
Section A.3 illustrates how a simple "Priority Bypass Model" can also Section A.3 illustrates how a simple "Priority Bypass Model" can also
be used for support of admission priority. be used for support of admission priority.
skipping to change at page 25, line 21 skipping to change at page 20, line 23
neered .or.or. | | . neered .or.or. | | .
. . . | | . . . . | | .
Capacity. . . | | . Capacity. . . | | .
v . . | | v v . . | | v
. . |--------------| --- . . |--------------| ---
v . | | ^ v . | | ^
. | | . Bandwidth available for . | | . Bandwidth available for
v | | v priority use v | | v priority use
------------------------- -------------------------
Figure 5: MAM Bandwidth Allocation Figure 4: MAM Bandwidth Allocation
Figure 5 shows a link within a routed network conforming to this Figure 4 shows a link within a routed network conforming to this
document. On this link are two amounts of bandwidth available to two document. On this link are two amounts of bandwidth available to two
types of traffic: non-priority and priority. types of traffic: non-priority and priority.
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 5, an operator may map the MAM model onto As illustrated in Figure 4, an operator may map the MAM model onto
the Engineered Capacity limits according to different policies. At the Engineered Capacity limits according to different policies. At
one extreme, where the proportion of priority traffic is reliably one extreme, where the proportion of priority traffic is reliably
known to be fairly small at all times and where there may be some known to be fairly small at all times and where there may be some
safety margin factored in the engineered capacity limits, the safety margin factored in the engineered capacity limits, the
operator may decide to configure the bandwidth available for non- operator may decide to configure the bandwidth available for non-
priority use to the full engineered capacity limits; effectively priority use to the full engineered capacity limits; effectively
allowing the priority traffic to ride within the safety margin of allowing the priority traffic to ride within the safety margin of
this engineered capacity. This policy can be seen as an economically this engineered capacity. This policy can be seen as an economically
attractive approach as all of the engineered capacity is made attractive approach as all of the engineered capacity is made
available to non-priority sessions. This policy is illustrated as available to non-priority sessions. This policy is illustrated as
(1) in Figure 5. As an example, if the engineered capacity limit on (1) in Figure 4. As an example, if the engineered capacity limit on
a given link is X, the operator may configure the bandwidth available a given link is X, the operator may configure the bandwidth available
to non-priority traffic to X, and the bandwidth available to priority to non-priority traffic to X, and the bandwidth available to priority
traffic to 5% of X. At the other extreme, where the proportion of traffic to 5% of X. At the other extreme, where the proportion of
priority traffic may be significant at times and the engineered priority traffic may be significant at times and the engineered
capacity limits are very tight, the operator may decide to configure capacity limits are very tight, the operator may decide to configure
the bandwidth available to non-priority traffic and the bandwidth the bandwidth available to non-priority traffic and the bandwidth
available to priority traffic such that their sum is equal to the available to priority traffic such that their sum is equal to the
engineered capacity limits. This guarantees that the total load engineered capacity limits. This guarantees that the total load
across non-priority and priority traffic is always below the across non-priority and priority traffic is always below the
engineered capacity and, in turn, guarantees there will never be any engineered capacity and, in turn, guarantees there will never be any
QoS degradation. However, this policy is less attractive QoS degradation. However, this policy is less attractive
economically as it prevents non-priority sessions from using the full economically as it prevents non-priority sessions from using the full
engineered capacity, even when there is no or little priority load, engineered capacity, even when there is no or little priority load,
which is the majority of time. This policy is illustrated as (3) in which is the majority of time. This policy is illustrated as (3) in
Figure 5. As an example, if the engineered capacity limit on a given Figure 4. As an example, if the engineered capacity limit on a given
link is X, the operator may configure the bandwidth available to non- link is X, the operator may configure the bandwidth available to non-
priority traffic to 95% of X, and the bandwidth available to priority priority traffic to 95% of X, and the bandwidth available to priority
traffic to 5% of X. Of course, an operator may also strike a balance traffic to 5% of X. Of course, an operator may also strike a balance
anywhere in between these two approaches. This policy is illustrated anywhere in between these two approaches. This policy is illustrated
as (2) in Figure 5. as (2) in Figure 4.
Figure 6 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
neered .or.or. |xxxxxxxxxxxxxx| . neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| . Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v v . . |xxxxxxxxxxxxxx| v
. . |--------------| --- . . |--------------| ---
v . | | ^ v . | | ^
. | | . Bandwidth available for . | | . Bandwidth available for
v | | v priority use v | | v priority use
------------------------- -------------------------
Figure 6: Partial load of non-priority calls Figure 5: Partial load of non-priority calls
Figure 7 shows the same amount of non-priority load being used at Figure 6 shows the same amount of non-priority load being used at
this link, and a small amount of priority bandwidth being used. this link, and a small amount of priority bandwidth being used.
----------------------- -----------------------
^ ^ ^ | | ^ ^ ^ ^ | | ^
. . . | | . . . . | | .
Total . . . | | . Bandwidth Total . . . | | . Bandwidth
. . . | | . Available . . . | | . Available
Engi- . . . | | . for non-priority use Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| . neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| . Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v v . . |xxxxxxxxxxxxxx| v
. . |--------------| --- . . |--------------| ---
v . | | ^ v . | | ^
. | | . Bandwidth available for . | | . Bandwidth available for
v |oooooooooooooo| v priority use v |oooooooooooooo| v priority use
------------------------- -------------------------
Figure 7: Partial load of non-priority calls & partial load of Figure 6: Partial load of non-priority calls & partial load of
priority calls Calls priority calls Calls
Figure 8 shows the case where non-priority load equates or exceeds Figure 7 shows the case where non-priority load equates or exceeds
the maximum bandwidth available to non-priority traffic. Note that the maximum bandwidth available to non-priority traffic. Note that
additional non-priority sessions would be rejected even if the additional non-priority sessions would be rejected even if the
bandwidth reserved for priority sessions is not fully utilized. bandwidth reserved for priority sessions is not fully utilized.
----------------------- -----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^ ^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . Available . . . |xxxxxxxxxxxxxx| . Available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| . neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| . Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v v . . |xxxxxxxxxxxxxx| v
. . |--------------| --- . . |--------------| ---
v . | | ^ v . | | ^
. | | . Bandwidth available for . | | . Bandwidth available for
v |oooooooooooooo| v priority use v |oooooooooooooo| v priority use
------------------------- -------------------------
Figure 8: Full non-priority load & partial load of priority calls Figure 7: Full non-priority load & partial load of priority calls
Figure 9 shows the case where the priority traffic equates or exceeds Figure 8 shows the case where the priority traffic equates or exceeds
the bandwidth reserved for such priority traffic. the bandwidth reserved for such priority traffic.
In that case additional priority sessions could not be accepted. In that case additional priority sessions could not be accepted.
Note that this does not mean that such sessions are dropped Note that this does not mean that such sessions are dropped
altogether: they may be handled by mechanisms, which are beyond the altogether: they may be handled by mechanisms, which are beyond the
scope of this particular document (such as establishment through scope of this particular document (such as establishment through
preemption of existing non-priority sessions, or such as queuing of preemption of existing non-priority sessions, or such as queuing of
new priority session requests until capacity becomes available again new priority session requests until capacity becomes available again
for priority traffic). for priority traffic).
skipping to change at page 28, line 25 skipping to change at page 23, line 25
neered .or.or. |xxxxxxxxxxxxxx| . neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Capacity. . . | | . Capacity. . . | | .
v . . | | v v . . | | v
. . |--------------| --- . . |--------------| ---
v . |oooooooooooooo| ^ v . |oooooooooooooo| ^
. |oooooooooooooo| . Bandwidth available for . |oooooooooooooo| . Bandwidth available for
v |oooooooooooooo| v priority use v |oooooooooooooo| v priority use
------------------------- -------------------------
Figure 9: 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 model, an operator may map the RDM model onto the
skipping to change at page 29, line 7 skipping to change at page 24, line 7
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
in the MAM context are equally applicable to RDM. in the MAM context are equally applicable to RDM.
Figure 10 shows the case where only some of the bandwidth available Figure 9 shows the case where only some of the bandwidth available to
to non-priority traffic is being used and a small amount of priority non-priority traffic is being used and a small amount of priority
traffic is in place. In that situation both new non-priority traffic is in place. In that situation both new non-priority
sessions and new priority sessions would be accepted. sessions and new priority sessions would be accepted.
-------------------------------------- --------------------------------------
|xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . Available for . |xxxxxxxxxxxxxx| . Available for .
|xxxxxxxxxxxxxx| . non-priority . |xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth |xxxxxxxxxxxxxx| . . Bandwidth
| | . . available for | | . . available for
| | v . non-priority | | v . non-priority
|--------------| --- . and priority |--------------| --- . and priority
| | . use | | . use
| | . | | .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Figure 10: Partial non-priority load & Partial Aggregate load Figure 9: Partial non-priority load & Partial Aggregate load
Figure 11 shows the case where all of the bandwidth available to non- Figure 10 shows the case where all of the bandwidth available to non-
priority traffic is being used and a small amount of priority traffic priority traffic is being used and a small amount of priority traffic
is in place. In that situation new priority sessions would be is in place. In that situation new priority sessions would be
accepted but new non-priority sessions would be rejected. accepted but new non-priority sessions would be rejected.
-------------------------------------- --------------------------------------
|xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . Available for . |xxxxxxxxxxxxxx| . Available for .
|xxxxxxxxxxxxxx| . non-priority . |xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth |xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for |xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority |xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority |--------------| --- . and priority
| | . use | | . use
| | . | | .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Figure 11: Full non-priority load & Partial Aggregate load Figure 10: Full non-priority load & Partial Aggregate load
Figure 12 shows the case where only some of the bandwidth available Figure 11 shows the case where only some of the bandwidth available
to non-priority traffic is being used and a heavy load of priority to non-priority traffic is being used and a heavy load of priority
traffic is in place. In that situation both new non-priority traffic is in place. In that situation both new non-priority
sessions and new priority sessions would be accepted. Note that, as sessions and new priority sessions would be accepted. Note that, as
illustrated in Figure 11, priority sessions use some of the bandwidth illustrated in Figure 10, priority sessions use some of the bandwidth
currently not used by non-priority traffic. currently not used by non-priority traffic.
-------------------------------------- --------------------------------------
|xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . Available for . |xxxxxxxxxxxxxx| . Available for .
|xxxxxxxxxxxxxx| . non-priority . |xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . use .
| | . . Bandwidth | | . . Bandwidth
| | . . available for | | . . available for
|oooooooooooooo| v . non-priority |oooooooooooooo| v . non-priority
|--------------| --- . and priority |--------------| --- . and priority
|oooooooooooooo| . use |oooooooooooooo| . use
|oooooooooooooo| . |oooooooooooooo| .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Figure 12: Partial non-priority load & Heavy Aggregate load Figure 11: Partial non-priority load & Heavy Aggregate load
Figure 13 shows the case where all of the bandwidth available to non- Figure 12 shows the case where all of the bandwidth available to non-
priority traffic is being used and all of the remaining available priority traffic is being used and all of the remaining available
bandwidth is used by priority traffic. In that situation new non- bandwidth is used by priority traffic. In that situation new non-
priority sessions would be rejected. In that situation new priority priority sessions would be rejected. In that situation new priority
sessions could not be accepted right away. Those priority sessions sessions could not be accepted right away. Those priority sessions
may be handled by mechanisms, which are beyond the scope of this may be handled by mechanisms, which are beyond the scope of this
particular document (such as established through preemption of particular document (such as established through preemption of
existing non-priority sessions, or such as queuing of new priority existing non-priority sessions, or such as queuing of new priority
session requests until capacity becomes available again for priority session requests until capacity becomes available again for priority
traffic). traffic).
skipping to change at page 31, line 23 skipping to change at page 26, line 23
|xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth |xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for |xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority |xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority |--------------| --- . and priority
|oooooooooooooo| . use |oooooooooooooo| . use
|oooooooooooooo| . |oooooooooooooo| .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Figure 13: Full non-priority load & Full Aggregate load Figure 12: Full non-priority load & Full Aggregate load
A.3. Admission Priority with Priority Bypass Model (PrBM) A.3. Admission Priority with Priority Bypass Model (PrBM)
This section illustrates operations of admission priority when a This section illustrates operations of admission priority when a
simple Priority Bypass Model (PrBM) is used for bandwidth allocation simple Priority Bypass Model (PrBM) is used for bandwidth allocation
across non-priority traffic and priority traffic. With the Priority across non-priority traffic and priority traffic. With the Priority
Bypass Model, non-priority traffic is subject to resource based Bypass Model, non-priority traffic is subject to resource based
admission control while priority traffic simply bypasses the resource admission control while priority traffic simply bypasses the resource
based admission control. In other words: based admission control. In other words:
skipping to change at page 32, line 4 skipping to change at page 27, line 4
A property of this model is that a priority session is never A property of this model is that a priority session is never
rejected. rejected.
The rationale for this simple scheme is that, in practice in some The rationale for this simple scheme is that, in practice in some
networks: networks:
o the volume of priority sessions is very low for the vast majority o the volume of priority sessions is very low for the vast majority
of time, so it may not be economical to completely set aside of time, so it may not be economical to completely set aside
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 emergency periods where priority sessions are more heavily o even in congestion periods where priority sessions may be more
used, those always still represent a fairly small proportion of heavily used, those always still represent a fairly small
the overall load which can be absorbed within the safety margin of proportion of the overall load which can be absorbed within the
the engineered capacity limits. Thus, even if they are admitted safety margin of the engineered capacity limits. Thus, even if
beyond the engineered bandwidth threshold, they are unlikely to they are admitted beyond the engineered bandwidth threshold, they
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 model, an operator may map the Priority
Bypass model onto the Engineered Capacity limits according to Bypass model onto the Engineered Capacity limits according to
different policies. The operator may decide to configure the different policies. The operator may decide to configure the
bandwidth limit for admission of non-priority traffic to the full bandwidth limit for admission of non-priority traffic to the full
engineered capacity limits; As an example, if the engineered capacity engineered capacity limits; As an example, if the engineered capacity
limit on a given link is X, the operator may configure the bandwidth limit on a given link is X, the operator may configure the bandwidth
limit for non-priority traffic to X. Alternatively, the operator may limit for non-priority traffic to X. Alternatively, the operator may
decide to configure the bandwidth limit for non-priority traffic to decide to configure the bandwidth limit for non-priority traffic to
below the engineered capacity limits (so that the sum of the non- below the engineered capacity limits (so that the sum of the non-
priority and priority traffic stays below the engineered capacity); priority and priority traffic stays below the engineered capacity);
As an example, if the engineered capacity limit on a given link is X, As an example, if the engineered capacity limit on a given link is X,
the operator may configure the bandwidth limit for non-priority the operator may configure the bandwidth limit for non-priority
traffic to 95% of X. Finally, the operator may decide to strike a traffic to 95% of X. Finally, the operator may decide to strike a
balance in between. The considerations presented for these policies balance in between. The considerations presented for these policies
in the previous sections in the MAM and RDM contexts are equally in the previous sections in the MAM and RDM contexts are equally
applicable to the Priority Bypass Model. applicable to the Priority Bypass Model.
Figure 14 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
neered . or . | | . of non-priority traffic neered . or . | | . of non-priority traffic
. . | | . . . | | .
Capacity. . | | . Capacity. . | | .
v . | | v v . | | v
. |--------------| --- . |--------------| ---
. | | . | |
v | | v | |
| | | |
Figure 14: Priority Bypass Model Bandwidth Allocation Figure 13: Priority Bypass Model Bandwidth Allocation
Figure 15 shows some of the non-priority capacity of this link being Figure 14 shows some of the non-priority capacity of this link being
used. In this situation, both new non-priority and new priority used. In this situation, both new non-priority and new priority
sessions would be accepted. sessions would be accepted.
----------------------- -----------------------
^ ^ |xxxxxxxxxxxxxx| ^ ^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| . . . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . | | . for admission Engi- . . | | . for admission
neered . or . | | . of non-priority traffic neered . or . | | . of non-priority traffic
. . | | . . . | | .
Capacity. . | | . Capacity. . | | .
v . | | v v . | | v
. |--------------| --- . |--------------| ---
. | | . | |
v | | v | |
| | | |
Figure 15: Partial load of non-priority calls Figure 14: Partial load of non-priority calls
Figure 16 shows the same amount of non-priority load being used at Figure 15 shows the same amount of non-priority load being used at
this link, and a small amount of priority bandwidth being used. In this link, and a small amount of priority bandwidth being used. In
this situation, both new non-priority and new priority sessions would this situation, both new non-priority and new priority sessions would
be accepted. be accepted.
----------------------- -----------------------
^ ^ |xxxxxxxxxxxxxx| ^ ^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| . . . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission Engi- . . |oooooooooooooo| . for admission
neered . or . | | . of non-priority traffic neered . or . | | . of non-priority traffic
. . | | . . . | | .
Capacity. . | | . Capacity. . | | .
v . | | v v . | | v
. |--------------| --- . |--------------| ---
. | | . | |
v | | v | |
| | | |
Figure 16: Partial load of non-priority calls & partial load of Figure 15: Partial load of non-priority calls & partial load of
priority calls priority calls
Figure 17 shows the case where aggregate non-priority and priority Figure 16 shows the case where aggregate non-priority and priority
load exceeds the bandwidth limit for admission of non-priority load exceeds the bandwidth limit for admission of non-priority
traffic. In this situation, any new non-priority session is rejected traffic. In this situation, any new non-priority session is rejected
while any new priority session is admitted. while any new priority session is admitted.
----------------------- -----------------------
^ ^ |xxxxxxxxxxxxxx| ^ ^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| . . . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission Engi- . . |oooooooooooooo| . for admission
neered . or . |xxxooxxxooxxxo| . of non-priority traffic neered . or . |xxxooxxxooxxxo| . of non-priority traffic
. . |xxoxxxxxxoxxxx| . . . |xxoxxxxxxoxxxx| .
Capacity. . |oxxxooooxxxxoo| . Capacity. . |oxxxooooxxxxoo| .
v . |xxoxxxooxxxxxx| v v . |xxoxxxooxxxxxx| v
. |--------------| --- . |--------------| ---
. |oooooooooooooo| . |oooooooooooooo|
v | | v | |
| | | |
Figure 17: Full non-priority load Figure 16: Full non-priority load
Appendix B. Example Usages of RSVP Extensions Appendix B. Example Usages of RSVP Extensions
This section provides examples of how RSVP extensions defined in this This section provides examples of how RSVP extensions defined in this
document can be used (in conjunctions with other RSVP functionality document can be used (in conjunctions with other RSVP functionality
and SIP functionality) to enforce different hypothetical policies for and SIP functionality) to enforce different hypothetical policies for
handling Emergency sessions in a given administrative domain. This handling prioritized sessions in a given administrative domain. This
Appendix does not provide additional specification. It is only Appendix does not provide additional specification. It is only
included in this document for illustration purposes. included in this document for illustration purposes.
We assume an environment where SIP is used for session control and We assume an environment where SIP is used for session control and
RSVP is used for resource reservation. RSVP is used for resource reservation.
In a mild abuse of language, we refer here to "Call Queueing" as the We refer here to "Session Queueing" as the set of "session" layer
set of "session" layer capabilities that may be implemented by SIP capabilities that may be implemented by SIP user agents to influence
user agents to influence their treatment of SIP requests. This may their treatment of SIP requests. This may include the ability to
include the ability to "queue" session requests when those can not be "queue" session requests when those can not be immediately honored
immediately honored (in some cases with the notion of "bumping", or (in some cases with the notion of "bumping", or "displacement", of
"displacement", of less important session requests from that queue). less important session requests from that queue). It may include
It may include additional mechanisms such as exemption from certain additional mechanisms such as exemption from certain network
network management controls, and alternate routing. management controls, and alternate routing.
We only mention below the RSVP policy elements that are to be We only mention below the RSVP policy elements that are to be
enforced by PEPs. It is assumed that these policy elements are set enforced by PEPs. It is assumed that these policy elements are set
at administrative domain boundaries by PDPs. The Admission Priority at a policy area boundary by PDPs. The Admission Priority and
and Preemption Priority RSVP policy elements are set by PDPs as a Preemption Priority RSVP policy elements are set by PDPs as a result
result of processing the Application Level Resource Priority Policy of processing the Application Level Resource Priority Policy Element
Element (which is carried in RSVP messages). (which is carried in RSVP messages).
If one wants to implement an emergency service purely based on Call If one wants to implement a prioritized service purely based on
Queueing, one can achieve this by signaling emergency sessions: Session Queueing, one can achieve this by signaling prioritized
sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" header in SIP
o not using Admission-Priority Policy Element in RSVP o not using Admission-Priority Policy Element in RSVP
o not using Preemption Policy Element in RSVP o not using Preemption Policy Element in RSVP
If one wants to implement an emergency service based on Call Queueing If one wants to implement a prioritized service based on Session
and on "prioritized access to network layer resources", one can Queueing and on "prioritized access to network layer resources", one
achieve this by signaling emergency sessions: can achieve this by signaling prioritized sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" header in SIP
o using Admission-Priority Policy Element in RSVP o using Admission-Priority Policy Element in RSVP
o not using Preemption Policy Element in RSVP o not using Preemption Policy Element in RSVP
Emergency sessions will not result in preemption of any session. Establishment of prioritized sessions will not result in preemption
Different bandwidth allocation models can be used to offer different of any session. Different bandwidth allocation models can be used to
"prioritized access to network resources". Just as examples, this offer different "prioritized access to network resources". Just as
includes strict setting aside of capacity for emergency sessions as examples, this includes strict setting aside of capacity for
well as simple bypass of admission limits for emergency sessions. prioritized sessions as well as simple bypass of admission limits for
prioritized sessions.
If one wants to implement an emergency service based on Call If one wants to implement a prioritized service based on Session
Queueing, on "prioritized access to network layer resources", and Queueing, on "prioritized access to network layer resources", and
ensures that (say) "Emergency-1" sessions can preempt "Emergency-2" ensures that (say) "Prioritized-1" sessions can preempt
sessions, but non-emergency sessions are not affected by preemption, "Prioritized-2" sessions, but non-prioritized sessions are not
one can do that by signaling emergency sessions: affected by preemption, one can do that by signaling prioritized
sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" header in SIP
o using Admission-Priority Policy Element in RSVP o using Admission-Priority Policy Element in RSVP
o using Preemption Policy Element in RSVP with: o using Preemption Policy Element in RSVP with:
* setup (Emergency-1) > defending (Emergency-2) * setup (Prioritized-1) > defending (Prioritized-2)
* setup (Emergency-2) <= defending (Emergency-1) * setup (Prioritized-2) <= defending (Prioritized-1)
* setup (Emergency-1) <= defending (Non-Emergency) * setup (Prioritized-1) <= defending (Non-Prioritized)
* setup (Emergency-2) <= defending (Non-Emergency) * setup (Prioritized-2) <= defending (Non-Prioritized)
If one wants to implement an emergency service based on Call If one wants to implement a prioritized service based on Session
Queueing, on "prioritized access to network layer resources", and Queueing, on "prioritized access to network layer resources", and
ensure that "emergency" sessions can preempt regular sessions, one ensure that prioritized sessions can preempt regular sessions, one
could do that by signaling emergency sessions: could do that by signaling Prioritized sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" header in SIP
o using Admission-Priority Policy Element in RSVP o using Admission-Priority Policy Element in RSVP
o using Preemption Policy Element in RSVP with: o using Preemption Policy Element in RSVP with:
* setup (Emergency) > defending (Non-Emergency) * setup (Prioritized) > defending (Non-Prioritized)
* setup (Non-Emergency) <= defending (Emergency) * setup (Non-Prioritized) <= defending (Prioritized)
If one wants to implement an emergency service based on Call If one wants to implement a prioritized service based on Session
Queueing, on "prioritized access to network layer resources", and Queueing, on "prioritized access to network layer resources", and
ensure that "emergency" sessions can partially preempt regular ensure that prioritized sessions can partially preempt regular
sessions (i.e. reduce their reservation size), one could do that by sessions (i.e. reduce their reservation size), one could do that by
signaling emergency sessions: signaling prioritized sessions:
o using "Resource-Priority" Header in SIP o using "Resource-Priority" header in SIP
o using Admission-Priority Policy Element in RSVP o using Admission-Priority Policy Element in RSVP
o using Preemption in Policy Element RSVP with: o using Preemption in Policy Element RSVP with:
* setup (Emergency) > defending (Non-Emergency) * setup (Prioritized) > defending (Non-Prioritized)
* setup (Non-Emergency) <= defending (Emergency) * setup (Non-Prioritized) <= defending (Prioritized)
o activate RFC4495 RSVP Bandwidth Reduction mechanisms o activate RFC4495 RSVP Bandwidth Reduction mechanisms
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
 End of changes. 123 change blocks. 
535 lines changed or deleted 322 lines changed or added

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