--- 1/draft-ietf-tsvwg-emergency-rsvp-06.txt 2008-04-11 12:12:16.000000000 +0200 +++ 2/draft-ietf-tsvwg-emergency-rsvp-07.txt 2008-04-11 12:12:16.000000000 +0200 @@ -1,20 +1,20 @@ TSVWG F. Le Faucheur Internet-Draft J. Polk Intended status: Standards Track Cisco -Expires: October 2, 2008 K. Carlberg +Expires: October 13, 2008 K. Carlberg G11 - March 31, 2008 + April 11, 2008 Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services - draft-ietf-tsvwg-emergency-rsvp-06.txt + draft-ietf-tsvwg-emergency-rsvp-07.txt 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,21 +25,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 2, 2008. + This Internet-Draft will expire on October 13, 2008. Abstract 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, @@ -139,37 +139,41 @@ 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. [RFC4542] also describes how these network layer admission control procedures can be realized using the Resource reSerVation Protocol [RFC2205] along with its associated protocol suite and extensions, including those for policy based admission control ([RFC2753], [RFC2750]), for user authentication and authorization ([RFC3182]) and for integrity and - authentication of RSVP messages ([RFC2747], [RFC3097]). - - Furthermore, [RFC4542] describes how the RSVP Signaled Preemption - Priority Policy Element specified in [RFC3181] can be used to enforce - the call preemption that may be needed by some emergency services. + authentication of RSVP messages ([RFC2747], [RFC3097]). The Diameter + QoS Application ([I-D.ietf-dime-diameter-qos]) allows network + elements to interact with Diameter servers when allocating QoS + resources in the network and thus, is also a possible method for + authentication and authorization of RSVP reservations in the context + of emergency services. - In contrast to [RFC4542], this document specifies new RSVP extensions - to increase the probability of call completion without preemption. + [RFC4542] describes how the RSVP Signaled Preemption Priority Policy + Element specified in [RFC3181] can be used to enforce the call + preemption that may be needed by some emergency services. In + contrast to [RFC4542], this document specifies new RSVP extensions to + increase the probability of call completion without preemption. Engineered capacity techniques in the form of bandwidth allocation models are used to satisfy the "admission priority" required by an RSVP capable ETS network. In particular this document specifies two new RSVP Policy Elements allowing the admission priority to be conveyed inside RSVP signaling messages so that RSVP nodes can enforce selective bandwidth admission control decision based on the call admission priority. Appendix A of this document also provides - three examples of a bandwidth allocation model, which can be used by - RSVP-routers to enforce such admission priority on every link. + examples of bandwidth allocation models which can be used by RSVP- + routers to enforce such admission priority on every link. 1.2. Terminology This document assumes the terminology defined in [RFC2753]. For convenience, the definition of a few key terms is repeated here: o Policy Decision Point (PDP): The point where policy decisions are made. o Local Policy Decision Point (LPDP): PDP local to the network @@ -400,34 +405,35 @@ * SHALL be set to zero on transmit and SHALL be ignored on reception o Adm. Priority (Admission Priority): 8 bits (unsigned) * The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher Priority. A given Admission Priority is encoded in this information element using the same value as when encoded in the + "Admission Priority" field of the "Admission Priority" + parameter defined in [I-D.ietf-nsis-qspec], or in the "Admission Priority" parameter defined in - [I-D.ietf-nsis-qspec], or in the "Admission Priority" parameter - defined in [I-D.ietf-dime-qos-parameters]. In other words, a - given value inside the Admission Priority information element - defined in the present document, inside the - [I-D.ietf-nsis-qspec] Admission Priority parameter or inside - the [I-D.ietf-dime-qos-parameters] Admission Priority - parameter, refers to the same Admission Priority. Bandwidth - allocation models such as those described in Appendix A are to - be used by the RSVP router to achieve such increased - probability of call completion. The admission priority value - effectively indicates which bandwidth constraint(s) of the - bandwidth constraint model in use is(are) applicable to - admission of this RSVP reservation. + [I-D.ietf-dime-qos-parameters]. In other words, a given value + inside the Admission Priority information element defined in + the present document, inside the [I-D.ietf-nsis-qspec] + Admission Priority field or inside the + [I-D.ietf-dime-qos-parameters] Admission Priority parameter, + refers to the same admission priority. Bandwidth allocation + models such as those described in Appendix A are to be used by + the RSVP router to achieve such increased probability of call + completion. The admission priority value effectively indicates + which bandwidth constraint(s) of the bandwidth constraint model + in use is(are) applicable to admission of this RSVP + reservation. Note that the Admission Priority Policy Element does NOT indicate 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. @@ -735,30 +741,36 @@ A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. 7.2. Informative References + [I-D.ietf-dime-diameter-qos] + Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., + and G. Zorn, "Diameter Quality of Service Application", + draft-ietf-dime-diameter-qos-05 (work in progress), + February 2008. + [I-D.ietf-dime-qos-parameters] Korhonen, J. and H. Tschofenig, "Quality of Service Parameters for Usage with the AAA Framework", draft-ietf-dime-qos-parameters-03 (work in progress), February 2008. [I-D.ietf-nsis-qspec] Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP - QSPEC Template", draft-ietf-nsis-qspec-19 (work in - progress), February 2008. + QSPEC Template", draft-ietf-nsis-qspec-20 (work in + progress), April 2008. [I-D.ietf-tsvwg-rsvp-security-groupkeying] Behringer, M. and F. Faucheur, "Applicability of Keying Methods for RSVP Security", draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in progress), February 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.