draft-ietf-tsvwg-emergency-rsvp-06.txt		draft-ietf-tsvwg-emergency-rsvp-07.txt
	TSVWG F. Le Faucheur		TSVWG F. Le Faucheur
	Internet-Draft J. Polk		Internet-Draft J. Polk
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: October 2, 2008 K. Carlberg		Expires: October 13, 2008 K. Carlberg
	G11		G11
	March 31, 2008		April 11, 2008
	Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services		Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services
	draft-ietf-tsvwg-emergency-rsvp-06.txt		draft-ietf-tsvwg-emergency-rsvp-07.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 2, 2008.		This Internet-Draft will expire on October 13, 2008.
	Abstract		Abstract
	An Emergency Telecommunications Service (ETS) requires the ability to		An Emergency Telecommunications Service (ETS) requires the ability to
	provide an elevated probability of session establishment to an		provide an elevated probability of session establishment to an
	authorized user in times of network congestion (typically, during a		authorized user in times of network congestion (typically, during a
	crisis). When supported over the Internet Protocol suite, this may		crisis). When supported over the Internet Protocol suite, this may
	be facilitated through a network layer admission control solution,		be facilitated through a network layer admission control solution,
	which supports prioritized access to resources (e.g., bandwidth).		which supports prioritized access to resources (e.g., bandwidth).
	These resources may be explicitly set aside for emergency services,		These resources may be explicitly set aside for emergency services,
	skipping to change at page 4, line 18		skipping to change at page 4, line 18
	one type of prioritized network layer admission control procedure		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. [RFC4542] also		continuing call model of the status of all calls. [RFC4542] 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 [RFC2205] along with		realized using the Resource reSerVation Protocol [RFC2205] along with
	its associated protocol suite and extensions, including those for		its associated protocol suite and extensions, including those for
	policy based admission control ([RFC2753], [RFC2750]), for user		policy based admission control ([RFC2753], [RFC2750]), for user
	authentication and authorization ([RFC3182]) and for integrity and		authentication and authorization ([RFC3182]) and for integrity and
	authentication of RSVP messages ([RFC2747], [RFC3097]).		authentication of RSVP messages ([RFC2747], [RFC3097]). The Diameter
			QoS Application ([I-D.ietf-dime-diameter-qos]) allows network
	Furthermore, [RFC4542] describes how the RSVP Signaled Preemption		elements to interact with Diameter servers when allocating QoS
	Priority Policy Element specified in [RFC3181] can be used to enforce		resources in the network and thus, is also a possible method for
	the call preemption that may be needed by some emergency services.		authentication and authorization of RSVP reservations in the context
			of emergency services.
	In contrast to [RFC4542], this document specifies new RSVP extensions		[RFC4542] describes how the RSVP Signaled Preemption Priority Policy
	to increase the probability of call completion without preemption.		Element specified in [RFC3181] can be used to enforce the call
			preemption that may be needed by some emergency services. In
			contrast to [RFC4542], this document specifies new RSVP extensions to
			increase the probability of call completion without preemption.
	Engineered capacity techniques in the form of bandwidth allocation		Engineered capacity techniques in the form of bandwidth allocation
	models are used to satisfy the "admission priority" required by an		models are used to satisfy the "admission priority" required by an
	RSVP capable ETS network. In particular this document specifies two		RSVP capable ETS network. In particular this document specifies two
	new RSVP Policy Elements allowing the admission priority to be		new RSVP Policy Elements allowing the admission priority to be
	conveyed inside RSVP signaling messages so that RSVP nodes can		conveyed inside RSVP signaling messages so that RSVP nodes can
	enforce selective bandwidth admission control decision based on the		enforce selective bandwidth admission control decision based on the
	call admission priority. Appendix A of this document also provides		call admission priority. Appendix A of this document also provides
	three examples of a bandwidth allocation model, which can be used by		examples of bandwidth allocation models which can be used by RSVP-
	RSVP-routers to enforce such admission priority on every link.		routers to enforce such admission priority on every link.
	1.2. Terminology		1.2. Terminology
	This document assumes the terminology defined in [RFC2753]. For		This document assumes the terminology defined in [RFC2753]. For
	convenience, the definition of a few key terms is repeated here:		convenience, the definition of a few key terms is repeated here:
	o Policy Decision Point (PDP): The point where policy decisions are		o Policy Decision Point (PDP): The point where policy decisions are
	made.		made.
	o Local Policy Decision Point (LPDP): PDP local to the network		o Local Policy Decision Point (LPDP): PDP local to the network
	skipping to change at page 9, line 40		skipping to change at page 9, line 46
	* SHALL be set to zero on transmit and SHALL be ignored on		* SHALL be set to zero on transmit and SHALL be ignored on
	reception		reception
	o Adm. Priority (Admission Priority): 8 bits (unsigned)		o 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. A given Admission Priority is encoded in this		higher Priority. A given Admission Priority is encoded in this
	information element using the same value as when encoded in the		information element using the same value as when encoded in the
			"Admission Priority" field of the "Admission Priority"
			parameter defined in [I-D.ietf-nsis-qspec], or in the
	"Admission Priority" parameter defined in		"Admission Priority" parameter defined in
	[I-D.ietf-nsis-qspec], or in the "Admission Priority" parameter		[I-D.ietf-dime-qos-parameters]. In other words, a given value
	defined in [I-D.ietf-dime-qos-parameters]. In other words, a		inside the Admission Priority information element defined in
	given value inside the Admission Priority information element		the present document, inside the [I-D.ietf-nsis-qspec]
	defined in the present document, inside the		Admission Priority field or inside the
	[I-D.ietf-nsis-qspec] Admission Priority parameter or inside		[I-D.ietf-dime-qos-parameters] Admission Priority parameter,
	the [I-D.ietf-dime-qos-parameters] Admission Priority		refers to the same admission priority. Bandwidth allocation
	parameter, refers to the same Admission Priority. Bandwidth		models such as those described in Appendix A are to be used by
	allocation models such as those described in Appendix A are to		the RSVP router to achieve such increased probability of call
	be used by the RSVP router to achieve such increased		completion. The admission priority value effectively indicates
	probability of call completion. The admission priority value		which bandwidth constraint(s) of the bandwidth constraint model
	effectively indicates which bandwidth constraint(s) of the		in use is(are) applicable to admission of this RSVP
	bandwidth constraint model in use is(are) applicable to		reservation.
	admission of this RSVP reservation.
	Note that the Admission Priority Policy Element does NOT indicate		Note that the Admission Priority Policy Element does NOT indicate
	that this RSVP reservation is to preempt any other RSVP reservation.		that this RSVP reservation is to preempt any other RSVP reservation.
	If a priority session justifies both admission priority and		If a priority session justifies both admission priority and
	preemption priority, the corresponding RSVP reservation needs to		preemption priority, the corresponding RSVP reservation needs to
	carry both an Admission Priority Policy Element and a Preemption		carry both an Admission Priority Policy Element and a Preemption
	Priority Policy Element. The Admission Priority and Preemption		Priority Policy Element. The Admission Priority and Preemption
	Priority are handled by LPDPs and PEPs as separate mechanisms. They		Priority are handled by LPDPs and PEPs as separate mechanisms. They
	can be used one without the other, or they can be used both in		can be used one without the other, or they can be used both in
	combination.		combination.
	skipping to change at page 16, line 49		skipping to change at page 16, line 49
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource		[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
	Priority for the Session Initiation Protocol (SIP)",		Priority for the Session Initiation Protocol (SIP)",
	RFC 4412, February 2006.		RFC 4412, February 2006.
	7.2. Informative References		7.2. Informative References
			[I-D.ietf-dime-diameter-qos]
			Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,
			and G. Zorn, "Diameter Quality of Service Application",
			draft-ietf-dime-diameter-qos-05 (work in progress),
			February 2008.
	[I-D.ietf-dime-qos-parameters]		[I-D.ietf-dime-qos-parameters]
	Korhonen, J. and H. Tschofenig, "Quality of Service		Korhonen, J. and H. Tschofenig, "Quality of Service
	Parameters for Usage with the AAA Framework",		Parameters for Usage with the AAA Framework",
	draft-ietf-dime-qos-parameters-03 (work in progress),		draft-ietf-dime-qos-parameters-03 (work in progress),
	February 2008.		February 2008.
	[I-D.ietf-nsis-qspec]		[I-D.ietf-nsis-qspec]
	Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP		Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP
	QSPEC Template", draft-ietf-nsis-qspec-19 (work in		QSPEC Template", draft-ietf-nsis-qspec-20 (work in
	progress), February 2008.		progress), April 2008.
	[I-D.ietf-tsvwg-rsvp-security-groupkeying]		[I-D.ietf-tsvwg-rsvp-security-groupkeying]
	Behringer, M. and F. Faucheur, "Applicability of Keying		Behringer, M. and F. Faucheur, "Applicability of Keying
	Methods for RSVP Security",		Methods for RSVP Security",
	draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in		draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in
	progress), February 2008.		progress), February 2008.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
End of changes. 11 change blocks.
	28 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/