draft-ietf-tsvwg-emergency-rsvp-10.txt   draft-ietf-tsvwg-emergency-rsvp-11.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft J. Polk Internet-Draft J. Polk
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: August 13, 2009 K. Carlberg Expires: August 22, 2009 K. Carlberg
G11 G11
February 9, 2009 February 18, 2009
Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Resource ReSerVation Protocol (RSVP) Extensions for Emergency Services
draft-ietf-tsvwg-emergency-rsvp-10.txt draft-ietf-tsvwg-emergency-rsvp-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
or they may be shared with other sessions. or they may be shared with other sessions.
This document specifies extensions to the Resource reSerVation This document specifies extensions to the Resource reSerVation
Protocol (RSVP) that can be used to support such an admission Protocol (RSVP) that can be used to support such an admission
priority capability at the network layer. Note that these extensions priority capability at the network layer. Note that these extensions
represent one possible solution component in satisfying ETS represent one possible solution component in satisfying ETS
requirements. Other solution components, or other solutions, are requirements. Other solution components, or other solutions, are
outside the scope of this document. outside the scope of this document.
The mechanisms defined in this document are applicable to controlled The mechanisms defined in this document are applicable to controlled
environments formed by either a single administrative domain or a set environments.
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).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Related Technical Documents . . . . . . . . . . . . . . . 6 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Related Technical Documents . . . . . . . . . . . . . . . 7
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 8 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 8
3. Overview of RSVP extensions and Operations . . . . . . . . . . 8 3. Overview of RSVP extensions and Operations . . . . . . . . . . 8
3.1. Operations of Admission Priority . . . . . . . . . . . . . 10 3.1. Operations of Admission Priority . . . . . . . . . . . . . 10
4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 10 4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 11
4.1. Admission Priority Policy Element . . . . . . . . . . . . 11 4.1. Admission Priority Policy Element . . . . . . . . . . . . 12
4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 13 4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 14
4.2. Application-Level Resource Priority Policy Element . . . . 13 4.2. Application-Level Resource Priority Policy Element . . . . 14
4.2.1. Application-Level Resource Priority Modifying and 4.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 15 Merging Rules . . . . . . . . . . . . . . . . . . . . 15
4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 15 4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Use of RSVP Authentication between RSVP neighbors . . . . 17 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 17
5.2. Use of INTEGRITY object within the POLICY_DATA object . . 17 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Examples of Bandwidth Allocation Model for 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.1. Admission Priority with Maximum Allocation Model (MAM) . . 24
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 28 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 28
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 31 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 31
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 34 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
[RFC3689] and [RFC3690] detail requirements for an Emergency [RFC3689] and [RFC3690] 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 emergency communications. Deployed examples of these types of
to present requirements that elevate the probability of session networks are the Government Emergency Telecommunications Systems
establishment from an authorized user in times of network congestion (GETS) and the Government Telephone Preference System (GTPS) [NCS]
(presumably because of a crisis condition). In some extreme cases, [RFC4190]. Both of these examples represent enhancements to publicly
the requirement for this probability may reach 100%, but that is a accessible systems instead of walled garden or private networks.
topic subject to policy and most likely local regulation (the latter
being outside the scope of this document). 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 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 access to resources controlled by the session control function. As
an example, entities involved in session control (such as SIP user an example, entities involved in session control (such as SIP user
agents, when the Session Initiation Protocol (SIP) [RFC3261], is the agents, when the Session Initiation Protocol (SIP) [RFC3261], is the
session control protocol in use) can influence their treatment of session control protocol in use) can influence their treatment of
session establishment requests (such as SIP requests). This may session establishment requests (such as SIP requests). This may
include the ability to "queue" session establishment requests when include the ability to "queue" session establishment requests when
those can not be immediately honored (in some cases with the notion those can not be immediately honored (in some cases with the notion
skipping to change at page 4, line 47 skipping to change at page 5, line 5
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 sessions. beyond the engineered capacity limits applied to normal sessions.
This document specifies the necessary extensions to support such This document specifies the necessary extensions to support such
admission priority when network layer admission control is performed admission priority when network layer admission control is performed
using the Resource reSerVation Protocol (RSVP) ([RFC2205]). 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 The mechanisms defined in this document are applicable to controlled
environments formed by either a single administrative domain or a set environments formed by either a single administrative domain or a set
of administrative domains that closely coordinate their network of administrative domains that closely coordinate their network
policy and network design. The mechanisms defined in this document policy and network design. The mechanisms defined in this document
can be used for a session whose path spans over such a controlled 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 through the controlled environment (thereby elevating the end to end
session establishment probability). Let us consider the end to end session establishment probability). Let us consider the end to end
environment illustrated in Figure 1 that comprises three separate environment illustrated in Figure 1 that comprises three separate
administrative domains, each with 2 endpoints and each with Session administrative domains, each with 2 endpoints and each with Session
Border Controller (SBC) elements ([I-D.ietf-sipping-sbc-funcs]) Border Controller (SBC) elements ([I-D.ietf-sipping-sbc-funcs])
handling session handover at the domain boundaries. handling session handover at the domain boundaries.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
|Endpoint 1| |Endpoint 3| |Endpoint 5| |Endpoint 1| |Endpoint 3| |Endpoint 5|
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
skipping to change at page 6, line 37 skipping to change at page 7, line 29
document within their own domain. This would ensure that emergency document within their own domain. This would ensure that emergency
sessions are protected by resource reservation and elevated session sessions are protected by resource reservation and elevated session
establishment probability through every domain on the end to end establishment probability through every domain on the end to end
path. But even in that case, RSVP signaling and the extensions path. But even in that case, RSVP signaling and the extensions
defined in this document need not operate end-to-end; rather they are 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 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 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 and regenerated by the ingress SBC on the ingress edge of the next
domain). domain).
IP telephony "calls" are one form of "sessions" that can benefit from 1.2. Related Technical Documents
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
[RFC4542] is patterned after [ITU.I.225] and describes an example of [RFC4542] is patterned after [ITU.I.225] and describes an example of
one type of prioritized network layer admission control procedure 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 session set up, as well as infrastructure. It discusses initial session set up, as well as
operations after session establishment through maintenance of a operations after session establishment through maintenance of a
continuing call model of the status of all sessions. [RFC4542] also continuing call model of the status of all sessions. [RFC4542] 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 [RFC2205] along with realized using the Resource reSerVation Protocol [RFC2205] along with
its associated protocol suite and extensions, including those for its associated protocol suite and extensions, including those for
skipping to change at page 7, line 30 skipping to change at page 8, line 16
Engineered capacity techniques in the form of bandwidth allocation Engineered capacity techniques in the form of bandwidth allocation
models are used to satisfy the "admission priority" required by an models are used to satisfy the "admission priority" required by an
RSVP capable ETS network. In particular this document specifies two RSVP capable ETS network. In particular this document specifies two
new RSVP Policy Elements allowing the admission priority to be new RSVP Policy Elements allowing the admission priority to be
conveyed inside RSVP signaling messages so that RSVP nodes can conveyed inside RSVP signaling messages so that RSVP nodes can
enforce selective bandwidth admission control decision based on the enforce selective bandwidth admission control decision based on the
session admission priority. Appendix A of this document also session admission priority. Appendix A of this document also
provides examples of bandwidth allocation models which can be used by provides examples of bandwidth allocation models which can be used by
RSVP-routers to enforce such admission priority on every link. 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 This document assumes the terminology defined in [RFC2753]. For
convenience, the definition of a few key terms is repeated here: convenience, the definition of a few key terms is repeated here:
o Policy Decision Point (PDP): The point where policy decisions are o Policy Decision Point (PDP): The point where policy decisions are
made. made.
o Local Policy Decision Point (LPDP): PDP local to the network o Local Policy Decision Point (LPDP): PDP local to the network
element. element.
skipping to change at page 22, line 31 skipping to change at page 23, line 5
Davie, B., Faucheur, F., and A. Narayanan, "Support for Davie, B., Faucheur, F., and A. Narayanan, "Support for
RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-01 RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-01
(work in progress), November 2008. (work in progress), November 2008.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] [I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security", Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-02 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-02 (work in
progress), November 2008. progress), November 2008.
[NCS] "GETS Home Page", <http://gets.ncs.gov>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, for Policy-based Admission Control", RFC 2753,
skipping to change at page 23, line 24 skipping to change at page 23, line 48
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic Constraints Model for Diffserv-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126, Engineering & Performance Comparisons", RFC 4126,
June 2005. June 2005.
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering", Model for Diffserv-aware MPLS Traffic Engineering",
RFC 4127, June 2005. 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 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005. Properties", RFC 4230, December 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency
Telecommunications Service (ETS) for Real-Time Services in Telecommunications Service (ETS) for Real-Time Services in
the Internet Protocol Suite", RFC 4542, May 2006. the Internet Protocol Suite", RFC 4542, May 2006.
 End of changes. 18 change blocks. 
40 lines changed or deleted 50 lines changed or added

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