MMUSIC Working Group James Polk Internet-Draft Cisco Systems Expires: Aug 23, 2008 February 23, 2008 Intended Status: Standards Track Configuring the Differentiated Services Codepoint of Session Description Protocol Established Media Streams draft-polk-mmusic-dscp-attribute-02 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 Feb 23, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Session Description Protocol (SDP) offer/answer model currently has no mechanism for dynamic configuration of the Differentiated Services Codepoints (DSCP) for the media streams endpoints establish. This document creates such a mechanism within SDP, as granular as at the media stream level where more than one stream can be in an offer/answer exchange, to set a particular DSCP for the desired Per Hop Behavior (PHB) of a media stream. This same mechanism can change a DSCP of an existing stream based on dynamic network conditions. Polk Expires Aug 2008 [Page 1] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Changes Since Last Version . . . . . . . . . . . . . . . . 3 2. SDP Attributes Definition . . . . . . . . . . . . . . . . . . 4 3. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 5 3.1 Offerer Behavior . . . . . . . . . . . . . . . . . . . . . 6 3.2 Answerer Behavior . . . . . . . . . . . . . . . . . . . . . 7 4. Changing the 'dscp' Attribute in an Established Session . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1 Registration of the SDP 'dscp' Attribute . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1 Normative References . . . . . . . . . . . . . . . . . . 11 9.2 Informative References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 Copyright and Intellectual Property Statements . . . . . . . 12 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. 1. Introduction The Session Description Protocol (SDP) [RFC4566] currently is neutral with respect to offering or modifying any domain per hop behavior (PHB) indications during session establishment or session update. Leaving this task for another mechanism to set, even if it is administratively fixed per application, such as 'voice always has the same indication', or 'video always has this other indication'. This fixed basis is undergoing a change, combining the IETF guidelines in [RFC4594] and [RFC5127] with the motivations surrounding [ID-VOICE-ADMIT], SDP becomes the logical place to solve per session indications like this. Differentiated Services [RFC2474] established a set of per hop behavior indications at layer 3, creating Differentiated Services Codepoints (DSCP) to be viewed by intermediate routers to provide packet treatment based upon these indicators. Additionally, there is no current capability in control plane signaling (aside from SDP's current inability) for an endpoint to offer, suggest, indicate or otherwise set a DSCP of a media stream; much less modify a default fixed codepoint. Example control plane signaling protocols here include SIP [RFC3261], MGCP [RFC3435] and Polk Expires Aug 2008 [Page 2] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 MEGACO [RFC3015] - which all utilize SDP for session capabilities. Further, none of these 3 signaling protocols have awareness that SDP has one or more session descriptions within a single offer. Therefore, it appears as if these signaling protocols are not suited for satisfying the requirement of per stream DSCP control. SDP has such an awareness because it can include more than one stream description within a single offer [RFC3264], possibly with each stream needing to use a different DSCP, for example, a voice and a video stream. Thus, it seems appropriate to provide the means of indicating which DSCP a stream is to have by the protocol that has the visibility and knowledge of each stream. SDP's knowledge of the desired characteristics of the packet flow provides for this. This document specifies a solution to this lack of ability - in SDP. There are times and environments in which the DSCP for a particular voice session, for example, will need to be different than other voice sessions, even from same endpoint. See [ID-VOICE-ADMIT], which describes and creates a new Expedited Forwarding DSCP (45 or 101101) for network admitted mission critical communicates. There are times in which, from the same endpoint, the DSCP of the same application (i.e., voice) will need to be different based on the conditions of the network, or the type of communication attempted. An example of usage is to provide this session with unique and/or elevated treatment, with an indication how these packets are placed into which MPLS tunnel. This elevated treatment can be achieved on a per stream basis, or for each stream with this indication if a router is configured to schedule/police this traffic differently than other real-time traffic (such as RTP). This extension will not be useful in all environments. Care needs to be taken by any domain implementing this capability to prevent misuse creating a means for unauthorized communications to achieve an elevated PHB. That said, a viable use is for a service provider who wants to grant its customers greater service than roaming endpoints into that network. This extension is for endpoint to endpoint session set-up and dynamic changes of DSCPs. 1.1 Changes Since Last Version The following are the changes since the last version of this document was produced: - removed all discussion of servers and intermediaries, including how they can initiate a change in DSCP values for any streams. - changed the ability of the answerer to change the 'dscp' attribute in the answer, and what this means Polk Expires Aug 2008 [Page 3] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 - cleaned up text - fixed nits 2. SDP Attributes Definition This document creates the 'dscp' media-level SDP [RFC4566] attribute. The following is the ABNF syntax [RFC5234], which is based on the SDP [RFC4566] grammar: attribute = dscp dscp = "dscp" *(SP dscp-value) dscp-value = dscp-value-rtp "/" dscp-value-rtcp SP direction-tag dscp-value-rtp = numeric-sting / alpha-string dscp-value-rtcp = numeric-sting / alpha-string numeric-sting = 0-63 (limited range) alpha-string = token direction-tag = sendonly / recvonly / sendrecv The dscp-value is the combination of the three parts o a dscp-value-rtp for the RTP of a session o a dscp-value-rtcp for the RTCP of a session o and a direction-tag for the DSCP of RTP The dscp-value-rtp and dscp-value-rtcp MUST each be in one of three forms, though they both do not have to be the same form in the same attribute o a decimal in the range of 0 to 63 o an alpha string with the DSCP category (i.e., EF) o or it can be a 6-bit binary sequence (i.e., 101110 for EF) The decimal range of the dscp-value-rtp and dscp-value-rtcp is limited to 0-63 because that is matching all the possible values as defined in [RFC2474] for codepoints. The alpha string is the name of the class of DSCP, compiled here. o EF or Expedited Forwarding, as defined in [RFC3246] o AF or Assure forwarding, as defined in [RFC2597] o BE or Best Effort, as defined in [RFC2474] o VOICE-ADMIT, as defined in [ID-VOICE-ADMIT] Inclusion of the dscp-value-rtcp is OPTIONAL. Lack of the presence of a dscp-value-rtcp in a 'dscp' attribute means the RTCP is to use whatever is default configured in the endpoint. If the 'dscp' attribute is present, the dscp-value-rtp MUST be Polk Expires Aug 2008 [Page 4] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 present, and the direction-tag SHOULD be present, to ensure both endpoints fully understand the DSCPs to use for a media level session. The direction-tag part of the dscp-value is to indicate which direction this codepoint is to be used in fro the dscp-value-rtp only, from the perspective of the endpoint generating this attribute. An endpoint MUST be able to indicate the bi-directional DSCP for a session. The receiver of the SDP does not have to comply with this DSCP, but SHOULD indicate which value it intends to use. This is not a negotiation. The offer can contain the sendrecv direction indicator to state what DSCP it will use and what DSCP SHOULD be indicated in the answer. If the answer does not contain a sendrecv indication, but does have a (answer SDP) of another DSCP value for RTP, then the original offer was accepted in the offer to answer direction, but the answer to offer direction will use another DSCP for RTP. If the answer did not contain a 'dscp' attribute, the offering endpoint SHOULD consider that to indicate the answerer either did no understand the 'dscp' attribute in the offer, or the it will maintain using whatever DSCP is preconfigured into that endpoint for this session. There can be only one dscp-value per media description. The following is an example of an "m=" line with a 'dscp' attribute: m=audio 50001 RTP/AVP 0 a=dscp 46/16 sendrecv The above "a=" line would set RTP packets for this stream to DSCP 46, or Expedited Forwarding (EF) as defined by [RFC3246], in both directions (provided the answerer agreed with the direction-tag of this attribute. 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. 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 indication of a value to be used as a binary DSCP in the media packets. The offerer can include a suggestion to use the same DSCP bi-directionally. The answerer's answer will indicate is this is acceptable or not. Figure 1. shows this exchange, Polk Expires Aug 2008 [Page 5] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 Alice Bob | | | Offer | | a=dscp 46/16 sendrecv | |---------------------------->| | | | Answer | | a=dscp 46/16 sendrecv | |<----------------------------| | | | 2-way RTP (DSCP=46 or EF) | |<===========================>| | | Figure 1. Diagram setting initial DSCP Values 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 sendrecv 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]. The direction-tag is set to send-recv in the offer, and accepted in the answer (because it is also indicating the same DSCP values and in both directions). If, at some point during the session, an endpoint 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 sendrecv thereby setting this media stream to what is considered Best Effort PHB, in both directions, while not changing the DSCP of the RTCP. 3.1 Offerer Behavior An offerer MUST include a 'dscp' attribute in a offer, if it wants to indicate it wants to have a particular stream have a non-default DSCP value in one or both directions. The offerer MUST set a direction-tag if it wants a non-default DSCP in one direction or another. The offerer does not have to include a direction-tag if it knows the answerer will not change the dscp-value in the answer. An offerer SHOULD NOT assume this is always the case, and be sure and include exactly what it wants. An offerer receiving an answer other than a copy of what was offered Polk Expires Aug 2008 [Page 6] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 only considers the changes to apply to what the answerer is going to do. It MUST NOT change what the offerer is going to do. There is no rejection of a stream based on what a DSCP is in a packet, so there is no ill effects from this. However, the answerer can become an offerer in an UPDATE or reINVITE (using SIP) of the same session if they do not want either endpoint using the DSCPs offered originally. Care SHOULD be taken that this does not occur over and over gain during the same session, as this event occurring more than once does not solve anything, and wastes resources. An answer that does not contain a 'dscp' attribute when there was one in the offer means the answerer does not support this extension. An offerer MAY include an empty 'dscp' attribute to indicate support for this capability. 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 '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. It is RECOMMENDED that the answerer reciprocate the 'dscp' attribute in the answer; meaning if the offer is a=dscp 46/16 sendrecv the answer SHOULD be a=dscp 46/16 sendrecv If the offer is a=dscp 46/16 sendonly and the answerer is not configured to use that DSCP, it would be either what DSCP the answerer is configured to use for its RTP packets with a sendonly direction-tag, or if it does not want to inform the offerer, it can answer like this a=dscp 46/16 recvonly Each of these cases are acceptable according to the rules here. Polk Expires Aug 2008 [Page 7] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 What is not acceptable for an answerer is to tell the offerer which DSCP the offerer should use in the initial answer. This is left for an (using SIP as an example) UPDATE or reINVITE transaction where the answerer becomes the offerer and attempts to suggest/control the DSCPs to be used for this particular media stream. An endpoint that does not support this extension merely ignores the 'dscp' attribute and answers without it. An answer that does not contain a 'dscp' attribute when there was one in the offer means the answerer does not support this extension. A DSCP of 0 (zero) is a valid DSCP, and MUST NOT be considered a null answer, and MUST only be used if the endpoint wishes to set their RTP codepoints to the "Best Effort" traffic class. An answerer that wants to go with what the offerer has offerer merely copies the 'dscp' attribute from the offer. If this is the offer a=dscp 46/16 sendrecv this is the answer a=dscp 46/16 sendrecv Inclusion of the dscp-value-rtcp is OPTIONAL in this extension. If an offerer or answerer wants to set or modify the DSCP to be used by either endpoint, this extension MUST be used to ensure consistency. With that said, discussion about copying the 'dscp' attribute from offer to answer equates supporting and accepting an offer, this does not apply to the RTCP value, which can change, and still consider the media stream 'dscp' attribute to have been accepted via a copy. [EDITOR's NOTE: does this make sense (that this extension is only sensitive to RTP codepoint values and not both?) 4. Changing the 'dscp' Attribute in an Established Session Whether or not the 'dscp' attribute was used in the initial offer/answer exchange, either endpoint is allowed to generate offers can change the 'dscp' attribute from a o null (or no DSCP value in the media packets) value, o a default uncommunicated value o or a previously communicated 'dscp' attribute to something (else) 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 Aug 2008 [Page 8] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 Alice Bob | Existing | | 2-way RTP (DSCP=46 or EF) | |<===========================>| | | | Offer | | a=dscp 0/16 sendrecv | |---------------------------->| | | | Answer | | a=dscp 0/16 sendrecv | |<----------------------------| | | | Modified | | 2-way RTP (DSCP=0 or BE) | |<===========================>| | | Figure 2. Diagram with Intermediary setting initial DSCPs In Figure 2. there is an existing session between Alice and Bob, when Alice's endpoint decides (however that occurs) to modify the DSCPs of a this stream. This process starts with an offer. Figure 2. shows an existing media stream marked as EF or 46, but Alice wants to change this to a codepoint of 0 (zero) for whatever reason. Perhaps the call was preempted and needs to be moved into a Best Effort class to maintain the call. The current DSCP being used is (perhaps as if the session was brought up as) a=dscp 46/16 sendrecv Alice's new offer is a=dscp 0/16 sendrecv If Bob answers affirmatively, this is the answer a=dscp 0/16 sendrecv This changes the marking of the media stream packets between the two endpoints. This MAY be how an IMS P- or S-CSCF modifies the DSCP of a particular session. 5. IANA Considerations This specification registers one new media level SDP attribute in the att-field (media level only) table. Polk Expires Aug 2008 [Page 9] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 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 DSCP value Allowed attribute values: - For DSCP of RTP, see Section 2. of this document for details - For DSCP of RTCP, see Section 2. of this document for details 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 a 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: Polk Expires Aug 2008 [Page 10] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 #1 - This document focuses on the RTP and RTCP DSCP markings, yet favors the RTP markings in the offer/answer exchange. Should equal weight be given to adhering to uniformity during an offer/answer exchange for RTCP markings? #2 - Not sure the ABNF is right for the look of the examples, which I believe is what is desired to convey what this extension intends. 8. Acknowledgements Kevin McMenamy and Subha Dhesikan helped form 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 9.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-VOICE-ADMIT] F. Baker, J. Polk, M. Dolly, "An EF DSCP for Capacity-Admitted Traffic", draft-ietf-tsvwg-admitted-realtime-dscp-04, "work in progress", December 07 [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 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. Polk Expires Aug 2008 [Page 11] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", RFC 5127, February 2008. 9.2 Informative References [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. [RFC3015] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000. Author's Address James Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Email: jmpolk@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Polk Expires Aug 2008 [Page 12] Internet-Draft DSCP Stream Configuration in SDP Feb 2008 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 Aug 2008 [Page 13]