draft-ietf-tsvwg-emergency-rsvp-02.txt		draft-ietf-tsvwg-emergency-rsvp-03.txt
	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-02.txt		draft-ietf-tsvwg-emergency-rsvp-03.txt
	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 23		skipping to change at page 2, line 23
	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
	1.3. Changes from previous versions.............................4		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............................................8		3.1. Admission Priority Policy Element.........................8
	3.1. Admission Priority Policy Element.........................9		3.1.1. Admission Priority Merging Rules 9
	3.1.1. Admission Priority Merging Rules 10		3.2. Application-Level Resource Priority Policy Element.......10
	3.2. Application-Level Resource Priority Policy Element.......11
	3.2.1. Application-Level Resource Priority Modifying and		3.2.1. Application-Level Resource Priority Modifying and
	Merging Rules 12		Merging Rules 11
	4. Security Considerations.......................................13		3.3. Default Handling.........................................11
	4.1. Use of RSVP Authentication...............................13		4. Security Considerations.......................................12
	4.2. Use of INTEGRITY object within the POLICY_DATA object....14		4.1. Use of RSVP Authentication between RSVP nighbors.........12
	5. IANA Considerations...........................................14		4.2. Use of INTEGRITY object within the POLICY_DATA object....12
	6. Acknowledgments...............................................15		5. IANA Considerations...........................................13
	7. Normative References..........................................15		6. Acknowledgments...............................................14
			7. Normative References..........................................14
	8. Informative References........................................15		8. Informative References........................................15
	Appendix A: Examples of Bandwidth Allocation Model for Admission		Appendix A: Examples of Bandwidth Allocation Model for Admission
	Priority.........................................................17		Priority.........................................................16
	A.1 Admission Priority with Maximum Allocation Model (MAM)......17		A.1 Admission Priority with Maximum Allocation Model (MAM)......16
	A.2 Admission Priority with Russian Dolls Model (RDM)...........21		A.2 Admission Priority with Russian Dolls Model (RDM)...........20
	A.3 Admission Priority with Priority Bypass Model (PBM).........23		A.3 Admission Priority with Priority Bypass Model (PrBM)........22
	Appendix B: Example Usages of RSVP Extensions....................26		Appendix B: Example Usages of RSVP Extensions....................25
	Authors' Address.................................................28		Authors' Address.................................................27
	1. Introduction		1. Introduction
	[EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency		[EMERG-RQTS] and [EMERG-TEL] 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 to		emergency communications. An underlying goal of these documents is to
	present requirements that elevate the probability of session		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 4, line 51		skipping to change at page 5, line 5
	- Local Policy Decision Point (LPDP): PDP local to the network		- Local Policy Decision Point (LPDP): PDP local to the network
	element		element
	- Policy Enforcement Point (PEP): The point where the policy		- Policy Enforcement Point (PEP): The point where the policy
	decisions are actually enforced.		decisions are actually enforced.
	- Policy Ignorant Node (PIN): A network element that does not		- Policy Ignorant Node (PIN): A network element that does not
	explicitly support policy control using the mechanisms defined in		explicitly support policy control using the mechanisms defined in
	[FW-POLICY].		[FW-POLICY].
	1.3. Changes from previous versions
	[Note to RFC Editor: This section is to be removed before
	publication]
	Changes from ietf-tsvwg-emergency-rsvp-01 to ietf-tsvwg-emergency-
	rsvp-02
	The changes are:
	o fix the idnits
	o Removed reference to Kerberos in Security Considerations
	section (in line with IESG review comment on Security
	Considerations section of draft-ietf-tsvwg-rsvp-ipsec)
	Changes from ietf-tsvwg-emergency-rsvp-00 to ietf-tsvwg-emergency-
	rsvp-01
	The most significant changes are:
	o editorial change (correction in description of
	"Take highest priority" in section 3.1.1).
	o expanded Security Considerations section
	Changes from lefaucheur-rsvp-emergency-01 to ietf-tsvwg-emergency-
	rsvp-00
	The most significant change is:
	o Extended the Admission Priority field from 3 to 8 bits and
	inverted the encoding order, in particular for better
	alignment with NSIS Qspec.
	Changes from lefaucheur-rsvp-emergency-01 to lefaucheur-rsvp-
	emergency-02
	The most significant changes are:
	o modified the Introduction to add additional clarity and to
	place related work in a better context to the extensions
	proposed in this draft
	o Moved bandwidth allocation models to an appendix
	o Allowed multiple Application-Level Resource Priority inside
	ALRP Policy Element
	o Added a 2nd appendix providing examples of RSVP extensions
	usage
	Changes from lefaucheur-rsvp-emergency-00 to lefaucheur-rsvp-
	emergency-01
	The most significant changes were:
	o adding a second RSVP Policy Element that contains the
	application-level resource priority requirements (for example
	as communicated in the SIP Resource-Priority Header) for
	scenarios where priority calls transits through multiple
	administrative domains.
	o adding description of a third bandwidth allocation model
	example: the Priority Bypass Model
	o adding discussion on policies for mapping the various
	bandwidth allocation model over the engineered capacity limits.
	2. Overview of RSVP extensions and Operations		2. Overview of RSVP extensions and Operations
	Let us consider the case where a call requiring ETS type service is		Let us consider the case where a call requiring ETS type service is
	to be established, and more specifically that the preference to be		to be established, and more specifically that the preference to be
	granted to this call is in terms of network layer "admission		granted to this call is in terms of network layer "admission
	priority" (as opposed to preference granted through preemption of		priority" (as opposed to preference granted through preemption of
	existing calls). By "admission priority" we mean allowing that		existing calls). By "admission priority" we mean allowing that
	priority call to seize network layer resources from the engineered		priority call to seize network layer resources from the engineered
	capacity that have been set-aside and not made available to normal		capacity that have been set-aside and not made available to normal
	calls, or alternatively by allowing that call to seize additional		calls, or alternatively by allowing that call to seize additional
	skipping to change at page 8, line 47		skipping to change at page 7, line 24
	A number of bandwidth allocation models have been defined in the IETF		A number of bandwidth allocation models have been defined in the IETF
	for allocation of bandwidth across different classes of traffic		for allocation of bandwidth across different classes of traffic
	trunks in the context of Diffserv-aware MPLS Traffic Engineering.		trunks in the context of Diffserv-aware MPLS Traffic Engineering.
	Those include the Maximum Allocation Model (MAM) defined in [DSTE-		Those include the Maximum Allocation Model (MAM) defined in [DSTE-
	MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These		MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These
	same models MAY however be applied for allocation of bandwidth across		same models MAY however be applied for allocation of bandwidth across
	different levels of admission priority as defined in this document.		different levels of admission priority as defined in this document.
	Appendix A provides an illustration of how these bandwidth allocation		Appendix A provides an illustration of how these bandwidth allocation
	models can be applied for such purposes and introduces an additional		models can be applied for such purposes and introduces an additional
	bandwidth allocation model that we term the Priority Bypass Model		bandwidth allocation model that we term the Priority Bypass Model
	(PBM). It is important to note that the models described and		(PrBM). It is important to note that the models described and
	illustrated in Appendix A are only informative and do not represent a		illustrated in Appendix A are only informative and do not represent a
	recommended course of action.		recommended course of action.
			We can see in these examples, that the RSVP Admission Priority may
			effectively influence the fundamental admission control decision of
			RSVP (for example by determining which bandwidth pool is to be used
			by RSVP for performing its fundamental bandwidth allocation). In that
			sense, we observe that the policy control and admission control are
			not separate logics but instead somewhat blended.
	3. New Policy Elements		3. New Policy Elements
	The Framework document for policy-based admission control [FW-POLICY]		The Framework document for policy-based admission control [FW-POLICY]
	describes the various components that participate in policy decision		describes the various components that participate in policy decision
	making (i.e., PDP, PEP and LPDP).		making (i.e., PDP, PEP and LPDP).
	As described in section 2 of the present document, the Application-		As described in section 2 of the present document, the Application-
	Level Resource Priority Policy Element and the Admission Priority		Level Resource Priority Policy Element and the Admission Priority
	Policy Element serve different roles in this framework:		Policy Element serve different roles in this framework:
	- the Application-Level Resource Priority Policy Element conveys		- the Application-Level Resource Priority Policy Element conveys
	application level information and is processed by PDPs		application level information and is processed by PDPs
	skipping to change at page 9, line 40		skipping to change at page 8, line 26
	Element.		Element.
	This document defines two new Policy Elements called:		This document defines two new Policy Elements called:
	- the Admission Priority Policy Element		- the Admission Priority Policy Element
	- the Application-Level Resource Priority Policy Element		- the Application-Level Resource Priority Policy Element
	3.1. Admission Priority Policy Element		3.1. Admission Priority Policy Element
	The format of the Admission Priority policy element is as follows:		The format of the Admission Priority policy element is as follows:
			0 0 0 1 1 2 2 3
			0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	| Length | P-Type = ADMISSION_PRI |		| Length | P-Type = ADMISSION_PRI |
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	| Flags | M. Strategy | Error Code | Reserved |		| Flags | M. Strategy | Error Code | Reserved |
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	|Adm. Priority| Reserved |		| 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 (MUST be set to zero on transmit and ignored on
	receive)		receive)
	Merge Strategy: 8 bit (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)
	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.		Always 0.
			Reserved: 24 bits
			Always 0.
	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 network bandwidth in order to provide higher probability of		to network bandwidth in order to provide higher probability of
	call completion to selected flows. Higher values represent		call completion to selected flows. Higher values represent
	higher Priority.		higher Priority.
	Bandwidth allocation models such as those described in Appendix		Bandwidth allocation models such as those described in Appendix
	A are to be used by the RSVP router to achieve such increased		A are to be used by the RSVP router to achieve such increased
	probability of call completion. The admission priority value		probability of call completion. The admission priority value
	effectively indicates which bandwidth constraint(s) of the		effectively indicates which bandwidth constraint(s) of the
	bandwidth constraint model in use is(are) applicable to		bandwidth constraint model in use is(are) applicable to
	admission of this RSVP reservation.		admission of this RSVP reservation.
	Reserved: 16 bits
	Always 0.
	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 orthogonal and independent		Priority are handled by LPDPs and PEPs as separate mechanisms. They
	mechanisms.		can be used one without the other, or they can be used both in
			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 11, line 28		skipping to change at page 10, line 19
	Note that with the Admission Priority (as is the case with the		Note that with the Admission Priority (as is the case with the
	Preemption Priority), "Take highest priority" translates into "take		Preemption Priority), "Take highest priority" translates into "take
	the highest numerical value".		the highest numerical value".
	3.2. Application-Level Resource Priority Policy Element		3.2. Application-Level Resource Priority Policy Element
	The format of the Application-Level Resource Priority policy element		The format of the Application-Level Resource Priority policy element
	is as follows:		is as follows:
			0 0 0 1 1 2 2 3
			0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	| Length | P-Type = APP_RESOURCE_PRI |		| Length | P-Type = APP_RESOURCE_PRI |
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	// ALRP List //		// ALRP List //
	+---------------------------+---------------------------+		+---------------------------+---------------------------+
	Length: The length of the policy element (including the Length and P-		Length: The length of the policy element (including the Length and P-
	Type) is in number of octets (MUST be a multiple of 4) and		Type) is in number of octets (MUST be a multiple of 4) and
	indicates the end of the ALRP list.		indicates the end of the ALRP list.
	P-Type: 16 bits		P-Type: 16 bits
	APP_RESOURCE_PRI = To be allocated by IANA		APP_RESOURCE_PRI = To be allocated by IANA
	(see "IANA Considerations" section)		(see "IANA Considerations" section)
	ARLP:		ALRP:
			0 0 0 1 1 2 2 3
			0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
	+---------------------------+---------------------------+		+---------------------------+---------------------------+
	| ALRP Namespace |ALRP Priority| Reserved |		| 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 the namespace of the application-level resource		Contains a numerical value identifying the namespace of the
	priority. This is encoded as a numerical value which		application-level resource priority. This value is encoded
	represents the position of the namespace in the "Resource-		as per the "Resource-Priority Namespace" IANA registry. (See
	Priority Namespace" IANA registry, starting with 0. Creation		IANA Considerations section for the request to IANA to
	of this registry has been requested to IANA in [SIP-		extend the registry to include this numerical value).
	PRIORITY].
	For example, as "drsn", "dsn", "q735", "ets" and "wps" are
	currently the first, second, third, fourth and fifth
	namespaces defined in the "Resource-Priority Namespace"
	registry, those are respectively encoded as value 0, 1, 2, 3
	and 4.
	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 is encoded as a		application-level resource priority. This is encoded as a
	numerical value which represents the priority defined in the		numerical value which represents the priority defined in the
	"Resource-Priority Namespace" IANA registry for the		"Resource-Priority Namespace" IANA registry for the
	considered namespace, starting from 0 for the highest		considered namespace, starting from 0 for the highest
	priority and increasing as priority decreases.		priority and increasing as priority decreases.
	For example, as "flash-override", "flash", "immediate",		For example, as "flash-override", "flash", "immediate",
	skipping to change at page 12, line 35		skipping to change at page 11, line 26
	are respectively encoded as value 0, 1, 2, 3 and 4. As		are respectively encoded as value 0, 1, 2, 3 and 4. As
	another example, as "flash-override-override", "flash-		another example, as "flash-override-override", "flash-
	override", "flash", "immediate", "priority" and "routine"		override", "flash", "immediate", "priority" and "routine"
	are the priorities in decreasing order of priority		are the priorities in decreasing order of priority
	registered for the "drsn" namespace, those are respectively		registered for the "drsn" namespace, those are respectively
	encoded as value 0, 1, 2, 3, 4 and 5.		encoded as value 0, 1, 2, 3, 4 and 5.
	Reserved: 16 bits		Reserved: 16 bits
	Always 0.		Always 0.
	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:
	The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list		The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list
	all the ALRPs appearing in the ALRP List of an incoming		all the ALRPs appearing in the ALRP List of an incoming
	APP_RESOURCE_PR element. A given ALRP MUST NOT appear more than		APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than
	once. In other words, the outgoing ALRP List is the reunion of		once. In other words, the outgoing ALRP List is the union of the
	the incoming ARLP Lists that are merged.		incoming ALRP Lists that are merged.
	As merging is only applicable to Multicast, this rule only applies to		As merging is only applicable to Multicast, this rule only applies to
	Multicast sessions.		Multicast sessions.
			3.3. Default Handling
			As specified in section 4.2 of [RSVP-POLICY], Policy Ignorant Nodes
			(PINs) implement a default handling of POLICY_DATA objects ensuring
			that those objects can traverse PIN nodes in transit from one PEP to
			another. This applies to the situations where POLICY_DATA objects
			contain the Admission Priority Policy Element and the ALRP Policy
			Element specified in this document, so that those can traverse PIN
			nodes.
			Section 4.2 of [RSVP-POLICY] also defines a similar default behavior
			for policy-capable nodes that do not recognized a particular Policy
			Element. This applies to the Admission Priority Policy Element and
			the ALRP Policy Element specified in this document, so that those can
			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		The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can
	be signaled by RSVP through encapsulation in a Policy Data object as		be signaled by RSVP through encapsulation in a Policy Data object as
	defined in [RSVP-POLICY]. Therefore, like any other Policy Elements,		defined in [RSVP-POLICY]. Therefore, like any other Policy Elements,
	their integrity can be protected as discussed in section 6 of [RSVP-		their integrity can be protected as discussed in section 6 of [RSVP-
	POLICY] by two optional security mechanisms. The first mechanism		POLICY] by two optional security mechanisms. The first mechanism
	relies on RSVP Authentication as specified in [RSVP-CRYPTO-1] and		relies on RSVP Authentication as specified in [RSVP-CRYPTO-1] and
	[RSVP-CRYPTO-2] to provide a chain of trust when all RSVP nodes are		[RSVP-CRYPTO-2] to provide a chain of trust when all RSVP nodes are
	policy capable. The second mechanism relies on the INTEGRITY object		policy capable. With this mechanism, the INTEGRITY object is carried
	within the POLICY_DATA object to guarantee integrity between RSVP		inside RSVP messages. The second mechanism relies on the INTEGRITY
	Policy Enforcement Points (PEPs) that are not RSVP neighbors.		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
	[RSVP-CRYPTO-1] discusses several approaches for distribution of keys
	to be used for RSVP Authentication. First, the RSVP Authentication
	shared keys can be distributed manually. This is the base option and
	its support is mandated for any implementation. However, in some
	environments, this approach may become a burden if keys frequently
	change over time. Alternatively, a standard key management protocol
	for secure key distribution can be used. However, existing key
	distribution protocols may not be appropriate in all environments
	because of the complexity or operational burden they involve.
	The use of RSVP Authentication in parts of the network where there
	may be one or more IP hops in between two RSVP neighbors raises an
	additional challenge. This is because, with some RSVP messages such
	as a Path message, an RSVP router does not know the RSVP next hop for
	that message at the time of forwarding it. In fact, part of the role
	of a Path message is precisely to discover the RSVP next hop (and to
	dynamically re-discover it when it changes, say because of a routing
	change). Hence, the RSVP router may not know which security
	association to use when forwarding such a message.
	In that situation, one approach is to share the same RSVP		4.1. Use of RSVP Authentication between RSVP nighbors
	Authentication shared key across all the RSVP routers of a part of
	the network where there may be RSVP neighbors with IP hops in between.
	For example, all the RSVP routers of an administrative domain could
	share the same RSVP Authentication key, while different per-neighbor
	keys could be used between any RSVP router pair straddling the
	boundary between two administrative domains that have agreed to use
	RSVP signaling.
	When the same RSVP Authentication shared key is to be shared among		This mechanism can be used can be used between RSVP neighbors that
	multiple RSVP neighbors, manual key distribution may be used. For		are policy capable. The RSVP neighbors use shared keys to compute the
	situations where RSVP is being used for multicast flows, it might		cryptographic signature of the RSVP message. [RSVP-GROUPKEYING]
	also be possible, in the future, to adapt a multicast key management		discusses key types, key provisioning methods as well as their
	method (e.g. from IETF Multicast Security Working Group) for key		respective applicability.
	distribution with such multicast RSVP usage. For situations where
	RSVP is being used for unicast flows across domain boundaries, it is
	not currently clear how one might provide automated key management.
	Specification of a specific automated key management technique is
	outside the scope of this document. Operators should consider these
	key management issues when contemplating deployment of this
	specification.
	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 [RSVP-POLICY]. This states that the Policy		found in Appendix B of [RSVP-POLICY]. This states that the Policy
	Decision Point (PDP), at its discretion, and based on destination		Decision Point (PDP), at its discretion, and based on destination
	PEP/PDP or other criteria, selects an Authentication Key and the hash		PEP/PDP or other criteria, selects an Authentication Key and the hash
	algorithm to be used. Keys to be used between PDPs can be distributed		algorithm to be used. Keys to be used between PDPs can be distributed
	manually or via standard key management protocol for secure key		manually or via standard key management protocol for secure key
	distribution.		distribution.
	Note that where non-RSVP hops may exist in between RSVP hops, as well		Note that where non-RSVP hops may exist in between RSVP hops, as well
	as where RSVP capable Policy Ignorant Nodes (PINs) may exist in		as where RSVP capable Policy Ignorant Nodes (PINs) may exist in
	between PEPs, it may be difficult for the PDP to determine what is		between PEPs, it may be difficult for the PDP to determine what is
	the destination PDP for a POLICY_DATA object contained in some RSVP		the destination PDP for a POLICY_DATA object contained in some RSVP
	messages (such as a Path message). This is because in those cases the		messages (such as a Path message). This is because in those cases the
	next PEP is not known at the time of forwarding the message. This		next PEP is not known at the time of forwarding the message. In this
	issue is similar to the one discussed in section 4.1, except it now		situation, key shared across multiple PDPs may be used. This is
	applies to PDP neighbors instead of RSVP neighbors. Hence similar		conceptually similar to the use of key shared across multiple RSVP
	approaches could be used, such as the use of a key shared across		neighbors discussed in [RSVP-GROUPKEYING]. We observe also that this
	multiple PDPs. We observe that this issue may not exist in some		issue may not exist in some deployment scenarios where a single (or
	deployment scenarios where a single (or low number of) PDP is used to		low number of) PDP is used to control all the PEPs of a region (such
	control all the PEPs of a region (such as an administrative domain).		as an administrative domain). In such scenarios, it may be easy for a
	In such scenarios, it may be easy for a PDP to determine what is the		PDP to determine what is the next hop PDP, even when the next hop PEP
	next hop PDP, even when the next hop PEP is not known, simply by		is not known, simply by determining what is the next region that will
	determining what is the next region that will be traversed (say based		be traversed (say based on the destination address).
	on the destination address).
	5. IANA Considerations		5. IANA Considerations
	As specified in [RSVP-POLICY], Standard RSVP Policy Elements (P-type		As specified in [RSVP-POLICY], 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" following
	the policies outlined in [IANA-CONSIDERATIONS].		the policies outlined in [IANA-CONSIDERATIONS].
	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:
	- one P-Type to the Admission Priority Policy Element		- one P-Type to the Admission Priority Policy Element
	- one P-Type to the Application-Level Resource Priority		- one P-Type to the Application-Level Resource Priority
	Policy Element		Policy Element
			This document defines an ALRP Priority field in section 3.2 that
			contains a numerical value identifying the namespace of the
			application-level resource priority. The IANA already maintains the
			Resource-Priority Namespaces registry (under the SIP Parameters)
			listing all such namespace. However, that registry does not currently
			allocate a numerical value to each namespace. Hence, this document
			requests the IANA to extend the Resource-Priority Namespace registry
			in the following ways:
			- a new column should be added to the registry
			- the title of the new column should be "Namespace numerical
			Value *"
			- in the Legend, add a line saying "Namespace numerical
			Value = the unique numerical value identifying the
			namespace"
			- add a line at the bottom of the registry stating the
			following "* : [RFCXXX] " where XXX is the RFC number of
			the present document
			- allocate an actual numerical value to each namespace in
			the registry and state that value in the new "Namespace
			numerical Value *" column.
			A numerical value should be allocated immediately by IANA to all
			existing namespace. Then, in the future, IANA should automatically
			allocate a numerical value to any new namespace added to the registry.
			[draft-ietf-nsis-qspec] also uses numerical values for Resource-
			Priority Namespaces. The request 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 only do one of the two approaches (an 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 16, line 33		skipping to change at page 15, line 36
	[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.
	[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 Security using Dynamic Group Keying", draft-behringer-tsvwg-
			rsvp-security-groupkeying-00.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-
	RDM] can be used for support of admission priority. Section A.3		RDM] can be used for support of admission priority. Section A.3
	skipping to change at page 23, line 32		skipping to change at page 22, line 32
	|xxxxxxxxxxxxxx| . . available for		|xxxxxxxxxxxxxx| . . available for
	|xxxxxxxxxxxxxx| v . non-priority		|xxxxxxxxxxxxxx| v . non-priority
	|--------------| --- . and priority		|--------------| --- . and priority
	|oooooooooooooo| . use		|oooooooooooooo| . use
	|oooooooooooooo| .		|oooooooooooooo| .
	|oooooooooooooo| v		|oooooooooooooo| v
	---------------------------------------		---------------------------------------
	Chart 9. Full non-priority load & Full Aggregate load		Chart 9. Full non-priority load & Full Aggregate load
	A.3 Admission Priority with Priority Bypass Model (PBM)		A.3 Admission Priority with Priority Bypass Model (PrBM)
	This section illustrates operations of admission priority when a		This section illustrates operations of admission priority when a
	simple Priority Bypass Model (PBM) is used for bandwidth allocation		simple Priority Bypass Model (PrBM) is used for bandwidth allocation
	across non-priority traffic and priority traffic. With the Priority		across non-priority traffic and priority traffic. With the Priority
	Bypass Model, non-priority traffic is subject to resource based		Bypass Model, non-priority traffic is subject to resource based
	admission control while priority traffic simply bypasses the resource		admission control while priority traffic simply bypasses the resource
	based admission control. In other words:		based admission control. In other words:
	- when a non-priority call arrives, this call is subject to		- when a non-priority call arrives, this call is subject to
	bandwidth admission control and is accepted if the current total load		bandwidth admission control and is accepted if the current total load
	(aggregate over non-priority and priority traffic) is below the		(aggregate over non-priority and priority traffic) is below the
	engineered/allocated bandwidth.		engineered/allocated bandwidth.
	- when a priority call arrives, this call is admitted regardless		- when a priority call arrives, this call is admitted regardless
	of the current load.		of the current load.
	skipping to change at page 29, line 30		skipping to change at page 28, line 30
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	PURPOSE.
End of changes. 33 change blocks.
	177 lines changed or deleted		134 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/