From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5432.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc5432.txt (limited to 'doc/rfc/rfc5432.txt') 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] + -- cgit v1.2.3