MMUSIC Working Group James Polk Internet-Draft Cisco Systems Expires: Sept 5th, 2007 Mar 5th, 2007 Intended Status: Standards Track Configuring the Differentiated Services Codepoint of Session Description Protocol Established Media Streams draft-polk-mmusic-dscp-attribute-01 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 5th, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The offer/answer model for SDP currently is without a mechanism for dynamic 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 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 Mar 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. SDP Attributes Definition . . . . . . . . . . . . . . . . . . 4 3. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 5 3.1 Offerer Behavior . . . . . . . . . . . . . . . . . . . . . 6 3.2 Answerer Behavior . . . . . . . . . . . . . . . . . . . . . 6 4. Changing the 'dscp' Attribute in an Established Session . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1 Registration of the SDP 'dscp' Attribute . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1 Normative References . . . . . . . . . . . . . . . . . . 9 9.2 Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 1. Introduction The Session Description Protocol (SDP) [RFC4566] currently is neutral with respect to indicating any domain per hop behaviors (PHB) that exist for a session, and therefore any layer 3 indications which 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 (B2BUA) [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 description within an offer [RFC3264], possibly with each stream needing to use a different DSCP. Thus, it seems 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. This document addresses this lack of ability - in SDP. 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). See RFC 4594 [RFC4594] for IETF guidelines of this. There are times and environments in which the DSCP for a voice session will be different than other voice sessions Polk Expires April 2007 [Page 2] Internet-Draft Stream DSCP Configuration in SDP Mar 2007 from a particular endpoint. See [ID-EF-ADMIT], which describes/creates a new Expedited Forwarding DSCP for mission critical communicates. 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 decide which DSCP, and ultimately which PHB, a media stream is to have within an environment (i.e. within a domain). [ID-EF-ADMIT] dynamically assigns a new DSCP to a voice call once the network has admitted this call's importance - perhaps to provide this session with elevated treatment, or an indication how these packets are placed into which MPLS tunnel. This elevated treatment can be achieved on a per interface basis, if a router is configured to schedule/police this traffic differently than other RTP. Thinking of SIP as a transport of SDP for a moment, SIP message routing servers are called proxy servers. 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. These servers are typically are session/dialog stateful (i.e. all messages within a dialog pass through that server instance). There is the Session Border Controller (SBC) form of SIP server, 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 receiving UA, in each direction. SBCs are typically at a network/domain boundary, meaning these devices are SIP and SDP aware, and are a relay point of RTP between source and destination UAs. 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. This extension is not useful in all environments, but more likely to be found in more controlled environments where a network administrator wants to have granular control of stream treatments. An example of this may be a service provider wants to grant its customers greater service than roaming endpoints into that network. Knowing that DSCPs can be reset at each router or border, within a network, that administrator can provide differentiated treatment even within RTP streams from the endpoint to the network boundary. Polk Expires April 2007 [Page 3] Internet-Draft Stream DSCP Configuration in SDP Mar 2007 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-pair) dscp-value-pair = dscp-value-rtp "/" dscp-value-rtcp dscp-value-rtp = numeric-sting / alpha-string dscp-value-rtcp = numeric-sting / alpha-string numeric-sting = 0-63 (range) alpha-string = token The dscp-value-pair is the combination of the DSCP for RTP and the DSCP value of RTCP. The dscp-value-rtcp is an optional entry here for when there is a DSCP assigned to the RTCP for a stream. 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]. An empty "a=dscp" attribute, with no value (numeric or alpha) MAY be present in an offer or answer to indicate support for this extension in SDP. Polk Expires April 2007 [Page 4] Internet-Draft Stream DSCP Configuration in SDP Mar 2007 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 Dialog Stateful Bob | Intermediary | | Offer | | |----------------->| Offer | | | a=dscp 46/16 | | |------------------>| | | Answer | | | a=dscp 46/16 | | Answer |<------------------| | a=dscp 46/16 | | |<-----------------| | | | | | 2-way RTP (DSCP=46 or EF) | |<====================================>| | | | Figure 1. Diagram with B2BUA setting initial DSCPs 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/16 The above "a=" line would set the media packets for this stream to Expedited Forwarding (EF) as defined by [RFC3246]. The RTCP packets would be set to CS2 (16), or the OAM class according to [RFC4594]. 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/16 thereby setting this media stream to what is considered Best Effort Polk Expires April 2007 [Page 5] Internet-Draft Stream DSCP Configuration in SDP Mar 2007 PHB, but not changing the DSCP of the RTCP. 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. An offerer MAY include a 'dscp' attribute in a offer for the purposes of indicating which level of support or service the offerer wants this session to have. Consider the case in which a customer (the offerer) has a contract with a network that allows multiple service levels, fr example a gold/silver/bronze package. An offerer MAY include this "a=dscp " attribute to indicate which service level this session is desired to achieve. This allows Alice to offer to Bob one of three different service levels of RTP to Bob, with the 5-tuple being the same for each of the sessions. 3.2 Answerer Behavior An answerer supporting this extension 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. Alice Dialog Stateful Bob | Intermediary | | | | | 2-way RTP (dscp=46 or EF) | | established | |<====================================>| | | | | Offer | Offer | | a=dscp 41 | a=dscp 41 | Polk Expires April 2007 [Page 6] Internet-Draft Stream DSCP Configuration in SDP Mar 2007 |<-----------------|------------------>| | 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 and related RTCP indication for that stream 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, as well as each related RTCP Polk Expires April 2007 [Page 7] Internet-Draft Stream DSCP Configuration in SDP Mar 2007 DSCP value Allowed attribute values: - One Decimal value in the range of 0 through 63 for DSCP of RTP, and IANA Registered Tokens (there are no tokens being registered in this document) - One Decimal value in the range of 0 through 63 for DSCP of RTCP, and IANA Registered Tokens (there are no tokens being registered in this document) Reference: This document (if published) 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. Open Issues Here is a list of known open issues understood to the author as needing to be addressed: #1 - Is there a need for a direction tag, allowing the session to be established with one DSCP in one direction and another in the opposite direction. The author is asking for a use-case for this, and how strong this function is desired (i.e. nice-to- have, really-want-this, showstopper-without-it). 8. Acknowledgements Kevin McMenamy and Subha Dhesikan helped form/focus this effort. As well as to Scott Brim for reviewing it. Thanks to Dan Wing, Shida Schubert, Francois Audet, Martin Dolly, and Janet Gunn for helpful comments, recommendations and support for this effort. 9. References Polk Expires April 2007 [Page 8] Internet-Draft Stream DSCP Configuration in SDP Mar 2007 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. [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with Session Description Protocol", RFC 3264, June 2002 [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for Diffserv Service Classes", RFC4594, August 2006 [ID-EF-ADMIT] F. Baker, J. Polk, M. Dolly, "An EF DSCP for Capacity- Admitted Traffic", draft-ietf-tsvwg-admitted-realtime-dscp- 00, "work in progress", December 06 [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 Polk Expires April 2007 [Page 9] Internet-Draft Stream DSCP Configuration in SDP Mar 2007 Email: jmpolk@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Polk Expires April 2007 [Page 10]