draft-ietf-mmusic-qos-identification-01.txt   draft-ietf-mmusic-qos-identification-02.txt 
MMUSIC James Polk MMUSIC James Polk
Internet-Draft Subha Dhesikan Internet-Draft Subha Dhesikan
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: July 26, 2008 Gonzalo Camarillo Expires: April 13, 2009 Gonzalo Camarillo
Ericsson Ericsson
January 23, 2008 October 10, 2008
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-ietf-mmusic-qos-identification-01.txt draft-ietf-mmusic-qos-identification-02.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 37 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 July 26, 2008. This Internet-Draft will expire on April 13, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
This document defines such a mechanism. This document defines such a mechanism.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 35 skipping to change at page 3, line 35
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 [RFC4566] attributes. The following is their and media-level SDP [RFC4566] attributes. The following is their
augmented Backus-Naur Form (BNF) [RFC4234] syntax, which is based on augmented Backus-Naur Form (BNF) [RFC5234] syntax, which is based on
the SDP [RFC4566] grammar: the SDP [RFC4566] 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
skipping to change at page 7, line 30 skipping to change at page 7, line 25
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
---------------------------- --------- ---------------------------- ---------
rsvp RFC 2205 rsvp RFC xxxx
nsis RFC 4080 nsis RFC xxxx
As per the terminology in [RFC2434], the registration policy for new [RFC Editor's note: please replace 'RFC xxxx' with the number this
RFC will get.]
As per the terminology in [RFC5226], the registration policy for new
QoS mechanism token values shall be 'Specification Required'. QoS mechanism token values shall be 'Specification Required'.
7. Security Considerations 7. Security Considerations
An attacker may attempt to add, modify, or remove 'qos-mech-send' and An attacker may attempt to add, modify, or remove 'qos-mech-send' and
'qos-mech-recv' attributes from a session description. This could 'qos-mech-recv' attributes from a session description. This could
result in an application behaving in a non-desirable way. For result in an application behaving in a non-desirable way. For
example, the endpoints under attack may not be able to find a common example, the endpoints under attack may not be able to find a common
QoS mechanism to use. QoS mechanism to use.
Consequently, it is strongly RECOMMENDED that integrity protection be Consequently, it is strongly RECOMMENDED that integrity and
applied to SDP session descriptions carrying these attributes. For authenticity protection be applied to SDP session descriptions
session descriptions carried in SIP [RFC3261], S/MIME [RFC3851] is carrying these attributes. For session descriptions carried in SIP
the natural choice to provide such end-to-end integrity protection, [RFC3261], S/MIME [RFC3851] is the natural choice to provide such
as described in [RFC3261]. Other applications MAY use a different end-to-end integrity protection, as described in [RFC3261]. Other
form of integrity protection. applications MAY use a different form of integrity 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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
9.2. Informative References 9.2. Informative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
Authors' Addresses Authors' Addresses
James Polk James Polk
Cisco Systems Cisco Systems
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
USA USA
Phone: +1-817-271-3552 Phone: +1-817-271-3552
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
skipping to change at page 10, line 44 skipping to change at line 414
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 15 change blocks. 
40 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/