--- 1/draft-ietf-tsvwg-emergency-rsvp-10.txt 2009-02-18 21:12:13.000000000 +0100 +++ 2/draft-ietf-tsvwg-emergency-rsvp-11.txt 2009-02-18 21:12:13.000000000 +0100 @@ -1,20 +1,20 @@ TSVWG F. Le Faucheur Internet-Draft J. Polk Intended status: Standards Track Cisco -Expires: August 13, 2009 K. Carlberg +Expires: August 22, 2009 K. Carlberg G11 - February 9, 2009 + February 18, 2009 - Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services - draft-ietf-tsvwg-emergency-rsvp-10.txt + Resource ReSerVation Protocol (RSVP) Extensions for Emergency Services + draft-ietf-tsvwg-emergency-rsvp-11.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -23,21 +23,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 August 13, 2009. + This Internet-Draft will expire on August 22, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -56,71 +56,72 @@ or they may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) 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. The mechanisms defined in this document are applicable to controlled - environments formed by either a single administrative domain or a set - of administrative domains that closely coordinate their network - policy and network design. The mechanisms defined in this document - can be used for a session whose path spans over such a controlled - environment in order to elevate the session establishment probability - through the controlled environment (thereby elevating the end to end - session establishment probability). + environments. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Related Technical Documents . . . . . . . . . . . . . . . 6 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 + 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2. Related Technical Documents . . . . . . . . . . . . . . . 7 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 8 3. Overview of RSVP extensions and Operations . . . . . . . . . . 8 3.1. Operations of Admission Priority . . . . . . . . . . . . . 10 - 4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 10 - 4.1. Admission Priority Policy Element . . . . . . . . . . . . 11 - 4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 13 - 4.2. Application-Level Resource Priority Policy Element . . . . 13 + 4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 11 + 4.1. Admission Priority Policy Element . . . . . . . . . . . . 12 + 4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 14 + 4.2. Application-Level Resource Priority Policy Element . . . . 14 4.2.1. Application-Level Resource Priority Modifying and Merging Rules . . . . . . . . . . . . . . . . . . . . 15 - 4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 15 + 4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 17 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 17 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 Appendix A. Examples of Bandwidth Allocation Model for - Admission Priority . . . . . . . . . . . . . . . . . 23 + Admission Priority . . . . . . . . . . . . . . . . . 24 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 24 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 28 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 31 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction [RFC3689] and [RFC3690] 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, - the requirement for this probability may reach 100%, but that is a - topic subject to policy and most likely local regulation (the latter - being outside the scope of this document). + emergency communications. Deployed examples of these types of + networks are the Government Emergency Telecommunications Systems + (GETS) and the Government Telephone Preference System (GTPS) [NCS] + [RFC4190]. Both of these examples represent enhancements to publicly + accessible systems instead of walled garden or private networks. + + An underlying goal of [RFC3689] and [RFC3690] 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, the + requirement for this probability may reach 100%, but that is a topic + subject to policy and most likely local regulation (the latter being + outside the scope of this document). Solutions to meet this requirement for elevated session establishment probability may involve session layer capabilities prioritizing access to resources controlled by the session control function. As an example, entities involved in session control (such as SIP user agents, when the Session Initiation Protocol (SIP) [RFC3261], is the session control protocol in use) can influence their treatment of session establishment requests (such as SIP requests). This may include the ability to "queue" session establishment requests when those can not be immediately honored (in some cases with the notion @@ -137,26 +138,35 @@ while satisfying the quality of service requirements of that traffic class. Admission priority may involve setting aside some network resources (e.g. bandwidth) out of the engineered capacity limits for the emergency services only. Or alternatively, it may involve allowing the emergency related sessions to seize additional resources beyond the engineered capacity limits applied to normal sessions. This document specifies the necessary extensions to support such admission priority when network layer admission control is performed using the Resource reSerVation Protocol (RSVP) ([RFC2205]). + IP telephony "calls" are one form of "sessions" that can benefit from + the elevated session establishment probability discussed in this + document. Video over IP and Instant Messaging are other examples. + For the sake of generality, we use the term "session" throughout this + document to refer to any type of session. + +1.1. Applicability + The mechanisms defined in this document are applicable to controlled environments formed by either a single administrative domain or a set of administrative domains that closely coordinate their network policy and network design. The mechanisms defined in this document can be used for a session whose path spans over such a controlled - environment in order to elevate the session establishment probability + environment where network layer admission control mechanisms are + used, in order to elevate the session establishment probability through the controlled environment (thereby elevating the end to end session establishment probability). Let us consider the end to end environment illustrated in Figure 1 that comprises three separate administrative domains, each with 2 endpoints and each with Session Border Controller (SBC) elements ([I-D.ietf-sipping-sbc-funcs]) handling session handover at the domain boundaries. +----------+ +----------+ +----------+ |Endpoint 1| |Endpoint 3| |Endpoint 5| +----------+ +----------+ +----------+ @@ -223,27 +233,21 @@ document within their own domain. This would ensure that emergency sessions are protected by resource reservation and elevated session establishment probability through every domain on the end to end path. But even in that case, RSVP signaling and the extensions defined in this document need not operate end-to-end; rather they are expected to operate edge-to-edge within each domain only (with RSVP being terminated by the egress SBC on the egress edge of one domain and regenerated by the ingress SBC on the ingress edge of the next domain). - IP telephony "calls" are one form of "sessions" that can benefit from - the elevated session establishment probability discussed in this - document. Video over IP and Instant Messaging are other examples. - For the sake of generality, we use the term "session" throughout this - document to refer to any type of session. - -1.1. Related Technical Documents +1.2. Related Technical Documents [RFC4542] 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 session set up, as well as operations after session establishment through maintenance of a continuing call model of the status of all sessions. [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 @@ -264,21 +268,21 @@ 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 session admission priority. Appendix A of this document also provides examples of bandwidth allocation models which can be used by RSVP-routers to enforce such admission priority on every link. -1.2. Terminology +1.3. 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 element. @@ -968,20 +971,22 @@ Davie, B., Faucheur, F., and A. Narayanan, "Support for RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-01 (work in progress), November 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-02 (work in progress), November 2008. + [NCS] "GETS Home Page", . + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, @@ -1009,20 +1014,24 @@ [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons", RFC 4126, June 2005. [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005. + [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for + Supporting Emergency Telecommunications Service (ETS) in + IP Telephony", RFC 4190, November 2005. + [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite", RFC 4542, May 2006.