draft-ietf-tsvwg-emergency-rsvp-00.txt   draft-ietf-tsvwg-emergency-rsvp-01.txt 
RSVP Extensions for Emergency Services October 2006 RSVP Extensions for Emergency Services January 2007
Internet Draft Francois Le Faucheur Internet Draft Francois Le Faucheur
James Polk James Polk
Cisco Systems, Inc. Cisco Systems, Inc.
Ken Carlberg Ken Carlberg
G11 G11
draft-ietf-tsvwg-emergency-rsvp-00.txt draft-ietf-tsvwg-emergency-rsvp-01.txt
Expires: April 2007 October 2006 Expires: July 2007 January 2007
RSVP Extensions for Emergency Services Resource ReSerVation Protovol (RSVP) Extensions for Emergency
Services
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 other
skipping to change at page 2, line 5 skipping to change at page 2, line 5
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 be
facilitated through a network layer admission control solution, which facilitated through a network layer admission control solution, which
supports prioritized access to resources (e.g., bandwidth). These supports prioritized access to resources (e.g., bandwidth). These
resources may be explicitly set aside for emergency services, or they resources may be explicitly set aside for emergency services, or they
may be shared with other sessions. may be shared with other sessions.
RSVP Extensions for Emergency Services October 2006 RSVP Extensions for Emergency Services January 2007
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 that
these extensions represent one possible solution component in 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 Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[KEYWORDS] and indicate requirement levels for compliant
implementations.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................3
1.1. Related Work...............................................3 1.1. Related Technical Documents................................3
1.2. Terminology................................................4 1.2. Terminology................................................4
1.3. Changes from previous versions.............................4 1.3. Changes from previous versions.............................5
2. Overview of RSVP extensions and Operations.....................5 2. Overview of RSVP extensions and Operations.....................6
2.1. Operations of Admission Priority..........................8 2.1. Operations of Admission Priority..........................8
3. New Policy Elements............................................8 3. New Policy Elements............................................8
3.1. Admission Priority Policy Element.........................9 3.1. Admission Priority Policy Element.........................9
3.1.1. Admission Priority Merging Rules 10 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.......11
3.2.1. Application-Level Resource Priority Modifying and 3.2.1. Application-Level Resource Priority Modifying and
Merging Rules 12 Merging Rules 12
4. Security Considerations.......................................12 4. Security Considerations.......................................12
5. IANA Considerations...........................................12 4.1. Use of RSVP Authentication...............................13
6. Acknowledgments...............................................13 4.2. Use of INTEGRITY object within the POLICY_DATA object....14
7. Normative References..........................................13 5. IANA Considerations...........................................14
8. Informative References........................................13 6. Acknowledgments...............................................15
7. Normative References..........................................15
8. Informative References........................................16
Appendix A: Examples of Bandwidth Allocation Model for Admission Appendix A: Examples of Bandwidth Allocation Model for Admission
Priority.........................................................14 Priority.........................................................16
A.1 Admission Priority with Maximum Allocation Model (MAM)......14 A.1 Admission Priority with Maximum Allocation Model (MAM)......17
A.2 Admission Priority with Russian Dolls Model (RDM)...........18 A.2 Admission Priority with Russian Dolls Model (RDM)...........20
A.3 Admission Priority with Priority Bypass Model (PBM).........20 A.3 Admission Priority with Priority Bypass Model (PBM).........23
Appendix B: Example Usages of RSVP Extensions....................23 Appendix B: Example Usages of RSVP Extensions....................26
Authors' Address.................................................25 Authors' Address.................................................27
1. Introduction RSVP Extensions for Emergency Services January 2007
RSVP Extensions for Emergency Services October 2006 1. Introduction
[EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency [EMERG-RQTS] and [EMERG-TEL] 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 to
present requirements that elevate the probability of session 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 an
example, entities involved in session control (such as SIP user example, entities involved in session control (such as SIP user
agents, when SIP is the session control protocol in use) can agents, when the Session Initiation Protocol, SIP [SIP], is the
influence their treatment of session establishment requests (such as session control protocol in use) can influence their treatment of
SIP requests). This may include the ability to "queue" call requests session establishment requests (such as SIP requests). This may
when those can not be immediately honored (in some cases with the include the ability to "queue" call requests when those can not be
notion of "bumping", or "displacement", of less important call immediately honored (in some cases with the notion of "bumping", or
request from that queue). It may include additional mechanisms such "displacement", of less important call request from that queue). It
as exemption from certain network management controls, and alternate may include additional mechanisms such as exemption from certain
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
control mechanisms supporting admission priority. Networks usually control mechanisms supporting admission priority. Networks usually
have engineered capacity limits that characterize the maximum load have engineered capacity limits that characterize the maximum load
that can be handled (say, on any given link) for a class of traffic that can be handled (say, on any given link) for a class of traffic
while satisfying the quality of service requirements of that traffic while satisfying the quality of service requirements of that traffic
class. Admission priority may involve setting aside some network class. Admission priority may involve setting aside some network
resources (e.g. bandwidth) out of the engineered capacity limits for resources (e.g. bandwidth) out of the engineered capacity limits for
the emergency services only. Or alternatively, it may involve the emergency services only. Or alternatively, it may involve
allowing the emergency related sessions to seize additional resources allowing the emergency related sessions to seize additional resources
beyond the engineered capacity limits applied to normal calls. beyond the engineered capacity limits applied to normal calls.
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 Work 1.1. Related Technical Documents
RSVP Extensions for Emergency Services January 2007
[EMERG-IMP] is patterned after [ITU.I.225] and describes an example [EMERG-IMP] is patterned after [ITU.I.225] and describes an example
of one type of prioritized network layer admission control procedure of 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
RSVP Extensions for Emergency Services October 2006
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. [EMERG-IMP] 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 [RSVP] 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 ([FW-POLICY], [RSVP-POLICY]), for user
authentication and authorization ([RSVP-ID]) and for integrity and authentication and authorization ([RSVP-ID]) and for integrity and
authentication of RSVP messages ([RSVP-CRYPTO-1], [RSVP-CRYPTO-2]). authentication of RSVP messages ([RSVP-CRYPTO-1], [RSVP-CRYPTO-2]).
Furthermore, [EMERG-IMP] describes how the RSVP Signaled Preemption Furthermore, [EMERG-IMP] describes how the RSVP Signaled Preemption
skipping to change at page 4, line 52 skipping to change at page 5, line 5
- Local Policy Decision Point (LPDP): PDP local to the network - Local Policy Decision Point (LPDP): PDP local to the network
element element
- Policy Enforcement Point (PEP): The point where the policy - 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 - 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]. [FW-POLICY].
RSVP Extensions for Emergency Services January 2007
1.3. Changes from previous versions 1.3. Changes from previous versions
[Note to RFC Editor: This section is to be removed before
publication]
RSVP Extensions for Emergency Services October 2006 Changes from ietf-tsvwg-emergency-rsvp-00 to ietf-tsvwg-
emergency-rsvp-01
The most significant changes are:
o editorial change (correction in description of
"Take highest priority" in section 3.1.1).
o expanded Security Considerations section
Changes from lefaucheur-rsvp-emergency-01 to ietf-tsvwg-rsvp- Changes from lefaucheur-rsvp-emergency-01 to ietf-tsvwg-rsvp-
emergency-00 emergency-00
The most significant change is: The most significant change is:
o Extended the Admission Priority field from 3 to 8 bits and o Extended the Admission Priority field from 3 to 8 bits and
inverted the encoding order, in particular for better inverted the encoding order, in particular for better
alignment with NSIS Qspec. alignment with NSIS Qspec.
skipping to change at page 5, line 38 skipping to change at page 6, line 5
ALRP Policy Element ALRP Policy Element
o Added a 2nd appendix providing examples of RSVP extensions o Added a 2nd appendix providing examples of RSVP extensions
usage usage
Changes from lefaucheur-rsvp-emergency-00 to lefaucheur-rsvp- Changes from lefaucheur-rsvp-emergency-00 to lefaucheur-rsvp-
emergency-01 emergency-01
The most significant changes were: The most significant changes were:
RSVP Extensions for Emergency Services January 2007
o adding a second RSVP Policy Element that contains the o adding a second RSVP Policy Element that contains the
application-level resource priority requirements (for example application-level resource priority requirements (for example
as communicated in the SIP Resource-Priority Header) for as communicated in the SIP Resource-Priority Header) for
scenarios where priority calls transits through multiple scenarios where priority calls transits through multiple
administrative domains. administrative domains.
o adding description of a third bandwidth allocation model o adding description of a third bandwidth allocation model
example: the Priority Bypass Model example: the Priority Bypass Model
o adding discussion on policies for mapping the various o adding discussion on policies for mapping the various
bandwidth allocation model over the engineered capacity limits. bandwidth allocation model over the engineered capacity limits.
2. Overview of RSVP extensions and Operations 2. Overview of RSVP extensions and Operations
RSVP Extensions for Emergency Services October 2006
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.
skipping to change at page 6, line 40 skipping to change at page 7, line 4
end-devices involved in the upper-layer session establishment simply end-devices involved in the upper-layer session establishment simply
need to copy the application-level resource priority requirements need to copy the application-level resource priority requirements
(e.g. as communicated in SIP Resource-Priority Header) inside the new (e.g. as communicated in SIP Resource-Priority Header) inside the new
RSVP Application-Level Resource-Priority Policy Element defined in RSVP Application-Level Resource-Priority Policy Element defined in
this document. this document.
Conveying the application-level resource priority requirements inside Conveying the application-level resource priority requirements inside
the RSVP message allows this application level requirement to be the RSVP message allows this application level requirement to be
mapped/remapped into a different RSVP "admission priority" at every mapped/remapped into a different RSVP "admission priority" at every
administrative domain boundary based on the policy applicable in that administrative domain boundary based on the policy applicable in that
RSVP Extensions for Emergency Services January 2007
domain. In a typical model (see [FW-POLICY]) where PDPs control PEPs domain. In a typical model (see [FW-POLICY]) 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
Application-Level Resource-Priority semantics. Application-Level Resource-Priority semantics.
As an example of operation across multiple administrative domains, a As an example of operation across multiple administrative domains, a
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
RSVP Extensions for Emergency Services October 2006
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 [SIP-
PRIORITY], for support of scenarios where calls traverse multiple PRIORITY], for support of scenarios where calls traverse multiple
skipping to change at page 7, line 40 skipping to change at page 8, line 4
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 mapping/remapping application level resource priority requirements
into an RSVP admission priority can also be used together with [RSVP- into an RSVP admission priority can also be used together with [RSVP-
PREEMP] for mapping/remapping application level resource priority PREEMP] for mapping/remapping application level resource priority
requirements into an RSVP preemption priority (when preemption is requirements into an RSVP preemption priority (when preemption is
indeed needed). In that case, when processing the RSVP Application- indeed needed). In that case, when processing the RSVP Application-
RSVP Extensions for Emergency Services January 2007
Level Resource-Priority Policy Element, the PDPs at boundaries Level Resource-Priority Policy Element, the PDPs at boundaries
between administrative domains (or between various QoS signaling between administrative domains (or between various QoS signaling
protocols) can map it into an RSVP "preemption priority" information. protocols) can map it into an RSVP "preemption priority" information.
This Preemption priority information comprises a setup preemption This Preemption priority information comprises a setup preemption
level and a defending preemption priority level. This preemption level and a defending preemption priority level. This preemption
priority information can then be encoded inside the Preemption priority information can then be encoded inside the Preemption
Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into
account at every RSVP-enabled network hop as discussed [EMERG-IMP]. account at every RSVP-enabled network hop as discussed [EMERG-IMP].
Appendix B provides examples of various hypothetical policies for Appendix B provides examples of various hypothetical policies for
emergency call handling, some of them involving admission priority, emergency call handling, some of them involving admission priority,
some of them involving both admission priority and preemption some of them involving both admission priority and preemption
priority. Appendix B also identifies how the Application-Level priority. Appendix B also identifies how the Application-Level
Resource Priority need to be mapped into RSVP policy elements by the Resource Priority need to be mapped into RSVP policy elements by the
PDPs to realize these policies. PDPs to realize these policies.
RSVP Extensions for Emergency Services October 2006
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.
skipping to change at page 8, line 41 skipping to change at page 9, line 5
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 - the Application-Level Resource Priority Policy Element conveys
application level information and is processed by PDPs application level information and is processed by PDPs
RSVP Extensions for Emergency Services January 2007
- the emphasis of Admission Priority Policy Element is to be - the emphasis of Admission Priority Policy Element is to be
simple, stateless, and light-weight such that it can be simple, stateless, and light-weight such that it can be
processed internally within a node's LPDP. It can then be processed internally within a node's LPDP. It can then be
enforced internally within a node's PEP. It is set by PDPs enforced internally within a node's PEP. It is set by PDPs
based on processing of the Application-Level Resource Priority based on processing of the Application-Level Resource Priority
Policy Element. Policy Element.
[RSVP-POLICY] defines extensions for supporting generic policy based [RSVP-POLICY] 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
RSVP Extensions for Emergency Services October 2006
example, [RSVP-PREEMP] specifies the Preemption Priority Policy example, [RSVP-PREEMP] 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 Admission Priority Policy Element
- the Application-Level Resource Priority Policy Element - 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 follows:
skipping to change at page 9, line 39 skipping to change at page 10, line 4
P-Type: 16 bits P-Type: 16 bits
ADMISSION_PRI = To be allocated by IANA ADMISSION_PRI = To be allocated by IANA
(see "IANA Considerations" section) (see "IANA Considerations" section)
Flags: Reserved (MUST be set to zero on transmit and ignored on Flags: Reserved (MUST be set to zero on transmit and ignored on
receive) receive)
Merge Strategy: 8 bit (only applicable to multicast flows) Merge Strategy: 8 bit (only applicable to multicast flows)
1 Take priority of highest QoS 1 Take priority of highest QoS
2 Take highest priority 2 Take highest priority
RSVP Extensions for Emergency Services January 2007
3 Force Error on heterogeneous merge 3 Force Error on heterogeneous merge
Error code: 8 bits (only applicable to multicast flows) Error code: 8 bits (only applicable to multicast flows)
0 NO_ERROR Value used for regular ADMISSION_PRI elements 0 NO_ERROR Value used for regular ADMISSION_PRI elements
2 HETEROGENEOUS This element encountered heterogeneous merge 2 HETEROGENEOUS This element encountered heterogeneous merge
Reserved: 8 bits Reserved: 8 bits
Always 0. Always 0.
Adm. Priority (Admission Priority): 8 bits (unsigned) Adm. Priority (Admission Priority): 8 bits (unsigned)
The admission control priority of the flow, in terms of access The admission control priority of the flow, in terms of access
to network bandwidth in order to provide higher probability of to network bandwidth in order to provide higher probability of
call completion to selected flows. Higher values represent call completion to selected flows. Higher values represent
higher Priority. higher Priority.
Bandwidth allocation models such as those described in Appendix Bandwidth allocation models such as those described in Appendix
RSVP Extensions for Emergency Services October 2006
A are to be used by the RSVP router to achieve such increased A are to be used by the RSVP router to achieve such increased
probability of call completion. The admission priority value probability of call completion. The admission priority value
effectively indicates which bandwidth constraint(s) of the effectively indicates which bandwidth constraint(s) of the
bandwidth constraint model in use is(are) applicable to bandwidth constraint model in use is(are) applicable to
admission of this RSVP reservation. admission of this RSVP reservation.
Reserved: 16 bits Reserved: 16 bits
Always 0. Always 0.
Note that the Admission Priority Policy Element does NOT indicate Note that the Admission Priority Policy Element does NOT indicate
skipping to change at page 10, line 40 skipping to change at page 11, line 4
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 [RSVP-PREEMP] for merging Preemption Priority
Policy Elements. In particular, the following merging strategies are Policy Elements. In particular, the following merging strategies are
supported: supported:
- Take priority of highest QoS - Take priority of highest QoS
- Take highest priority - Take highest priority
- Force Error on heterogeneous merge. - Force Error on heterogeneous merge.
RSVP Extensions for Emergency Services January 2007
The only difference with [RSVP-PREEMP] is that this document does not The only difference with [RSVP-PREEMP] is that this document does not
recommend any merge strategies for Admission Priority while [RSVP- recommend any merge strategies for Admission Priority while [RSVP-
PREEMP] recommends the first of these merge strategies for Preemption PREEMP] recommends the first of these merge strategies for Preemption
Priority. Priority.
Note that with the Admission Priority, "Take Highest Priority" Note that with the Admission Priority (as is the case with the
translates into "take the lowest numerical value", while with the Preemption Priority), "Take highest priority" translates into "take
Preemption Priority it translates into "take the highest numerical the highest numerical value".
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 follows:
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
RSVP Extensions for Emergency Services October 2006
| 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- 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 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 P-Type: 16 bits
skipping to change at page 11, line 40 skipping to change at page 12, line 5
represents the position of the namespace in the "Resource- represents the position of the namespace in the "Resource-
Priority Namespace" IANA registry, starting with 0. Creation Priority Namespace" IANA registry, starting with 0. Creation
of this registry has been requested to IANA in [SIP- of this registry has been requested to IANA in [SIP-
PRIORITY]. PRIORITY].
For example, as "drsn", "dsn", "q735", "ets" and "wps" are For example, as "drsn", "dsn", "q735", "ets" and "wps" are
currently the first, second, third, fourth and fifth currently the first, second, third, fourth and fifth
namespaces defined in the "Resource-Priority Namespace" namespaces defined in the "Resource-Priority Namespace"
registry, those are respectively encoded as value 0, 1, 2, 3 registry, those are respectively encoded as value 0, 1, 2, 3
and 4. and 4.
RSVP Extensions for Emergency Services January 2007
ALRP Priority: (Application-Level Resource Priority Priority): ALRP Priority: (Application-Level Resource Priority Priority):
8 bits (unsigned) 8 bits (unsigned)
Contains the priority value within the namespace of the Contains the priority value within the namespace of the
application-level resource priority. This is encoded as a application-level resource priority. This is encoded as a
numerical value which represents the priority defined in the numerical value which represents the priority defined in the
"Resource-Priority Namespace" IANA registry for the "Resource-Priority Namespace" IANA registry for the
considered namespace, starting from 0 for the highest considered namespace, starting from 0 for the highest
priority and increasing as priority decreases. priority and increasing as priority decreases.
For example, as "flash-override", "flash", "immediate", For example, as "flash-override", "flash", "immediate",
"priority" and "routine" are the priorities in decreasing "priority" and "routine" are the priorities in decreasing
order of priority registered for the "dsn" namespace, those order of priority registered for the "dsn" namespace, those
are respectively encoded as value 0, 1, 2, 3 and 4. As are respectively encoded as value 0, 1, 2, 3 and 4. As
another example, as "flash-override-override", "flash- another example, as "flash-override-override", "flash-
override", "flash", "immediate", "priority" and "routine" override", "flash", "immediate", "priority" and "routine"
are the priorities in decreasing order of priority are the priorities in decreasing order of priority
RSVP Extensions for Emergency Services October 2006
registered for the "drsn" namespace, those are respectively registered for the "drsn" namespace, those are respectively
encoded as value 0, 1, 2, 3, 4 and 5. encoded as value 0, 1, 2, 3, 4 and 5.
Reserved: 16 bits Reserved: 16 bits
Always 0. Always 0.
3.2.1. 3.2.1.
Application-Level Resource Priority Modifying and Merging Rules 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
skipping to change at page 12, line 36 skipping to change at page 12, line 51
all the ALRPs appearing in the ALRP List of an incoming all the ALRPs appearing in the ALRP List of an incoming
APP_RESOURCE_PR element. A given ALRP MUST NOT appear more than APP_RESOURCE_PR element. A given ALRP MUST NOT appear more than
once. In other words, the outgoing ALRP List is the reunion of once. In other words, the outgoing ALRP List is the reunion of
the incoming ARLP Lists that are merged. the incoming ARLP 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.
4. Security Considerations 4. Security Considerations
The integrity of ADMISSION_PRI and APP_RESOURCE_PRI is guaranteed, as The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can
any other policy element, by the encapsulation into a Policy Data be signaled by RSVP through encapsulation in a Policy Data object as
object [RSVP-POLICY]. The two optional security mechanisms discussed defined in [RSVP-POLICY]. Therefore, like any other Policy Elements,
in section 6 of [RSVP-POLICY] can be used to protect the their integrity can be protected as discussed in section 6 of [RSVP-
ADMISSION_PRI and APP_RESOURCE_PRI policy elements.
RSVP Extensions for Emergency Services January 2007
POLICY] by two optional security mechanisms. The first mechanism
relies on RSVP Authentication as specified in [RSVP-CRYPTO-1] and
[RSVP-CRYPTO-2] to provide a chain of trust when all RSVP nodes are
policy capable. The second mechanism relies on the INTEGRITY object
within the POLICY_DATA object to guarantee integrity between RSVP
Policy Enforcement Points (PEPs) that are not RSVP neighbors.
4.1. Use of RSVP Authentication
[RSVP-CRYPTO-1] discusses several approaches for distribution of keys
to be used for RSVP Authentication. First, the RSVP Authentication
shared keys can be distributed manually. This is the base option and
its support is mandated for any implementation. However, in some
environments, this approach may become a burden if keys frequently
change over time. Alternatively, a standard key management protocol
for secure key distribution can be used. However, existing key
distribution protocols may not be appropriate in all environments
because of the complexity or operational burden they involve. Finally,
[RSVP-CRYPTO-1] specifies how Kerberos [KERBEROS] may be used to
generate the RSVP Authentication keys. Kerberos allows for the use of
trusted third party keying relationships between security principals
(RSVP sender and receivers) where the Kerberos key distribution
center (KDC) establishes an ephemeral session key to be shared
between RSVP sender and receivers.
The use of RSVP Authentication in parts of the network where there
may be one or more IP hops in between two RSVP neighbors raises an
additional challenge. This is because, with some RSVP messages such
as a Path message, an RSVP router does not know the RSVP next hop for
that message at the time of forwarding it. In fact, part of the role
of a Path message is precisely to discover the RSVP next hop (and to
dynamically re-discover it when it changes, say because of a routing
change). Hence, the RSVP router may not know which security
association to use when forwarding such a message.
In that situation, one approach is to share the same RSVP
Authentication shared key across all the RSVP routers of a part of
the network where there may be RSVP neighbors with IP hops in between.
For example, all the RSVP routers of an administrative domain could
share the same RSVP Authentication key, while different per-neighbor
keys could be used between any RSVP router pair straddling the
boundary between two administrative domains that have agreed to use
RSVP signaling.
When the same RSVP Authentication shared key is to be shared among
multiple RSVP neighbors, manual key distribution may be used. For
situations where RSVP is being used for multicast flows, it might
also be possible, in the future, to adapt a multicast key management
method (e.g. from IETF Multicast Security Working Group) for key
distribution with such multicast RSVP usage. For situations where
RSVP Extensions for Emergency Services January 2007
RSVP is being used for unicast flows within a single administrative
domain, the Kerberos technique described in Section 7 of [RSVP-
CRYPTO-1] might be considered. For situations where RSVP is being
used for unicast flows across domain boundaries, it is not currently
clear how one might provide automated key management. Specification
of a specific automated key management technique is outside the scope
of this document. Operators should consider these key management
issues when contemplating deployment of this specification.
4.2. Use of INTEGRITY object within the POLICY_DATA object
The INTEGRITY object within the POLICY_DATA object can be used to
guarantee integrity between non-neighboring RSVP PEPs.
Details for computation of the content of the INTEGRITY object can be
found in Appendix B of [RSVP-POLICY]. This states that the Policy
Decision Point (PDP), at its discretion, and based on destination
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
manually or via standard key management protocol for secure key
distribution.
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
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
messages (such as a Path message). This is because in those cases the
next PEP is not known at the time of forwarding the message. This
issue is similar to the one discussed in section 4.1, except it now
applies to PDP neighbors instead of RSVP neighbors. Hence similar
approaches could be used, such as the use of a key shared across
multiple PDPs. We observe that this issue may not exist in some
deployment scenarios where a single (or low number of) PDP is used to
control all the PEPs of a region (such as an administrative domain).
In such scenarios, it may be easy for a PDP to determine what is the
next hop PDP, even when the next hop PEP is not known, simply by
determining what is the next region that will be traversed (say based
on the destination address).
5. IANA Considerations 5. IANA Considerations
As specified in [POLICY-RSVP], Standard RSVP Policy Elements (P-type As specified in [RSVP-POLICY], 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 [IANA-CONSIDERATIONS].
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 Admission Priority Policy Element
RSVP Extensions for Emergency Services January 2007
- one P-Type to the Application-Level Resource Priority - one P-Type to the Application-Level Resource Priority
Policy Element Policy Element
RSVP Extensions for Emergency Services October 2006
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 [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input
into this document. into this document.
7. Normative References 7. Normative References
[DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC
4125, June 2005.
[DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June
2005
[EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for
Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
for Emergency Telecommunication Service (ETS)", RFC 3690, February for Emergency Telecommunication Service (ETS)", RFC 3690, February
2004. 2004.
[FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January 2000.
[IANA-CONSIDERATIONS] Alverstrand et al., "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[KEYWORDS] "Key words for use in RFCs to Indicate Requirement Levels",
Bradner, RFC2119, BCP14
[KERBEROS] Neuman et al., "The Kerberos Network Authentication
Service (V5)", RFC 4120, July 2005.
[RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol
(RSVP)- Functional Specification", RFC 2205, September 1997. (RSVP)- Functional Specification", RFC 2205, September 1997.
[FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A [RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP
Framework for Policy-based Admission Control", RFC 2753, January 2000. Cryptographic Authentication", RFC 2747, January 2000.
RSVP Extensions for Emergency Services January 2007
[RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC [RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC
2750, January 2000. 2750, January 2000.
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001. Element", RFC 3181, October 2001.
[DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth [SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261,
Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC [SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource
4125, June 2005. Priority for the Session Initiation Protocol (SIP)", RFC4412,
February 2006.
[DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June
2005
[SIP-PRIORITY] H. Schulzrinne & J. Polk. Communications Resource
Priority for the Session Initiation Protocol (SIP), RFC4412, February
2006.
8. Informative References 8. Informative References
[EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency [EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency
Telecommunications Service for Real Time Services in the Internet Telecommunications Service for Real Time Services in the Internet
Protocol Suite", RFC 4542, May 2006. Protocol Suite", RFC 4542, May 2006.
RSVP Extensions for Emergency Services October 2006
[ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU, [ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU,
Recommendation, I.255.3, July, 1990. Recommendation, I.255.3, July, 1990.
[RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182,
October 2001. October 2001.
[RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation Protocol "Integration of Resource Management and Session Initiation Protocol
(SIP)", RFC 3312, October 2002. (SIP)", RFC 3312, October 2002.
Appendix A: Examples of Bandwidth Allocation Model for Admission Appendix A: Examples of Bandwidth Allocation Model for Admission
Priority Priority
Sections A.1 and A.2 respectively illustrate how the Maximum Sections A.1 and A.2 respectively illustrate how the Maximum
Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE- Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE-
RDM] can be used for support of admission priority. Section A.3 RDM] can be used for support of admission priority. Section A.3
illustrates how a simple "Priority Bypass Model" can also be used for illustrates how a simple "Priority Bypass Model" can also be used for
support of admission priority. 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.
RSVP Extensions for Emergency Services January 2007
In all the charts below: In all the charts 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).
----------------------- -----------------------
RSVP Extensions for Emergency Services October 2006
^ ^ ^ | | ^ ^ ^ ^ | | ^
. . . | | . . . . | | .
Total . . . | | . Bandwidth Total . . . | | . Bandwidth
(1)(2)(3) | | . Available (1)(2)(3) | | . Available
Engi- . . . | | . for non-priority use Engi- . . . | | . for non-priority use
neered .or.or. | | . neered .or.or. | | .
. . . | | . . . . | | .
Capacity. . . | | . Capacity. . . | | .
v . . | | v v . . | | v
. . |--------------| --- . . |--------------| ---
skipping to change at page 15, line 39 skipping to change at page 18, line 4
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 Chart 1, an operator may map the MAM model onto the
Engineered Capacity limits according to different policies. At one Engineered Capacity limits according to different policies. At one
extreme, where the proportion of priority traffic is reliably known extreme, where the proportion of priority traffic is reliably known
RSVP Extensions for Emergency Services January 2007
to be fairly small at all times and where there may be some safety to be fairly small at all times and where there may be some safety
margin factored in the engineered capacity limits, the operator may margin factored in the engineered capacity limits, the operator may
decide to configure the bandwidth available for non-priority use to decide to configure the bandwidth available for non-priority use to
the full engineered capacity limits; effectively allowing the the full engineered capacity limits; effectively allowing the
priority traffic to ride within the safety margin of this engineered priority traffic to ride within the safety margin of this engineered
capacity. This policy can be seen as an economically attractive capacity. This policy can be seen as an economically attractive
approach as all of the engineered capacity is made available to non- approach as all of the engineered capacity is made available to non-
priority calls. This policy illustrated as (1) in Chart 1. As an priority calls. This policy illustrated as (1) in Chart 1. As an
example, if the engineered capacity limit on a given link is X, the example, if the engineered capacity limit on a given link is X, the
operator may configure the bandwidth available to non-priority operator may configure the bandwidth available to non-priority
traffic to X, and the bandwidth available to priority traffic to 5% traffic to X, and the bandwidth available to priority traffic to 5%
of X. of X.
At the other extreme, where the proportion of priority traffic may be At the other extreme, where the proportion of priority traffic may be
significant at times and the engineered capacity limits are very significant at times and the engineered capacity limits are very
tight, the operator may decide to configure the bandwidth available tight, the operator may decide to configure the bandwidth available
to non-priority traffic and the bandwidth available to priority to non-priority traffic and the bandwidth available to priority
RSVP Extensions for Emergency Services October 2006
traffic such that their sum is equal to the engineered capacity traffic such that their sum is equal to the engineered capacity
limits. This guarantees that the total load across non-priority and limits. This guarantees that the total load across non-priority and
priority traffic is always below the engineered capacity and, in turn, priority traffic is always below the engineered capacity and, in turn,
guarantees there will never be any QoS degradation. However, this guarantees there will never be any QoS degradation. However, this
policy is less attractive economically as it prevents non-priority policy is less attractive economically as it prevents non-priority
calls from using the full engineered capacity, even when there is no calls from using the full engineered capacity, even when there is no
or little priority load, which is the majority of time. This policy or little priority load, which is the majority of time. This policy
illustrated as (3) in Chart 1. As an example, if the engineered illustrated as (3) in Chart 1. As an example, if the engineered
capacity limit on a given link is X, the operator may configure the capacity limit on a given link is X, the operator may configure the
bandwidth available to non-priority traffic to 95% of X, and the bandwidth available to non-priority traffic to 95% of X, and the
skipping to change at page 16, line 39 skipping to change at page 19, line 4
. . . | | . 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
RSVP Extensions for Emergency Services January 2007
------------------------- -------------------------
Chart 2. Partial load of non-priority calls Chart 2. Partial load of non-priority calls
Chart 3 shows the same amount of non-priority load being used at this Chart 3 shows the same amount of non-priority load being used at this
link, and a small amount of priority bandwidth being used. 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
RSVP Extensions for Emergency Services October 2006
. . |--------------| --- . . |--------------| ---
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 Chart 3. Partial load of non-priority calls
& partial load of priority calls & partial load of priority calls
Chart 4 shows the case where non-priority load equates or exceeds the Chart 4 shows the case where non-priority load equates or exceeds the
skipping to change at page 17, line 39 skipping to change at page 20, line 5
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 Chart 4. Full non-priority load
& partial load of priority calls & partial load of priority calls
RSVP Extensions for Emergency Services January 2007
Chart 5 shows the case where the priority traffic equates or exceeds Chart 5 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. Note
that this does not mean that such calls are dropped altogether: they that this does not mean that such calls are dropped altogether: they
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 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
RSVP Extensions for Emergency Services October 2006
. . . |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. . . | | . 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
skipping to change at page 18, line 38 skipping to change at page 21, line 5
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-
priority use to the full engineered capacity limits; As an example, priority use to the full engineered capacity limits; As an example,
if the engineered capacity limit on a given link is X, the operator if the engineered capacity limit on a given link is X, the operator
may configure the bandwidth available to non-priority traffic to X, may configure the bandwidth available to non-priority traffic to X,
and the bandwidth available to non-priority and priority traffic to and the bandwidth available to non-priority and priority traffic to
105% of X. 105% of X.
RSVP Extensions for Emergency Services January 2007
Alternatively, the operator may decide to configure the bandwidth Alternatively, the operator may decide to configure the bandwidth
available to non-priority and priority traffic to the engineered available to non-priority and priority traffic to the engineered
capacity limits; As an example, if the engineered capacity limit on a capacity limits; As an example, if the engineered capacity limit on a
given link is X, the operator may configure the bandwidth available given link is X, the operator may configure the bandwidth available
to non-priority traffic to 95% of X, and the bandwidth available to to non-priority traffic to 95% of X, and the bandwidth available to
non-priority and priority traffic to X. non-priority and priority traffic to X.
Finally, the operator may decide to strike a balance in between. The Finally, the operator may decide to strike a balance in between. The
considerations presented for these policies in the previous section considerations presented for these policies in the previous section
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 Chart 6 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 sessions
and new priority sessions would be accepted. and new priority sessions would be accepted.
RSVP Extensions for Emergency Services October 2006
-------------------------------------- --------------------------------------
|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
skipping to change at page 19, line 38 skipping to change at page 22, line 4
-------------------------------------- --------------------------------------
|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
RSVP Extensions for Emergency Services January 2007
|--------------| --- . and priority |--------------| --- . and priority
| | . use | | . use
| | . | | .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Chart 7. Full non-priority load & Partial Aggregate load Chart 7. Full non-priority load & Partial Aggregate load
Chart 8 shows the case where only some of the bandwidth available to Chart 8 shows the case where only some of the bandwidth available to
non-priority traffic is being used and a heavy load of priority 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 sessions
and new priority sessions would be accepted. and new priority sessions would be accepted.
Note that, as illustrated in Chart 7, priority calls use some of the Note that, as illustrated in Chart 7, priority calls use some of the
bandwidth currently not used by non-priority traffic. bandwidth currently not used by non-priority traffic.
-------------------------------------- --------------------------------------
RSVP Extensions for Emergency Services October 2006
|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
skipping to change at page 20, line 38 skipping to change at page 23, line 4
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).
-------------------------------------- --------------------------------------
|xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . Available for . |xxxxxxxxxxxxxx| . Available for .
RSVP Extensions for Emergency Services January 2007
|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
|oooooooooooooo| . use |oooooooooooooo| . use
|oooooooooooooo| . |oooooooooooooo| .
|oooooooooooooo| v |oooooooooooooo| v
--------------------------------------- ---------------------------------------
Chart 9. Full non-priority load & Full Aggregate load Chart 9. Full non-priority load & Full Aggregate load
A.3 Admission Priority with Priority Bypass Model (PBM) A.3 Admission Priority with Priority Bypass Model (PBM)
RSVP Extensions for Emergency Services October 2006
This section illustrates operations of admission priority when a This section illustrates operations of admission priority when a
simple Priority Bypass Model (PBM) is used for bandwidth allocation simple Priority Bypass Model (PBM) 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 - when a non-priority call arrives, this call is subject to
bandwidth admission control and is accepted if the current total load bandwidth admission control and is accepted if the current total load
(aggregate over non-priority and priority traffic) is below the (aggregate over non-priority and priority traffic) is below the
engineered/allocated bandwidth. engineered/allocated bandwidth.
skipping to change at page 21, line 39 skipping to change at page 24, line 4
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 the engineered capacity limits. Thus, even if they are of the engineered capacity limits. Thus, even if they are
admitted beyond the engineered bandwidth threshold, they are admitted beyond the engineered bandwidth threshold, they are
unlikely to result in noticeable QoS degradation. unlikely to result in noticeable QoS degradation.
As with the MAM and RDM model, an operator may map the Priority As with the MAM and RDM model, an operator may map the Priority
Bypass model onto the Engineered Capacity limits according to Bypass model onto the Engineered Capacity limits according to
different policies. The operator may decide to configure the different policies. The operator may decide to configure the
bandwidth limit for admission of non-priority traffic to the full bandwidth limit for admission of non-priority traffic to the full
RSVP Extensions for Emergency Services January 2007
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 Chart 10 shows illustrates the bandwidth allocation with the Priority
Bypass Model. Bypass Model.
----------------------- -----------------------
RSVP Extensions for Emergency Services October 2006
^ ^ | | ^ ^ ^ | | ^
. . | | . . . | | .
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
. |--------------| --- . |--------------| ---
skipping to change at page 22, line 39 skipping to change at page 25, line 4
. . |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
. |--------------| --- . |--------------| ---
. | | . | |
RSVP Extensions for Emergency Services January 2007
v | | v | |
| | | |
Chart 11. Partial load of non-priority calls Chart 11. Partial load of non-priority calls
Chart 12 shows the same amount of non-priority load being used at Chart 12 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
RSVP Extensions for Emergency Services October 2006
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 Chart 12. Partial load of non-priority calls
skipping to change at page 23, line 39 skipping to change at page 26, line 5
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 | |
| | | |
RSVP Extensions for Emergency Services January 2007
Chart 13. Full non-priority load Chart 13. 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. The content of included in this document for illustration purposes. The content of
this appendix may be moved into a future applicability statement this appendix may be moved into a future applicability statement
document. document.
RSVP Extensions for Emergency Services October 2006
We assume an environment where SIP is used for session control and We assume an environment where SIP is used for session control and
RSVP is used for resource reservation. RSVP is used for resource reservation.
In a mild abuse of language, we refer here to "Call Queueing" as the 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
skipping to change at page 24, line 39 skipping to change at page 27, line 4
* not using Admission-Priority Policy Element in RSVP * not using Admission-Priority Policy Element in RSVP
* 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 If one wants to implement an emergency service based on Call
Queueing and on "prioritized access to network layer resources", one Queueing and on "prioritized access to network layer resources", one
can achieve this by signaling emergency calls: can achieve this by signaling emergency calls:
* using "Resource-Priority" Header in SIP * using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP * using Admission-Priority Policy Element in RSVP
* not using Preemption Policy Element in RSVP * 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.
RSVP Extensions for Emergency Services January 2007
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 Queueing, If one wants to implement an emergency service based on Call Queueing,
on "prioritized access to network layer resources", and ensures that on "prioritized access to network layer resources", and ensures that
(say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but
non-emergency sessions are not affected by preemption, one can do non-emergency sessions are not affected by preemption, one can do
that by signaling emergency calls: that by signaling emergency calls:
* using "Resource-Priority" Header in SIP * using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP * using Admission-Priority Policy Element in RSVP
* using Preemption Policy Element in RSVP with: * using Preemption Policy Element in RSVP with:
o setup (Emergency-1) > defending (Emergency-2) o setup (Emergency-1) > defending (Emergency-2)
o setup (Emergency-2) <= defending (Emergency-1) o setup (Emergency-2) <= defending (Emergency-1)
o setup (Emergency-1) <= defending (Non-Emergency) o setup (Emergency-1) <= defending (Non-Emergency)
o setup (Emergency-2) <= defending (Non-Emergency) o setup (Emergency-2) <= defending (Non-Emergency)
RSVP Extensions for Emergency Services October 2006
If one wants to implement an emergency service based on Call Queueing, If one wants to implement an emergency service based on Call Queueing,
on "prioritized access to network layer resources", and ensure that on "prioritized access to network layer resources", and ensure that
"emergency" sessions can preempt regular sessions, one could do that "emergency" sessions can preempt regular sessions, one could do that
by signaling emergency calls: by signaling emergency calls:
* using "Resource-Priority" Header in SIP * using "Resource-Priority" Header in SIP
* using Admission-Priority Policy Element in RSVP * using Admission-Priority Policy Element in RSVP
* using Preemption Policy Element in RSVP with: * using Preemption Policy Element in RSVP with:
o setup (Emergency) > defending (Non-Emergency) o setup (Emergency) > defending (Non-Emergency)
o setup (Non-Emergency) <= defending (Emergency) o setup (Non-Emergency) <= defending (Emergency)
skipping to change at page 25, line 35 skipping to change at page 28, line 4
o setup (Emergency) > defending (Non-Emergency) o setup (Emergency) > defending (Non-Emergency)
o setup (Non-Emergency) <= defending (Emergency) o setup (Non-Emergency) <= defending (Emergency)
* activate RFC4495 RSVP Bandwidth Reduction mechanisms * activate RFC4495 RSVP Bandwidth Reduction mechanisms
Authors' Address Authors' Address
Francois Le Faucheur Francois Le Faucheur
Cisco Systems, Inc. Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3 Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille 400, Avenue de Roumanille
RSVP Extensions for Emergency Services January 2007
06410 Biot Sophia-Antipolis 06410 Biot Sophia-Antipolis
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
James Polk James Polk
Cisco Systems, Inc. Cisco Systems, Inc.
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, Texas 75082 Richardson, Texas 75082
USA USA
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
RSVP Extensions for Emergency Services October 2006
USA USA
email: carlberg@g11.org.uk email: carlberg@g11.org.uk
IPR Statements 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
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. this standard. Please address the information to the IETF at ietf-
Please address the information to the IETF at ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Full Copyright Statement
RSVP Extensions for Emergency Services January 2007
Copyright (C) The Internet Society (2007).
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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Notice
Copyright (C) The Internet Society (2006). 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.
 End of changes. 72 change blocks. 
127 lines changed or deleted 252 lines changed or added

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