draft-ietf-tsvwg-emergency-rsvp-08.txt   draft-ietf-tsvwg-emergency-rsvp-09.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: November 14, 2008 K. Carlberg Expires: April 20, 2009 K. Carlberg
G11 G11
May 13, 2008 October 17, 2008
Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services
draft-ietf-tsvwg-emergency-rsvp-08.txt draft-ietf-tsvwg-emergency-rsvp-09.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 November 14, 2008. This Internet-Draft will expire on April 20, 2009.
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,
or they may be shared with other sessions. or they may be shared with other sessions.
This document specifies RSVP extensions that can be used to support This document specifies extensions to the Resource reSerVation
such an admission priority capability at the network layer. Note Protocol (RSVP) that can be used to support such an admission
that these extensions represent one possible solution component in priority capability at the network layer. Note that these extensions
satisfying ETS requirements. Other solution components, or other represent one possible solution component in satisfying ETS
solutions, are outside the scope of this document. 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).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Related Technical Documents . . . . . . . . . . . . . . . 4 1.1. Related Technical Documents . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of RSVP extensions and Operations . . . . . . . . . . 5 2. Overview of RSVP extensions and Operations . . . . . . . . . . 6
2.1. Operations of Admission Priority . . . . . . . . . . . . . 7 2.1. Operations of Admission Priority . . . . . . . . . . . . . 8
3. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7 3. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 9
3.1. Admission Priority Policy Element . . . . . . . . . . . . 8 3.1. Admission Priority Policy Element . . . . . . . . . . . . 9
3.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10 3.1.1. Admission Priority Merging Rules . . . . . . . . . . . 11
3.2. Application-Level Resource Priority Policy Element . . . . 10 3.2. Application-Level Resource Priority Policy Element . . . . 12
3.2.1. Application-Level Resource Priority Modifying and 3.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 12 Merging Rules . . . . . . . . . . . . . . . . . . . . 13
3.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12 3.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
4.1. Use of RSVP Authentication between RSVP nighbors . . . . . 13 4.1. Use of RSVP Authentication between RSVP neighbors . . . . 15
4.2. Use of INTEGRITY object within the POLICY_DATA object . . 13 4.2. Use of INTEGRITY object within the POLICY_DATA object . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Examples of Bandwidth Allocation Model for Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 18 Admission Priority . . . . . . . . . . . . . . . . . 21
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 22
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 26
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 29
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 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. An underlying goal of these documents is
to present requirements that elevate the probability of session to present requirements that elevate the probability of session
establishment from an authorized user in times of network congestion establishment from an authorized user in times of network congestion
(presumably because of a crisis condition). In some extreme cases, (presumably because of a crisis condition). In some extreme cases,
skipping to change at page 3, line 43 skipping to change at page 4, line 43
probability may also take advantage of network layer admission probability may also take advantage of network layer admission
control mechanisms supporting admission priority. Networks usually control mechanisms supporting admission priority. Networks usually
have engineered capacity limits that characterize the maximum load have engineered capacity limits that characterize the maximum load
that can be handled (say, on any given link) for a class of traffic that can be handled (say, on any given link) for a class of traffic
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
admission priority when network layer admission control is performed
using the Resource ReSerVation Protovol (RSVP) ([RFC2205]).
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).
IP telephony "calls" are one form of "sessions" that can benefit from IP telephony "calls" are one form of "sessions" that can benefit from
the elevated session establishment probability discussed in this the elevated session establishment probability discussed in this
document. Video over IP and Instant Messaging are other examples. document. Video over IP and Instant Messaging are other examples.
For the sake of generality, we use the term "session" throughout this For the sake of generality, we use the term "session" throughout this
document to refer to any type of session. document to refer to any type of session.
1.1. Related Technical Documents 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
skipping to change at page 13, line 8 skipping to change at page 14, line 28
nodes. nodes.
Section 4.2 of [RFC2750] also defines a similar default behavior for Section 4.2 of [RFC2750] also defines a similar default behavior for
policy-capable nodes that do not recognized a particular Policy policy-capable nodes that do not recognized a particular Policy
Element. This applies to the Admission Priority Policy Element and Element. This applies to the Admission Priority Policy Element and
the ALRP Policy Element specified in this document, so that those can the ALRP Policy Element specified in this document, so that those can
traverse policy-capable nodes that do not support this document. traverse policy-capable nodes that do not support this document.
4. Security Considerations 4. Security Considerations
The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can As this document defines extensions to RSVP, the security
be signaled by RSVP through encapsulation in a Policy Data object as considerations of RSVP apply. Those are discussed in [RFC2205],
defined in [RFC2750]. Therefore, like any other Policy Elements, [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying].
their integrity can be protected as discussed in section 6 of
[RFC2750] by two optional security mechanisms. The first mechanism
relies on RSVP Authentication as specified in [RFC2747] and [RFC3097]
to provide a chain of trust when all RSVP nodes are policy capable.
With this mechanism, the INTEGRITY object is carried inside RSVP
messages. 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 between RSVP nighbors A subset of RSVP messages are signaled with the Router Alert Option
(RAO)([RFC2113],[RFC2711]). However, some network administrators
activate mechanisms at the edge of their administrative domain to
protect against potential Denial Of Service (DOS) attacks associated
with RAO. This may include hiding of the RAO to downstream interior
routers in the domain (as recommended by default over an MPLS network
in [I-D.dasmith-mpls-ip-options]) or complete blocking of packets
received with RAO at the administrative boundary. As the mechanisms
defined in this document rely on RSVP, their usage assume that such
protection against RAO packets are not activated in a way that
prevents RSVP processing on relevant interfaces or routers of the
controlled environments electing to deploy these mechanisms.
Nonetheless, it is recommended that protection mechanisms be
activated against potential DOS attacks through RAO even when RAO
message are processed. This may include rate limiting of incoming
RAO packets (e.g. at interface and/or router level). This may also
include deploying an RSVP architecture whereby interior routers are
not exposed to any RSVP messages associated with end to end
reservations (such as the architecture defined in
[I-D.ietf-tsvwg-rsvp-l3vpn]). We observe that the risks and security
measures associated with processing of RAO messages at an
administrative domain edge are fundamentally similar to those
involved with other forms of control plane interactions allowed at
administrative domain edges, such as routing or multicast routing
interactions allowed between a customer and his Internet Service
Provider, MPLS VPN ( [RFC4364] Service Provider , [RFC4659]) or MPLS
MVPN ([I-D.ietf-l3vpn-2547bis-mcast]) Service Provider.
This mechanism can be used can be used between RSVP neighbors that The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in
are policy capable. The RSVP neighbors use shared keys to compute this doocument are signaled by RSVP through encapsulation in a Policy
the cryptographic signature of the RSVP message. Data object as defined in [RFC2750]. Therefore, like any other
Policy Elements, their integrity can be protected as discussed in
section 6 of [RFC2750] by two optional security mechanisms. The
first mechanism relies on RSVP Authentication as specified in
[RFC2747] and [RFC3097] to provide a chain of trust when all RSVP
nodes are policy capable. With this mechanism, the INTEGRITY object
is carried inside RSVP messages. 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 between RSVP neighbors
This mechanism can be used between RSVP neighbors that are policy
capable. The RSVP neighbors use shared keys to compute the
cryptographic signature of the RSVP message.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key
provisioning methods as well as their respective applicability. provisioning methods as well as their respective applicability.
4.2. Use of INTEGRITY object within the POLICY_DATA object 4.2. Use of INTEGRITY object within the POLICY_DATA object
The INTEGRITY object within the POLICY_DATA object can be used to The INTEGRITY object within the POLICY_DATA object can be used to
guarantee integrity between non-neighboring RSVP PEPs. guarantee integrity between non-neighboring RSVP PEPs.
Details for computation of the content of the INTEGRITY object can be Details for computation of the content of the INTEGRITY object can be
found in Appendix B of [RFC2750]. This states that the Policy found in Appendix B of [RFC2750]. This states that the Policy
skipping to change at page 14, line 14 skipping to change at page 16, line 19
scenarios where a single (or low number of) PDP is used to control scenarios where a single (or low number of) PDP is used to control
all the PEPs of a region (such as an administrative domain). In such all the PEPs of a region (such as an administrative domain). In such
scenarios, it may be easy for a PDP to determine what is the next hop scenarios, it may be easy for a PDP to determine what is the next hop
PDP, even when the next hop PEP is not known, simply by determining PDP, even when the next hop PEP is not known, simply by determining
what is the next region that will be traversed (say based on the what is the next region that will be traversed (say based on the
destination address). destination address).
5. IANA Considerations 5. IANA Considerations
As specified in [RFC2750], Standard RSVP Policy Elements (P-type As specified in [RFC2750], Standard RSVP Policy Elements (P-type
values) are to be assigned by IANA as per "IETF Consensus" following values) are to be assigned by IANA as per "IETF Consensus" policy
the policies outlined in [RFC2434]. following the policies outlined in [RFC2434] (this policy is now
called "IETF Review" as per [RFC5226]) .
IANA needs to allocate two P-Types from the Standard RSVP Policy IANA needs to allocate two P-Types from the Standard RSVP Policy
Element range: Element range:
o one P-Type to the Admission Priority Policy Element o one P-Type to the Admission Priority Policy Element
o one P-Type to the Application-Level Resource Priority Policy o one P-Type to the Application-Level Resource Priority Policy
Element. Element.
In section 3.1, the present document defines a Merge Strategy field In section 3.1, the present document defines a Merge Strategy field
inside the Admission Priority policy element. IANA needs to create a inside the Admission Priority policy element. IANA needs to create a
registry for this field and allocate the following values: registry for this field and allocate the following values:
o 1: Take priority of highest QoS o 1: Take priority of highest QoS
o 2: Take highest priority o 2: Take highest priority
o 3: Force Error on heterogeneous merge o 3: Force Error on heterogeneous merge
Following the policies outlined in [RFC2434], numbers in the range Following the policies outlined in [RFC5226], numbers in the range
4-127 are allocated through an IETF Consensus action, numbers in the 4-127 are allocated according to the "IETF Review" policy, numbers in
range 128-240 as First Come First Served and numbers between 241-255 the range 128-240 as "First Come First Served" and numbers between
are reserved for Private Use. Value 0 is Reserved (for consistency 241-255 are reserved for "Private Use". Value 0 is Reserved (for
with [RFC3181] Merge Strategy values). consistency with [RFC3181] Merge Strategy values).
In section 3.1, the present document defines an Error Code field In section 3.1, the present document defines an Error Code field
inside the Admission Priority policy element. IANA needs to create a inside the Admission Priority policy element. IANA needs to create a
registry for this field and allocate the following values: registry for this field and allocate the following values:
o 0: NO_ERROR Value used for regular ADMISSION_PRI elements o 0: NO_ERROR Value used for regular ADMISSION_PRI elements
o 2: HETEROGENEOUS This element encountered heterogeneous merge o 2: HETEROGENEOUS This element encountered heterogeneous merge
Following the policies outlined in [RFC2434], numbers in the range Following the policies outlined in [RFC5226], numbers in the range
3-127 are allocated through an IETF Consensus action, numbers in the 3-127 are allocated according to the "IETF Review" policy, numbers in
range 128-240 as First Come First Served and numbers between 241-255 the range 128-240 as "First Come First Served" and numbers between
are reserved for Private Use. Value 1 is Reserved (for consistency 241-255 are reserved for "Private Use". Value 1 is Reserved (for
with [RFC3181] Error Code values). consistency with [RFC3181] Error Code values).
The present document defines an ALRP Namespace field in section 3.2 The present document defines an ALRP Namespace field in section 3.2
that contains a numerical value identifying the namespace of the that contains a numerical value identifying the namespace of the
application-level resource priority. The IANA already maintains the application-level resource priority. The IANA already maintains the
Resource-Priority Namespaces registry (under the SIP Parameters) Resource-Priority Namespaces registry (under the SIP Parameters)
listing all such namespace. However, that registry does not listing all such namespace. However, that registry does not
currently allocate a numerical value to each namespace. Hence, this currently allocate a numerical value to each namespace. Hence, this
document requests the IANA to extend the Resource-Priority Namespace document requests the IANA to extend the Resource-Priority Namespace
registry in the following ways: registry in the following ways:
skipping to change at page 16, line 38 skipping to change at page 18, line 45
priority is always allocated value 0). For example, in the drsn priority is always allocated value 0). For example, in the drsn
namespace, "routine" would be allocated numerical value 5 and "flash- namespace, "routine" would be allocated numerical value 5 and "flash-
override-override" would be allocated numerical value 0. override-override" would be allocated numerical value 0.
6. Acknowledgments 6. Acknowledgments
We would like to thank An Nguyen for his encouragement to address We would like to thank An Nguyen for his encouragement to address
this topic and ongoing comments. Also, this document borrows heavily this topic and ongoing comments. Also, this document borrows heavily
from some of the work of S. Herzog on Preemption Priority Policy from some of the work of S. Herzog on Preemption Priority Policy
Element [RFC3181]. Dave Oran and Janet Gunn provided useful input Element [RFC3181]. Dave Oran and Janet Gunn provided useful input
into this document. into this document. Thanks to Magnus Westerlund, Cullen Jennings and
Ross Callon for helping clarify applicability of the mechanisms
defined in this document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", [RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000. RFC 2750, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
skipping to change at page 17, line 28 skipping to change at page 19, line 46
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
7.2. Informative References 7.2. Informative References
[I-D.dasmith-mpls-ip-options]
Jaeger, W., Mullooly, J., Scholl, T., and D. Smith,
"Requirements for Label Edge Router Forwarding of IPv4
Option Packets", draft-dasmith-mpls-ip-options-01 (work in
progress), October 2008.
[I-D.ietf-dime-diameter-qos] [I-D.ietf-dime-diameter-qos]
Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,
and G. Zorn, "Diameter Quality of Service Application", and G. Zorn, "Diameter Quality of Service Application",
draft-ietf-dime-diameter-qos-05 (work in progress), draft-ietf-dime-diameter-qos-06 (work in progress),
February 2008. July 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-06 (work in progress),
February 2008. May 2008.
[I-D.ietf-l3vpn-2547bis-mcast]
Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work
in progress), July 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-20 (work in QSPEC Template", draft-ietf-nsis-qspec-20 (work in
progress), April 2008. progress), April 2008.
[I-D.ietf-tsvwg-rsvp-l3vpn]
Davie, B., Faucheur, F., and A. Narayanan, "Support for
RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-00
(work in progress), July 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-01 (work in
progress), February 2008. progress), July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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,
January 2000. January 2000.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S., and R. Hess, "Identity Representation for Herzog, S., and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001. RSVP", RFC 3182, October 2001.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
skipping to change at page 18, line 41 skipping to change at page 21, line 31
[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.
[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 [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.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006.
Appendix A. Examples of Bandwidth Allocation Model for Admission Appendix A. Examples of Bandwidth Allocation Model for Admission
Priority Priority
Sections A.1 and A.2 respectively illustrate how the Maximum Sections A.1 and A.2 respectively illustrate how the Maximum
Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM) Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM)
([RFC4127]) can be used for support of admission priority. The ([RFC4127]) can be used for support of admission priority. The
Maximum Allocation model with Reservation (MAR) ([RFC4126]) could Maximum Allocation model with Reservation (MAR) ([RFC4126]) could
also be used in a similar manner for support of admission priority. also be used in a similar manner for support of admission priority.
Section A.3 illustrates how a simple "Priority Bypass Model" can also Section A.3 illustrates how a simple "Priority Bypass Model" can also
be used for support of admission priority. be used for support of admission priority.
 End of changes. 26 change blocks. 
72 lines changed or deleted 167 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/