< draft-polk-mmusic-qos-mechanism-identification-02.txt		draft-polk-mmusic-qos-mechanism-identification-03.txt >
	MMUSIC James Polk		MMUSIC James Polk
	Internet-Draft Subha Dhesikan		Internet-Draft Subha Dhesikan
	Expires: April 9, 2007 Cisco Systems		Expires: September 4, 2007 Cisco Systems
	Gonzalo Camarillo		Gonzalo Camarillo
	Ericsson		Ericsson
	October 6, 2006		March 3, 2007
	Quality of Service (QoS) Mechanism Selection in the Session Description		Quality of Service (QoS) Mechanism Selection in the Session Description
	Protocol (SDP)		Protocol (SDP)
	draft-polk-mmusic-qos-mechanism-identification-02.txt		draft-polk-mmusic-qos-mechanism-identification-03.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 37 ¶
	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 April 9, 2007.		This Internet-Draft will expire on September 4, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The offer/answer model for SDP assumes that endpoints establish,		The offer/answer model for SDP assumes that endpoints establish,
	somehow, the QoS required for the media streams they establish.		somehow, the QoS required for the media streams they establish.
	Endpoints in closed environments typically agree out of band (e.g.,		Endpoints in closed environments typically agree out of band (e.g.,
	using configuration information) which QoS mechanism to use.		using configuration information) which QoS mechanism to use.
	However, on the Internet, there is more than one QoS service		However, on the Internet, there is more than one QoS service
	available. Consequently, there is a need for a mechanism to		available. Consequently, there is a need for a mechanism to
	negotiate which QoS mechanism to use for a particular media stream.		negotiate which QoS mechanism to use for a particular media stream.
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. SDP Attributes Definition . . . . . . . . . . . . . . . . . . 3		3. SDP Attributes Definition . . . . . . . . . . . . . . . . . . 3
	4. Offer/answer Behavior . . . . . . . . . . . . . . . . . . . . 4		4. Offer/answer Behavior . . . . . . . . . . . . . . . . . . . . 4
	4.1. Offerer Behavior . . . . . . . . . . . . . . . . . . . . . 4		4.1. Offerer Behavior . . . . . . . . . . . . . . . . . . . . . 4
	4.2. Answerer Behavior . . . . . . . . . . . . . . . . . . . . 4		4.2. Answerer Behavior . . . . . . . . . . . . . . . . . . . . 4
	4.3. Resource Reservation . . . . . . . . . . . . . . . . . . . 5		4.3. Resource Reservation . . . . . . . . . . . . . . . . . . . 5
			4.4. Subsequent Offer/answer Exchanges . . . . . . . . . . . . 5
	5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Registration of the SDP 'qos-mech-send' Attribute . . . . 6		6.1. Registration of the SDP 'qos-mech-send' Attribute . . . . 6
	6.2. Registration of the SDP 'qos-mech-recv' Attribute . . . . 6		6.2. Registration of the SDP 'qos-mech-recv' Attribute . . . . 6
	6.3. Registry for QoS Mechanism Tokens . . . . . . . . . . . . 7		6.3. Registry for QoS Mechanism Tokens . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . . . . 10		Intellectual Property and Copyright Statements . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The offer/answer model [1] for SDP [2] does not provide any mechanism		The offer/answer model [1] for SDP [2] does not provide any mechanism
	for endpoints to negotiate the QoS mechanism to be used for a		for endpoints to negotiate the QoS mechanism to be used for a
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	This document defines a mechanism that allows endpoints to negotiate		This document defines a mechanism that allows endpoints to negotiate
	the QoS mechanism to be used for a particular media stream.		the QoS mechanism to be used for a particular media stream.
	Section 3 defines the 'qos-mech-send' and 'qos-mech-recv' SDP		Section 3 defines the 'qos-mech-send' and 'qos-mech-recv' SDP
	attributes. Section 4 specifies the use of these new SDP attributes		attributes. Section 4 specifies the use of these new SDP attributes
	with the offer/answer model. Section 5 provides an example of an		with the offer/answer model. Section 5 provides an example of an
	offer/answer exchanges that uses these attributes.		offer/answer exchanges that uses these attributes.
	2. Terminology		2. Terminology
	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", "NOT		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as		document are to be interpreted as described in RFC 2119 [5].
	described in BCP 14, RFC 2119 [5] and indicate requirement levels for
	compliant implementations.
	3. SDP Attributes Definition		3. SDP Attributes Definition
	This document defines the 'qos-mech-send' and 'qos-mech-recv' session		This document defines the 'qos-mech-send' and 'qos-mech-recv' session
	and media-level SDP [2] attributes. The following is their ABNF		and media-level SDP [2] attributes. The following is their augmented
	syntax [6], which is based on the SDP [2] grammar:		Backus-Naur Form (BNF) [6] syntax, which is based on the SDP [2]
			grammar:
	attribute = qos-mech-send-attr		attribute = qos-mech-send-attr
	attribute = qos-mech-recv-attr		attribute = qos-mech-recv-attr
	qos-mech-send-attr = "qos-mech-send" ":" *(SP qos-mech)		qos-mech-send-attr = "qos-mech-send" ":" *(SP qos-mech)
	qos-mech-recv-attr = "qos-mech-recv" ":" *(SP qos-mech)		qos-mech-recv-attr = "qos-mech-recv" ":" *(SP qos-mech)
	qos-mech = rsvp / nsis / extension-mech		qos-mech = rsvp / nsis / extension-mech
	extension-mech = token		extension-mech = token
	The 'qos-mech' token identifies a QoS mechanism that is supported by		The 'qos-mech' token identifies a QoS mechanism that is supported by
	the entity generating the session description. A token that appears		the entity generating the session description. A token that appears
	in a 'qos-mech-send' attribute identifies a QoS mechanism that can be		in a 'qos-mech-send' attribute identifies a QoS mechanism that can be
	used to reserve resources for traffic sent by the entity generating		used to reserve resources for traffic sent by the entity generating
	the session description. A token that appears in a 'qos-mech-recv'		the session description. A token that appears in a 'qos-mech-recv'
	attribute identifies a QoS mechanism that can be used to reserve		attribute identifies a QoS mechanism that can be used to reserve
	resources for traffic received by the entity generating the session		resources for traffic received by the entity generating the session
	description.		description.
			The 'qos-mech-send' and 'qos-mech-recv' attributes are not
			interdependent; one can be used without the other.
	The following is an example of an 'm' line with a 'qos-mech-send' and		The following is an example of an 'm' line with a 'qos-mech-send' and
	a 'qos-mech-recv' attributes:		a 'qos-mech-recv' attributes:
	m=audio 50000 RTP/AVP 0		m=audio 50000 RTP/AVP 0
	a=qos-mech-send:rsvp nsis		a=qos-mech-send:rsvp nsis
	a=qos-mech-recv:rsvp nsis		a=qos-mech-recv:rsvp nsis
	4. Offer/answer Behavior		4. Offer/answer Behavior
	An offer/answer exchange using the 'qos-mech-send' and 'qos-mech-		An offer/answer exchange using the 'qos-mech-send' and 'qos-mech-
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 30 ¶
	answerer) does not succeed using the mechanism with highest priority		answerer) does not succeed using the mechanism with highest priority
	in a given direction, it SHOULD attempt to use the next QoS mechanism		in a given direction, it SHOULD attempt to use the next QoS mechanism
	in order of priority in that direction, and so on.		in order of priority in that direction, and so on.
	If an endpoint tries unsuccessfully all the common QoS mechanisms for		If an endpoint tries unsuccessfully all the common QoS mechanisms for
	a given direction, the endpoint MAY attempt to use additional QoS		a given direction, the endpoint MAY attempt to use additional QoS
	mechanisms not supported by the remote endpoint. This is because		mechanisms not supported by the remote endpoint. This is because
	there may be network entities out of the endpoint's control (e.g., an		there may be network entities out of the endpoint's control (e.g., an
	RSVP proxy) that make those mechanisms work.		RSVP proxy) that make those mechanisms work.
			4.4. Subsequent Offer/answer Exchanges
			If, during an established session for which the QoS mechanism to be
			used for a given direction was agreed using the mechanism defined in
			this specification, an endpoint receives a subsequent offer that does
			not contain the QoS selection attribute corresponding to that
			direction (i.e., the 'qos-mech-send' or 'qos-mech-recv' attribute is
			missing), the endpoints SHOULD continue using the same QoS mechanism
			used up to that moment.
	5. Example		5. Example
	The following is an offer/answer exchange between two endpoints using		The following is an offer/answer exchange between two endpoints using
	the 'qos-mech-send' and 'qos-mech-recv' attributes. Parts of the		the 'qos-mech-send' and 'qos-mech-recv' attributes. Parts of the
	session descriptions are ommitted for clarity purposes.		session descriptions are ommitted for clarity purposes.
	The offerer generates the following session description listing both		The offerer generates the following session description listing both
	RSVP and NSIS for both directions. The offerer would prefer to use		RSVP and NSIS for both directions. The offerer would prefer to use
	RSVP and, thus, includes it before NSIS.		RSVP and, thus, includes it before NSIS.
	skipping to change at page 6, line 16 ¶		skipping to change at page 6, line 27 ¶
	This specification registers two new SDP attributes and creates a new		This specification registers two new SDP attributes and creates a new
	registry for QoS mechanisms.		registry for QoS mechanisms.
	6.1. Registration of the SDP 'qos-mech-send' Attribute		6.1. Registration of the SDP 'qos-mech-send' Attribute
	This section instructs the IANA to register the following SDP att-		This section instructs the IANA to register the following SDP att-
	field under the Session Description Protocol (SDP) Parameters		field under the Session Description Protocol (SDP) Parameters
	registry:		registry:
	Contact name: Gonzalo.Camarillo@ericsson.com		Contact name: Gonzalo.Camarillo@ericsson.com
	Attribute name: qos-mech-send		Attribute name: qos-mech-send
	Long-form attribute name: QoS Mechanism for the Send Direction		Long-form attribute name: QoS Mechanism for the Send Direction
	Type of attribute Session and Media levels		Type of attribute Session and Media levels
	Subject to charset: No		Subject to charset: No
	Purpose of attribute: To list QoS mechanisms supported in the send		Purpose of attribute: To list QoS mechanisms supported in the send
	direction.		direction.
	Allowed attribute values: IANA Registered Tokens		Allowed attribute values: IANA Registered Tokens
	6.2. Registration of the SDP 'qos-mech-recv' Attribute		6.2. Registration of the SDP 'qos-mech-recv' Attribute
	This section instructs the IANA to register the following SDP att-		This section instructs the IANA to register the following SDP att-
	field under the Session Description Protocol (SDP) Parameters		field under the Session Description Protocol (SDP) Parameters
	registry:		registry:
	Contact name: Gonzalo.Camarillo@ericsson.com		Contact name: Gonzalo.Camarillo@ericsson.com
	Attribute name: qos-mech-recv		Attribute name: qos-mech-recv
	Long-form attribute name: QoS Mechanism for the Receive Direction		Long-form attribute name: QoS Mechanism for the Receive Direction
	Type of attribute Session and Media levels		Type of attribute Session and Media levels
	Subject to charset: No		Subject to charset: No
	Purpose of attribute: To list QoS mechanisms supported in the		Purpose of attribute: To list QoS mechanisms supported in the
	receive direction.		receive direction.
	Allowed attribute values: IANA Registered Tokens		Allowed attribute values: IANA Registered Tokens
	6.3. Registry for QoS Mechanism Tokens		6.3. Registry for QoS Mechanism Tokens
	The IANA is requested to create a subregistry for QoS mechanism token		The IANA is requested to create a subregistry for QoS mechanism token
	values to be used in the 'qos-mech-send' and 'qos-mech-recv'		values to be used in the 'qos-mech-send' and 'qos-mech-recv'
	attributes under the Session Description Protocol (SDP) Parameters		attributes under the Session Description Protocol (SDP) Parameters
	registry. The initial values for the subregistry are presented in		registry. The initial values for the subregistry are presented in
	the following, and IANA is requested to add them into its database:		the following, and IANA is requested to add them into its database:
	QoS Mechanism Reference		QoS Mechanism Reference
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 11 ¶
	choice to provide such end-to-end integrity protection, as described		choice to provide such end-to-end integrity protection, as described
	in [8]. Other applications MAY use a different form of integrity		in [8]. Other applications MAY use a different form of integrity
	protection.		protection.
	8. Acknowledgements		8. Acknowledgements
	Dave Oran helped form this effort. Flemming Andreasen provided		Dave Oran helped form this effort. Flemming Andreasen provided
	useful comments on this specification.		useful comments on this specification.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with		[1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
	Session Description Protocol (SDP)", RFC 3264, June 2002.		Session Description Protocol (SDP)", RFC 3264, June 2002.
	[2] Handley, M., "SDP: Session Description Protocol",		[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.		Description Protocol", RFC 4566, July 2006.
	[3] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,		[3] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
	"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional		"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
	Specification", RFC 2205, September 1997.		Specification", RFC 2205, September 1997.
	[4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den		[4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
	Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,		Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
	June 2005.		June 2005.
	[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 4234, October 2005.		Specifications: ABNF", RFC 4234, October 2005.
	[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		Considerations Section in RFCs", BCP 26, RFC 2434,
			October 1998.
	[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions		[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
	(S/MIME) Version 3.1 Message Specification", RFC 3851,		(S/MIME) Version 3.1 Message Specification", RFC 3851,
	July 2004.		July 2004.
	9.2. Informative References		9.2. Informative References
	[10] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of		[10] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
	Resource Management and Session Initiation Protocol (SIP)",		Resource Management and Session Initiation Protocol (SIP)",
	RFC 3312, October 2002.		RFC 3312, October 2002.
	Authors' Addresses		Authors' Addresses
	James M. Polk		James M. Polk
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	Email: sdhesika@cisco.com		Email: sdhesika@cisco.com
	Gonzalo Camarillo		Gonzalo Camarillo
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: Gonzalo.Camarillo@ericsson.com		Email: Gonzalo.Camarillo@ericsson.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
			OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 10, line 29 ¶		skipping to change at page 10, line 45 ¶
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	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		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 39 change blocks.
	66 lines changed or deleted		82 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/