draft-ietf-tsvwg-emergency-rsvp-06.txt   draft-ietf-tsvwg-emergency-rsvp-07.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: October 2, 2008 K. Carlberg Expires: October 13, 2008 K. Carlberg
G11 G11
March 31, 2008 April 11, 2008
Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 October 2, 2008. This Internet-Draft will expire on October 13, 2008.
Abstract Abstract
An Emergency Telecommunications Service (ETS) requires the ability to An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a authorized user in times of network congestion (typically, during a
crisis). When supported over the Internet Protocol suite, this may crisis). When supported over the Internet Protocol suite, this may
be facilitated through a network layer admission control solution, be facilitated through a network layer admission control solution,
which supports prioritized access to resources (e.g., bandwidth). which supports prioritized access to resources (e.g., bandwidth).
These resources may be explicitly set aside for emergency services, These resources may be explicitly set aside for emergency services,
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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 call set up, as well as infrastructure. It discusses initial call set up, as well as
operations after call establishment through maintenance of a operations after call establishment through maintenance of a
continuing call model of the status of all calls. [RFC4542] also continuing call model of the status of all calls. [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
policy based admission control ([RFC2753], [RFC2750]), for user policy based admission control ([RFC2753], [RFC2750]), for user
authentication and authorization ([RFC3182]) and for integrity and authentication and authorization ([RFC3182]) and for integrity and
authentication of RSVP messages ([RFC2747], [RFC3097]). authentication of RSVP messages ([RFC2747], [RFC3097]). The Diameter
QoS Application ([I-D.ietf-dime-diameter-qos]) allows network
Furthermore, [RFC4542] describes how the RSVP Signaled Preemption elements to interact with Diameter servers when allocating QoS
Priority Policy Element specified in [RFC3181] can be used to enforce resources in the network and thus, is also a possible method for
the call preemption that may be needed by some emergency services. authentication and authorization of RSVP reservations in the context
of emergency services.
In contrast to [RFC4542], this document specifies new RSVP extensions [RFC4542] describes how the RSVP Signaled Preemption Priority Policy
to increase the probability of call completion without preemption. 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 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
call admission priority. Appendix A of this document also provides call admission priority. Appendix A of this document also provides
three examples of a bandwidth allocation model, which can be used by examples of bandwidth allocation models which can be used by RSVP-
RSVP-routers to enforce such admission priority on every link. routers to enforce such admission priority on every link.
1.2. Terminology 1.2. 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
skipping to change at page 9, line 40 skipping to change at page 9, line 46
* SHALL be set to zero on transmit and SHALL be ignored on * SHALL be set to zero on transmit and SHALL be ignored on
reception reception
o Adm. Priority (Admission Priority): 8 bits (unsigned) o Adm. Priority (Admission Priority): 8 bits (unsigned)
* The admission control priority of the flow, in terms of access * The admission control priority of the flow, in terms of access
to network bandwidth in order to provide higher probability of to network bandwidth in order to provide higher probability of
call completion to selected flows. Higher values represent call completion to selected flows. Higher values represent
higher Priority. A given Admission Priority is encoded in this higher Priority. A given Admission Priority is encoded in this
information element using the same value as when encoded in the 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 "Admission Priority" parameter defined in
[I-D.ietf-nsis-qspec], or in the "Admission Priority" parameter [I-D.ietf-dime-qos-parameters]. In other words, a given value
defined in [I-D.ietf-dime-qos-parameters]. In other words, a inside the Admission Priority information element defined in
given value inside the Admission Priority information element the present document, inside the [I-D.ietf-nsis-qspec]
defined in the present document, inside the Admission Priority field or inside the
[I-D.ietf-nsis-qspec] Admission Priority parameter or inside [I-D.ietf-dime-qos-parameters] Admission Priority parameter,
the [I-D.ietf-dime-qos-parameters] Admission Priority refers to the same admission priority. Bandwidth allocation
parameter, refers to the same Admission Priority. Bandwidth models such as those described in Appendix A are to be used by
allocation models such as those described in Appendix A are to the RSVP router to achieve such increased probability of call
be used by the RSVP router to achieve such increased completion. The admission priority value effectively indicates
probability of call completion. The admission priority value which bandwidth constraint(s) of the bandwidth constraint model
effectively indicates which bandwidth constraint(s) of the in use is(are) applicable to admission of this RSVP
bandwidth constraint model in use is(are) applicable to reservation.
admission of this RSVP reservation.
Note that the Admission Priority Policy Element does NOT indicate Note that the Admission Priority Policy Element does NOT indicate
that this RSVP reservation is to preempt any other RSVP reservation. that this RSVP reservation is to preempt any other RSVP reservation.
If a priority session justifies both admission priority and If a priority session justifies both admission priority and
preemption priority, the corresponding RSVP reservation needs to preemption priority, the corresponding RSVP reservation needs to
carry both an Admission Priority Policy Element and a Preemption carry both an Admission Priority Policy Element and a Preemption
Priority Policy Element. The Admission Priority and Preemption Priority Policy Element. The Admission Priority and Preemption
Priority are handled by LPDPs and PEPs as separate mechanisms. They 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 can be used one without the other, or they can be used both in
combination. combination.
skipping to change at page 16, line 49 skipping to change at page 16, line 49
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006. RFC 4412, February 2006.
7.2. Informative References 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] [I-D.ietf-dime-qos-parameters]
Korhonen, J. and H. Tschofenig, "Quality of Service Korhonen, J. and H. Tschofenig, "Quality of Service
Parameters for Usage with the AAA Framework", Parameters for Usage with the AAA Framework",
draft-ietf-dime-qos-parameters-03 (work in progress), draft-ietf-dime-qos-parameters-03 (work in progress),
February 2008. February 2008.
[I-D.ietf-nsis-qspec] [I-D.ietf-nsis-qspec]
Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP
QSPEC Template", draft-ietf-nsis-qspec-19 (work in QSPEC Template", draft-ietf-nsis-qspec-20 (work in
progress), February 2008. progress), April 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-00 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in
progress), February 2008. progress), February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 11 change blocks. 
28 lines changed or deleted 39 lines changed or added

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