draft-ietf-tsvwg-emergency-rsvp-01.txt		draft-ietf-tsvwg-emergency-rsvp-02.txt
			TSVWG Francois Le Faucheur
	RSVP Extensions for Emergency Services January 2007		Internet-Draft James Polk
			Intended Status: Standards Track Cisco Systems, Inc.
	Internet Draft Francois Le Faucheur
	James Polk
	Cisco Systems, Inc.
	Ken Carlberg		Ken Carlberg
	G11		G11
	draft-ietf-tsvwg-emergency-rsvp-01.txt		draft-ietf-tsvwg-emergency-rsvp-02.txt
	Expires: July 2007 January 2007
	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 5		skipping to change at page 2, line 5
	An Emergency Telecommunications Service (ETS) requires the ability to		An Emergency Telecommunications Service (ETS) requires the ability to
	provide an elevated probability of session establishment to an		provide an elevated probability of session establishment to an
	authorized user in times of network congestion (typically, during a		authorized user in times of network congestion (typically, during a
	crisis). When supported over the Internet Protocol suite, this may be		crisis). When supported over the Internet Protocol suite, this may be
	facilitated through a network layer admission control solution, which		facilitated through a network layer admission control solution, which
	supports prioritized access to resources (e.g., bandwidth). These		supports prioritized access to resources (e.g., bandwidth). These
	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.
	RSVP Extensions for Emergency Services January 2007
	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 Internet Society (2007).		Copyright (C) The IETF Trust (2007).
	Specification of Requirements		Specification of Requirements
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	"OPTIONAL" in this document are to be interpreted as described in		document are to be interpreted as described in RFC 2119.
	[KEYWORDS] and indicate requirement levels for compliant
	implementations.
	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.............................5		1.3. Changes from previous versions.............................4
	2. Overview of RSVP extensions and Operations.....................6		2. Overview of RSVP extensions and Operations.....................6
	2.1. Operations of Admission Priority..........................8		2.1. Operations of Admission Priority..........................8
	3. New Policy Elements............................................8		3. New Policy Elements............................................8
	3.1. Admission Priority Policy Element.........................9		3.1. Admission Priority Policy Element.........................9
	3.1.1. Admission Priority Merging Rules 10		3.1.1. Admission Priority Merging Rules 10
	3.2. Application-Level Resource Priority Policy Element.......11		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 12
	4. Security Considerations.......................................12		4. Security Considerations.......................................13
	4.1. Use of RSVP Authentication...............................13		4.1. Use of RSVP Authentication...............................13
	4.2. Use of INTEGRITY object within the POLICY_DATA object....14		4.2. Use of INTEGRITY object within the POLICY_DATA object....14
	5. IANA Considerations...........................................14		5. IANA Considerations...........................................14
	6. Acknowledgments...............................................15		6. Acknowledgments...............................................15
	7. Normative References..........................................15		7. Normative References..........................................15
	8. Informative References........................................16		8. Informative References........................................15
	Appendix A: Examples of Bandwidth Allocation Model for Admission		Appendix A: Examples of Bandwidth Allocation Model for Admission
	Priority.........................................................16		Priority.........................................................17
	A.1 Admission Priority with Maximum Allocation Model (MAM)......17		A.1 Admission Priority with Maximum Allocation Model (MAM)......17
	A.2 Admission Priority with Russian Dolls Model (RDM)...........20		A.2 Admission Priority with Russian Dolls Model (RDM)...........21
	A.3 Admission Priority with Priority Bypass Model (PBM).........23		A.3 Admission Priority with Priority Bypass Model (PBM).........23
	Appendix B: Example Usages of RSVP Extensions....................26		Appendix B: Example Usages of RSVP Extensions....................26
	Authors' Address.................................................27		Authors' Address.................................................28
	RSVP Extensions for Emergency Services January 2007
	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 5		skipping to change at page 3, line 52
	Note: Below, this document references several examples of IP		Note: Below, this document references several examples of IP
	telephony and its use of "calls", which is one form of the term		telephony and its use of "calls", which is one form of the term
	"sessions" (Video over IP and Instant Messaging being other examples		"sessions" (Video over IP and Instant Messaging being other examples
	that rely on session establishment). For the sake of simplicity, we		that rely on session establishment). For the sake of simplicity, we
	shall use the widely known term "call" for the remainder of this		shall use the widely known term "call" for the remainder of this
	document.		document.
	1.1. Related Technical Documents		1.1. Related Technical Documents
	RSVP Extensions for Emergency Services January 2007
	[EMERG-IMP] is patterned after [ITU.I.225] and describes an example		[EMERG-IMP] is patterned after [ITU.I.225] and describes an example
	of one type of prioritized network layer admission control procedure		of one type of prioritized network layer admission control procedure
	that may be used for emergency services operating over an IP network		that may be used for emergency services operating over an IP network
	infrastructure. It discusses initial call set up, as well as		infrastructure. It discusses initial call set up, as well as
	operations after call establishment through maintenance of a		operations after call establishment through maintenance of a
	continuing call model of the status of all calls. [EMERG-IMP] also		continuing call model of the status of all calls. [EMERG-IMP] also
	describes how these network layer admission control procedures can be		describes how these network layer admission control procedures can be
	realized using the Resource reSerVation Protocol [RSVP] along with		realized using the Resource reSerVation Protocol [RSVP] along with
	its associated protocol suite and extensions, including those for		its associated protocol suite and extensions, including those for
	policy based admission control ([FW-POLICY], [RSVP-POLICY]), for user		policy based admission control ([FW-POLICY], [RSVP-POLICY]), for user
	skipping to change at page 5, line 5		skipping to change at page 4, line 51
	- 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].
	RSVP Extensions for Emergency Services January 2007
	1.3. Changes from previous versions		1.3. Changes from previous versions
	[Note to RFC Editor: This section is to be removed before		[Note to RFC Editor: This section is to be removed before
	publication]		publication]
	Changes from ietf-tsvwg-emergency-rsvp-00 to ietf-tsvwg-		Changes from ietf-tsvwg-emergency-rsvp-01 to ietf-tsvwg-emergency-
	emergency-rsvp-01		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:		The most significant changes are:
	o editorial change (correction in description of		o editorial change (correction in description of
	"Take highest priority" in section 3.1.1).		"Take highest priority" in section 3.1.1).
	o expanded Security Considerations section		o expanded Security Considerations section
	Changes from lefaucheur-rsvp-emergency-01 to ietf-tsvwg-rsvp-		Changes from lefaucheur-rsvp-emergency-01 to ietf-tsvwg-emergency-
	emergency-00		rsvp-00
	The most significant change is:		The most significant change is:
	o Extended the Admission Priority field from 3 to 8 bits and		o Extended the Admission Priority field from 3 to 8 bits and
	inverted the encoding order, in particular for better		inverted the encoding order, in particular for better
	alignment with NSIS Qspec.		alignment with NSIS Qspec.
	Changes from lefaucheur-rsvp-emergency-01 to lefaucheur-rsvp-		Changes from lefaucheur-rsvp-emergency-01 to lefaucheur-rsvp-
	emergency-02		emergency-02
	skipping to change at page 5, line 43		skipping to change at page 6, line 4
	The most significant changes are:		The most significant changes are:
	o modified the Introduction to add additional clarity and to		o modified the Introduction to add additional clarity and to
	place related work in a better context to the extensions		place related work in a better context to the extensions
	proposed in this draft		proposed in this draft
	o Moved bandwidth allocation models to an appendix		o Moved bandwidth allocation models to an appendix
	o Allowed multiple Application-Level Resource Priority inside		o Allowed multiple Application-Level Resource Priority inside
	ALRP Policy Element		ALRP Policy Element
	o Added a 2nd appendix providing examples of RSVP extensions		o Added a 2nd appendix providing examples of RSVP extensions
	usage		usage
	Changes from lefaucheur-rsvp-emergency-00 to lefaucheur-rsvp-		Changes from lefaucheur-rsvp-emergency-00 to lefaucheur-rsvp-
	emergency-01		emergency-01
	The most significant changes were:		The most significant changes were:
	RSVP Extensions for Emergency Services January 2007
	o adding a second RSVP Policy Element that contains the		o adding a second RSVP Policy Element that contains the
	application-level resource priority requirements (for example		application-level resource priority requirements (for example
	as communicated in the SIP Resource-Priority Header) for		as communicated in the SIP Resource-Priority Header) for
	scenarios where priority calls transits through multiple		scenarios where priority calls transits through multiple
	administrative domains.		administrative domains.
	o adding description of a third bandwidth allocation model		o adding description of a third bandwidth allocation model
	example: the Priority Bypass Model		example: the Priority Bypass Model
	o adding discussion on policies for mapping the various		o adding discussion on policies for mapping the various
	skipping to change at page 7, line 4		skipping to change at page 7, line 13
	end-devices involved in the upper-layer session establishment simply		end-devices involved in the upper-layer session establishment simply
	need to copy the application-level resource priority requirements		need to copy the application-level resource priority requirements
	(e.g. as communicated in SIP Resource-Priority Header) inside the new		(e.g. as communicated in SIP Resource-Priority Header) inside the new
	RSVP Application-Level Resource-Priority Policy Element defined in		RSVP Application-Level Resource-Priority Policy Element defined in
	this document.		this document.
	Conveying the application-level resource priority requirements inside		Conveying the application-level resource priority requirements inside
	the RSVP message allows this application level requirement to be		the RSVP message allows this application level requirement to be
	mapped/remapped into a different RSVP "admission priority" at every		mapped/remapped into a different RSVP "admission priority" at every
	administrative domain boundary based on the policy applicable in that		administrative domain boundary based on the policy applicable in that
	RSVP Extensions for Emergency Services January 2007
	domain. In a typical model (see [FW-POLICY]) where PDPs control PEPs		domain. In a typical model (see [FW-POLICY]) where PDPs control PEPs
	at the periphery of the policy domain (e.g., in border routers), PDPs		at the periphery of the policy domain (e.g., in border routers), PDPs
	would interpret the RSVP Application-Level Resource-Priority Policy		would interpret the RSVP Application-Level Resource-Priority Policy
	Element and map the requirement of the emergency session into an RSVP		Element and map the requirement of the emergency session into an RSVP
	"admission priority" level. Then, PDPs would convey this information		"admission priority" level. Then, PDPs would convey this information
	inside the new Admission Priority Policy Element defined in this		inside the new Admission Priority Policy Element defined in this
	document. This way, the RSVP admission priority can be communicated		document. This way, the RSVP admission priority can be communicated
	to downstream PEPs (ie RSVP Routers) of the same policy domain, which		to downstream PEPs (ie RSVP Routers) of the same policy domain, which
	have LPDPs but no controlling PDP. In turn, this means the necessary		have LPDPs but no controlling PDP. In turn, this means the necessary
	RSVP Admission priority can be enforced at every RSVP hop, including		RSVP Admission priority can be enforced at every RSVP hop, including
	skipping to change at page 8, line 4		skipping to change at page 8, line 15
	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.
	As can be observed, the framework described above for		As can be observed, the framework described above for
	mapping/remapping application level resource priority requirements		mapping/remapping application level resource priority requirements
	into an RSVP admission priority can also be used together with [RSVP-		into an RSVP admission priority can also be used together with [RSVP-
	PREEMP] for mapping/remapping application level resource priority		PREEMP] for mapping/remapping application level resource priority
	requirements into an RSVP preemption priority (when preemption is		requirements into an RSVP preemption priority (when preemption is
	indeed needed). In that case, when processing the RSVP Application-		indeed needed). In that case, when processing the RSVP Application-
	RSVP Extensions for Emergency Services January 2007
	Level Resource-Priority Policy Element, the PDPs at boundaries		Level Resource-Priority Policy Element, the PDPs at boundaries
	between administrative domains (or between various QoS signaling		between administrative domains (or between various QoS signaling
	protocols) can map it into an RSVP "preemption priority" information.		protocols) can map it into an RSVP "preemption priority" information.
	This Preemption priority information comprises a setup preemption		This Preemption priority information comprises a setup preemption
	level and a defending preemption priority level. This preemption		level and a defending preemption priority level. This preemption
	priority information can then be encoded inside the Preemption		priority information can then be encoded inside the Preemption
	Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into		Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into
	account at every RSVP-enabled network hop as discussed [EMERG-IMP].		account at every RSVP-enabled network hop as discussed [EMERG-IMP].
	Appendix B provides examples of various hypothetical policies for		Appendix B provides examples of various hypothetical policies for
	emergency call handling, some of them involving admission priority,		emergency call handling, some of them involving admission priority,
	skipping to change at page 9, line 5		skipping to change at page 9, line 15
	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
	RSVP Extensions for Emergency Services January 2007
	- the emphasis of Admission Priority Policy Element is to be		- the emphasis of Admission Priority Policy Element is to be
	simple, stateless, and light-weight such that it can be		simple, stateless, and light-weight such that it can be
	processed internally within a node's LPDP. It can then be		processed internally within a node's LPDP. It can then be
	enforced internally within a node's PEP. It is set by PDPs		enforced internally within a node's PEP. It is set by PDPs
	based on processing of the Application-Level Resource Priority		based on processing of the Application-Level Resource Priority
	Policy Element.		Policy Element.
	[RSVP-POLICY] defines extensions for supporting generic policy based		[RSVP-POLICY] defines extensions for supporting generic policy based
	admission control in RSVP. These extensions include the standard		admission control in RSVP. These extensions include the standard
	format of POLICY_DATA objects and a description of RSVP handling of		format of POLICY_DATA objects and a description of RSVP handling of
	skipping to change at page 10, line 4		skipping to change at page 10, line 15
	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 bit (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
	RSVP Extensions for Emergency Services January 2007
	3 Force Error on heterogeneous merge		3 Force Error on heterogeneous merge
	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.
	Adm. Priority (Admission Priority): 8 bits (unsigned)		Adm. Priority (Admission Priority): 8 bits (unsigned)
	skipping to change at page 11, line 4		skipping to change at page 11, line 14
	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:
	- Take priority of highest QoS		- Take priority of highest QoS
	- Take highest priority		- Take highest priority
	- Force Error on heterogeneous merge.		- Force Error on heterogeneous merge.
	RSVP Extensions for Emergency Services January 2007
	The only difference with [RSVP-PREEMP] is that this document does not		The only difference with [RSVP-PREEMP] is that this document does not
	recommend any merge strategies for Admission Priority while [RSVP-		recommend any merge strategies for Admission Priority while [RSVP-
	PREEMP] recommends the first of these merge strategies for Preemption		PREEMP] recommends the first of these merge strategies for Preemption
	Priority.		Priority.
	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
	skipping to change at page 12, line 5		skipping to change at page 12, line 14
	represents the position of the namespace in the "Resource-		represents the position of the namespace in the "Resource-
	Priority Namespace" IANA registry, starting with 0. Creation		Priority Namespace" IANA registry, starting with 0. Creation
	of this registry has been requested to IANA in [SIP-		of this registry has been requested to IANA in [SIP-
	PRIORITY].		PRIORITY].
	For example, as "drsn", "dsn", "q735", "ets" and "wps" are		For example, as "drsn", "dsn", "q735", "ets" and "wps" are
	currently the first, second, third, fourth and fifth		currently the first, second, third, fourth and fifth
	namespaces defined in the "Resource-Priority Namespace"		namespaces defined in the "Resource-Priority Namespace"
	registry, those are respectively encoded as value 0, 1, 2, 3		registry, those are respectively encoded as value 0, 1, 2, 3
	and 4.		and 4.
	RSVP Extensions for Emergency Services January 2007
	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",
	"priority" and "routine" are the priorities in decreasing		"priority" and "routine" are the priorities in decreasing
	skipping to change at page 13, line 4		skipping to change at page 13, line 14
	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.
	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-
	RSVP Extensions for Emergency Services January 2007
	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. The second mechanism relies on the INTEGRITY object
	within the POLICY_DATA object to guarantee integrity between RSVP		within the POLICY_DATA object to guarantee integrity between RSVP
	Policy Enforcement Points (PEPs) that are not RSVP neighbors.		Policy Enforcement Points (PEPs) that are not RSVP neighbors.
	4.1. Use of RSVP Authentication		4.1. Use of RSVP Authentication
	[RSVP-CRYPTO-1] discusses several approaches for distribution of keys		[RSVP-CRYPTO-1] discusses several approaches for distribution of keys
	to be used for RSVP Authentication. First, the RSVP Authentication		to be used for RSVP Authentication. First, the RSVP Authentication
	shared keys can be distributed manually. This is the base option and		shared keys can be distributed manually. This is the base option and
	its support is mandated for any implementation. However, in some		its support is mandated for any implementation. However, in some
	environments, this approach may become a burden if keys frequently		environments, this approach may become a burden if keys frequently
	change over time. Alternatively, a standard key management protocol		change over time. Alternatively, a standard key management protocol
	for secure key distribution can be used. However, existing key		for secure key distribution can be used. However, existing key
	distribution protocols may not be appropriate in all environments		distribution protocols may not be appropriate in all environments
	because of the complexity or operational burden they involve. Finally,		because of the complexity or operational burden they involve.
	[RSVP-CRYPTO-1] specifies how Kerberos [KERBEROS] may be used to
	generate the RSVP Authentication keys. Kerberos allows for the use of
	trusted third party keying relationships between security principals
	(RSVP sender and receivers) where the Kerberos key distribution
	center (KDC) establishes an ephemeral session key to be shared
	between RSVP sender and receivers.
	The use of RSVP Authentication in parts of the network where there		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		may be one or more IP hops in between two RSVP neighbors raises an
	additional challenge. This is because, with some RSVP messages such		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		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		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		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		dynamically re-discover it when it changes, say because of a routing
	change). Hence, the RSVP router may not know which security		change). Hence, the RSVP router may not know which security
	association to use when forwarding such a message.		association to use when forwarding such a message.
	skipping to change at page 14, line 4		skipping to change at page 14, line 11
	keys could be used between any RSVP router pair straddling the		keys could be used between any RSVP router pair straddling the
	boundary between two administrative domains that have agreed to use		boundary between two administrative domains that have agreed to use
	RSVP signaling.		RSVP signaling.
	When the same RSVP Authentication shared key is to be shared among		When the same RSVP Authentication shared key is to be shared among
	multiple RSVP neighbors, manual key distribution may be used. For		multiple RSVP neighbors, manual key distribution may be used. For
	situations where RSVP is being used for multicast flows, it might		situations where RSVP is being used for multicast flows, it might
	also be possible, in the future, to adapt a multicast key management		also be possible, in the future, to adapt a multicast key management
	method (e.g. from IETF Multicast Security Working Group) for key		method (e.g. from IETF Multicast Security Working Group) for key
	distribution with such multicast RSVP usage. For situations where		distribution with such multicast RSVP usage. For situations where
			RSVP is being used for unicast flows across domain boundaries, it is
	RSVP Extensions for Emergency Services January 2007		not currently clear how one might provide automated key management.
			Specification of a specific automated key management technique is
	RSVP is being used for unicast flows within a single administrative		outside the scope of this document. Operators should consider these
	domain, the Kerberos technique described in Section 7 of [RSVP-		key management issues when contemplating deployment of this
	CRYPTO-1] might be considered. For situations where RSVP is being		specification.
	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
	skipping to change at page 15, line 4		skipping to change at page 15, line 8
	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
	RSVP Extensions for Emergency Services January 2007
	- one P-Type to the Application-Level Resource Priority		- one P-Type to the Application-Level Resource Priority
	Policy Element		Policy Element
	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
	[DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth
	Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC
	4125, June 2005.
	[DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints
	Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June
	2005
	[EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for
	Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
	[EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
	for Emergency Telecommunication Service (ETS)", RFC 3690, February
	2004.
	[FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
	for Policy-based Admission Control", RFC 2753, January 2000.
	[IANA-CONSIDERATIONS] Alverstrand et al., "Guidelines for Writing an		[IANA-CONSIDERATIONS] Alverstrand et al., "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	[KEYWORDS] "Key words for use in RFCs to Indicate Requirement Levels",
	Bradner, RFC2119, BCP14
	[KERBEROS] Neuman et al., "The Kerberos Network Authentication
	Service (V5)", RFC 4120, July 2005.
	[RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol		[RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol
	(RSVP)- Functional Specification", RFC 2205, September 1997.		(RSVP)- Functional Specification", RFC 2205, September 1997.
	[RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP		[RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP
	Cryptographic Authentication", RFC 2747, January 2000.		Cryptographic Authentication", RFC 2747, January 2000.
	RSVP Extensions for Emergency Services January 2007
	[RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic		[RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic
	Authentication -- Updated Message Type Value", RFC 3097, April 2001.		Authentication -- Updated Message Type Value", RFC 3097, April 2001.
	[RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC		[RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC
	2750, January 2000.		2750, January 2000.
	[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
			Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC
			4125, June 2005.
			[DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints
			Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June
			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
			Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
			[EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
			for Emergency Telecommunication Service (ETS)", RFC 3690, February
			2004.
			[FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
			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.
	[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.
	skipping to change at page 17, line 5		skipping to change at page 17, line 19
	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
	illustrates how a simple "Priority Bypass Model" can also be used for		illustrates how a simple "Priority Bypass Model" can also be used for
	support of admission priority.		support of admission priority.
	For simplicity, operations with only a single "priority" level		For simplicity, operations with only a single "priority" level
	(beyond non-priority) are illustrated here; However, the reader will		(beyond non-priority) are illustrated here; However, the reader will
	appreciate that operations with multiple priority levels can easily		appreciate that operations with multiple priority levels can easily
	be supported with these models.		be supported with these models.
	RSVP Extensions for Emergency Services January 2007
	In all the charts below:		In all the charts below:
	x represents a non-priority session		x represents a non-priority session
	o represents a priority session		o represents a priority session
	A.1 Admission Priority with Maximum Allocation Model (MAM)		A.1 Admission Priority with Maximum Allocation Model (MAM)
	This section illustrates operations of admission priority when a		This section illustrates operations of admission priority when a
	Maximum Allocation Model (MAM) is used for bandwidth allocation		Maximum Allocation Model (MAM) is used for bandwidth allocation
	across non-priority traffic and priority traffic. A property of the		across non-priority traffic and priority traffic. A property of the
	Maximum Allocation Model is that priority traffic can not use more		Maximum Allocation Model is that priority traffic can not use more
	skipping to change at page 18, line 4		skipping to change at page 18, line 19
	be accepted even if the bandwidth reserved for priority traffic is		be accepted even if the bandwidth reserved for priority traffic is
	not currently fully utilized.		not currently fully utilized.
	With the Maximum Allocation Model, in the case where the priority		With the Maximum Allocation Model, in the case where the priority
	load reaches the maximum bandwidth reserved for priority calls, no		load reaches the maximum bandwidth reserved for priority calls, no
	additional priority sessions can be accepted.		additional priority sessions can be accepted.
	As illustrated in Chart 1, an operator may map the MAM model onto the		As illustrated in Chart 1, an operator may map the MAM model onto the
	Engineered Capacity limits according to different policies. At one		Engineered Capacity limits according to different policies. At one
	extreme, where the proportion of priority traffic is reliably known		extreme, where the proportion of priority traffic is reliably known
	RSVP Extensions for Emergency Services January 2007
	to be fairly small at all times and where there may be some safety		to be fairly small at all times and where there may be some safety
	margin factored in the engineered capacity limits, the operator may		margin factored in the engineered capacity limits, the operator may
	decide to configure the bandwidth available for non-priority use to		decide to configure the bandwidth available for non-priority use to
	the full engineered capacity limits; effectively allowing the		the full engineered capacity limits; effectively allowing the
	priority traffic to ride within the safety margin of this engineered		priority traffic to ride within the safety margin of this engineered
	capacity. This policy can be seen as an economically attractive		capacity. This policy can be seen as an economically attractive
	approach as all of the engineered capacity is made available to non-		approach as all of the engineered capacity is made available to non-
	priority calls. This policy illustrated as (1) in Chart 1. As an		priority calls. This policy illustrated as (1) in Chart 1. As an
	example, if the engineered capacity limit on a given link is X, the		example, if the engineered capacity limit on a given link is X, the
	operator may configure the bandwidth available to non-priority		operator may configure the bandwidth available to non-priority
	skipping to change at page 19, line 4		skipping to change at page 19, line 19
	. . . | | . Available		. . . | | . Available
	Engi- . . . | | . for non-priority use		Engi- . . . | | . for non-priority use
	neered .or.or. |xxxxxxxxxxxxxx| .		neered .or.or. |xxxxxxxxxxxxxx| .
	. . . |xxxxxxxxxxxxxx| .		. . . |xxxxxxxxxxxxxx| .
	Capacity. . . |xxxxxxxxxxxxxx| .		Capacity. . . |xxxxxxxxxxxxxx| .
	v . . |xxxxxxxxxxxxxx| v		v . . |xxxxxxxxxxxxxx| v
	. . |--------------| ---		. . |--------------| ---
	v . | | ^		v . | | ^
	. | | . Bandwidth available for		. | | . Bandwidth available for
	v | | v priority use		v | | v priority use
	RSVP Extensions for Emergency Services January 2007
	-------------------------		-------------------------
	Chart 2. Partial load of non-priority calls		Chart 2. Partial load of non-priority calls
	Chart 3 shows the same amount of non-priority load being used at this		Chart 3 shows the same amount of non-priority load being used at this
	link, and a small amount of priority bandwidth being used.		link, and a small amount of priority bandwidth being used.
	-----------------------		-----------------------
	^ ^ ^ | | ^		^ ^ ^ | | ^
	. . . | | .		. . . | | .
	Total . . . | | . Bandwidth		Total . . . | | . Bandwidth
	skipping to change at page 20, line 5		skipping to change at page 20, line 20
	Capacity. . . |xxxxxxxxxxxxxx| .		Capacity. . . |xxxxxxxxxxxxxx| .
	v . . |xxxxxxxxxxxxxx| v		v . . |xxxxxxxxxxxxxx| v
	. . |--------------| ---		. . |--------------| ---
	v . | | ^		v . | | ^
	. | | . Bandwidth available for		. | | . Bandwidth available for
	v |oooooooooooooo| v priority use		v |oooooooooooooo| v priority use
	-------------------------		-------------------------
	Chart 4. Full non-priority load		Chart 4. Full non-priority load
	& partial load of priority calls		& partial load of priority calls
	RSVP Extensions for Emergency Services January 2007
	Chart 5 shows the case where the priority traffic equates or exceeds		Chart 5 shows the case where the priority traffic equates or exceeds
	the bandwidth reserved for such priority traffic.		the bandwidth reserved for such priority traffic.
	In that case additional priority sessions could not be accepted. Note		In that case additional priority sessions could not be accepted. Note
	that this does not mean that such calls are dropped altogether: they		that this does not mean that such calls are dropped altogether: they
	may be handled by mechanisms, which are beyond the scope of this		may be handled by mechanisms, which are beyond the scope of this
	particular document (such as establishment through preemption of		particular document (such as establishment through preemption of
	existing non-priority sessions, or such as queuing of new priority		existing non-priority sessions, or such as queuing of new priority
	session requests until capacity becomes available again for priority		session requests until capacity becomes available again for priority
	traffic).		traffic).
	skipping to change at page 21, line 5		skipping to change at page 21, line 22
	As with the MAM model, an operator may map the RDM model onto the		As with the MAM model, an operator may map the RDM model onto the
	Engineered Capacity limits according to different policies. The		Engineered Capacity limits according to different policies. The
	operator may decide to configure the bandwidth available for non-		operator may decide to configure the bandwidth available for non-
	priority use to the full engineered capacity limits; As an example,		priority use to the full engineered capacity limits; As an example,
	if the engineered capacity limit on a given link is X, the operator		if the engineered capacity limit on a given link is X, the operator
	may configure the bandwidth available to non-priority traffic to X,		may configure the bandwidth available to non-priority traffic to X,
	and the bandwidth available to non-priority and priority traffic to		and the bandwidth available to non-priority and priority traffic to
	105% of X.		105% of X.
	RSVP Extensions for Emergency Services January 2007
	Alternatively, the operator may decide to configure the bandwidth		Alternatively, the operator may decide to configure the bandwidth
	available to non-priority and priority traffic to the engineered		available to non-priority and priority traffic to the engineered
	capacity limits; As an example, if the engineered capacity limit on a		capacity limits; As an example, if the engineered capacity limit on a
	given link is X, the operator may configure the bandwidth available		given link is X, the operator may configure the bandwidth available
	to non-priority traffic to 95% of X, and the bandwidth available to		to non-priority traffic to 95% of X, and the bandwidth available to
	non-priority and priority traffic to X.		non-priority and priority traffic to X.
	Finally, the operator may decide to strike a balance in between. The		Finally, the operator may decide to strike a balance in between. The
	considerations presented for these policies in the previous section		considerations presented for these policies in the previous section
	in the MAM context are equally applicable to RDM.		in the MAM context are equally applicable to RDM.
	skipping to change at page 22, line 4		skipping to change at page 22, line 18
	--------------------------------------		--------------------------------------
	|xxxxxxxxxxxxxx| . ^		|xxxxxxxxxxxxxx| . ^
	|xxxxxxxxxxxxxx| . Bandwidth .		|xxxxxxxxxxxxxx| . Bandwidth .
	|xxxxxxxxxxxxxx| . Available for .		|xxxxxxxxxxxxxx| . Available for .
	|xxxxxxxxxxxxxx| . non-priority .		|xxxxxxxxxxxxxx| . non-priority .
	|xxxxxxxxxxxxxx| . use .		|xxxxxxxxxxxxxx| . use .
	|xxxxxxxxxxxxxx| . . Bandwidth		|xxxxxxxxxxxxxx| . . Bandwidth
	|xxxxxxxxxxxxxx| . . available for		|xxxxxxxxxxxxxx| . . available for
	|xxxxxxxxxxxxxx| v . non-priority		|xxxxxxxxxxxxxx| v . non-priority
	RSVP Extensions for Emergency Services January 2007
	|--------------| --- . and priority		|--------------| --- . and priority
	| | . use		| | . use
	| | .		| | .
	|oooooooooooooo| v		|oooooooooooooo| v
	---------------------------------------		---------------------------------------
	Chart 7. Full non-priority load & Partial Aggregate load		Chart 7. Full non-priority load & Partial Aggregate load
	Chart 8 shows the case where only some of the bandwidth available to		Chart 8 shows the case where only some of the bandwidth available to
	non-priority traffic is being used and a heavy load of priority		non-priority traffic is being used and a heavy load of priority
	skipping to change at page 23, line 4		skipping to change at page 23, line 19
	may be handled by mechanisms, which are beyond the scope of this		may be handled by mechanisms, which are beyond the scope of this
	particular document (such as established through preemption of		particular document (such as established through preemption of
	existing non-priority sessions, or such as queuing of new priority		existing non-priority sessions, or such as queuing of new priority
	session requests until capacity becomes available again for priority		session requests until capacity becomes available again for priority
	traffic).		traffic).
	--------------------------------------		--------------------------------------
	|xxxxxxxxxxxxxx| . ^		|xxxxxxxxxxxxxx| . ^
	|xxxxxxxxxxxxxx| . Bandwidth .		|xxxxxxxxxxxxxx| . Bandwidth .
	|xxxxxxxxxxxxxx| . Available for .		|xxxxxxxxxxxxxx| . Available for .
	RSVP Extensions for Emergency Services January 2007
	|xxxxxxxxxxxxxx| . non-priority .		|xxxxxxxxxxxxxx| . non-priority .
	|xxxxxxxxxxxxxx| . use .		|xxxxxxxxxxxxxx| . use .
	|xxxxxxxxxxxxxx| . . Bandwidth		|xxxxxxxxxxxxxx| . . Bandwidth
	|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
	---------------------------------------		---------------------------------------
	skipping to change at page 24, line 4		skipping to change at page 24, line 22
	used, those always still represent a fairly small proportion of		used, those always still represent a fairly small proportion of
	the overall load which can be absorbed within the safety margin		the overall load which can be absorbed within the safety margin
	of the engineered capacity limits. Thus, even if they are		of the engineered capacity limits. Thus, even if they are
	admitted beyond the engineered bandwidth threshold, they are		admitted beyond the engineered bandwidth threshold, they are
	unlikely to result in noticeable QoS degradation.		unlikely to result in noticeable QoS degradation.
	As with the MAM and RDM model, an operator may map the Priority		As with the MAM and RDM model, an operator may map the Priority
	Bypass model onto the Engineered Capacity limits according to		Bypass model onto the Engineered Capacity limits according to
	different policies. The operator may decide to configure the		different policies. The operator may decide to configure the
	bandwidth limit for admission of non-priority traffic to the full		bandwidth limit for admission of non-priority traffic to the full
	RSVP Extensions for Emergency Services January 2007
	engineered capacity limits; As an example, if the engineered capacity		engineered capacity limits; As an example, if the engineered capacity
	limit on a given link is X, the operator may configure the bandwidth		limit on a given link is X, the operator may configure the bandwidth
	limit for non-priority traffic to X. Alternatively, the operator may		limit for non-priority traffic to X. Alternatively, the operator may
	decide to configure the bandwidth limit for non-priority traffic to		decide to configure the bandwidth limit for non-priority traffic to
	below the engineered capacity limits (so that the sum of the non-		below the engineered capacity limits (so that the sum of the non-
	priority and priority traffic stays below the engineered capacity);		priority and priority traffic stays below the engineered capacity);
	As an example, if the engineered capacity limit on a given link is X,		As an example, if the engineered capacity limit on a given link is X,
	the operator may configure the bandwidth limit for non-priority		the operator may configure the bandwidth limit for non-priority
	traffic to 95% of X. Finally, the operator may decide to strike a		traffic to 95% of X. Finally, the operator may decide to strike a
	balance in between. The considerations presented for these policies		balance in between. The considerations presented for these policies
	skipping to change at page 25, line 4		skipping to change at page 25, line 20
	. . |xxxxxxxxxxxxxx| .		. . |xxxxxxxxxxxxxx| .
	Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit		Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit
	(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)		(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
	Engi- . . | | . for admission		Engi- . . | | . for admission
	neered . or . | | . of non-priority traffic		neered . or . | | . of non-priority traffic
	. . | | .		. . | | .
	Capacity. . | | .		Capacity. . | | .
	v . | | v		v . | | v
	. |--------------| ---		. |--------------| ---
	. | |		. | |
	RSVP Extensions for Emergency Services January 2007
	v | |		v | |
	| |		| |
	Chart 11. Partial load of non-priority calls		Chart 11. Partial load of non-priority calls
	Chart 12 shows the same amount of non-priority load being used at		Chart 12 shows the same amount of non-priority load being used at
	this link, and a small amount of priority bandwidth being used. In		this link, and a small amount of priority bandwidth being used. In
	this situation, both new non-priority and new priority calls would be		this situation, both new non-priority and new priority calls would be
	accepted.		accepted.
	skipping to change at page 26, line 5		skipping to change at page 26, line 22
	Engi- . . |oooooooooooooo| . for admission		Engi- . . |oooooooooooooo| . for admission
	neered . or . |xxxooxxxooxxxo| . of non-priority traffic		neered . or . |xxxooxxxooxxxo| . of non-priority traffic
	. . |xxoxxxxxxoxxxx| .		. . |xxoxxxxxxoxxxx| .
	Capacity. . |oxxxooooxxxxoo| .		Capacity. . |oxxxooooxxxxoo| .
	v . |xxoxxxooxxxxxx| v		v . |xxoxxxooxxxxxx| v
	. |--------------| ---		. |--------------| ---
	. |oooooooooooooo|		. |oooooooooooooo|
	v | |		v | |
	| |		| |
	RSVP Extensions for Emergency Services January 2007
	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. The content of
	skipping to change at page 27, line 4		skipping to change at page 27, line 21
	* not using Admission-Priority Policy Element in RSVP		* not using Admission-Priority Policy Element in RSVP
	* not using Preemption Policy Element in RSVP		* not using Preemption Policy Element in RSVP
	If one wants to implement an emergency service based on Call		If one wants to implement an emergency service based on Call
	Queueing and on "prioritized access to network layer resources", one		Queueing and on "prioritized access to network layer resources", one
	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.
	RSVP Extensions for Emergency Services January 2007
	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:
	skipping to change at page 28, line 4		skipping to change at page 28, line 20
	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
	Authors' Address		Authors' Address
	Francois Le Faucheur		Francois Le Faucheur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Village d'Entreprise Green Side - Batiment T3		Village d'Entreprise Green Side - Batiment T3
	400, Avenue de Roumanille		400, Avenue de Roumanille
	RSVP Extensions for Emergency Services January 2007
	06410 Biot Sophia-Antipolis		06410 Biot Sophia-Antipolis
	France		France
	Email: flefauch@cisco.com		Email: flefauch@cisco.com
	James Polk		James Polk
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Richardson, Texas 75082		Richardson, Texas 75082
	USA		USA
	Email: jmpolk@cisco.com		Email: jmpolk@cisco.com
	skipping to change at page 29, line 5		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
	RSVP Extensions for Emergency Services January 2007		Copyright (C) The IETF Trust (2007).
	Copyright (C) The Internet Society (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 AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
			PURPOSE.
End of changes. 46 change blocks.
	137 lines changed or deleted		54 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/