draft-ietf-tsvwg-emergency-rsvp-05.txt   draft-ietf-tsvwg-emergency-rsvp-06.txt 
RSVP Extensions for Emergency Services January 2008
TSVWG Francois Le Faucheur
Internet-Draft James Polk
Intended Status: Standards Track Cisco Systems, Inc.
Ken Carlberg TSVWG F. Le Faucheur
Internet-Draft J. Polk
Intended status: Standards Track Cisco
Expires: October 2, 2008 K. Carlberg
G11 G11
draft-ietf-tsvwg-emergency-rsvp-05.txt March 31, 2008
Expires: August 1, 2008 January 31, 2008
Resource ReSerVation Protovol (RSVP) Extensions for Emergency Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services
Services draft-ietf-tsvwg-emergency-rsvp-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
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 October 2, 2008.
Abstract Abstract
An Emergency Telecommunications Service (ETS) requires the ability to An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a authorized user in times of network congestion (typically, during a
crisis). When supported over the Internet Protocol suite, this may be crisis). When supported over the Internet Protocol suite, this may
facilitated through a network layer admission control solution, which be facilitated through a network layer admission control solution,
supports prioritized access to resources (e.g., bandwidth). These which supports prioritized access to resources (e.g., bandwidth).
resources may be explicitly set aside for emergency services, or they These resources may be explicitly set aside for emergency services,
may be shared with other sessions. or they may be shared with other sessions.
This document specifies RSVP extensions that can be used to support This document specifies RSVP extensions that can be used to support
such an admission priority capability at the network layer. Note that such an admission priority capability at the network layer. Note
these extensions represent one possible solution component in that these extensions represent one possible solution component in
satisfying ETS requirements. Other solution components, or other satisfying ETS requirements. Other solution components, or other
solutions, are outside the scope of this document. solutions, are outside the scope of this document.
Copyright Notice Requirements Language
Copyright (C) The IETF Trust (2008).
Specification of Requirements
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. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Technical Documents................................3 1.1. Related Technical Documents . . . . . . . . . . . . . . . 4
1.2. Terminology................................................4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of RSVP extensions and Operations.....................5 2. Overview of RSVP extensions and Operations . . . . . . . . . . 5
2.1. Operations of Admission Priority..........................7 2.1. Operations of Admission Priority . . . . . . . . . . . . . 7
3. New Policy Elements............................................7 3. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7
3.1. Admission Priority Policy Element.........................8 3.1. Admission Priority Policy Element . . . . . . . . . . . . 8
3.1.1. Admission Priority Merging Rules 9 3.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10
3.2. Application-Level Resource Priority Policy Element.......10 3.2. Application-Level Resource Priority Policy Element . . . . 10
3.2.1. Application-Level Resource Priority Modifying and 3.2.1. Application-Level Resource Priority Modifying and
Merging Rules 11 Merging Rules . . . . . . . . . . . . . . . . . . . . 12
3.3. Default Handling.........................................11 3.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations.......................................12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Use of RSVP Authentication between RSVP nighbors.........12 4.1. Use of RSVP Authentication between RSVP nighbors . . . . . 13
4.2. Use of INTEGRITY object within the POLICY_DATA object....12 4.2. Use of INTEGRITY object within the POLICY_DATA object . . 13
5. IANA Considerations...........................................13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments...............................................15 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. Normative References..........................................15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Informative References........................................15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
Appendix A: Examples of Bandwidth Allocation Model for Admission 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Priority.........................................................17 Appendix A. Examples of Bandwidth Allocation Model for
A.1 Admission Priority with Maximum Allocation Model (MAM)......17 Admission Priority . . . . . . . . . . . . . . . . . 18
A.2 Admission Priority with Russian Dolls Model (RDM)...........21 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 18
A.3 Admission Priority with Priority Bypass Model (PrBM)........23 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 22
Appendix B: Example Usages of RSVP Extensions....................26 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 25
Authors' Address.................................................28 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Introduction 1. Introduction
[EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency [RFC3689] and [RFC3690] detail requirements for an Emergency
Telecommunications Service (ETS), which is an umbrella term Telecommunications Service (ETS), which is an umbrella term
identifying those networks and specific services used to support identifying those networks and specific services used to support
emergency communications. An underlying goal of these documents is to emergency communications. An underlying goal of these documents is
present requirements that elevate the probability of session to present requirements that elevate the probability of session
establishment from an authorized user in times of network congestion establishment from an authorized user in times of network congestion
(presumably because of a crisis condition). In some extreme cases, (presumably because of a crisis condition). In some extreme cases,
the requirement for this probability may reach 100%, but that is a the requirement for this probability may reach 100%, but that is a
topic subject to policy and most likely local regulation (the latter topic subject to policy and most likely local regulation (the latter
being outside the scope of this document). 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 an access to resources controlled by the session control function. As
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 [SIP], 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" call requests when those can not be include the ability to "queue" call requests when those can not be
immediately honored (in some cases with the notion of "bumping", or immediately honored (in some cases with the notion of "bumping", or
"displacement", of less important call request from that queue). It "displacement", of less important call request from that queue). It
may include additional mechanisms such as exemption from certain may include additional mechanisms such as exemption from certain
network management controls, and alternate routing. network management 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
skipping to change at page 3, line 52 skipping to change at page 4, line 7
Note: Below, this document references several examples of IP Note: Below, this document references several examples of IP
telephony and its use of "calls", which is one form of the term telephony and its use of "calls", which is one form of the term
"sessions" (Video over IP and Instant Messaging being other examples "sessions" (Video over IP and Instant Messaging being other examples
that rely on session establishment). For the sake of simplicity, we that rely on session establishment). For the sake of simplicity, we
shall use the widely known term "call" for the remainder of this shall use the widely known term "call" for the remainder of this
document. document.
1.1. Related Technical Documents 1.1. Related Technical Documents
[EMERG-IMP] is patterned after [ITU.I.225] and describes an example [RFC4542] is patterned after [ITU.I.225] and describes an example of
of one type of prioritized network layer admission control procedure one type of prioritized network layer admission control procedure
that may be used for emergency services operating over an IP network that may be used for emergency services operating over an IP network
infrastructure. It discusses initial call set up, as well as infrastructure. It discusses initial call set up, as well as
operations after call establishment through maintenance of a operations after call establishment through maintenance of a
continuing call model of the status of all calls. [EMERG-IMP] also continuing call model of the status of all calls. [RFC4542] also
describes how these network layer admission control procedures can be describes how these network layer admission control procedures can be
realized using the Resource reSerVation Protocol [RSVP] along with realized using the Resource reSerVation Protocol [RFC2205] along with
its associated protocol suite and extensions, including those for its associated protocol suite and extensions, including those for
policy based admission control ([FW-POLICY], [RSVP-POLICY]), for user policy based admission control ([RFC2753], [RFC2750]), for user
authentication and authorization ([RSVP-ID]) and for integrity and authentication and authorization ([RFC3182]) and for integrity and
authentication of RSVP messages ([RSVP-CRYPTO-1], [RSVP-CRYPTO-2]). authentication of RSVP messages ([RFC2747], [RFC3097]).
Furthermore, [EMERG-IMP] describes how the RSVP Signaled Preemption Furthermore, [RFC4542] describes how the RSVP Signaled Preemption
Priority Policy Element specified in [RSVP-PREEMP] can be used to Priority Policy Element specified in [RFC3181] can be used to enforce
enforce the call preemption that may be needed by some emergency the call preemption that may be needed by some emergency services.
services.
In contrast to [EMERG-IMP], this document specifies new RSVP In contrast to [RFC4542], this document specifies new RSVP extensions
extensions to increase the probability of call completion without to increase the probability of call completion without preemption.
preemption. Engineered capacity techniques in the form of bandwidth Engineered capacity techniques in the form of bandwidth allocation
allocation models are used to satisfy the "admission priority" models are used to satisfy the "admission priority" required by an
required by an RSVP capable ETS network. In particular this document RSVP capable ETS network. In particular this document specifies two
specifies two new RSVP Policy Elements allowing the admission new RSVP Policy Elements allowing the admission priority to be
priority to be conveyed inside RSVP signaling messages so that RSVP conveyed inside RSVP signaling messages so that RSVP nodes can
nodes can enforce selective bandwidth admission control decision enforce selective bandwidth admission control decision based on the
based on the call admission priority. Appendix A of this document call admission priority. Appendix A of this document also provides
also provides three examples of a bandwidth allocation model, which three examples of a bandwidth allocation model, which can be used by
can be used by RSVP-routers to enforce such admission priority on RSVP-routers to enforce such admission priority on every link.
every link.
1.2. Terminology 1.2. Terminology
This document assumes the terminology defined in [FW-POLICY]. 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:
- Policy Decision Point (PDP): The point where policy decisions are o Policy Decision Point (PDP): The point where policy decisions are
made. made.
- Local Policy Decision Point (LPDP): PDP local to the network o Local Policy Decision Point (LPDP): PDP local to the network
element element.
- Policy Enforcement Point (PEP): The point where the policy o Policy Enforcement Point (PEP): The point where the policy
decisions are actually enforced. decisions are actually enforced.
- Policy Ignorant Node (PIN): A network element that does not o Policy Ignorant Node (PIN): A network element that does not
explicitly support policy control using the mechanisms defined in explicitly support policy control using the mechanisms defined in
[FW-POLICY]. [RFC2753].
2. Overview of RSVP extensions and Operations 2. Overview of RSVP extensions and Operations
Let us consider the case where a call requiring ETS type service is Let us consider the case where a call requiring ETS type service is
to be established, and more specifically that the preference to be to be established, and more specifically that the preference to be
granted to this call is in terms of network layer "admission granted to this call is in terms of network layer "admission
priority" (as opposed to preference granted through preemption of priority" (as opposed to preference granted through preemption of
existing calls). By "admission priority" we mean allowing that existing calls). By "admission priority" we mean allowing that
priority call to seize network layer resources from the engineered priority call to seize network layer resources from the engineered
capacity that have been set-aside and not made available to normal capacity that have been set-aside and not made available to normal
calls, or alternatively by allowing that call to seize additional calls, or alternatively by allowing that call to seize additional
resources beyond the engineered capacity limits applied to normal resources beyond the engineered capacity limits applied to normal
calls. calls.
As described in [EMERG-IMP], the session establishment can be As described in [RFC4542], the session establishment can be
conditioned to resource-based and policy-based network layer conditioned to resource-based and policy-based network layer
admission control achieved via RSVP signaling. In the case where the admission control achieved via RSVP signaling. In the case where the
session control protocol is SIP, the use of RSVP-based admission session control protocol is SIP, the use of RSVP-based admission
control by SIP is specified in [SIP-RESOURCE]. control by SIP is 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 emergency
calls. Again considering the case where the session control protocol calls. Again considering the case where the session control protocol
is SIP, the SIP user agents can be made aware of the resource is SIP, the SIP user agents can be made aware of the resource
priority requirements in the case of an emergency call using the priority requirements in the case of an emergency call using the
Resource-Priority Header mechanism specified in [SIP-PRIORITY]. The Resource-Priority Header mechanism specified in [RFC4412]. The end-
end-devices involved in the upper-layer session establishment simply devices involved in the upper-layer session establishment simply need
need to copy the application-level resource priority requirements to copy the application-level resource priority requirements (e.g. as
(e.g. as communicated in SIP Resource-Priority Header) inside the new communicated in SIP Resource-Priority Header) inside the new RSVP
RSVP Application-Level Resource-Priority Policy Element defined in Application-Level Resource-Priority Policy Element defined in this
this document. 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 every
administrative domain boundary based on the policy applicable in that administrative domain boundary based on the policy applicable in that
domain. In a typical model (see [FW-POLICY]) where PDPs control PEPs domain. In a typical model (see [RFC2753]) where PDPs control PEPs
at the periphery of the policy domain (e.g., in border routers), PDPs at the periphery of the policy domain (e.g., in border routers), 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 emergency session into an RSVP
"admission priority" level. Then, PDPs would convey this information "admission priority" level. Then, PDPs would convey this information
inside the new Admission Priority Policy Element defined in this inside the new Admission Priority Policy Element defined in this
document. This way, the RSVP admission priority can be communicated document. This way, the RSVP admission priority can be communicated
to downstream PEPs (ie RSVP Routers) of the same policy domain, which to downstream PEPs (ie RSVP Routers) of the same policy domain, which
have LPDPs but no controlling PDP. In turn, this means the necessary have LPDPs but no controlling PDP. In turn, this means the necessary
RSVP Admission priority can be enforced at every RSVP hop, including RSVP Admission priority can be enforced at every RSVP hop, including
all the (many) hops which do not have any understanding of all the (many) hops which do not have any understanding of
skipping to change at page 6, line 16 skipping to change at page 6, line 16
first domain might decide to provide network layer admission priority first domain might decide to provide network layer admission priority
to calls of a given Application Level Resource Priority and map it to calls of a given Application Level Resource Priority and map it
into a high RSVP admission control priority inside the Admission into a high RSVP admission control priority inside the Admission
Priority Policy Element; while a second domain may decide to not Priority Policy Element; while a second domain may decide to not
provide admission priority to calls of this same Application Level provide admission priority to calls of this same Application Level
Resource Priority and hence map it into a low RSVP admission control Resource Priority and hence map it into a low RSVP admission control
priority. priority.
As another example of operation across multiple administrative As another example of operation across multiple administrative
domains, we can consider the case where the resource priority header domains, we can consider the case where the resource priority header
enumerates several namespaces, as explicitly allowed by [SIP- enumerates several namespaces, as explicitly allowed by [RFC4412],
PRIORITY], for support of scenarios where calls traverse multiple for support of scenarios where calls traverse multiple administrative
administrative domains using different namespace. In that case, the domains using different namespace. In that case, the relevant
relevant namespace can be used at each domain boundary to map into an namespace can be used at each domain boundary to map into an RSVP
RSVP Admission priority for that domain. It is not expected that the Admission priority for that domain. It is not expected that the RSVP
RSVP Application-Level Resource-Priority Header Policy Element would Application-Level Resource-Priority Header Policy Element would be
be taken into account at RSVP-hops within a given administrative taken into account at RSVP-hops within a given administrative domain.
domain. It is expected to be used at administrative domain boundaries It is expected to be used at administrative domain boundaries only in
only in order to set/reset the RSVP Admission Priority Policy order to set/reset the RSVP Admission Priority Policy Element.
Element.
The existence of pre-established inter-domain policy agreements or The existence of pre-established inter-domain policy agreements or
Service Level Agreements may avoid the need to take real-time action Service Level Agreements may avoid the need to take real-time action
at administrative domain boundaries for mapping/remapping of at administrative domain boundaries for mapping/remapping of
admission priorities. admission priorities.
Mapping/remapping by PDPs may also be applied to boundaries between Mapping/remapping by PDPs may also be applied to boundaries between
various signaling protocols, such as those advanced by the NSIS various signaling protocols, such as those advanced by the NSIS
working group. working group.
As can be observed, the framework described above for As can be observed, the framework described above for mapping/
remapping application level resource priority requirements into an
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 admission priority can also be used together with [RSVP- into an RSVP preemption priority (when preemption is indeed needed).
PREEMP] for mapping/remapping application level resource priority In that case, when processing the RSVP Application-Level Resource-
requirements into an RSVP preemption priority (when preemption is Priority Policy Element, the PDPs at boundaries between
indeed needed). In that case, when processing the RSVP Application- administrative domains (or between various QoS signaling protocols)
Level Resource-Priority Policy Element, the PDPs at boundaries can map it into an RSVP "preemption priority" information. This
between administrative domains (or between various QoS signaling Preemption priority information comprises a setup preemption level
protocols) can map it into an RSVP "preemption priority" information. and a defending preemption priority level. This preemption priority
This Preemption priority information comprises a setup preemption information can then be encoded inside the Preemption Priority Policy
level and a defending preemption priority level. This preemption Element of [RFC3181] and thus, can be taken into account at every
priority information can then be encoded inside the Preemption RSVP-enabled network hop as discussed [RFC4542]. Appendix B provides
Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into examples of various hypothetical policies for emergency call
account at every RSVP-enabled network hop as discussed [EMERG-IMP]. handling, some of them involving admission priority, some of them
Appendix B provides examples of various hypothetical policies for involving both admission priority and preemption priority. Appendix
emergency call handling, some of them involving admission priority, B also identifies how the Application-Level Resource Priority need to
some of them involving both admission priority and preemption be mapped into RSVP policy elements by the PDPs to realize these
priority. Appendix B also identifies how the Application-Level policies.
Resource Priority need to be mapped into RSVP policy elements by the
PDPs to realize these policies.
2.1. Operations of Admission Priority 2.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 an
authorized priority service. Multiple models of bandwidth allocation authorized priority service. Multiple models of bandwidth allocation
MAY be used to that end. MAY be 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 [DSTE- Those include the Maximum Allocation Model (MAM) defined in
MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127] and
same models MAY however be applied for allocation of bandwidth across the Maximum Allocation model with Reservation (MAR) defined in
different levels of admission priority as defined in this document. [RFC4126]. These same models MAY however be applied for allocation
Appendix A provides an illustration of how these bandwidth allocation of bandwidth across different levels of admission priority as defined
models can be applied for such purposes and introduces an additional in this document. Appendix A provides an illustration of how these
bandwidth allocation model that we term the Priority Bypass Model bandwidth allocation models can be applied for such purposes and
(PrBM). It is important to note that the models described and introduces an additional bandwidth allocation model that we term the
illustrated in Appendix A are only informative and do not represent a Priority Bypass Model (PrBM). It is important to note that the
recommended course of action. models described and illustrated in Appendix A are only informative
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, that the RSVP Admission Priority may
effectively influence the fundamental admission control decision of effectively influence the fundamental admission control decision of
RSVP (for example by determining which bandwidth pool is to be used RSVP (for example by determining which bandwidth pool is to be used
by RSVP for performing its fundamental bandwidth allocation). In that by RSVP for performing its fundamental bandwidth allocation). In
sense, we observe that the policy control and admission control are that sense, we observe that the policy control and admission control
not separate logics but instead somewhat blended. are not separate logics but instead somewhat blended.
3. New Policy Elements 3. New Policy Elements
The Framework document for policy-based admission control [FW-POLICY] 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 2 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:
- 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
- the emphasis of Admission Priority Policy Element is to be o the emphasis of Admission Priority Policy Element is to be simple,
simple, stateless, and light-weight such that it can be stateless, and light-weight such that it can be processed
processed internally within a node's LPDP. It can then be internally within a node's LPDP. It can then be enforced
enforced internally within a node's PEP. It is set by PDPs internally within a node's PEP. It is set by PDPs based on
based on processing of the Application-Level Resource Priority processing of the Application-Level Resource Priority Policy
Policy Element. Element.
[RSVP-POLICY] defines extensions for supporting generic policy based [RFC2750] defines extensions for supporting generic policy based
admission control in RSVP. These extensions include the standard admission control in RSVP. These extensions include the standard
format of POLICY_DATA objects and a description of RSVP handling of format of POLICY_DATA objects and a description of RSVP handling of
policy events. policy events.
The POLICY_DATA object contains one or more of Policy Elements, each The POLICY_DATA object contains one or more of Policy Elements, each
representing a different (and perhaps orthogonal) policy. As an representing a different (and perhaps orthogonal) policy. As an
example, [RSVP-PREEMP] specifies the Preemption Priority Policy example, [RFC3181] specifies the Preemption Priority Policy Element.
Element.
This document defines two new Policy Elements called: This document defines two new Policy Elements called:
- the Admission Priority Policy Element
- the Application-Level Resource Priority Policy Element o the Admission Priority Policy Element
o the Application-Level Resource Priority Policy Element
3.1. Admission Priority Policy Element 3.1. Admission Priority Policy Element
The format of the Admission Priority policy element is as follows: The format of the Admission Priority policy element is as shown in
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|
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Length: 16 bits Figure 1: Admission Priority Policy Element
Always 12. The overall length of the policy element, in bytes.
P-Type: 16 bits where:
ADMISSION_PRI = To be allocated by IANA
(see "IANA Considerations" section)
Flags: Reserved (SHALL be set to zero on transmit and SHALL be o Length: 16 bits
ignored on reception)
Merge Strategy: 8 bits (only applicable to multicast flows) * Always 12. The overall length of the policy element, in bytes.
1 Take priority of highest QoS
2 Take highest priority
3 Force Error on heterogeneous merge
(See section 3.1.1)
Error code: 8 bits (only applicable to multicast flows)
0 NO_ERROR Value used for regular ADMISSION_PRI elements
2 HETEROGENEOUS This element encountered heterogeneous merge
Reserved: 8 bits o P-Type: 16 bits
SHALL be set to zero on transmit and SHALL be ignored on
reception.
Reserved: 24 bits * ADMISSION_PRI = To be allocated by IANA (see "IANA
SHALL be set to zero on transmit and SHALL be ignored on Considerations" section)
reception. o Flags: Reserved
Adm. Priority (Admission Priority): 8 bits (unsigned) * SHALL be set to zero on transmit and SHALL be ignored on
The admission control priority of the flow, in terms of access to reception
network bandwidth in order to provide higher probability of call
completion to selected flows. Higher values represent higher
Priority. A given Admission Priority is encoded in this information
element using the same value as when encoded in the Admission
Priority parameter defined in section 6.2.9 of [NSIS-QSPEC], or in
the Admission Priority parameter defined in section 4.10 of [DIME-
PARAM]. In other words, a given value inside the Admission Priority
information element defined in the present document, inside the
[NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM]
Admission Priority parameter, refers to the same Admission Priority.
Bandwidth allocation models such as those described in Appendix A are o Merge Strategy: 8 bits (only applicable to multicast flows)
to be used by the RSVP router to achieve such increased probability
of call completion. The admission priority value effectively * 1 Take priority of highest QoS
indicates which bandwidth constraint(s) of the bandwidth constraint
model in use is(are) applicable to admission of this RSVP * 2 Take highest priority
reservation.
* 3 Force Error on heterogeneous merge (See section 3.1.1)
o Error code: 8 bits (only applicable to multicast flows)
* 0 NO_ERROR Value used for regular ADMISSION_PRI elements
* 2 HETEROGENEOUS This element encountered heterogeneous merge
o Reserved: 8 bits
* SHALL be set to zero on transmit and SHALL be ignored on
reception
o Reserved: 24 bits
* SHALL be set to zero on transmit and SHALL be ignored on
reception
o Adm. Priority (Admission Priority): 8 bits (unsigned)
* The admission control priority of the flow, in terms of access
to network bandwidth in order to provide higher probability of
call completion to selected flows. Higher values represent
higher Priority. A given Admission Priority is encoded in this
information element using the same value as when encoded in the
"Admission Priority" parameter defined in
[I-D.ietf-nsis-qspec], or in the "Admission Priority" parameter
defined in [I-D.ietf-dime-qos-parameters]. In other words, a
given value inside the Admission Priority information element
defined in the present document, inside the
[I-D.ietf-nsis-qspec] Admission Priority parameter or inside
the [I-D.ietf-dime-qos-parameters] Admission Priority
parameter, refers to the same Admission Priority. Bandwidth
allocation models such as those described in Appendix A are to
be used by the RSVP router to achieve such increased
probability of call completion. 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.
3.1.1. Admission Priority Merging Rules 3.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 is only
applicable to multicast, this section also only applies to multicast applicable to multicast, this section also only applies to multicast
sessions. sessions.
The rules for merging Admission Priority Policy Elements are the same The rules for merging Admission Priority Policy Elements are the same
as those defined in [RSVP-PREEMP] for merging Preemption Priority as those defined in [RFC3181] for merging Preemption Priority Policy
Policy Elements. In particular, the following merging strategies are Elements. In particular, the following merging strategies are
supported: supported:
- Take priority of highest QoS
- Take highest priority
- Force Error on heterogeneous merge.
The only difference with [RSVP-PREEMP] is that this document does not
recommend any merge strategies for Admission Priority while [RSVP-
PREEMP] recommends the first of these merge strategies for Preemption
Priority.
Note that with the Admission Priority (as is the case with the o Take priority of highest QoS
Preemption Priority), "Take highest priority" translates into "take
the highest numerical value". o Take highest priority
o Force Error on heterogeneous merge.
The only difference with [RFC3181] is that this document does not
recommend any merge strategies for Admission Priority while [RFC3181]
recommends the first of these merge strategies for Preemption
Priority. Note that with the Admission Priority (as is the case with
the Preemption Priority), "Take highest priority" translates into
"take the highest numerical value".
3.2. Application-Level Resource Priority Policy Element 3.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 follows: 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 //
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Length: The length of the policy element (including the Length and P- Figure 2: Application-Level Resource Priority Policy Element
Type) is in number of octets (MUST be a multiple of 4) and
where:
o Length:
* The length of the policy element (including the Length 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.
P-Type: 16 bits o P-Type: 16 bits
APP_RESOURCE_PRI = To be allocated by IANA
(see "IANA Considerations" section)
ALRP: * APP_RESOURCE_PRI = To be allocated by IANA (see "IANA
Considerations" section)
o ALRP List:
* List of ALRP where each ALRP is encoded as shown in Figure 3.
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 Priority|
+---------------------------+---------------------------+ +---------------------------+---------------------------+
ALRP Namespace (Application-Level Resource Priority Namespace):
16 bits (unsigned)
Contains a numerical value identifying the namespace of the
application-level resource priority. This value is encoded
as per the "Resource-Priority Namespaces" IANA registry. (See
IANA Considerations section for the request to IANA to
extend the registry to include this numerical value).
Reserved: 8 bits Figure 3: Application-Level Resource Priority
SHALL be set to zero on transmit and SHALL be ignored on
where:
o ALRP Namespace (Application-Level Resource Priority Namespace): 16
bits (unsigned)
* Contains a numerical value identifying the namespace of the
application-level resource priority. This value is encoded as
per the "Resource-Priority Namespaces" IANA registry. (See
IANA Considerations section for the request to IANA to extend
the registry to include this numerical value).
o Reserved: 8 bits
* SHALL be set to zero on transmit and SHALL be ignored on
reception. reception.
ALRP Priority: (Application-Level Resource Priority Priority): o ALRP Priority: (Application-Level Resource Priority Priority): 8
8 bits (unsigned) bits (unsigned)
Contains the priority value within the namespace of the
application-level resource priority. This value is encoded * Contains the priority value within the namespace of the
as per the "Resource-Priority Priority-Value" IANA registry. application-level resource priority. This value is encoded as
(See IANA Considerations section for the request to IANA to per the "Resource-Priority Priority-Value" IANA registry. (See
extend the registry to include this numerical value). IANA Considerations section for the request to IANA to extend
the registry to include this numerical value).
3.2.1. Application-Level Resource Priority Modifying and Merging Rules 3.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 merge Priority elements to reduce their size and number. When they do
those, LPDPs MUST do so according to the following rule: merge those, LPDPs MUST do so according to the following rule:
The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list
all the ALRPs appearing in the ALRP List of an incoming 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 is only applicable to Multicast, this rule only applies to
Multicast sessions. Multicast sessions.
3.3. Default Handling 3.3. Default Handling
As specified in section 4.2 of [RSVP-POLICY], 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 [RSVP-POLICY] also defines a similar default behavior Section 4.2 of [RFC2750] also defines a similar default behavior for
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 this document.
4. Security Considerations 4. Security Considerations
The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can
be signaled by RSVP through encapsulation in a Policy Data object as be signaled by RSVP through encapsulation in a Policy Data object as
defined in [RSVP-POLICY]. Therefore, like any other Policy Elements, defined in [RFC2750]. Therefore, like any other Policy Elements,
their integrity can be protected as discussed in section 6 of [RSVP- their integrity can be protected as discussed in section 6 of
POLICY] by two optional security mechanisms. The first mechanism [RFC2750] by two optional security mechanisms. The first mechanism
relies on RSVP Authentication as specified in [RSVP-CRYPTO-1] and relies on RSVP Authentication as specified in [RFC2747] and [RFC3097]
[RSVP-CRYPTO-2] to provide a chain of trust when all RSVP nodes are to provide a chain of trust when all RSVP nodes are policy capable.
policy capable. With this mechanism, the INTEGRITY object is carried With this mechanism, the INTEGRITY object is carried inside RSVP
inside RSVP messages. The second mechanism relies on the INTEGRITY messages. The second mechanism relies on the INTEGRITY object within
object within the POLICY_DATA object to guarantee integrity between the POLICY_DATA object to guarantee integrity between RSVP Policy
RSVP Policy Enforcement Points (PEPs) that are not RSVP neighbors. Enforcement Points (PEPs) that are not RSVP neighbors.
4.1. Use of RSVP Authentication between RSVP nighbors 4.1. Use of RSVP Authentication between RSVP nighbors
This mechanism can be used can be used between RSVP neighbors that This mechanism can be used can be used between RSVP neighbors that
are policy capable. The RSVP neighbors use shared keys to compute the are policy capable. The RSVP neighbors use shared keys to compute
cryptographic signature of the RSVP message. [RSVP-GROUPKEYING] the cryptographic signature of the RSVP message.
discusses key types, key provisioning methods as well as their [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key
respective applicability. provisioning methods as well as their respective applicability.
4.2. Use of INTEGRITY object within the POLICY_DATA object 4.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.
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 [RSVP-POLICY]. 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 distributed algorithm to be used. Keys to be used between PDPs can be
manually or via standard key management protocol for secure key distributed manually or via standard key management protocol for
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
as where RSVP capable Policy Ignorant Nodes (PINs) may exist in as where RSVP capable Policy Ignorant Nodes (PINs) may exist in
between PEPs, it may be difficult for the PDP to determine what is between PEPs, it may be difficult for the PDP to determine what is
the destination PDP for a POLICY_DATA object contained in some RSVP the destination PDP for a POLICY_DATA object contained in some RSVP
messages (such as a Path message). This is because in those cases the messages (such as a Path message). This is because in those cases
next PEP is not known at the time of forwarding the message. In this the next PEP is not known at the time of forwarding the message. In
situation, key shared across multiple PDPs may be used. This is this situation, key shared across multiple PDPs may be used. This is
conceptually similar to the use of key shared across multiple RSVP conceptually similar to the use of key shared across multiple RSVP
neighbors discussed in [RSVP-GROUPKEYING]. We observe also that this neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying].
issue may not exist in some deployment scenarios where a single (or We observe also that this issue may not exist in some deployment
low number of) PDP is used to control all the PEPs of a region (such scenarios where a single (or low number of) PDP is used to control
as an administrative domain). In such scenarios, it may be easy for a all the PEPs of a region (such as an administrative domain). In such
PDP to determine what is the next hop PDP, even when the next hop PEP scenarios, it may be easy for a PDP to determine what is the next hop
is not known, simply by determining what is the next region that will PDP, even when the next hop PEP is not known, simply by determining
be traversed (say based on the destination address). what is the next region that will be traversed (say based on the
destination address).
5. IANA Considerations 5. IANA Considerations
As specified in [RSVP-POLICY], Standard RSVP Policy Elements (P-type As specified in [RFC2750], Standard RSVP Policy Elements (P-type
values) are to be assigned by IANA as per "IETF Consensus" following values) are to be assigned by IANA as per "IETF Consensus" following
the policies outlined in [IANA-CONSIDERATIONS]. the policies outlined in [RFC2434].
IANA needs to allocate two P-Types from the Standard RSVP Policy IANA needs to allocate two P-Types from the Standard RSVP Policy
Element range: Element range:
- one P-Type to the Admission Priority Policy Element
- one P-Type to the Application-Level Resource Priority o one P-Type to the Admission Priority Policy Element
Policy Element
o one P-Type to the Application-Level Resource Priority Policy
Element.
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 currently listing all such namespace. However, that registry does not
allocate a numerical value to each namespace. Hence, this document currently allocate a numerical value to each namespace. Hence, this
requests the IANA to extend the Resource-Priority Namespace registry document requests the IANA to extend the Resource-Priority Namespace
in the following ways: registry in the following ways:
- a new column should be added to the registry
- the title of the new column should be "Namespace Numerical o a new column should be added to the registry
Value *"
- in the Legend, add a line saying "Namespace Numerical o the title of the new column should be "Namespace Numerical Value
Value = the unique numerical value identifying the *"
namespace"
- add a line at the bottom of the registry stating the o in the Legend, add a line saying "Namespace Numerical Value = the
following "* : [RFCXXX] " where XXX is the RFC number of unique numerical value identifying the namespace"
the present document
- allocate an actual numerical value to each namespace in o add a line at the bottom of the registry stating the following "*
the registry and state that value in the new "Namespace : [RFCXXX] " where XXX is the RFC number of the present document
numerical Value *" column.
o allocate an actual numerical value to each namespace in the
registry and state that value in the new "Namespace numerical
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
registry. registry.
The present document defines an ALRP Priority field in section 3.2 The present document defines an ALRP Priority field in section 3.2
that contains a numerical value identifying the actual application- that contains a numerical value identifying the actual application-
level resource priority within the application-level resource level resource priority within the application-level resource
priority namespace. The IANA already maintains the Resource-Priority priority namespace. The IANA already maintains the Resource-Priority
Priority-values registry (under the SIP Parameters) listing all such Priority-values registry (under the SIP Parameters) listing all such
priorities. However, that registry does not currently allocate a priorities. However, that registry does not currently allocate a
numerical value to each priority-value. Hence, this document requests numerical value to each priority-value. Hence, this document
the IANA to extend the Resource-Priority Priority-Values registry in requests the IANA to extend the Resource-Priority Priority-Values
the following ways: registry in the following ways:
- for each namespace, the registry should be structured with
two columns o for each namespace, the registry should be structured with two
- the title of the first column should read "Priority Values columns
(least to greatest)"
- the first column should list all the values currently o the title of the first column should read "Priority Values (least
defined in the registry (e.g. for the drsn namespace: to greatest)"
"routine", "priority", "immediate", "flash", "flash-
override", "flash-override-override" for the drsn o the first column should list all the values currently defined in
namespace) the registry (e.g. for the drsn namespace: "routine", "priority",
- the title of the second column should read "Priority "immediate", "flash", "flash-override", "flash-override-override"
Numerical Value *" for the drsn namespace)
- At the bottom of the registry, add a "Legend" with a line
saying "Priority Numerical Value = the unique numerical o the title of the second column should read "Priority Numerical
value identifying the priority within a namespace" Value *"
- add a line at the bottom of the registry stating the
following "* : [RFCXXX] " where XXX is the RFC number of o At the bottom of the registry, add a "Legend" with a line saying
the present document "Priority Numerical Value = the unique numerical value identifying
- allocate an actual numerical value to each and state that the priority within a namespace"
value in the new "Priority Numerical Value *" column.
o add a line at the bottom of the registry stating the following "*
: [RFCXXX] " where XXX is the RFC number of the present document
o allocate an actual numerical value to each and state that value in
the new "Priority Numerical 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 priority. Then, in the future, IANA should automatically existing priority. Then, in the future, IANA should automatically
allocate a numerical value to any new namespace added to the allocate a numerical value to any new namespace added to the
registry. The numerical value must be unique within each namespace. registry. The numerical value must be unique within each namespace.
Within each namespace, values should be allocated in decreasing order Within each namespace, values should be allocated in decreasing order
ending with 0 (so that the greatest priority is always allocated ending with 0 (so that the greatest priority is always allocated
value 0). For example, in the drsn namespace, "routine" would be value 0). For example, in the drsn namespace, "routine" would be
allocated numerical value 5 and "flash-override-override" would be allocated numerical value 5 and "flash-override-override" would be
allocated numerical value 0. allocated numerical value 0.
6. Acknowledgments 6. 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 [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input Element [RFC3181]. Dave Oran and Janet Gunn provided useful input
into this document. into this document.
7. Normative References 7. References
[IANA-CONSIDERATIONS] Alverstrand et al., "Guidelines for Writing an 7.1. Normative References
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
(RSVP)- Functional Specification", RFC 2205, September 1997. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Cryptographic Authentication", RFC 2747, January 2000. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, April 2001. Authentication", RFC 2747, January 2000.
[RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC [RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
2750, January 2000. RFC 2750, January 2000.
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Element", RFC 3181, October 2001. Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261, [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
[SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource RFC 3181, October 2001.
Priority for the Session Initiation Protocol (SIP)", RFC4412,
February 2006.
8. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[DIME-PARAM] J. Korhonen & H. Tschofenig, "Quality of Service [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Parameters for Usage with the AAA Framework", draft-ietf-dime-qos- Priority for the Session Initiation Protocol (SIP)",
parameters-01.txt, work in progress. RFC 4412, February 2006.
[DSTE-MAM] F. Le Faucheur & W. Lai, "Maximum Allocation Bandwidth 7.2. Informative References
Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC
4125, June 2005.
[DSTE-RDM] Le Faucheur et al., Russian Dolls Bandwidth Constraints [I-D.ietf-dime-qos-parameters]
Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June Korhonen, J. and H. Tschofenig, "Quality of Service
2005. Parameters for Usage with the AAA Framework",
draft-ietf-dime-qos-parameters-03 (work in progress),
February 2008.
[EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency [I-D.ietf-nsis-qspec]
Telecommunications Service for Real Time Services in the Internet Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP
Protocol Suite", RFC 4542, May 2006. QSPEC Template", draft-ietf-nsis-qspec-19 (work in
progress), February 2008.
[EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for [I-D.ietf-tsvwg-rsvp-security-groupkeying]
Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in
progress), February 2008.
[EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
for Emergency Telecommunication Service (ETS)", RFC 3690, February Requirement Levels", BCP 14, RFC 2119, March 1997.
2004.
[FW-POLICY] 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, January 2000. for Policy-based Admission Control", RFC 2753,
January 2000.
[ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU, [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Recommendation, I.255.3, July, 1990. Herzog, S., and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001.
[NSIS-QSPEC] G. Ash et al., "QoS NLSP QSPEC Template", draft-ietf- [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
nsis-qspec-18.txt, work in progress. "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for
Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC3182, Emergency Telecommunication Service (ETS)", RFC 3689,
October 2001. February 2004.
[RSVP-GROUPKEYING] Behringer, M., Le Faucheur, F., "Applicability of [RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
Keying Methods for RSVP Security", draft-behringer-tsvwg-rsvp- for Emergency Telecommunication Service (ETS)", RFC 3690,
security-groupkeying-01.txt, work in progress. February 2004.
[SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
"Integration of Resource Management and Session Initiation Protocol Constraints Model for Diffserv-aware MPLS Traffic
(SIP)", RFC 3312, October 2002. Engineering", RFC 4125, June 2005.
Appendix A: Examples of Bandwidth Allocation Model for Admission [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126,
June 2005.
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering",
RFC 4127, June 2005.
[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.
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 [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE- Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM)
RDM] can be used for support of admission priority. Section A.3 ([RFC4127]) can be used for support of admission priority. The
illustrates how a simple "Priority Bypass Model" can also be used for Maximum Allocation model with Reservation (MAR) ([RFC4126]) could
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
be used for support of admission priority.
For simplicity, operations with only a single "priority" level For simplicity, operations with only a single "priority" level
(beyond non-priority) are illustrated here; However, the reader will (beyond non-priority) are illustrated here; However, the reader will
appreciate that operations with multiple priority levels can easily appreciate that operations with multiple priority levels can easily
be supported with these models. be supported with these models.
In all the charts below: In all the figures below:
x represents a non-priority session x represents a non-priority session
o represents a priority session o represents a priority session
A.1 Admission Priority with Maximum Allocation Model (MAM) A.1. Admission Priority with Maximum Allocation Model (MAM)
This section illustrates operations of admission priority when a This section illustrates operations of admission priority when a
Maximum Allocation Model (MAM) is used for bandwidth allocation Maximum Allocation Model (MAM) is used for bandwidth allocation
across non-priority traffic and priority traffic. A property of the across non-priority traffic and priority traffic. A property of the
Maximum Allocation Model is that priority traffic can not use more Maximum Allocation Model is that priority traffic can not use more
than the bandwidth made available to priority traffic (even if the than the bandwidth made available to priority traffic (even if the
non-priority traffic is not using all of the bandwidth available for non-priority traffic is not using all of the bandwidth available for
it). it).
----------------------- -----------------------
skipping to change at page 17, line 49 skipping to change at page 19, line 21
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
------------------------- -------------------------
Chart 1. MAM Bandwidth Allocation Figure 4: MAM Bandwidth Allocation
Chart 1 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 calls, no load reaches the maximum bandwidth reserved for priority calls, no
additional priority sessions can be accepted. additional priority sessions can be accepted.
As illustrated in Chart 1, an operator may map the MAM model onto the As illustrated in Figure 4, an operator may map the MAM model onto
Engineered Capacity limits according to different policies. At one the Engineered Capacity limits according to different policies. At
extreme, where the proportion of priority traffic is reliably known one extreme, where the proportion of priority traffic is reliably
to be fairly small at all times and where there may be some safety known to be fairly small at all times and where there may be some
margin factored in the engineered capacity limits, the operator may safety margin factored in the engineered capacity limits, the
decide to configure the bandwidth available for non-priority use to operator may decide to configure the bandwidth available for non-
the full engineered capacity limits; effectively allowing the priority use to the full engineered capacity limits; effectively
priority traffic to ride within the safety margin of this engineered allowing the priority traffic to ride within the safety margin of
capacity. This policy can be seen as an economically attractive this engineered capacity. This policy can be seen as an economically
approach as all of the engineered capacity is made available to non- attractive approach as all of the engineered capacity is made
priority calls. This policy illustrated as (1) in Chart 1. As an available to non-priority calls. This policy is illustrated as (1)
example, if the engineered capacity limit on a given link is X, the in Figure 4. As an example, if the engineered capacity limit on a
operator may configure the bandwidth available to non-priority given link is X, the operator may configure the bandwidth available
traffic to X, and the bandwidth available to priority traffic to 5% to non-priority traffic to X, and the bandwidth available to priority
of X. traffic to 5% of X. At the other extreme, where the proportion of
priority traffic may be significant at times and the engineered
At the other extreme, where the proportion of priority traffic may be capacity limits are very tight, the operator may decide to configure
significant at times and the engineered capacity limits are very the bandwidth available to non-priority traffic and the bandwidth
tight, the operator may decide to configure the bandwidth available available to priority traffic such that their sum is equal to the
to non-priority traffic and the bandwidth available to priority engineered capacity limits. This guarantees that the total load
traffic such that their sum is equal to the engineered capacity across non-priority and priority traffic is always below the
limits. This guarantees that the total load across non-priority and engineered capacity and, in turn, guarantees there will never be any
priority traffic is always below the engineered capacity and, in QoS degradation. However, this policy is less attractive
turn, guarantees there will never be any QoS degradation. However, economically as it prevents non-priority calls from using the full
this policy is less attractive economically as it prevents non- engineered capacity, even when there is no or little priority load,
priority calls from using the full engineered capacity, even when which is the majority of time. This policy is illustrated as (3) in
there is no or little priority load, which is the majority of time. Figure 4. As an example, if the engineered capacity limit on a given
This policy illustrated as (3) in Chart 1. As an example, if the link is X, the operator may configure the bandwidth available to non-
engineered capacity limit on a given link is X, the operator may priority traffic to 95% of X, and the bandwidth available to priority
configure the bandwidth available to non-priority traffic to 95% traffic to 5% of X. Of course, an operator may also strike a balance
of X, and the bandwidth available to priority traffic to 5% of X. anywhere in between these two approaches. This policy is illustrated
as (2) in Figure 4.
Of course, an operator may also strike a balance anywhere in between
these two approaches. This policy illustrated as (2) in Chart 1.
Chart 2 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
------------------------- -------------------------
Chart 2. Partial load of non-priority calls
Chart 3 shows the same amount of non-priority load being used at this Figure 5: Partial load of non-priority calls
link, and a small amount of priority bandwidth being used.
Figure 6 shows the same amount of non-priority load being used at
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
------------------------- -------------------------
Chart 3. Partial load of non-priority calls Figure 6: Partial load of non-priority calls & partial load of
& partial load of priority calls priority calls Calls
Chart 4 shows the case where non-priority load equates or exceeds the Figure 7 shows the case where non-priority load equates or exceeds
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
------------------------- -------------------------
Chart 4. Full non-priority load
& partial load of priority calls
Chart 5 shows the case where the priority traffic equates or exceeds Figure 7: Full non-priority load & partial load of priority calls
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. Note In that case additional priority sessions could not be accepted.
that this does not mean that such calls are dropped altogether: they Note that this does not mean that such calls are dropped altogether:
may be handled by mechanisms, which are beyond the scope of this they may be handled by mechanisms, which are beyond the scope of this
particular document (such as establishment through preemption of particular document (such as establishment 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).
----------------------- -----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^ ^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . Available . . . |xxxxxxxxxxxxxx| . Available
skipping to change at page 20, line 47 skipping to change at page 22, 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
------------------------- -------------------------
Chart 5. 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
Engineered Capacity limits according to different policies. The Engineered Capacity limits according to different policies. The
operator may decide to configure the bandwidth available for non- operator may decide to configure the bandwidth available for non-
skipping to change at page 21, line 33 skipping to change at page 23, 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.
Chart 6 shows the case where only some of the bandwidth available to Figure 9 shows the case where only some of the bandwidth available 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 sessions traffic is in place. In that situation both new non-priority
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
--------------------------------------- ---------------------------------------
Chart 6. Partial non-priority load & Partial Aggregate load Figure 9: Partial non-priority load & Partial Aggregate load
Chart 7 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
--------------------------------------- ---------------------------------------
Chart 7. Full non-priority load & Partial Aggregate load Figure 10: Full non-priority load & Partial Aggregate load
Chart 8 shows the case where only some of the bandwidth available to Figure 11 shows the case where only some of the bandwidth available
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 sessions traffic is in place. In that situation both new non-priority
and new priority sessions would be accepted. sessions and new priority sessions would be accepted. Note that, as
Note that, as illustrated in Chart 7, priority calls use some of the illustrated in Figure 10, priority calls use some of the bandwidth
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
--------------------------------------- ---------------------------------------
Chart 8. Partial non-priority load & Heavy Aggregate load Figure 11: Partial non-priority load & Heavy Aggregate load
Chart 9 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 23, line 30 skipping to change at page 25, 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
--------------------------------------- ---------------------------------------
Chart 9. 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:
- when a non-priority call arrives, this call is subject to
bandwidth admission control and is accepted if the current total load o when a non-priority call arrives, this call is subject to
(aggregate over non-priority and priority traffic) is below the bandwidth admission control and is accepted if the current total
engineered/allocated bandwidth. load (aggregate over non-priority and priority traffic) is below
- when a priority call arrives, this call is admitted regardless the engineered/allocated bandwidth.
of the current load.
o when a priority call arrives, this call is admitted regardless of
the current load.
A property of this model is that a priority call is never rejected. A property of this model is that a priority call is never 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:
- the volume of priority calls is very low for the vast majority
of time, so it may not be economical to completely set aside o the volume of priority calls is very low for the vast majority of
bandwidth for priority calls and preclude the utilization of time, so it may not be economical to completely set aside
this bandwidth by normal calls in normal situations bandwidth for priority calls and preclude the utilization of this
- even in emergency periods where priority calls are more heavily bandwidth by normal calls in normal situations
o even in emergency periods where priority calls are more heavily
used, those always still represent a fairly small proportion of used, those always still represent a fairly small proportion of
the overall load which can be absorbed within the safety margin the overall load which can be absorbed within the safety margin of
of the engineered capacity limits. Thus, even if they are the engineered capacity limits. Thus, even if they are admitted
admitted beyond the engineered bandwidth threshold, they are beyond the engineered bandwidth threshold, they are unlikely to
unlikely to result in noticeable QoS degradation. 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.
Chart 10 shows 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 | |
| | | |
Chart 10. Priority Bypass Model Bandwidth Allocation Figure 13: Priority Bypass Model Bandwidth Allocation
Chart 11 shows some of the non-priority capacity of this link being
used. In this situation, both new non-priority and new priority calls Figure 14 shows some of the non-priority capacity of this link being
would be accepted. used. In this situation, both new non-priority and new priority
calls 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 | |
| | | |
Chart 11. Partial load of non-priority calls Figure 14: Partial load of non-priority calls
Chart 12 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 calls would be this situation, both new non-priority and new priority calls would be
accepted. 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 | |
| | | |
Chart 12. Partial load of non-priority calls Figure 15: Partial load of non-priority calls & partial load of
& partial load of priority calls priority calls
Chart 13 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 call is rejected traffic. In this situation, any new non-priority call is rejected
while any new priority call is admitted. while any new priority call 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 | |
| | | |
Chart 13. 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 Emergency 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.
skipping to change at page 26, line 46 skipping to change at page 28, line 44
In a mild abuse of language, we refer here to "Call Queueing" as the In a mild abuse of language, we refer here to "Call Queueing" as the
set of "session" layer capabilities that may be implemented by SIP set of "session" layer capabilities that may be implemented by SIP
user agents to influence their treatment of SIP requests. This may user agents to influence their treatment of SIP requests. This may
include the ability to "queue" call requests when those can not be include the ability to "queue" call requests when those can not be
immediately honored (in some cases with the notion of "bumping", or immediately honored (in some cases with the notion of "bumping", or
"displacement", of less important call request from that queue). It "displacement", of less important call request from that queue). It
may include additional mechanisms such as exemption from certain may include additional mechanisms such as exemption from certain
network management controls, and alternate routing. network 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 at enforced by PEPs. It is assumed that these policy elements are set
administrative domain boundaries by PDPs. The Admission Priority and at administrative domain boundaries by PDPs. The Admission Priority
Preemption Priority RSVP policy elements are set by PDPs as a result and Preemption Priority RSVP policy elements are set by PDPs as a
of processing the Application Level Resource Priority Policy Element result of processing the Application Level Resource Priority Policy
(which is carried in RSVP messages). Element (which is carried in RSVP messages).
If one wants to implement an emergency service purely based on Call If one wants to implement an emergency service purely based on Call
Queueing, one can achieve this by signaling emergency calls: Queueing, one can achieve this by signaling emergency calls:
* using "Resource-Priority" Header in SIP
* not using Admission-Priority Policy Element in RSVP
* not using Preemption Policy Element in RSVP
If one wants to implement an emergency service based on Call o using "Resource-Priority" Header in SIP
Queueing and on "prioritized access to network layer resources", one
can achieve this by signaling emergency calls: o not using Admission-Priority Policy Element in RSVP
* using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP o not using Preemption Policy Element in RSVP
* not using Preemption Policy Element in RSVP
If one wants to implement an emergency service based on Call Queueing
and on "prioritized access to network layer resources", one can
achieve this by signaling emergency calls:
o using "Resource-Priority" Header in SIP
o using Admission-Priority Policy Element in RSVP
o not using Preemption Policy Element in RSVP
Emergency calls will not result in preemption of any session. Emergency calls will not result in preemption of any session.
Different bandwidth allocation models can be used to offer different Different bandwidth allocation models can be used to offer different
"prioritized access to network resources". Just as examples, this "prioritized access to network resources". Just as examples, this
includes strict setting aside of capacity for emergency sessions as includes strict setting aside of capacity for emergency sessions as
well as simple bypass of admission limits for emergency sessions. well as simple bypass of admission limits for emergency sessions.
If one wants to implement an emergency service based on Call If one wants to implement an emergency service based on Call
Queueing, Queueing, on "prioritized access to network layer resources", and
on "prioritized access to network layer resources", and ensures that ensures that (say) "Emergency-1" sessions can preempt "Emergency-2"
(say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but sessions, but non-emergency sessions are not affected by preemption,
non-emergency sessions are not affected by preemption, one can do one can do that by signaling emergency calls:
that by signaling emergency calls:
* using "Resource-Priority" Header in SIP o using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP
* using Preemption Policy Element in RSVP with: o using Admission-Priority Policy Element in RSVP
o setup (Emergency-1) > defending (Emergency-2)
o setup (Emergency-2) <= defending (Emergency-1) o using Preemption Policy Element in RSVP with:
o setup (Emergency-1) <= defending (Non-Emergency)
o setup (Emergency-2) <= defending (Non-Emergency) * setup (Emergency-1) > defending (Emergency-2)
* setup (Emergency-2) <= defending (Emergency-1)
* setup (Emergency-1) <= defending (Non-Emergency)
* setup (Emergency-2) <= defending (Non-Emergency)
If one wants to implement an emergency service based on Call If one wants to implement an emergency service based on Call
Queueing, Queueing, on "prioritized access to network layer resources", and
on "prioritized access to network layer resources", and ensure that ensure that "emergency" sessions can preempt regular sessions, one
"emergency" sessions can preempt regular sessions, one could do that could do that by signaling emergency calls:
by signaling emergency calls:
* using "Resource-Priority" Header in SIP o using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP
* using Preemption Policy Element in RSVP with: o using Admission-Priority Policy Element in RSVP
o setup (Emergency) > defending (Non-Emergency)
o setup (Non-Emergency) <= defending (Emergency) o using Preemption Policy Element in RSVP with:
* setup (Emergency) > defending (Non-Emergency)
* setup (Non-Emergency) <= defending (Emergency)
If one wants to implement an emergency service based on Call If one wants to implement an emergency service based on Call
Queueing, Queueing, on "prioritized access to network layer resources", and
on "prioritized access to network layer resources", and ensure that ensure that "emergency" sessions can partially preempt regular
"emergency" sessions can partially preempt regular sessions (ie sessions (ie reduce their reservation size), one could do that by
reduce their reservation size), one could do that by signaling signaling emergency calls:
emergency calls:
* using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP
* using Preemption in Policy Element RSVP with:
o setup (Emergency) > defending (Non-Emergency)
o setup (Non-Emergency) <= defending (Emergency)
* activate RFC4495 RSVP Bandwidth Reduction mechanisms
Authors' Address o using "Resource-Priority" Header in SIP
o using Admission-Priority Policy Element in RSVP
o using Preemption in Policy Element RSVP with:
* setup (Emergency) > defending (Non-Emergency)
* setup (Non-Emergency) <= defending (Emergency)
o activate RFC4495 RSVP Bandwidth Reduction mechanisms
Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems, Inc. Cisco Systems
Village d'Entreprise Green Side - Batiment T3 Greenside, 400 Avenue de Roumanille
400, Avenue de Roumanille Sophia Antipolis 06410
06410 Biot Sophia-Antipolis
France France
Email: flefauch@cisco.com
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
James Polk James Polk
Cisco Systems, Inc. Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Highway
Richardson, Texas 75082 Richardson, TX 75082-3550
USA United States
Phone: +1 972 813 5208
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Ken Carlberg Ken Carlberg
G11 G11
123a Versailles Circle 123a Versailles Circle
Towson, MD. 21204 Towson, MD 21204
USA United States
email: carlberg@g11.org.uk
Email: carlberg@g11.org.uk
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 29, line 17 skipping to change at page 32, line 42
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 149 change blocks. 
513 lines changed or deleted 635 lines changed or added

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