summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5432.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5432.txt')
-rw-r--r--doc/rfc/rfc5432.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5432.txt b/doc/rfc/rfc5432.txt
new file mode 100644
index 0000000..f7f432c
--- /dev/null
+++ b/doc/rfc/rfc5432.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group J. Polk
+Request for Comments: 5432 S. Dhesikan
+Category: Standards Track Cisco Systems
+ G. Camarillo
+ Ericsson
+ March 2009
+
+
+ Quality of Service (QoS) Mechanism Selection
+ in the Session Description Protocol (SDP)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 1]
+
+RFC 5432 QoS Mechanism Selection in SDP March 2009
+
+
+Abstract
+
+ The offer/answer model for the Session Description Protocol (SDP)
+ assumes that endpoints somehow establish the Quality of Service (QoS)
+ required for the media streams they establish. Endpoints in closed
+ environments typically agree out-of-band (e.g., using configuration
+ information) regarding which QoS mechanism to use. However, on the
+ Internet, there is more than one QoS service available.
+ Consequently, there is a need for a mechanism to 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. SDP Attributes Definition .......................................3
+ 4. Offer/Answer Behavior ...........................................4
+ 4.1. Offerer Behavior ...........................................4
+ 4.2. Answerer Behavior ..........................................4
+ 4.3. Resource Reservation .......................................5
+ 4.4. Subsequent Offer/Answer Exchanges ..........................5
+ 5. Example .........................................................5
+ 6. IANA Considerations .............................................6
+ 6.1. Registration of the SDP 'qos-mech-send' Attribute ..........6
+ 6.2. Registration of the SDP 'qos-mech-recv' Attribute ..........6
+ 6.3. Registry for QoS Mechanism Tokens ..........................7
+ 7. Security Considerations .........................................7
+ 8. Acknowledgements ................................................7
+ 9. References ......................................................8
+ 9.1. Normative References .......................................8
+ 9.2. Informative References .....................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 2]
+
+RFC 5432 QoS Mechanism Selection in SDP March 2009
+
+
+1. Introduction
+
+ The offer/answer model [RFC3264] for SDP [RFC4566] does not provide
+ any mechanism for endpoints to negotiate the QoS mechanism to be used
+ for a particular media stream. Even when QoS preconditions [RFC3312]
+ are used, the choice of the QoS mechanism is left unspecified and is
+ 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) [RFC2205]
+ and NSIS (Next Steps in Signaling) [QoS-NSLP].
+
+ This document defines a mechanism that allows endpoints to negotiate
+ the QoS mechanism to be used for a particular media stream. However,
+ the fact that endpoints agree on a particular QoS mechanism does not
+ imply that that particular mechanism is supported by the network.
+ Discovering which QoS mechanisms are supported at the network layer
+ is out of the scope of this document. In any case, the information
+ the endpoints exchange to negotiate QoS mechanisms, as defined in
+ this document, can be useful for a network operator to resolve a
+ subset of the QoS interoperability problem -- namely, to ensure that
+ a mechanism commonly acceptable to the endpoints is chosen and make
+ it possible to debug potential misconfiguration situations.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. SDP Attributes Definition
+
+ This document defines the 'qos-mech-send' and 'qos-mech-recv' session
+ and media-level SDP [RFC4566] attributes. The following is their
+ Augmented Backus-Naur Form (ABNF) [RFC5234] syntax, which is based on
+ the SDP [RFC4566] grammar:
+
+ attribute =/ qos-mech-send-attr
+ attribute =/ qos-mech-recv-attr
+
+ qos-mech-send-attr = "qos-mech-send" ":"
+ [[SP] qos-mech *(SP qos-mech)]
+ qos-mech-recv-attr = "qos-mech-recv" ":"
+ [[SP] qos-mech *(SP qos-mech)]
+
+ qos-mech = "rsvp" / "nsis" / extension-mech
+ extension-mech = token
+
+
+
+Polk, et al. Standards Track [Page 3]
+
+RFC 5432 QoS Mechanism Selection in SDP March 2009
+
+
+ The 'qos-mech' token identifies a QoS mechanism that is supported by
+ the entity generating the session description. A token that appears
+ in a 'qos-mech-send' attribute identifies a QoS mechanism that can be
+ used to reserve resources for traffic sent by the entity generating
+ the session description. A token that appears in a 'qos-mech-recv'
+ attribute identifies a QoS mechanism that can be used to reserve
+ resources for traffic received by the entity generating the session
+ 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 'qos-mech-send' and
+ 'qos-mech-recv' attributes:
+
+ m=audio 50000 RTP/AVP 0
+ a=qos-mech-send: rsvp nsis
+ a=qos-mech-recv: rsvp nsis
+
+4. Offer/Answer Behavior
+
+ Through the use of the 'qos-mech-send' and 'qos-mech-recv'
+ attributes, an offer/answer exchange allows endpoints to come up with
+ a list of common QoS mechanisms sorted by preference. However, note
+ that endpoints negotiate in which direction QoS is needed using other
+ mechanisms, such as preconditions [RFC3312]. 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).
+
+4.1. Offerer Behavior
+
+ Offerers include a 'qos-mech-send' attribute with the tokens
+ corresponding to the QoS mechanisms (in order of preference) that are
+ supported in the send direction. Similarly, offerers include a
+ 'qos-mech-recv' attribute with the tokens corresponding to the QoS
+ mechanisms (in order of preference) that are supported in the receive
+ direction.
+
+4.2. Answerer Behavior
+
+ On receiving an offer with a set of tokens in a 'qos-mech-send'
+ attribute, the answerer takes those tokens corresponding to QoS
+ mechanisms that it supports in the receive direction and includes
+ them, in order of preference, in a 'qos-mech-recv' attribute in the
+ answer. On receiving an offer with a set of tokens in a 'qos-mech-
+ recv' attribute, the answerer takes those tokens corresponding to QoS
+ mechanisms that it supports in the send direction and includes them,
+ in order of preference, in a 'qos-mech-send' attribute in the answer.
+
+
+
+Polk, et al. Standards Track [Page 4]
+
+RFC 5432 QoS Mechanism Selection in SDP March 2009
+
+
+ When ordering the tokens in a 'qos-mech-send' or a 'qos-mech-recv'
+ attribute by preference, the answerer may take into account its own
+ preferences and those expressed in the offer. However, the exact
+ algorithm to be used to order such token lists is outside the scope
+ of this specification.
+
+ Note that if the answerer does not have any QoS mechanism in common
+ with the offerer, it will return empty 'qos-mech-send' and 'qos-mech-
+ recv' attributes.
+
+4.3. Resource Reservation
+
+ Once the offer/answer exchange completes, both offerer and answerer
+ use the token lists in the 'qos-mech-send' and 'qos-mech-recv'
+ attributes of the answer to perform resource reservations. Offerers
+ and answerers SHOULD attempt to use the QoS mechanism with highest
+ priority in each direction first. If an endpoint (the offerer or the
+ answerer) does not succeed in using the mechanism with highest
+ priority in a given direction, it SHOULD attempt to use the next QoS
+ mechanism in order of priority in that direction, and so on.
+
+ If an endpoint unsuccessfully tries all the common QoS mechanisms for
+ a given direction, the endpoint MAY attempt to use additional QoS
+ mechanisms not supported by the remote endpoint. This is because
+ there may be network entities out of the endpoint's control (e.g., an
+ 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 upon 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
+
+ The following is an offer/answer exchange between two endpoints using
+ the 'qos-mech-send' and 'qos-mech-recv' attributes. Parts of the
+ session descriptions are omitted for clarity purposes.
+
+ The offerer generates the following session description, listing both
+ RSVP and NSIS for both directions. The offerer would prefer to use
+ RSVP and, thus, includes it before NSIS.
+
+
+
+
+
+Polk, et al. Standards Track [Page 5]
+
+RFC 5432 QoS Mechanism Selection in SDP March 2009
+
+
+ m=audio 50000 RTP/AVP 0
+ a=qos-mech-send: rsvp nsis
+ a=qos-mech-recv: rsvp nsis
+
+ The answerer supports NSIS in both directions, but not RSVP.
+ Consequently, it returns the following session description:
+
+ m=audio 55000 RTP/AVP 0
+ a=qos-mech-send: nsis
+ a=qos-mech-recv: nsis
+
+6. IANA Considerations
+
+ This specification registers two new SDP attributes and creates a new
+ registry for QoS mechanisms.
+
+6.1. Registration of the SDP 'qos-mech-send' Attribute
+
+ IANA has registered the following SDP att-field under the Session
+ Description Protocol (SDP) Parameters registry:
+
+ Contact name: Gonzalo.Camarillo@ericsson.com
+
+ Attribute name: qos-mech-send
+
+ Long-form attribute name: QoS Mechanism for the Send Direction
+
+ Type of attribute: Session and Media levels
+
+ Subject to charset: No
+
+ Purpose of attribute: To list QoS mechanisms supported in the send
+ direction
+
+ Allowed attribute values: IANA Registered Tokens
+
+6.2. Registration of the SDP 'qos-mech-recv' Attribute
+
+ IANA has registered the following SDP att-field under the Session
+ Description Protocol (SDP) Parameters registry:
+
+ Contact name: Gonzalo.Camarillo@ericsson.com
+
+ Attribute name: qos-mech-recv
+
+ Long-form attribute name: QoS Mechanism for the Receive Direction
+
+ Type of attribute: Session and Media levels
+
+
+
+Polk, et al. Standards Track [Page 6]
+
+RFC 5432 QoS Mechanism Selection in SDP March 2009
+
+
+ Subject to charset: No
+
+ Purpose of attribute: To list QoS mechanisms supported in the
+ receive direction
+
+ Allowed attribute values: IANA Registered Tokens
+
+6.3. Registry for QoS Mechanism Tokens
+
+ The IANA has created a subregistry for QoS mechanism token values to
+ be used in the 'qos-mech-send' and 'qos-mech-recv' attributes under
+ the Session Description Protocol (SDP) Parameters registry. The
+ initial values for the subregistry are as follows:
+
+ QoS Mechanism Reference
+ ---------------------------- ---------
+ rsvp RFC 5432
+ nsis RFC 5432
+
+ As per the terminology in [RFC5226], the registration policy for new
+ QoS mechanism token values shall be 'Specification Required'.
+
+7. Security Considerations
+
+ An attacker may attempt to add, modify, or remove 'qos-mech-send' and
+ 'qos-mech-recv' attributes from a session description. This could
+ result in an application behaving in a non-desirable way. For
+ example, the endpoints under attack may not be able to find a common
+ QoS mechanism to use.
+
+ Consequently, it is strongly RECOMMENDED that integrity and
+ authenticity protection be applied to SDP session descriptions
+ carrying these attributes. For session descriptions carried in SIP
+ [RFC3261], S/MIME [RFC3851] is the natural choice to provide such
+ end-to-end integrity protection, as described in [RFC3261]. Other
+ applications MAY use a different form of integrity protection.
+
+8. Acknowledgements
+
+ Dave Oran helped form this effort. Flemming Andreasen and Magnus
+ Westerlund provided useful comments on this specification.
+
+
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 7]
+
+RFC 5432 QoS Mechanism Selection in SDP March 2009
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+ with Session Description Protocol (SDP)", RFC 3264, June
+ 2002.
+
+ [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Message Specification",
+ RFC 3851, July 2004.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ 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., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234, January
+ 2008.
+
+9.2. Informative References
+
+ [QoS-NSLP] Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
+ Quality-of-Service Signaling", Work in Progress, February
+ 2008.
+
+ [RFC2205] Braden, R., Ed., 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., Ed., Marshall, W., Ed., and J. Rosenberg,
+ "Integration of Resource Management and Session Initiation
+ Protocol (SIP)", RFC 3312, October 2002.
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 8]
+
+RFC 5432 QoS Mechanism Selection in SDP March 2009
+
+
+Authors' Addresses
+
+ James 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 9]
+