--- 1/draft-ietf-tsvwg-emergency-rsvp-04.txt 2008-02-20 21:12:18.000000000 +0100 +++ 2/draft-ietf-tsvwg-emergency-rsvp-05.txt 2008-02-20 21:12:18.000000000 +0100 @@ -1,20 +1,20 @@ - RSVP Extensions for Emergency Services November 2007 + RSVP Extensions for Emergency Services January 2008 TSVWG Francois Le Faucheur Internet-Draft James Polk Intended Status: Standards Track Cisco Systems, Inc. Ken Carlberg G11 - draft-ietf-tsvwg-emergency-rsvp-04.txt - Expires: May 2008 November 19, 2007 + draft-ietf-tsvwg-emergency-rsvp-05.txt + Expires: August 1, 2008 January 31, 2008 Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. @@ -45,33 +45,33 @@ resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. Copyright Notice - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1. Introduction...................................................3 - 1.1. Related Technical Documents.................................3 - 1.2. Terminology.................................................4 + 1.1. Related Technical Documents................................3 + 1.2. Terminology................................................4 2. Overview of RSVP extensions and Operations.....................5 2.1. Operations of Admission Priority..........................7 3. New Policy Elements............................................7 3.1. Admission Priority Policy Element.........................8 3.1.1. Admission Priority Merging Rules 9 3.2. Application-Level Resource Priority Policy Element.......10 3.2.1. Application-Level Resource Priority Modifying and Merging Rules 11 3.3. Default Handling.........................................11 4. Security Considerations.......................................12 @@ -245,21 +245,22 @@ As another example of operation across multiple administrative domains, we can consider the case where the resource priority header enumerates several namespaces, as explicitly allowed by [SIP- PRIORITY], for support of scenarios where calls traverse multiple administrative domains using different namespace. In that case, the relevant namespace can be used at each domain boundary to map into an RSVP Admission priority for that domain. It is not expected that the RSVP Application-Level Resource-Priority Header Policy Element would be taken into account at RSVP-hops within a given administrative domain. It is expected to be used at administrative domain boundaries - only in order to set/reset the RSVP Admission Priority Policy Element. + only in order to set/reset the RSVP Admission Priority Policy + Element. The existence of pre-established inter-domain policy agreements or Service Level Agreements may avoid the need to take real-time action at administrative domain boundaries for mapping/remapping of admission priorities. Mapping/remapping by PDPs may also be applied to boundaries between various signaling protocols, such as those advanced by the NSIS working group. @@ -360,63 +361,71 @@ | Reserved |Adm. Priority| +---------------------------+---------------------------+ Length: 16 bits Always 12. The overall length of the policy element, in bytes. P-Type: 16 bits ADMISSION_PRI = To be allocated by IANA (see "IANA Considerations" section) - Flags: Reserved (MUST be set to zero on transmit and ignored on - receive) + Flags: Reserved (SHALL be set to zero on transmit and SHALL be + ignored on reception) Merge Strategy: 8 bits (only applicable to multicast flows) 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 - Always 0. + SHALL be set to zero on transmit and SHALL be ignored on + reception. Reserved: 24 bits - Always 0. + SHALL be set to zero on transmit and SHALL be ignored on + reception. 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. + 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 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 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. + 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 that this RSVP reservation is to preempt any other RSVP reservation. If a priority session justifies both admission priority and preemption priority, the corresponding RSVP reservation needs to carry both an Admission Priority Policy Element and a Preemption Priority Policy Element. The Admission Priority and Preemption 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 combination. -3.1.1. - Admission Priority Merging Rules +3.1.1. Admission Priority Merging Rules This section discusses alternatives for dealing with RSVP admission priority in case of merging of reservations. As merging is only applicable to multicast, this section also only applies to multicast sessions. The rules for merging Admission Priority Policy Elements are the same as those defined in [RSVP-PREEMP] for merging Preemption Priority Policy Elements. In particular, the following merging strategies are supported: @@ -454,42 +462,41 @@ APP_RESOURCE_PRI = To be allocated by IANA (see "IANA Considerations" section) ALRP: 0 0 0 1 1 2 2 3 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 +---------------------------+-------------+-------------+ | 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 - Always 0. + SHALL be set to zero on transmit and SHALL be ignored on + reception. ALRP Priority: (Application-Level Resource Priority Priority): 8 bits (unsigned) Contains the priority value within the namespace of the application-level resource priority. This value is encoded as per the "Resource-Priority Priority-Value" IANA registry. (See 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 attempt to modify them. They MUST be forwarded as-is to ensure their security envelope is not invalidated. In case of multicast, when POLICY_DATA objects are not protected by integrity, LPDPs MAY merge incoming Application-Level Resource Priority elements to reduce their size and number. When they do merge those, LPDPs MUST do so according to the following rule: @@ -596,32 +602,22 @@ Value = the unique numerical value identifying the namespace" - add a line at the bottom of the registry stating the following "* : [RFCXXX] " where XXX is the RFC number of the present document - 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 existing namespace. Then, in the future, IANA should automatically - allocate a numerical value to any new namespace added to the registry. - - [draft-ietf-nsis-qspec] also uses numerical values for Resource- - Priority Namespaces. To that end, the document requests IANA to - create a new registry to allocate numerical values to each namespace. - We suggest that the approach above be followed instead (i.e. extend - the existing registry) and that [draft-ietf-nsis-qspec] also makes - use of the values defined in the new "Namespace numerical Value *" - column of the extended existing Resource-Priority Namespace registry. - - In any case, the IANA should honor only one of the two competing - requests (and not both). + allocate a numerical value to any new namespace added to the + registry. The present document defines an ALRP Priority field in section 3.2 that contains a numerical value identifying the actual application- level resource priority within the application-level resource priority namespace. The IANA already maintains the Resource-Priority Priority-values registry (under the SIP Parameters) listing all such priorities. However, that registry does not currently allocate a numerical value to each priority-value. Hence, this document requests the IANA to extend the Resource-Priority Priority-Values registry in the following ways: @@ -639,37 +635,27 @@ - At the bottom of the registry, add a "Legend" with a line saying "Priority Numerical Value = the unique numerical value identifying the priority within a namespace" - add a line at the bottom of the registry stating the following "* : [RFCXXX] " where XXX is the RFC number of the present document - 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 existing priority. Then, in the future, IANA should automatically - allocate a numerical value to any new namespace added to the registry. - The numerical value must be unique within each namespace. Within each - namespace, values should be allocated in decreasing order ending with - 0 (so that the greatest priority is always allocated value 0). For - example, in the drsn namespace, "routine" would be allocated - numerical value 5 and "flash-override-override" would be allocated - numerical value 0. - - [draft-ietf-nsis-qspec] also uses numerical values for Resource- - Priority Priorities. To that end, the document requests IANA to - create a new registry to allocate numerical values to each priority. - We suggest that the approach above be followed instead (i.e. extend - the existing registry) and that [draft-ietf-nsis-qspec] also makes - use of the values defined in the new "Priority Numerical Value *" - column of the extended existing Resource-Priority Priority-Values - registry. In any case, the IANA should honor only one of the two - competing requests (and not both). + allocate a numerical value to any new namespace added to the + registry. The numerical value must be unique within each namespace. + Within each namespace, values should be allocated in decreasing order + ending with 0 (so that the greatest priority is always allocated + value 0). For example, in the drsn namespace, "routine" would be + allocated numerical value 5 and "flash-override-override" would be + allocated numerical value 0. 6. Acknowledgments We would like to thank An Nguyen for his encouragement to address this topic and ongoing comments. Also, this document borrows heavily from some of the work of S. Herzog on Preemption Priority Policy Element [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input into this document. 7. Normative References @@ -692,52 +678,59 @@ [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. [SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261, [SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC4412, February 2006. 8. Informative References - [DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth + [DIME-PARAM] J. Korhonen & H. Tschofenig, "Quality of Service + Parameters for Usage with the AAA Framework", draft-ietf-dime-qos- + parameters-01.txt, work in progress. + + [DSTE-MAM] F. Le Faucheur & W. 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 + [DSTE-RDM] Le Faucheur et al., Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June - 2005 + 2005. [EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency Telecommunications Service for Real Time Services in the Internet Protocol Suite", RFC 4542, May 2006. [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunication Service (ETS)", RFC 3690, February 2004. [FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU, Recommendation, I.255.3, July, 1990. + [NSIS-QSPEC] G. Ash et al., "QoS NLSP QSPEC Template", draft-ietf- + nsis-qspec-18.txt, work in progress. + [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001. - [RSVP-GROUPKEYING] Behringer, M., Le Faucheur, F., "A Framework for - RSVP Security using Dynamic Group Keying", draft-behringer-tsvwg- - rsvp-security-groupkeying-00.txt, work in progress. + [RSVP-GROUPKEYING] Behringer, M., Le Faucheur, F., "Applicability of + Keying Methods for RSVP Security", draft-behringer-tsvwg-rsvp- + security-groupkeying-01.txt, work in progress. [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. Appendix A: Examples of Bandwidth Allocation Model for Admission Priority Sections A.1 and A.2 respectively illustrate how the Maximum Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE- @@ -808,29 +801,29 @@ operator may configure the bandwidth available to non-priority traffic to X, and the bandwidth available to priority traffic to 5% of X. At the other extreme, where the proportion of priority traffic may be significant at times and the engineered capacity limits are very tight, the operator may decide to configure the bandwidth available to non-priority traffic and the bandwidth available to priority traffic such that their sum is equal to the engineered capacity limits. This guarantees that the total load across non-priority and - priority traffic is always below the engineered capacity and, in turn, - guarantees there will never be any QoS degradation. However, this - policy is less attractive economically as it prevents non-priority - calls from using the full engineered capacity, even when there is no - or little priority load, which is the majority of time. This policy - 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 - bandwidth available to non-priority traffic to 95% of X, and the - bandwidth available to priority traffic to 5% of X. + priority traffic is always below the engineered capacity and, in + turn, guarantees there will never be any QoS degradation. However, + this policy is less attractive economically as it prevents non- + priority calls from using the full engineered capacity, even when + there is no or little priority load, which is the majority of time. + This policy 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 bandwidth available to non-priority traffic to 95% + of X, and the bandwidth available to priority traffic to 5% of X. Of course, an operator may also strike a balance 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 used. ----------------------- ^ ^ ^ | | ^ . . . | | . @@ -1176,23 +1169,21 @@ Chart 13. Full non-priority load Appendix B: Example Usages of RSVP Extensions This section provides examples of how RSVP extensions defined in this document can be used (in conjunctions with other RSVP functionality and SIP functionality) to enforce different hypothetical policies for handling Emergency sessions in a given administrative domain. This Appendix does not provide additional specification. It is only - included in this document for illustration purposes. The content of - this appendix may be moved into a future applicability statement - document. + included in this document for illustration purposes. We assume an environment where SIP is used for session control and RSVP is used for resource reservation. 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 user agents to influence their treatment of SIP requests. This may include the ability to "queue" call requests when those can not be immediately honored (in some cases with the notion of "bumping", or "displacement", of less important call request from that queue). It @@ -1217,44 +1208,47 @@ can achieve this by signaling emergency calls: * using "Resource-Priority" Header in SIP * using Admission-Priority Policy Element in RSVP * not using Preemption Policy Element in RSVP Emergency calls will not result in preemption of any session. Different bandwidth allocation models can be used to offer different "prioritized access to network resources". Just as examples, this includes strict setting aside of capacity for emergency sessions as 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 (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but non-emergency sessions are not affected by preemption, one can do that by signaling emergency calls: * using "Resource-Priority" Header in SIP * using Admission-Priority Policy Element in RSVP * using Preemption Policy Element in RSVP with: o setup (Emergency-1) > defending (Emergency-2) o setup (Emergency-2) <= defending (Emergency-1) o setup (Emergency-1) <= defending (Non-Emergency) o setup (Emergency-2) <= defending (Non-Emergency) - 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 "emergency" sessions can preempt regular sessions, one could do that by signaling emergency calls: * using "Resource-Priority" Header in SIP * using Admission-Priority Policy Element in RSVP * using Preemption Policy Element in RSVP with: o setup (Emergency) > defending (Non-Emergency) o setup (Non-Emergency) <= defending (Emergency) - 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 "emergency" sessions can partially preempt regular sessions (ie reduce their reservation size), one could do that by signaling 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 @@ -1302,21 +1296,21 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Statement - Copyright (C) The IETF Trust (2007). + 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