draft-ietf-tsvwg-emergency-rsvp-04.txt		draft-ietf-tsvwg-emergency-rsvp-05.txt
	RSVP Extensions for Emergency Services November 2007		RSVP Extensions for Emergency Services January 2008
	TSVWG Francois Le Faucheur		TSVWG Francois Le Faucheur
	Internet-Draft James Polk		Internet-Draft James Polk
	Intended Status: Standards Track Cisco Systems, Inc.		Intended Status: Standards Track Cisco Systems, Inc.
	Ken Carlberg		Ken Carlberg
	G11		G11
	draft-ietf-tsvwg-emergency-rsvp-04.txt		draft-ietf-tsvwg-emergency-rsvp-05.txt
	Expires: May 2008 November 19, 2007		Expires: August 1, 2008 January 31, 2008
	Resource ReSerVation Protovol (RSVP) Extensions for Emergency		Resource ReSerVation Protovol (RSVP) Extensions for Emergency
	Services		Services
	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.
	skipping to change at page 2, line 12		skipping to change at page 2, line 12
	resources may be explicitly set aside for emergency services, or they		resources may be explicitly set aside for emergency services, or they
	may be shared with other sessions.		may be shared with other sessions.
	This document specifies RSVP extensions that can be used to support		This document specifies RSVP extensions that can be used to support
	such an admission priority capability at the network layer. Note that		such an admission priority capability at the network layer. Note that
	these extensions represent one possible solution component in		these extensions represent one possible solution component in
	satisfying ETS requirements. Other solution components, or other		satisfying ETS requirements. Other solution components, or other
	solutions, are outside the scope of this document.		solutions, are outside the scope of this document.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Specification of Requirements		Specification of Requirements
	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.		document are to be interpreted as described in RFC 2119.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction...................................................3
	1.1. Related Technical Documents.................................3		1.1. Related Technical Documents................................3
	1.2. Terminology.................................................4		1.2. Terminology................................................4
	2. Overview of RSVP extensions and Operations.....................5		2. Overview of RSVP extensions and Operations.....................5
	2.1. Operations of Admission Priority..........................7		2.1. Operations of Admission Priority..........................7
	3. New Policy Elements............................................7		3. New Policy Elements............................................7
	3.1. Admission Priority Policy Element.........................8		3.1. Admission Priority Policy Element.........................8
	3.1.1. Admission Priority Merging Rules 9		3.1.1. Admission Priority Merging Rules 9
	3.2. Application-Level Resource Priority Policy Element.......10		3.2. Application-Level Resource Priority Policy Element.......10
	3.2.1. Application-Level Resource Priority Modifying and		3.2.1. Application-Level Resource Priority Modifying and
	Merging Rules 11		Merging Rules 11
	3.3. Default Handling.........................................11		3.3. Default Handling.........................................11
	4. Security Considerations.......................................12		4. Security Considerations.......................................12
	skipping to change at page 6, line 24		skipping to change at page 6, line 24
	As another example of operation across multiple administrative		As another example of operation across multiple administrative
	domains, we can consider the case where the resource priority header		domains, we can consider the case where the resource priority header
	enumerates several namespaces, as explicitly allowed by [SIP-		enumerates several namespaces, as explicitly allowed by [SIP-
	PRIORITY], for support of scenarios where calls traverse multiple		PRIORITY], for support of scenarios where calls traverse multiple
	administrative domains using different namespace. In that case, the		administrative domains using different namespace. In that case, the
	relevant namespace can be used at each domain boundary to map into an		relevant namespace can be used at each domain boundary to map into an
	RSVP Admission priority for that domain. It is not expected that the		RSVP Admission priority for that domain. It is not expected that the
	RSVP Application-Level Resource-Priority Header Policy Element would		RSVP Application-Level Resource-Priority Header Policy Element would
	be taken into account at RSVP-hops within a given administrative		be taken into account at RSVP-hops within a given administrative
	domain. It is expected to be used at administrative domain boundaries		domain. It is expected to be used at administrative domain boundaries
	only in order to set/reset the RSVP Admission Priority Policy Element.		only in order to set/reset the RSVP Admission Priority Policy
			Element.
	The existence of pre-established inter-domain policy agreements or		The existence of pre-established inter-domain policy agreements or
	Service Level Agreements may avoid the need to take real-time action		Service Level Agreements may avoid the need to take real-time action
	at administrative domain boundaries for mapping/remapping of		at administrative domain boundaries for mapping/remapping of
	admission priorities.		admission priorities.
	Mapping/remapping by PDPs may also be applied to boundaries between		Mapping/remapping by PDPs may also be applied to boundaries between
	various signaling protocols, such as those advanced by the NSIS		various signaling protocols, such as those advanced by the NSIS
	working group.		working group.
	skipping to change at page 8, line 43		skipping to change at page 8, line 43
	| Reserved |Adm. Priority|		| Reserved |Adm. Priority|
	+---------------------------+---------------------------+		+---------------------------+---------------------------+
	Length: 16 bits		Length: 16 bits
	Always 12. The overall length of the policy element, in bytes.		Always 12. The overall length of the policy element, in bytes.
	P-Type: 16 bits		P-Type: 16 bits
	ADMISSION_PRI = To be allocated by IANA		ADMISSION_PRI = To be allocated by IANA
	(see "IANA Considerations" section)		(see "IANA Considerations" section)
	Flags: Reserved (MUST be set to zero on transmit and ignored on		Flags: Reserved (SHALL be set to zero on transmit and SHALL be
	receive)		ignored on reception)
	Merge Strategy: 8 bits (only applicable to multicast flows)		Merge Strategy: 8 bits (only applicable to multicast flows)
	1 Take priority of highest QoS		1 Take priority of highest QoS
	2 Take highest priority		2 Take highest priority
	3 Force Error on heterogeneous merge		3 Force Error on heterogeneous merge
	(See section 3.1.1)		(See section 3.1.1)
	Error code: 8 bits (only applicable to multicast flows)		Error code: 8 bits (only applicable to multicast flows)
	0 NO_ERROR Value used for regular ADMISSION_PRI elements		0 NO_ERROR Value used for regular ADMISSION_PRI elements
	2 HETEROGENEOUS This element encountered heterogeneous merge		2 HETEROGENEOUS This element encountered heterogeneous merge
	Reserved: 8 bits		Reserved: 8 bits
	Always 0.		SHALL be set to zero on transmit and SHALL be ignored on
			reception.
	Reserved: 24 bits		Reserved: 24 bits
	Always 0.		SHALL be set to zero on transmit and SHALL be ignored on
			reception.
	Adm. Priority (Admission Priority): 8 bits (unsigned)		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
	to network bandwidth in order to provide higher probability of		network bandwidth in order to provide higher probability of call
	call completion to selected flows. Higher values represent		completion to selected flows. Higher values represent higher
	higher Priority.		Priority. A given Admission Priority is encoded in this information
			element using the same value as when encoded in the Admission
			Priority parameter defined in section 6.2.9 of [NSIS-QSPEC], or in
			the Admission Priority parameter defined in section 4.10 of [DIME-
			PARAM]. In other words, a given value inside the Admission Priority
			information element defined in the present document, inside the
			[NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM]
			Admission Priority parameter, refers to the same Admission Priority.
	Bandwidth allocation models such as those described in Appendix		Bandwidth allocation models such as those described in Appendix A are
	A are to be used by the RSVP router to achieve such increased		to be used by the RSVP router to achieve such increased probability
	probability of call completion. The admission priority value		of call completion. The admission priority value effectively
	effectively indicates which bandwidth constraint(s) of the		indicates which bandwidth constraint(s) of the bandwidth constraint
	bandwidth constraint model in use is(are) applicable to		model in use is(are) applicable to admission of this RSVP
	admission of this RSVP reservation.		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.
	3.1.1.		3.1.1. Admission Priority Merging Rules
	Admission Priority Merging Rules
	This section discusses alternatives for dealing with RSVP admission		This section discusses alternatives for dealing with RSVP admission
	priority in case of merging of reservations. As merging is only		priority in case of merging of reservations. As merging is only
	applicable to multicast, this section also only applies to multicast		applicable to multicast, this section also only applies to multicast
	sessions.		sessions.
	The rules for merging Admission Priority Policy Elements are the same		The rules for merging Admission Priority Policy Elements are the same
	as those defined in [RSVP-PREEMP] for merging Preemption Priority		as those defined in [RSVP-PREEMP] for merging Preemption Priority
	Policy Elements. In particular, the following merging strategies are		Policy Elements. In particular, the following merging strategies are
	supported:		supported:
	skipping to change at page 10, line 42		skipping to change at page 11, line 4
	APP_RESOURCE_PRI = To be allocated by IANA		APP_RESOURCE_PRI = To be allocated by IANA
	(see "IANA Considerations" section)		(see "IANA Considerations" section)
	ALRP:		ALRP:
	0 0 0 1 1 2 2 3		0 0 0 1 1 2 2 3
	0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1		0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
	+---------------------------+-------------+-------------+		+---------------------------+-------------+-------------+
	| ALRP Namespace | Reserved |ALRP Priority|		| ALRP Namespace | Reserved |ALRP Priority|
	+---------------------------+---------------------------+		+---------------------------+---------------------------+
	ALRP Namespace (Application-Level Resource Priority Namespace):		ALRP Namespace (Application-Level Resource Priority Namespace):
	16 bits (unsigned)		16 bits (unsigned)
	Contains a numerical value identifying the namespace of the		Contains a numerical value identifying the namespace of the
	application-level resource priority. This value is encoded		application-level resource priority. This value is encoded
	as per the "Resource-Priority Namespaces" IANA registry. (See		as per the "Resource-Priority Namespaces" IANA registry. (See
	IANA Considerations section for the request to IANA to		IANA Considerations section for the request to IANA to
	extend the registry to include this numerical value).		extend the registry to include this numerical value).
	Reserved: 8 bits		Reserved: 8 bits
	Always 0.		SHALL be set to zero on transmit and SHALL be ignored on
			reception.
	ALRP Priority: (Application-Level Resource Priority Priority):		ALRP Priority: (Application-Level Resource Priority Priority):
	8 bits (unsigned)		8 bits (unsigned)
	Contains the priority value within the namespace of the		Contains the priority value within the namespace of the
	application-level resource priority. This value is encoded		application-level resource priority. This value is encoded
	as per the "Resource-Priority Priority-Value" IANA registry.		as per the "Resource-Priority Priority-Value" IANA registry.
	(See IANA Considerations section for the request to IANA to		(See IANA Considerations section for the request to IANA to
	extend the registry to include this numerical value).		extend the registry to include this numerical value).
	3.2.1.		3.2.1. Application-Level Resource Priority Modifying and Merging Rules
	Application-Level Resource Priority Modifying and Merging Rules
	When POLICY_DATA objects are protected by integrity, LPDPs should not		When POLICY_DATA objects are protected by integrity, LPDPs should not
	attempt to modify them. They MUST be forwarded as-is to ensure their		attempt to modify them. They MUST be forwarded as-is to ensure their
	security envelope is not invalidated.		security envelope is not invalidated.
	In case of multicast, when POLICY_DATA objects are not protected by		In case of multicast, when POLICY_DATA objects are not protected by
	integrity, LPDPs MAY merge incoming Application-Level Resource		integrity, LPDPs MAY merge incoming Application-Level Resource
	Priority elements to reduce their size and number. When they do merge		Priority elements to reduce their size and number. When they do merge
	those, LPDPs MUST do so according to the following rule:		those, LPDPs MUST do so according to the following rule:
	skipping to change at page 13, line 43		skipping to change at page 14, line 9
	Value = the unique numerical value identifying the		Value = the unique numerical value identifying the
	namespace"		namespace"
	- add a line at the bottom of the registry stating the		- add a line at the bottom of the registry stating the
	following "* : [RFCXXX] " where XXX is the RFC number of		following "* : [RFCXXX] " where XXX is the RFC number of
	the present document		the present document
	- allocate an actual numerical value to each namespace in		- allocate an actual numerical value to each namespace in
	the registry and state that value in the new "Namespace		the registry and state that value in the new "Namespace
	numerical Value *" column.		numerical Value *" column.
	A numerical value should be allocated immediately by IANA to all		A numerical value should be allocated immediately by IANA to all
	existing namespace. Then, in the future, IANA should automatically		existing namespace. Then, in the future, IANA should automatically
	allocate a numerical value to any new namespace added to the registry.		allocate a numerical value to any new namespace added to the
			registry.
	[draft-ietf-nsis-qspec] also uses numerical values for Resource-
	Priority Namespaces. To that end, the document requests IANA to
	create a new registry to allocate numerical values to each namespace.
	We suggest that the approach above be followed instead (i.e. extend
	the existing registry) and that [draft-ietf-nsis-qspec] also makes
	use of the values defined in the new "Namespace numerical Value *"
	column of the extended existing Resource-Priority Namespace registry.
	In any case, the IANA should honor only one of the two competing
	requests (and not both).
	The present document defines an ALRP Priority field in section 3.2		The present document defines an ALRP Priority field in section 3.2
	that contains a numerical value identifying the actual application-		that contains a numerical value identifying the actual application-
	level resource priority within the application-level resource		level resource priority within the application-level resource
	priority namespace. The IANA already maintains the Resource-Priority		priority namespace. The IANA already maintains the Resource-Priority
	Priority-values registry (under the SIP Parameters) listing all such		Priority-values registry (under the SIP Parameters) listing all such
	priorities. However, that registry does not currently allocate a		priorities. However, that registry does not currently allocate a
	numerical value to each priority-value. Hence, this document requests		numerical value to each priority-value. Hence, this document requests
	the IANA to extend the Resource-Priority Priority-Values registry in		the IANA to extend the Resource-Priority Priority-Values registry in
	the following ways:		the following ways:
	skipping to change at page 14, line 38		skipping to change at page 14, line 42
	- At the bottom of the registry, add a "Legend" with a line		- At the bottom of the registry, add a "Legend" with a line
	saying "Priority Numerical Value = the unique numerical		saying "Priority Numerical Value = the unique numerical
	value identifying the priority within a namespace"		value identifying the priority within a namespace"
	- add a line at the bottom of the registry stating the		- add a line at the bottom of the registry stating the
	following "* : [RFCXXX] " where XXX is the RFC number of		following "* : [RFCXXX] " where XXX is the RFC number of
	the present document		the present document
	- allocate an actual numerical value to each and state that		- allocate an actual numerical value to each and state that
	value in the new "Priority Numerical Value *" column.		value in the new "Priority Numerical Value *" column.
	A numerical value should be allocated immediately by IANA to all		A numerical value should be allocated immediately by IANA to all
	existing priority. Then, in the future, IANA should automatically		existing priority. Then, in the future, IANA should automatically
	allocate a numerical value to any new namespace added to the registry.		allocate a numerical value to any new namespace added to the
	The numerical value must be unique within each namespace. Within each		registry. The numerical value must be unique within each namespace.
	namespace, values should be allocated in decreasing order ending with		Within each namespace, values should be allocated in decreasing order
	0 (so that the greatest priority is always allocated value 0). For		ending with 0 (so that the greatest priority is always allocated
	example, in the drsn namespace, "routine" would be allocated		value 0). For example, in the drsn namespace, "routine" would be
	numerical value 5 and "flash-override-override" would be allocated		allocated numerical value 5 and "flash-override-override" would be
	numerical value 0.		allocated numerical value 0.
	[draft-ietf-nsis-qspec] also uses numerical values for Resource-
	Priority Priorities. To that end, the document requests IANA to
	create a new registry to allocate numerical values to each priority.
	We suggest that the approach above be followed instead (i.e. extend
	the existing registry) and that [draft-ietf-nsis-qspec] also makes
	use of the values defined in the new "Priority Numerical Value *"
	column of the extended existing Resource-Priority Priority-Values
	registry. In any case, the IANA should honor only one of the two
	competing requests (and not both).
	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 [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input		Element [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input
	into this document.		into this document.
	7. Normative References		7. Normative References
	skipping to change at page 15, line 42		skipping to change at page 15, line 40
	[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy		[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy
	Element", RFC 3181, October 2001.		Element", RFC 3181, October 2001.
	[SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261,		[SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261,
	[SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource		[SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource
	Priority for the Session Initiation Protocol (SIP)", RFC4412,		Priority for the Session Initiation Protocol (SIP)", RFC4412,
	February 2006.		February 2006.
	8. Informative References		8. Informative References
	[DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth		[DIME-PARAM] J. Korhonen & H. Tschofenig, "Quality of Service
			Parameters for Usage with the AAA Framework", draft-ietf-dime-qos-
			parameters-01.txt, work in progress.
			[DSTE-MAM] F. Le Faucheur & W. Lai, "Maximum Allocation Bandwidth
	Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC		Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC
	4125, June 2005.		4125, June 2005.
	[DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints		[DSTE-RDM] Le Faucheur et al., Russian Dolls Bandwidth Constraints
	Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June		Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June
	2005		2005.
	[EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency		[EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency
	Telecommunications Service for Real Time Services in the Internet		Telecommunications Service for Real Time Services in the Internet
	Protocol Suite", RFC 4542, May 2006.		Protocol Suite", RFC 4542, May 2006.
	[EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for		[EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for
	Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.		Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
	[EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements		[EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
	for Emergency Telecommunication Service (ETS)", RFC 3690, February		for Emergency Telecommunication Service (ETS)", RFC 3690, February
	2004.		2004.
	[FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework		[FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
	for Policy-based Admission Control", RFC 2753, January 2000.		for Policy-based Admission Control", RFC 2753, January 2000.
	[ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU,		[ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU,
	Recommendation, I.255.3, July, 1990.		Recommendation, I.255.3, July, 1990.
			[NSIS-QSPEC] G. Ash et al., "QoS NLSP QSPEC Template", draft-ietf-
			nsis-qspec-18.txt, work in progress.
	[RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,		[RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
	Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182,		Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182,
	October 2001.		October 2001.
	[RSVP-GROUPKEYING] Behringer, M., Le Faucheur, F., "A Framework for		[RSVP-GROUPKEYING] Behringer, M., Le Faucheur, F., "Applicability of
	RSVP Security using Dynamic Group Keying", draft-behringer-tsvwg-		Keying Methods for RSVP Security", draft-behringer-tsvwg-rsvp-
	rsvp-security-groupkeying-00.txt, work in progress.		security-groupkeying-01.txt, work in progress.
	[SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg,		[SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg,
	"Integration of Resource Management and Session Initiation Protocol		"Integration of Resource Management and Session Initiation Protocol
	(SIP)", RFC 3312, October 2002.		(SIP)", RFC 3312, October 2002.
	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 [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE-		Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE-
	skipping to change at page 18, line 38		skipping to change at page 18, line 38
	operator may configure the bandwidth available to non-priority		operator may configure the bandwidth available to non-priority
	traffic to X, and the bandwidth available to priority traffic to 5%		traffic to X, and the bandwidth available to priority traffic to 5%
	of X.		of X.
	At the other extreme, where the proportion of priority traffic may be		At the other extreme, where the proportion of priority traffic may be
	significant at times and the engineered capacity limits are very		significant at times and the engineered capacity limits are very
	tight, the operator may decide to configure the bandwidth available		tight, the operator may decide to configure the bandwidth available
	to non-priority traffic and the bandwidth available to priority		to non-priority traffic and the bandwidth available to priority
	traffic such that their sum is equal to the engineered capacity		traffic such that their sum is equal to the engineered capacity
	limits. This guarantees that the total load across non-priority and		limits. This guarantees that the total load across non-priority and
	priority traffic is always below the engineered capacity and, in turn,		priority traffic is always below the engineered capacity and, in
	guarantees there will never be any QoS degradation. However, this		turn, guarantees there will never be any QoS degradation. However,
	policy is less attractive economically as it prevents non-priority		this policy is less attractive economically as it prevents non-
	calls from using the full engineered capacity, even when there is no		priority calls from using the full engineered capacity, even when
	or little priority load, which is the majority of time. This policy		there is no or little priority load, which is the majority of time.
	illustrated as (3) in Chart 1. As an example, if the engineered		This policy illustrated as (3) in Chart 1. As an example, if the
	capacity limit on a given link is X, the operator may configure the		engineered capacity limit on a given link is X, the operator may
	bandwidth available to non-priority traffic to 95% of X, and the		configure the bandwidth available to non-priority traffic to 95%
	bandwidth available to priority traffic to 5% of X.		of X, and the bandwidth available to priority traffic to 5% of X.
	Of course, an operator may also strike a balance anywhere in between		Of course, an operator may also strike a balance anywhere in between
	these two approaches. This policy illustrated as (2) in Chart 1.		these two approaches. This policy illustrated as (2) in Chart 1.
	Chart 2 shows some of the non-priority capacity of this link being		Chart 2 shows some of the non-priority capacity of this link being
	used.		used.
	-----------------------		-----------------------
	^ ^ ^ | | ^		^ ^ ^ | | ^
	. . . | | .		. . . | | .
	skipping to change at page 26, line 31		skipping to change at page 26, line 31
	Chart 13. Full non-priority load		Chart 13. Full non-priority load
	Appendix B: Example Usages of RSVP Extensions		Appendix B: Example Usages of RSVP Extensions
	This section provides examples of how RSVP extensions defined in this		This section provides examples of how RSVP extensions defined in this
	document can be used (in conjunctions with other RSVP functionality		document can be used (in conjunctions with other RSVP functionality
	and SIP functionality) to enforce different hypothetical policies for		and SIP functionality) to enforce different hypothetical policies for
	handling Emergency sessions in a given administrative domain. This		handling Emergency sessions in a given administrative domain. This
	Appendix does not provide additional specification. It is only		Appendix does not provide additional specification. It is only
	included in this document for illustration purposes. The content of		included in this document for illustration purposes.
	this appendix may be moved into a future applicability statement
	document.
	We assume an environment where SIP is used for session control and		We assume an environment where SIP is used for session control and
	RSVP is used for resource reservation.		RSVP is used for resource reservation.
	In a mild abuse of language, we refer here to "Call Queueing" as the		In a mild abuse of language, we refer here to "Call Queueing" as the
	set of "session" layer capabilities that may be implemented by SIP		set of "session" layer capabilities that may be implemented by SIP
	user agents to influence their treatment of SIP requests. This may		user agents to influence their treatment of SIP requests. This may
	include the ability to "queue" call requests when those can not be		include the ability to "queue" call requests when those can not be
	immediately honored (in some cases with the notion of "bumping", or		immediately honored (in some cases with the notion of "bumping", or
	"displacement", of less important call request from that queue). It		"displacement", of less important call request from that queue). It
	skipping to change at page 27, line 26		skipping to change at page 27, line 25
	can achieve this by signaling emergency calls:		can achieve this by signaling emergency calls:
	* using "Resource-Priority" Header in SIP		* using "Resource-Priority" Header in SIP
	* using Admission-Priority Policy Element in RSVP		* using Admission-Priority Policy Element in RSVP
	* not using Preemption Policy Element in RSVP		* not using Preemption Policy Element in RSVP
	Emergency calls will not result in preemption of any session.		Emergency calls will not result in preemption of any session.
	Different bandwidth allocation models can be used to offer different		Different bandwidth allocation models can be used to offer different
	"prioritized access to network resources". Just as examples, this		"prioritized access to network resources". Just as examples, this
	includes strict setting aside of capacity for emergency sessions as		includes strict setting aside of capacity for emergency sessions as
	well as simple bypass of admission limits for emergency sessions.		well as simple bypass of admission limits for emergency sessions.
	If one wants to implement an emergency service based on Call Queueing,		If one wants to implement an emergency service based on Call
			Queueing,
	on "prioritized access to network layer resources", and ensures that		on "prioritized access to network layer resources", and ensures that
	(say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but		(say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but
	non-emergency sessions are not affected by preemption, one can do		non-emergency sessions are not affected by preemption, one can do
	that by signaling emergency calls:		that by signaling emergency calls:
	* using "Resource-Priority" Header in SIP		* using "Resource-Priority" Header in SIP
	* using Admission-Priority Policy Element in RSVP		* using Admission-Priority Policy Element in RSVP
	* using Preemption Policy Element in RSVP with:		* using Preemption Policy Element in RSVP with:
	o setup (Emergency-1) > defending (Emergency-2)		o setup (Emergency-1) > defending (Emergency-2)
	o setup (Emergency-2) <= defending (Emergency-1)		o setup (Emergency-2) <= defending (Emergency-1)
	o setup (Emergency-1) <= defending (Non-Emergency)		o setup (Emergency-1) <= defending (Non-Emergency)
	o setup (Emergency-2) <= defending (Non-Emergency)		o setup (Emergency-2) <= defending (Non-Emergency)
	If one wants to implement an emergency service based on Call Queueing,		If one wants to implement an emergency service based on Call
			Queueing,
	on "prioritized access to network layer resources", and ensure that		on "prioritized access to network layer resources", and ensure that
	"emergency" sessions can preempt regular sessions, one could do that		"emergency" sessions can preempt regular sessions, one could do that
	by signaling emergency calls:		by signaling emergency calls:
	* using "Resource-Priority" Header in SIP		* using "Resource-Priority" Header in SIP
	* using Admission-Priority Policy Element in RSVP		* using Admission-Priority Policy Element in RSVP
	* using Preemption Policy Element in RSVP with:		* using Preemption Policy Element in RSVP with:
	o setup (Emergency) > defending (Non-Emergency)		o setup (Emergency) > defending (Non-Emergency)
	o setup (Non-Emergency) <= defending (Emergency)		o setup (Non-Emergency) <= defending (Emergency)
	If one wants to implement an emergency service based on Call Queueing,		If one wants to implement an emergency service based on Call
			Queueing,
	on "prioritized access to network layer resources", and ensure that		on "prioritized access to network layer resources", and ensure that
	"emergency" sessions can partially preempt regular sessions (ie		"emergency" sessions can partially preempt regular sessions (ie
	reduce their reservation size), one could do that by signaling		reduce their reservation size), one could do that by signaling
	emergency calls:		emergency calls:
	* using "Resource-Priority" Header in SIP		* using "Resource-Priority" Header in SIP
	* using Admission-Priority Policy Element in RSVP		* using Admission-Priority Policy Element in RSVP
	* using Preemption in Policy Element RSVP with:		* using Preemption in Policy Element RSVP with:
	o setup (Emergency) > defending (Non-Emergency)		o setup (Emergency) > defending (Non-Emergency)
	o setup (Non-Emergency) <= defending (Emergency)		o setup (Non-Emergency) <= defending (Emergency)
	* activate RFC4495 RSVP Bandwidth Reduction mechanisms		* activate RFC4495 RSVP Bandwidth Reduction mechanisms
	skipping to change at page 29, line 22		skipping to change at page 29, line 22
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 27 change blocks.
	78 lines changed or deleted		74 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/