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/