draft-ietf-tsvwg-emergency-rsvp-12.txt		draft-ietf-tsvwg-emergency-rsvp-13.txt
			TSVWG
			Internet-Draft Zhao Jihong
			Intended status: Standards Track Ren Luyuan
			Expires: May 20, 2010 Xi'an Institute of
			Posts and Telecommunications
			November 16, 2009
	TSVWG F. Le Faucheur		Addition to Resource ReSerVation Protocol (RSVP) Extension for Emergency Services
	Internet-Draft J. Polk		draft-ietf-tsvwg-emergency-rsvp-13.txt
	Intended status: Standards Track Cisco
	Expires: November 29, 2009 K. Carlberg
	G11
	May 28, 2009
	Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority
	draft-ietf-tsvwg-emergency-rsvp-12.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this		the person(s) controlling the copyright in such materials, this
	skipping to change at page 2, line 15		skipping to change at page 2, line ?
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		Abstract
	Some applications require the ability to provide an elevated		Some applications require the ability to provide an elevated
	probability of session establishment to specific sessions in times of		probability of session establishment to specific sessions in times of
	network congestion. When supported over the Internet Protocol suite,		network congestion.When supported over the Internet Protocol suite,
	this may be facilitated through a network layer admission control		this may be facilitated through a network layer admission control
	solution that supports prioritized access to resources (e.g.,		solution that supports prioritized access to resources (e.g.,
	bandwidth). These resources may be explicitly set aside for		bandwidth). These resources may be explicitly set aside for
	prioritized sessions, or may be shared with other sessions. This		prioritized sessions, or may be shared with other sessions. This
	document specifies extensions to the Resource reSerVation Protocol		document specifies extensions to the Resource reSerVation Protocol
	(RSVP) that can be used to support such an admission priority		(RSVP) that can be used to support such an admission priority
	capability at the network layer.		capability at the network layer.
	Based on current security concerns, these extensions are targeting		Based on current security concerns, these extensions are targeting
	applicability within a single domain.		applicability within a single domain.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Overview of RSVP extensions and Operations . . . . . . . . . . 5		3. Overview of RSVP extensions and Operations . . . . . . . . . . 3
	3.1. Operations of Admission Priority . . . . . . . . . . . . . 7		3.1. Operations of Admission Priority . . . . . . . . . . . . . 5
	4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 8		4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Admission Priority Policy Element . . . . . . . . . . . . 8		4.1. Admission Priority Policy Element . . . . . . . . . . . . 6
	4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10		4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 8
	4.2. Application-Level Resource Priority Policy Element . . . . 11		4.2. Application-Level Resource Priority Policy Element . . . . 8
	4.2.1. Application-Level Resource Priority Modifying and		4.2.1. Application-Level Resource Priority Modifying and
	Merging Rules . . . . . . . . . . . . . . . . . . . . 12		Merging Rules . . . . . . . . . . . . . . . . . . . . 9
	4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12		4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5.1. Use of RSVP Authentication between RSVP neighbors . . . . 13		5.1. Use of RSVP Authentication between RSVP neighbors . . . . 11
	5.2. Use of INTEGRITY object within the POLICY_DATA object . . 14		5.2. Use of INTEGRITY object within the POLICY_DATA object . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Appendix A. Examples of Bandwidth Allocation Model for		Appendix A. Examples of Bandwidth Allocation Model for
	Admission Priority . . . . . . . . . . . . . . . . . 19		Admission Priority . . . . . . . . . . . . . . . . . 16
	A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19		A.1. Admission Priority with Maximum Allocation Model (MAM) . . 18
	A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23		A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 20
	A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26		A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 22
			A.4 Admission Priority with Temporary Allocation Model(TAM). . 25
	Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29		Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		Introduction
	Some applications require the ability to provide an elevated		Some applications require the ability to provide an elevated
	probability of session establishment to specific sessions in times of		probability of session establishment to specific sessions in times of
	network congestion.		network congestion.
	Solutions to meet this requirement for elevated session establishment		Solutions to meet this requirement for elevated session establishment
	probability may involve session layer capabilities prioritizing		probability may involve session layer capabilities prioritizing
	access to resources controlled by the session control function. As		access to resources controlled by the session control function. As
	an example, entities involved in session control (such as SIP user		an example, entities involved in session control (such as SIP user
	agents, when the Session Initiation Protocol (SIP) [RFC3261], is the		agents, when the Session Initiation Protocol (SIP) [RFC3261], is the
	skipping to change at page 17, line 12		skipping to change at page 14, line 25
	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		allocate a numerical value to any new namespace added to the
	registry. The numerical value must be unique within each namespace.		registry. The numerical value must be unique within each namespace.
	For the initial allocation, within each namespace, values should be		For the initial allocation, within each namespace, values should be
	allocated in decreasing order ending with 0 (so that the greatest		allocated in decreasing order ending with 0 (so that the greatest
	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.
	7. Acknowledgments		7. Acknowledgments
	We would like to thank An Nguyen for his encouragement to address		This context is as a complement to the previous draft-ietf
	this topic and ongoing comments. Also, this document borrows heavily		-tsvwg-emergency-rsvp-12.txt.
	from some of the work of S. Herzog on Preemption Priority Policy
	Element [RFC3181]. Dave Oran and Janet Gunn provided useful input
	into this document. Ron Bonica, Magnus Westerlund, Cullen Jennings,
	and Ross Callon provided specific guidance for the applicability
	statement of the mechanisms defined in this document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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
	skipping to change at page 29, line 22		skipping to change at page 25, line 45
	. . |xxoxxxxxxoxxxx| .		. . |xxoxxxxxxoxxxx| .
	Capacity. . |oxxxooooxxxxoo| .		Capacity. . |oxxxooooxxxxoo| .
	v . |xxoxxxooxxxxxx| v		v . |xxoxxxooxxxxxx| v
	. |--------------| ---		. |--------------| ---
	. |oooooooooooooo|		. |oooooooooooooo|
	v | |		v | |
	| |		| |
	Figure 16: Full non-priority load		Figure 16: Full non-priority load
			A.4. Admission Priority with Temporary Allocation Model(TAM)
			This section illustrates operations of admission priority when a
			Temporary Allocation Model(TAM) is used for bandwidth allocation
			across non-priority traffic and priority traffic.According to the
			characters of emergency services,burstiness and short duration,there
			are two periods.One is the emergency period and the other is non-emergency
			period.The emergency service can be regarded as priority traffic,while
			the normal service is non-priority service.In the non-emergency period,
			there is only non-priority traffic.So the bandwidth is available to all
			the traffic.
			Figure 17 shows all the bandwidth is available for non-priority traffic
			in the non-emergency period and some amount of non-priority load being
			used at this link.
			------------------------
			^ | xxxxxxxxxxxxxxx | ^
			. | xxxxxxxxxxxxxxx | .
			Total . | xxxxxxxxxxxxxxx | .
			. | xxxxxxxxxxxxxxx | . Bandwidth
			Engi- . | xxxxxxxxxxxxxxx | . Available
			neered . | xxxxxxxxxxxxxxx | . for non-priority use
			Capacity. | xxxxxxx | .
			. | | .
			. | | .
			. | | .
			. | | .
			. | | .
			. | | .
			v | | V
			| |
			Figure 17: TAM Bandwidth Allocation for non-Emergency
			when one or more emergency service requests arrive at PEP or the time
			for emergency period arrives (for example,the operator set the time
			<9:00~11:00> for emergency period),the operator configure the maximum
			bandwidth available for non-priority, no additional non-priority
			sessions can be accepted even if the bandwidth reserved for priority
			traffic is not currently fully utilized.If the current non-priority
			traffic exceeds the maximum bandwidth which is available to non-priority
			traffic,then the operator chooses some of the sessions to be teared
			down in order to make sure there is a portion of bandwidth available
			for priority use.
			The same as the other bandwidth allocation models,an operator may map
			the TAM model onto the Engineered Capacity limits according to different
			policies. As an example,if the engineered capacity limit on a given
			link is X,the operator may configure the bandwidth available to
			non-priority traffic to 95% of X in the emergency period.when a priority
			session(emergency service) arrives,this session is admitted regardless
			of the current load.Finally,the operator may decide to strike a balance
			in between.The considerations presented for these policies in the MAM,RDM
			and PrBM contexts are equally applicable to the Priority Bypass Model.
			Figure 18 illustrates the bandwidth allocation with the Temporary Allocation
			Model in the emergency periods.
			------------------------
			^ ^ | | ^
			. . | | .
			Total . . | | .
			. . | | . Bandwidth Limit
			Engi- . (2) | | . (on non-priority+priority)
			neered (1)or . | | . for admission
			Capacity . . | | . of non-priority traffic
			. . | | V
			. . |------------------| --
			. . | |
			V . | |
			. | |
			. | |
			v | |
			Figure 18: Temporary Allocation Model Bandwidth Allocation for Emergency
			Figure 19 shows some of the non-priority capacity and priority capacity of
			this link being used.In this situation, both new
			non-priority and new priority sessions would be accepted.
			--------------------------
			^ ^ |xxxxxxxxxxxxxxxxx | ^
			. . |xxxxxxxxxxxxxxxxx | .
			Total . . |xxxxxxxxxxxxxxxxx | .
			. . |xxxxxxxxxxxxxxxxx | . Bandwidth Limit
			Engi- . (2) |ooooooooooooooooo | . (on non-priority+priority)
			neered (1)or . | | . for admission
			Capacity . . | | . of non-priority traffic
			. . | | V
			. . |------------------| --
			. . | |
			V . | |
			. | |
			. | |
			v | |
			Figure 19: Partial load of non-priority calls & partial load of priority calls
			Figure 20 shows the case where aggregate non-priority and priority
			load exceeds the bandwidth limit for admission of non-priority
			traffic.In the situation,any new non-priority session is rejected
			while any new priority session is admitted.
			-------------------------
			^ ^ |xxxxxxxxxxxxxxxx | ^
			. . |xxxxxxxxxxxxxxxx | .
			Total . . |xxxxxxxxxxxxxxxx | .
			. . |xxxxxxxxxxxxxxxx | . Bandwidth Limit
			Engi- . (2) |oooooooooooooooo | . (on non-priority+priority)
			neered (1)or . |xxxxxooxxxxooooo | . for admission
			Capacity . . |xxxxxxxoooooxxxx | . of non-priority traffic
			. . |xxxxxxoooooxxooo | V
			. . |-----------------| --
			. . |ooooooooooooooooo|
			V . | |
			. | |
			. | |
			v | |
			Figure 20:Full non-priority load
			Figure 21 shows the case when one or more emergency service requests
			arrive at PEP or the time for emergency period arrives,
			non-priority load exceeds the bandwidth limit for admission of
			non-priority traffic .
			-------------------------
			^ ^ |xxxxxxxxxxxxxxxx | ^
			. . |xxxxxxxxxxxxxxxx | .
			Total . . |xxxxxxxxxxxxxxxx | .
			. . |xxxxxxxxxxxxxxxx | . Bandwidth Limit
			Engi- . (2) |xxxxxxxxxxxxxxxx | . (on non-priority+priority)
			neered (1)or . |xxxxxxxxxxxxxxxx | . for admission
			Capacity . . |xxxxxxxxxxxxxxxx | . of non-priority traffic
			. . |xxxxxxxxxxxxxxxx | V
			. . |-----------------| --
			. . |xxxxxxxxxxxxxxxx |
			V . |xxxxxxxx |
			. | |
			. | |
			v | |
			Figure 21: non-priority traffic load at the beginning of Emergency
			Figure 22 shows the operator chooses some of non-priority sessions to be
			teared down and any new non-priority sessionis rejected while any new
			priority session is admitted.
			-------------------------
			^ ^ |xxxxxxxxxxxxxxxx | ^
			. . |xxxxxxxxxxxxxxxx | .
			Total . . |xxxxxxxxxxxxxxxx | .
			. . |xxxxxxxxxxxxxxxx | . Bandwidth Limit
			Engi- . (2) |xxxxxxxxxxxxxxxx | . (on non-priority+priority)
			neered (1)or . |xxxxxxxxxxxxxxxx | . for admission
			Capacity . . |xxxxxxxxxxxxxxxx | . of non-priority traffic
			. . |xxxxxxxxxxxxxxxx | V
			. . |-----------------| --
			. . |oooooooooooooooo |
			V . |oooooooooooooooo |
			. |oooo |
			. | |
			v | |
			Figure 22: Full non-priority load and partial 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 prioritized sessions in a given administrative domain. This		handling prioritized 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.		included in this document for illustration purposes.
	We assume an environment where SIP is used for session control and		We assume an environment where SIP is used for session control and
	skipping to change at page 31, line 35		skipping to change at line 1545
	o using Admission-Priority Policy Element in RSVP		o using Admission-Priority Policy Element in RSVP
	o using Preemption in Policy Element RSVP with:		o using Preemption in Policy Element RSVP with:
	* setup (Prioritized) > defending (Non-Prioritized)		* setup (Prioritized) > defending (Non-Prioritized)
	* setup (Non-Prioritized) <= defending (Prioritized)		* setup (Non-Prioritized) <= defending (Prioritized)
	o activate RFC4495 RSVP Bandwidth Reduction mechanisms		o activate RFC4495 RSVP Bandwidth Reduction mechanisms
	Authors' Addresses		Authors'Addresses
	Francois Le Faucheur
	Cisco Systems
	Greenside, 400 Avenue de Roumanille
	Sophia Antipolis 06410
	France
	Phone: +33 4 97 23 26 19
	Email: flefauch@cisco.com
	James Polk
	Cisco Systems
	2200 East President George Bush Highway
	Richardson, TX 75082-3550
	United States
	Phone: +1 972 813 5208
	Email: jmpolk@cisco.com
	Ken Carlberg
	G11
	123a Versailles Circle
	Towson, MD 21204
	United States
	Email: carlberg@g11.org.uk		Zhao Jihong, Ren Luyuan
			Xi'an Institute of Posts and Telecommunications
			y.y0910@163.com
End of changes. 13 change blocks.
	68 lines changed or deleted		205 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/