MMUSIC Working Group James Polk Internet-Draft Cisco Systems Expires: April 16th, 2007 Oct 16th, 2006 Configuring the Differentiated Services Codepoint of Session Description Protocol Established Media Streams draft-polk-mmusic-dscp-attribute-00 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 April 16th, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The offer/answer model for SDP currently is without a mechanism for the configuration of the Differentiated Services Codepoint to use for the media streams endpoints establish. Endpoints in more controlled environments, typically bounded within a domain, require intermediary servers to notify them what specific DSCP, lending itself to a PHB, a media stream should be set to, as granular as at the media stream level when more than one stream is in a session description, or changed to, based on dynamic network conditions. Polk Expires April 2007 [Page 1] Internet-Draft Stream DSCP Configuration in SDP Oct 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SDP Attributes Definition . . . . . . . . . . . . . . . . . . 3 3. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 4 3.1 Offerer Behavior . . . . . . . . . . . . . . . . . . . . . 5 3.2 Answerer Behavior . . . . . . . . . . . . . . . . . . . . . 5 4. Changing the 'dscp' Attribute in an Established Session . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1 Registration of the SDP 'dscp' Attribute . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . 7 8.2 Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . 8 1. Introduction The offer/answer model for SDP [RFC4566] currently is neutral to any domain per hop behaviors (PHB) that exist, and therefore any layer 3 indications endpoints establish, somehow, for the media streams they establish. Differentiated Services [RFC2474] established a set of per hop behaviors indications at layer 3, called Differentiated Services Codepoints (DSCP). Endpoints in more controlled environments (with more aware intermediary servers such as SIP Back-to-Back-User-Agents [RFC3261] for example) typically have a limited, if any means of dynamically setting or altering the DSCP of established media stream packets. There is no current means in control plane signaling (including SDP) for an endpoint or intermediary server to suggest, indicate or set a DSCP of a media stream. SDP can include more than one stream within each offer [RFC3264], possibly with each stream needing to use different DSCPs per stream. Thus, it seem appropriate to provide a means of indicating what DSCP a stream is to have by a protocol that has the visibility and knowledge of each stream, as well as knowing the desired characteristics of the packet flow. In some environments, endpoints do not typically have decision making control over what DSCP a media stream is to be set to. Yet, each type of media will not necessarily always have the same DSCP marking (i.e. voice is always the same, or video is always the same - but different than voice). There are times, and environments, in which the DSCP for a voice session will be different than other voice sessions from a particular endpoint. There are times in which, from the same endpoint, the DSCP will be different based on the conditions of the network. Servers are in a better position to Polk Expires April 2007 [Page 2] Internet-Draft Stream DSCP Configuration in SDP Oct 2006 decide which DSCP, and ultimately which PHB, a media stream is to have within an environment (i.e. within a domain). Thinking of SIP as a transport of SDP for a moment, SIP message routing servers are called proxies. There are several instances of a SIP proxy. There are stateless and stateful proxies. There is a Back-to-Back-User-Agent (B2BUA) form of proxy, and there is the Session Border Controller (SBC) form, which is essentially (in SIP) a B2BUA, but typically does other functions like being a NAT, a firewall, etc. In a B2BUA arrangement, all offers terminate in the B2BUA's UAS side, and are regenerated on the UAC side. This type of server can manipulate everything within a message, including the SDP offer of a message. The SBC form of B2BUA will reset the offer's IP address(es) to the SBC's, and not to the endpoint within its domain. The SBC will relay the offer and the media stream from the sender to the UA, in each direction. SBCs are typically at a domain boundary, meaning these devices are SIP and SDP aware, and are a relay point of RTP. Creating a means in SDP to set and/or modify the DSCP for a media stream in an offer (or more than one media stream if there is more than one in that offer), coupled with a network topology of a B2BUA and SBC, allows SDP to control the DSCPs of the media streams in both directions within that same domain. This document specifies an extension to SDP for a new media level attribute to set or modify the DSCP value of a media stream, per stream within an offer and answer. 1.1 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 [RFC2119] and indicate requirement levels for compliant implementations. 2. SDP Attributes Definition This document defines the 'dscp' media-level SDP [RFC4566] attribute. The following is the ABNF syntax [RFC4234], which is based on the SDP [2] grammar: attribute = dscp dscp = "dscp" *(SP dscp-value) Polk Expires April 2007 [Page 3] Internet-Draft Stream DSCP Configuration in SDP Oct 2006 dscp-value = numeric-sting / alpha-string numeric-sting = 0-63 (range) alpha-string = token The dscp-value is a decimal form of the 6 bit DSCP field of an IP header [RFC2474]. There can be only one dscp-value in this attribute. The numeric-string is limited to within a range of decimal zero through decimal sixty-three. If used consistently throughout a domain, with consistent behavior in underlying routers, this can become a Per Domain Behavior (PDB) for the media packets throughout a domain. The following is an example of an "m=" line with a 'dscp' attribute: m=audio 50001 RTP/AVP 0 a=dscp 46 The above "a=" line would set the media packets for this stream to Expedited Forwarding (EF) as defined by [RFC3246]. 3. Offer/Answer Behavior An offer/answer exchange using the 'dscp' attribute allows endpoints provide media packets the desired DSCP through a routed infrastructure. Including the 'dscp' in an offer or answer attribute is not a negotiation. This is a presentation of a value to be used as a binary DSCP in the media packets. 2-way media packets use the same DSCP value. An offer received by a intermediary that is allowed to modify SDP, MAY do so based on local policy. In other words, an offer from an endpoint may start with one 'dscp' value when the message is sent towards the server; but may have a different, server modified 'dscp' value from that server towards the receiving endpoint. Figure 1. shows this exchange, and change in 'dscp' at the server: Alice Intermediary Bob | Offer | | |----------------->| Offer | | | a=dscp 46 | | |------------------>| | | Answer | | | a=dscp 46 | | Answer |<------------------| | a=dscp 46 | | |<-----------------| | | | | | 2-way RTP (DSCP=46 or EF) | |<====================================>| | | | Figure 1. Diagram with B2BUA setting initial DSCPs Polk Expires April 2007 [Page 4] Internet-Draft Stream DSCP Configuration in SDP Oct 2006 The following is an example of the "m=" line in Figure 1. with a 'dscp' attribute: m=audio 50001 RTP/AVP 0 a=dscp 46 The above "a=" line would set the media packets for this stream to Expedited Forwarding (EF) as defined by [RFC3246]. If, at some point during the session, an entity (for example an SBC or B2BUA in the signaling plane) wanted to change the DSCP markings of the RTP packets within this media stream, it could sent this offer (illustrated in Figure 2.) in both directions: m=audio 50001 RTP/AVP 0 a=dscp 0 thereby setting this media stream to what is considered Best Effort PHB. 3.1 Offerer Behavior An offerer MAY include a 'dscp' attribute in a offer, with its value subject to change by any intermediary allowed to modify the offer. An offerer receiving the 'dscp' attribute in an answer, per media stream included, MUST use this value in the DSCP field of the media stream packets indicated in the answer. 3.2 Answerer Behavior An answerer MUST adhere to the 'dscp' attribute in the offer if the offer in whole is acceptable to the answerer. The 'dscp' attribute of each media stream MUST be used by the answerer to set the DSCP field of the respective media stream packets from the answerer. An answerer MUST NOT delete or change the 'dscp' attribute from offer to answer (analogous to copying from offer to answer), and SHOULD NOT ignore the 'dscp' attribute of the offer when setting the respective media stream packets towards the offerer. 4. Changing the 'dscp' Attribute in an Established Session Whether or not the 'dscp' attribute was used in the initial offer/answer exchange, an intermediary allowed to generate offers can change 'dscp' attribute during a session. Maintaining compliance with Section 3 above, here in Figure 2. is one example of a 'dscp' attribute being changed for a media stream. Polk Expires April 2007 [Page 5] Internet-Draft Stream DSCP Configuration in SDP Oct 2006 Alice Intermediary Bob | | | 2-way RTP (dscp=46 or EF) | | established | |<====================================>| | | | | Offer | Offer | | a=dscp 41 | a=dscp 41 | |<-----------------|------------------>| | Answer | Answer | | a=dscp 41 | a=dscp 41 | |----------------->|<------------------| | | | 2-way RTP (DSCP=41) | |<====================================>| | | | Figure 2. Diagram with Intermediary setting initial DSCPs In Figure 2. an intermediary server sends new offers to both Alice and Bob, each with a new 'dscp' attribute of 41. This changes the marking of the media stream packets between the two endpoints. This MAY be how an IMS x-CSCF changes the DSCP of a particular session. If an SBC were between Alice and Bob, it would be a focus point of the media stream (i.e. the RTP packets would traverse the SBC just as the signaling messages do). Such a topology would ensure the media packets were marked according to domain policy for that part of the end-to-end flow. This SBC could attempt to continue into the adjacent domain with an appropriate 'dscp' attribute for the next leg of the session. 5. IANA Considerations This specification registers one new media level SDP attribute in the att-field (media level only) table. 5.1. Registration of the SDP 'dscp' Attribute This section instructs the IANA to register the following SDP att- field under the Session Description Protocol (SDP) Parameters registry: Contact name: James Polk , +1.817.271.3552 Attribute name: dscp Long-form attribute name: Mechanism for Configuring the DSCP of a Media Stream Polk Expires April 2007 [Page 6] Internet-Draft Stream DSCP Configuration in SDP Oct 2006 Type of attribute: Media level only Subject to charset: No Purpose of attribute: To configure a new DSCP for one or more (i.e. possibly each) media stream within an SDP during session establishment or session modification Allowed attribute values: One Decimal value in the range of 0 through 63, and IANA Registered Tokens (there are no tokens being registered in this document) Reference: This document (if an RFC) 6. Security Considerations An attacker may attempt to add, modify, or remove the 'dscp' attribute(s) from a session description. This could result in a media stream receiving undesirable behavior through a network. For example, the endpoints under attack may receive more or less desirable PHB. Consequently, it is strongly RECOMMENDED that integrity 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. 7. Acknowledgements Kevin McMenamy and Subha Dhesikan helped form/focus this effort. As well as to Scott Brim for reviewing it. 8. References 8.1 Normative References [RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 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. Polk Expires April 2007 [Page 7] Internet-Draft Stream DSCP Configuration in SDP Oct 2006 [RFC3246] B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 8.2 Informative References none Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Email: jmpolk@cisco.com 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 Polk Expires April 2007 [Page 8] Internet-Draft Stream DSCP Configuration in SDP Oct 2006 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 provided by the IETF Administrative Support Activity (IASA). Polk Expires April 2007 [Page 9]