MMUSIC James Polk
Internet-Draft Subha Dhesikan
Expires: September 7, 2006 Cisco Systems
Gonzalo Camarillo
Ericsson
March 6, 2006
An Identification of QoS Mechanism for Preconditions
draft-polk-mmusic-qos-mechanism-identification-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The offer/answer model for SDP assumes that endpoints establish,
somehow, the QoS (Quality of Service) required for the media streams
they establish. Endpoints in closed environments typically agree out
of band (e.g., using configuration information) which QoS mechanism
to use. However, in the Internet, there is more than one QoS service
available. Consequently, there is a need for a mechanism to
James Polk, et al. Expires September 7, 2006 [Page 1]
Internet-Draft An Identification QoS Mechanism March 2006
negotiate which QoS mechanism to use for a particular media stream.
This document defines such a mechanism.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of the qos-selection Attribute . . . . . . . . . . . 3
4. Offer/answer Behavior . . . . . . . . . . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
James Polk, et al. Expires September 7, 2006 [Page 2]
Internet-Draft An Identification QoS Mechanism March 2006
1. Introduction
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
particular media stream. Even when QoS preconditions [9] are used,
the choice of the QoS mechanism is left unspecified, up to the
endpoints.
Endpoints that support more than one QoS mechanism need a way to
negotiate which one to use for a particular media stream. Examples
of QoS mechanisms are RSVP (Resource Reservation Protocol), initially
defined in [3], and NSIS (Next Steps in Signaling), defined in at
least 3 documents: [4], [5] and [6].
This document defines a mechanism that allows endpoints to negotiate
the QoS mechanism to be used for a particular media stream.
Section 3 defines the 'qos-selection' SDP attribute, Section 4
specifies the use of the 'qos-selection' attribute with the offer/
answer model, and Section 5 provides examples of offer/answer
exchanges that use the 'qos-selection' attribute.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [7] and indicate requirement levels for
compliant implementations.
3. Definition of the qos-selection Attribute
This document defines the 'qos-selection' session and media-level SDP
[2] attribute. The following is its ABNF syntax [8], which is based
on the SDP [2] grammar:
attribute = qos-selection-attr
qos-selection-attr = "qos-selection" ":" qos-mech SP direction
qos-mech = rsvp / nsis / extension-mech
extension-mech = token
direction = send / recv / sendrecv
Figure 1: Syntax of the qos-selection attribute
James Polk, et al. Expires September 7, 2006 [Page 3]
Internet-Draft An Identification QoS Mechanism March 2006
The 'qos-mech' token identifies a QoS mechanism that is supported by
the entity generating the session description. The 'direction' token
indicates in which direction can be used to reserve resources that
QoS mechanism.
send: QoS can be reserved for traffic sent by the entity generating
the session description.
recv: QoS can be reserved for traffic received by the entity
generating the session description.
sendrecv: QoS can be reserved for traffic in both directions.
An SDP session description MAY contain more than one 'qos-selection'
attribute.
The following is an example of an 'm' line with two 'qos-selection'
attributes:
m=audio 50000 RTP/AVP 0
a=qos-selection:rsvp sendrecv
a=qos-selection:nsis sendrecv
4. Offer/answer Behavior
Offerers include a 'qos-selection' attribute per QoS mechanism they
are willing to use for the media stream. Each 'qos-selection'
attribute includes the direction in which the mechanism can be used.
On receiving an offer with 'qos-selection' attributes, the answerer
chooses a QoS mechanism from the 'qos-selection' attributes for each
direction where QoS is needed. That is, if QoS is needed in both
directions (sendrecv), the answerer can choose the same QoS mechanism
for both directions or a different one for each direction.
The answerer MUST add 'qos-selection' attributes for each QoS
mechanisms it has chosen to use. If the answerer lists two QoS
mechanisms for a given direction, both mechanisms will be used.
Note that endpoints negotiate in which direction QoS is needed using
other mechanisms, such as preconditions [9]. Endpoints may also use
other mechanisms to negotiate, if needed, the parameters to use with
a given QoS mechanism (e.g., bandwidth to be reserved).
5. Example
The following is an offer/answer exchange between two endpoints using
James Polk, et al. Expires September 7, 2006 [Page 4]
Internet-Draft An Identification QoS Mechanism March 2006
the 'qos-selection' attribute. Parts of the session descriptions are
ommitted for clarity purposes.
The offerer generates the following session description listing both
RSVP and NSIS for both directions:
m=audio 50000 RTP/AVP 0
a=qos-selection:rsvp sendrecv
a=qos-selection:nsis sendrecv
The answerer chooses to use RSVP in both directions and,
consequently, returns the following session description:
m=audio 55000 RTP/AVP 0
a=qos-selection:rsvp sendrecv
6. IANA Considerations
TBD.
7. Security Considerations
TBD.
8. Acknowledgements
To Dave Oran for his help in forming this effort.
9. References
9.1. Normative References
[1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[2] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.
[3] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
James Polk, et al. Expires September 7, 2006 [Page 5]
Internet-Draft An Identification QoS Mechanism March 2006
[4] "GIMPS: General Internet Messaging Protocol for Signaling",
draft-draft-ietf-nsis-ntlp-00 (work in progress), October 2003.
[5] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005.
[6] Chaskar, H., "Requirements of a QoS Solution for Mobile IP",
draft-ietf-nsis-qos-requirements-01 (work in progress),
June 2003.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
9.2. Informative References
[9] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)",
RFC 3312, October 2002.
James Polk, et al. Expires September 7, 2006 [Page 6]
Internet-Draft An Identification QoS Mechanism March 2006
Authors' Addresses
James M. Polk
Cisco Systems
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Email: jmpolk@cisco.com
Subha Dhesikan
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: sdhesika@cisco.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
James Polk, et al. Expires September 7, 2006 [Page 7]
Internet-Draft An Identification QoS Mechanism March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
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
Funding for the RFC Editor function is currently provided by the
Internet Society.
James Polk, et al. Expires September 7, 2006 [Page 8]