--- 1/draft-ietf-tsvwg-emergency-rsvp-01.txt 2007-03-08 23:14:54.000000000 +0100 +++ 2/draft-ietf-tsvwg-emergency-rsvp-02.txt 2007-03-08 23:14:54.000000000 +0100 @@ -1,22 +1,17 @@ - - RSVP Extensions for Emergency Services January 2007 - - Internet Draft Francois Le Faucheur - James Polk - Cisco Systems, Inc. + TSVWG Francois Le Faucheur + Internet-Draft James Polk + Intended Status: Standards Track Cisco Systems, Inc. Ken Carlberg G11 - draft-ietf-tsvwg-emergency-rsvp-01.txt - Expires: July 2007 January 2007 - + draft-ietf-tsvwg-emergency-rsvp-02.txt 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. @@ -39,69 +34,63 @@ An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. - RSVP Extensions for Emergency Services January 2007 - 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 Internet Society (2007). + Copyright (C) The IETF Trust (2007). Specification of Requirements - In this document, 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 - [KEYWORDS] and indicate requirement levels for compliant - implementations. + 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.3. Changes from previous versions.............................5 + 1.3. Changes from previous versions.............................4 2. Overview of RSVP extensions and Operations.....................6 2.1. Operations of Admission Priority..........................8 3. New Policy Elements............................................8 3.1. Admission Priority Policy Element.........................9 3.1.1. Admission Priority Merging Rules 10 3.2. Application-Level Resource Priority Policy Element.......11 3.2.1. Application-Level Resource Priority Modifying and Merging Rules 12 - 4. Security Considerations.......................................12 + 4. Security Considerations.......................................13 4.1. Use of RSVP Authentication...............................13 4.2. Use of INTEGRITY object within the POLICY_DATA object....14 5. IANA Considerations...........................................14 6. Acknowledgments...............................................15 7. Normative References..........................................15 - 8. Informative References........................................16 + 8. Informative References........................................15 Appendix A: Examples of Bandwidth Allocation Model for Admission - Priority.........................................................16 + Priority.........................................................17 A.1 Admission Priority with Maximum Allocation Model (MAM)......17 - A.2 Admission Priority with Russian Dolls Model (RDM)...........20 + A.2 Admission Priority with Russian Dolls Model (RDM)...........21 A.3 Admission Priority with Priority Bypass Model (PBM).........23 Appendix B: Example Usages of RSVP Extensions....................26 - Authors' Address.................................................27 - - RSVP Extensions for Emergency Services January 2007 + Authors' Address.................................................28 1. Introduction [EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency Telecommunications Service (ETS), which is an umbrella term identifying those networks and specific services used to support emergency communications. An underlying goal of these documents is to present requirements that elevate the probability of session establishment from an authorized user in times of network congestion (presumably because of a crisis condition). In some extreme cases, @@ -136,22 +125,20 @@ Note: Below, this document references several examples of IP telephony and its use of "calls", which is one form of the term "sessions" (Video over IP and Instant Messaging being other examples that rely on session establishment). For the sake of simplicity, we shall use the widely known term "call" for the remainder of this document. 1.1. Related Technical Documents - RSVP Extensions for Emergency Services January 2007 - [EMERG-IMP] is patterned after [ITU.I.225] and describes an example of one type of prioritized network layer admission control procedure that may be used for emergency services operating over an IP network infrastructure. It discusses initial call set up, as well as operations after call establishment through maintenance of a continuing call model of the status of all calls. [EMERG-IMP] also describes how these network layer admission control procedures can be realized using the Resource reSerVation Protocol [RSVP] along with its associated protocol suite and extensions, including those for policy based admission control ([FW-POLICY], [RSVP-POLICY]), for user @@ -187,38 +174,47 @@ - Local Policy Decision Point (LPDP): PDP local to the network element - Policy Enforcement Point (PEP): The point where the policy decisions are actually enforced. - Policy Ignorant Node (PIN): A network element that does not explicitly support policy control using the mechanisms defined in [FW-POLICY]. - RSVP Extensions for Emergency Services January 2007 - 1.3. Changes from previous versions [Note to RFC Editor: This section is to be removed before publication] - Changes from ietf-tsvwg-emergency-rsvp-00 to ietf-tsvwg- - emergency-rsvp-01 + Changes from ietf-tsvwg-emergency-rsvp-01 to ietf-tsvwg-emergency- + rsvp-02 + + The changes are: + + o fix the idnits + + o Removed reference to Kerberos in Security Considerations + section (in line with IESG review comment on Security + Considerations section of draft-ietf-tsvwg-rsvp-ipsec) + + 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- - emergency-00 + Changes from lefaucheur-rsvp-emergency-01 to ietf-tsvwg-emergency- + rsvp-00 The most significant change is: o Extended the Admission Priority field from 3 to 8 bits and inverted the encoding order, in particular for better alignment with NSIS Qspec. Changes from lefaucheur-rsvp-emergency-01 to lefaucheur-rsvp- emergency-02 @@ -225,31 +221,28 @@ The most significant changes are: o modified the Introduction to add additional clarity and to place related work in a better context to the extensions proposed in this draft o Moved bandwidth allocation models to an appendix o Allowed multiple Application-Level Resource Priority inside ALRP Policy Element - o Added a 2nd appendix providing examples of RSVP extensions usage Changes from lefaucheur-rsvp-emergency-00 to lefaucheur-rsvp- emergency-01 The most significant changes were: - RSVP Extensions for Emergency Services January 2007 - o adding a second RSVP Policy Element that contains the application-level resource priority requirements (for example as communicated in the SIP Resource-Priority Header) for scenarios where priority calls transits through multiple administrative domains. o adding description of a third bandwidth allocation model example: the Priority Bypass Model o adding discussion on policies for mapping the various @@ -283,23 +276,20 @@ end-devices involved in the upper-layer session establishment simply need to copy the application-level resource priority requirements (e.g. as communicated in SIP Resource-Priority Header) inside the new RSVP Application-Level Resource-Priority Policy Element defined in this document. Conveying the application-level resource priority requirements inside the RSVP message allows this application level requirement to be mapped/remapped into a different RSVP "admission priority" at every 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 at the periphery of the policy domain (e.g., in border routers), PDPs would interpret the RSVP Application-Level Resource-Priority Policy Element and map the requirement of the emergency session into an RSVP "admission priority" level. Then, PDPs would convey this information inside the new Admission Priority Policy Element defined in this document. This way, the RSVP admission priority can be communicated to downstream PEPs (ie RSVP Routers) of the same policy domain, which have LPDPs but no controlling PDP. In turn, this means the necessary RSVP Admission priority can be enforced at every RSVP hop, including @@ -335,23 +325,20 @@ Mapping/remapping by PDPs may also be applied to boundaries between various signaling protocols, such as those advanced by the NSIS working group. As can be observed, the framework described above for mapping/remapping application level resource priority requirements into an RSVP admission priority can also be used together with [RSVP- PREEMP] for mapping/remapping application level resource priority requirements into an RSVP preemption priority (when preemption is 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 between administrative domains (or between various QoS signaling protocols) can map it into an RSVP "preemption priority" information. This Preemption priority information comprises a setup preemption level and a defending preemption priority level. This preemption priority information can then be encoded inside the Preemption Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into account at every RSVP-enabled network hop as discussed [EMERG-IMP]. Appendix B provides examples of various hypothetical policies for emergency call handling, some of them involving admission priority, @@ -387,22 +373,20 @@ describes the various components that participate in policy decision making (i.e., PDP, PEP and LPDP). As described in section 2 of the present document, the Application- Level Resource Priority Policy Element and the Admission Priority Policy Element serve different roles in this framework: - the Application-Level Resource Priority Policy Element conveys 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 simple, stateless, and light-weight such that it can be processed internally within a node's LPDP. It can then be enforced internally within a node's PEP. It is set by PDPs based on processing of the Application-Level Resource Priority Policy Element. [RSVP-POLICY] defines extensions for supporting generic policy based admission control in RSVP. These extensions include the standard format of POLICY_DATA objects and a description of RSVP handling of @@ -435,23 +419,20 @@ 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) Merge Strategy: 8 bit (only applicable to multicast flows) 1 Take priority of highest QoS 2 Take highest priority - - RSVP Extensions for Emergency Services January 2007 - 3 Force Error on heterogeneous merge 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. Adm. Priority (Admission Priority): 8 bits (unsigned) @@ -487,23 +468,20 @@ 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: - Take priority of highest QoS - Take highest priority - Force Error on heterogeneous merge. - - RSVP Extensions for Emergency Services January 2007 - The only difference with [RSVP-PREEMP] is that this document does not recommend any merge strategies for Admission Priority while [RSVP- PREEMP] recommends the first of these merge strategies for Preemption Priority. Note that with the Admission Priority (as is the case with the Preemption Priority), "Take highest priority" translates into "take the highest numerical value". 3.2. Application-Level Resource Priority Policy Element @@ -538,22 +516,20 @@ represents the position of the namespace in the "Resource- Priority Namespace" IANA registry, starting with 0. Creation of this registry has been requested to IANA in [SIP- PRIORITY]. For example, as "drsn", "dsn", "q735", "ets" and "wps" are currently the first, second, third, fourth and fifth namespaces defined in the "Resource-Priority Namespace" registry, those are respectively encoded as value 0, 1, 2, 3 and 4. - RSVP Extensions for Emergency Services January 2007 - ALRP Priority: (Application-Level Resource Priority Priority): 8 bits (unsigned) Contains the priority value within the namespace of the application-level resource priority. This is encoded as a numerical value which represents the priority defined in the "Resource-Priority Namespace" IANA registry for the considered namespace, starting from 0 for the highest priority and increasing as priority decreases. For example, as "flash-override", "flash", "immediate", "priority" and "routine" are the priorities in decreasing @@ -588,47 +564,38 @@ As merging is only applicable to Multicast, this rule only applies to Multicast sessions. 4. Security Considerations The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can be signaled by RSVP through encapsulation in a Policy Data object as defined in [RSVP-POLICY]. Therefore, like any other Policy Elements, their integrity can be protected as discussed in section 6 of [RSVP- - - 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. + because of the complexity or operational burden they involve. 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. @@ -640,31 +608,26 @@ 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. + 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 @@ -691,91 +654,79 @@ 5. IANA Considerations As specified in [RSVP-POLICY], Standard RSVP Policy Elements (P-type values) are to be assigned by IANA as per "IETF Consensus" following the policies outlined in [IANA-CONSIDERATIONS]. IANA needs to allocate two P-Types from the Standard RSVP Policy Element range: - 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 Policy Element 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 - [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 - 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. - [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)- Functional Specification", RFC 2205, September 1997. [RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP 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 2750, January 2000. [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 + 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-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. [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. [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. @@ -787,22 +738,20 @@ Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE- RDM] can be used for support of admission priority. Section A.3 illustrates how a simple "Priority Bypass Model" can also be used for support of admission priority. For simplicity, operations with only a single "priority" level (beyond non-priority) are illustrated here; However, the reader will appreciate that operations with multiple priority levels can easily be supported with these models. - RSVP Extensions for Emergency Services January 2007 - In all the charts below: x represents a non-priority session o represents a priority session A.1 Admission Priority with Maximum Allocation Model (MAM) This section illustrates operations of admission priority when a Maximum Allocation Model (MAM) is used for bandwidth allocation across non-priority traffic and priority traffic. A property of the Maximum Allocation Model is that priority traffic can not use more @@ -836,23 +784,20 @@ be accepted even if the bandwidth reserved for priority traffic is not currently fully utilized. With the Maximum Allocation Model, in the case where the priority load reaches the maximum bandwidth reserved for priority calls, no additional priority sessions can be accepted. As illustrated in Chart 1, an operator may map the MAM model onto the Engineered Capacity limits according to different policies. At one 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 margin factored in the engineered capacity limits, the operator may decide to configure the bandwidth available for non-priority use to the full engineered capacity limits; effectively allowing the priority traffic to ride within the safety margin of this engineered capacity. This policy can be seen as an economically attractive approach as all of the engineered capacity is made available to non- 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 operator may configure the bandwidth available to non-priority @@ -888,23 +833,20 @@ . . . | | . Available Engi- . . . | | . for non-priority use neered .or.or. |xxxxxxxxxxxxxx| . . . . |xxxxxxxxxxxxxx| . Capacity. . . |xxxxxxxxxxxxxx| . v . . |xxxxxxxxxxxxxx| v . . |--------------| --- v . | | ^ . | | . Bandwidth available for v | | v priority use - - RSVP Extensions for Emergency Services January 2007 - ------------------------- Chart 2. Partial load of non-priority calls Chart 3 shows the same amount of non-priority load being used at this link, and a small amount of priority bandwidth being used. ----------------------- ^ ^ ^ | | ^ . . . | | . Total . . . | | . Bandwidth @@ -939,22 +881,20 @@ Capacity. . . |xxxxxxxxxxxxxx| . v . . |xxxxxxxxxxxxxx| v . . |--------------| --- v . | | ^ . | | . Bandwidth available for v |oooooooooooooo| v priority use ------------------------- Chart 4. Full non-priority load & partial load of priority calls - RSVP Extensions for Emergency Services January 2007 - Chart 5 shows the case where the priority traffic equates or exceeds the bandwidth reserved for such priority traffic. In that case additional priority sessions could not be accepted. Note that this does not mean that such calls are dropped altogether: they may be handled by mechanisms, which are beyond the scope of this particular document (such as establishment through preemption of existing non-priority sessions, or such as queuing of new priority session requests until capacity becomes available again for priority traffic). @@ -987,22 +927,20 @@ As with the MAM model, an operator may map the RDM model onto the Engineered Capacity limits according to different policies. The operator may decide to configure the bandwidth available for non- priority use to the full engineered capacity limits; 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 X, and the bandwidth available to non-priority and priority traffic to 105% of X. - RSVP Extensions for Emergency Services January 2007 - Alternatively, the operator may decide to configure the bandwidth available to non-priority and priority traffic to the engineered capacity limits; 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 non-priority and priority traffic to X. Finally, the operator may decide to strike a balance in between. The considerations presented for these policies in the previous section in the MAM context are equally applicable to RDM. @@ -1036,23 +973,20 @@ -------------------------------------- |xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Available for . |xxxxxxxxxxxxxx| . non-priority . |xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . . Bandwidth |xxxxxxxxxxxxxx| . . available for |xxxxxxxxxxxxxx| v . non-priority - - RSVP Extensions for Emergency Services January 2007 - |--------------| --- . and priority | | . use | | . |oooooooooooooo| v --------------------------------------- Chart 7. Full non-priority load & Partial Aggregate load 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 @@ -1086,23 +1019,20 @@ may be handled by mechanisms, which are beyond the scope of this particular document (such as established through preemption of existing non-priority sessions, or such as queuing of new priority session requests until capacity becomes available again for priority traffic). -------------------------------------- |xxxxxxxxxxxxxx| . ^ |xxxxxxxxxxxxxx| . Bandwidth . |xxxxxxxxxxxxxx| . Available for . - - RSVP Extensions for Emergency Services January 2007 - |xxxxxxxxxxxxxx| . non-priority . |xxxxxxxxxxxxxx| . use . |xxxxxxxxxxxxxx| . . Bandwidth |xxxxxxxxxxxxxx| . . available for |xxxxxxxxxxxxxx| v . non-priority |--------------| --- . and priority |oooooooooooooo| . use |oooooooooooooo| . |oooooooooooooo| v --------------------------------------- @@ -1136,23 +1066,20 @@ used, those always still represent a fairly small proportion of the overall load which can be absorbed within the safety margin of the engineered capacity limits. Thus, even if they are admitted beyond the engineered bandwidth threshold, they are unlikely to result in noticeable QoS degradation. As with the MAM and RDM model, an operator may map the Priority Bypass model onto the Engineered Capacity limits according to different policies. The operator may decide to configure the 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 limit on a given link is X, the operator may configure the bandwidth limit for non-priority traffic to X. Alternatively, the operator may decide to configure the bandwidth limit for non-priority traffic to below the engineered capacity limits (so that the sum of the non- priority and priority traffic stays below the engineered capacity); As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth limit for non-priority traffic to 95% of X. Finally, the operator may decide to strike a balance in between. The considerations presented for these policies @@ -1188,23 +1114,20 @@ . . |xxxxxxxxxxxxxx| . Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) Engi- . . | | . for admission neered . or . | | . of non-priority traffic . . | | . Capacity. . | | . v . | | v . |--------------| --- . | | - - RSVP Extensions for Emergency Services January 2007 - v | | | | Chart 11. Partial load of non-priority calls 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 situation, both new non-priority and new priority calls would be accepted. @@ -1239,22 +1162,20 @@ Engi- . . |oooooooooooooo| . for admission neered . or . |xxxooxxxooxxxo| . of non-priority traffic . . |xxoxxxxxxoxxxx| . Capacity. . |oxxxooooxxxxoo| . v . |xxoxxxooxxxxxx| v . |--------------| --- . |oooooooooooooo| v | | | | - RSVP Extensions for Emergency Services January 2007 - 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 @@ -1286,23 +1207,20 @@ * not using Admission-Priority Policy Element in RSVP * not using Preemption Policy Element in RSVP If one wants to implement an emergency service based on Call Queueing and on "prioritized access to network layer resources", one 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. - - RSVP Extensions for Emergency Services January 2007 - 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, 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: @@ -1335,23 +1253,20 @@ o setup (Emergency) > defending (Non-Emergency) o setup (Non-Emergency) <= defending (Emergency) * activate RFC4495 RSVP Bandwidth Reduction mechanisms Authors' Address Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille - - RSVP Extensions for Emergency Services January 2007 - 06410 Biot Sophia-Antipolis France Email: flefauch@cisco.com James Polk Cisco Systems, Inc. 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Email: jmpolk@cisco.com @@ -1382,25 +1297,24 @@ 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 - RSVP Extensions for Emergency Services January 2007 - - Copyright (C) The Internet Society (2007). + Copyright (C) The IETF Trust (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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST + AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY + IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR + PURPOSE.