Network WG James Polk Internet-Draft Subha Dhesikan Expires: April 18, 2011 Cisco Systems Intended Status: Standards Track (PS) October 18, 2010 The Session Description Protocol (SDP) 'servclass' Attribute draft-polk-mmusic-traffic-class-for-sdp-00 Abstract This document proposes a new Session Description Protocol (SDP) attribute line to identify the traffic class a session is requesting in its offer/answer exchange. This document uses previously defined traffic class strings for consistency between IETF documents. Legal This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 18, 2011. Polk & Dhesikan Expires April 18, 2011 [Page 1] Internet-Draft SDP servclass Attribute Oct 2010 Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. SDP Attribute Definition . . . . . . . . . . . . . . . . . . 5 3. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 5 3.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 6 3.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 6 4. Are Additional Tags Required? . . . . . . . . . . . . . . . . 7 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 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 RFC 2119 [RFC2119]. 1. Introduction The Session Description Protocol (SDP) [RFC4566] provides a means for an offerer to describe the specifics of a session to an answerer, and for the answerer to respond back to the offerer. These specifics include offering the codec or codecs to choose from, the specific IP address and port number the offerer wants to receive the RTP stream(s) on/at, the particulars about the codecs the offerer wants considered or mandated, and so on. There are many facets within SDP to determine the Real-time Transport Protocol (RTP) [RFC3550] specifics established between one Polk & Dhesikan Expires April 18, 2011 [Page 2] Internet-Draft SDP servclass Attribute Oct 2010 or more endpoints, but identifying how the underlying network should process each stream still remains under-defined. RFC 4594 [RFC4594] established a guideline for classifying the various flows in the network and the Differentiated Services Codepoints (DSCP) that apply to many traffic types, including RTP based voice and video traffic sessions. It also defines the per hop network behavior that is strongly suggested for each of these application traffic types. When looking at RTP from a voice and video standpoint, merely separating RTP into either voice or video is not as granular as is needed, as demonstrated by Differentiated Services Codepoint guidelines in RFC 4594 [RFC4594]. Within that document, there are 4 distinct video traffic classifications of RTP: - The Broadcast video (which is to use the CS5 per hop marking) - The Real-time Interactive (which is to use the CS4 per hop marking) - The Multimedia Conferencing (per hop marking AF4x per hop marking) - The Multimedia Streaming (per hop marking AF3x per hop marking) In addition, there are 2 voice classes: - The VOIP class (per hop marking EF per hop marking). - the Voice-Admit (per hop marking Voice-Admit per hop marking) from RFC 5865 [RFC5865] The DSCP recommendations from RFC 4594 create a traffic classification, i.e., a Class of Service (COS) for each different type of traffic type, at least for those that are specified within that RFC. Looking at those traffic types carried in RTP, as sessions established by SDP, an indication is necessary within the offer/answer exchange to identify which type of traffic is being offered. This is especially true if more than one traffic type can be offered by the same offerer. Why is this needed? For several reasons listed here - to aid in the proper classification into the network, so network nodes (i.e., switches and routers) treat each RTP packet as desired/expected. - to synchronize with call control entities (i.e., middleboxes) which type of traffic is in both the offer and answer, allowing policy decisions to occur when needed. To the first point, some are looking into allocating different amounts of available capacity within routers and switches based on the type of traffic that is being sent. For example, unadmitted voice gets X% of the available interface's capacity (i.e., router or Polk & Dhesikan Expires April 18, 2011 [Page 3] Internet-Draft SDP servclass Attribute Oct 2010 switch port), desktop video (what RFC 4594 calls 'multimedia conferencing') can get up to Y% of an interface's capacity and Telepresence video (what RFC 4594 calls Real-time Interactive) can have Z% of an interface's capacity. The offerer and answerer, with or without middleboxes, coordinate how to mark each traffic type. Network configuration determines how much of each traffic type get access to what percentage of each interface. Networks that do not wish to allocate bandwidth availability to one traffic type verses another can always us best effort markings. Those that want to differentiate traffic types, and make sure one traffic type does not starve out another (or all other) traffic type(s) use (at least) differentiated services as the indication to accomplish this. Within a network core, where only MPLS is used, Diffserv obviously does not apply. That said, Diffserv can be used to mark traffic into MPLS tunnels [RFC4124]. The idea of traffic - or service - identification is not new; it has been defined in [RFC5897]. If that RFC is used as a guideline, identification that leads to stream differentiation can be quite useful. One of the points within RFC 5897 is that users cannot be allowed to assign any identification (fraud is but one reason given). In addition, RFC 5897 recommends that service identification should be done in signaling, rather than guessing or deep packet inspection. The network will have to currently guess or perform deep packet inspection to classify and offer the service as per RFC 4594 since such service identification information is currently not available in SDP and therefore to the network elements. Since SDP understands how each stream is created (i.e., the particulars of the RTP stream), this is the right place to have this service differentiated. Such service differentiation can then be communicated to and leveraged by the network. [Editor's Note: the words "traffic" and "service" are similar enough that the above paragraph talks about RFC 5897's "service identification", but this document is only wanting to discuss and propose traffic indications in SDP.] This document proposes how SDP [RFC4566] uniquely identifies which Application class - as a traffic type - a stream is for network handling and policy purposes. This can also be leveraged for call signaling policies such as acceptance or rejection, authorization of a certain type of application by call controlling entities, and synchronization with lower layers for network handling. This document proposes a simple attribute line to identify the application a session is requesting in its offer/answer exchange. This document uses previously defined service class strings for consistency between IETF documents. Polk & Dhesikan Expires April 18, 2011 [Page 4] Internet-Draft SDP servclass Attribute Oct 2010 2. SDP Attribute Definition This document proposes the 'trafficclass' session and media-level SDP [RFC4566] attribute. The following is their Augmented Backus-Naur Form (ABNF) [RFC5234] syntax, which is based on the SDP [RFC4566] grammar: attribute =/ traffic-classification traffic-classification = "trafficclass" ":" [SP] app-type app-type = "Broadcast video" / "Real-time Interactive" / "Multimedia Conferencing" / "Multimedia Streaming" / "VoIP" / "Voice-Admit" / extension-mech extension-mech = token The attribute is named "trafficclass", for traffic classification, identifying which one of the six traffic classes listed above applies to the media stream. The traffic classes defined in this document for SDP align with the application labels introduced by table 3 of RFC 4594. RFC 5685 updates the guidelines set forth in RFC 4594 by creating a new voice classification where call admission control (CAC) has been applied. So, there are four video classifications and two voice classifications - Broadcast video - Real-time Interactive - Multimedia Conferencing - Multimedia Streaming - VoIP - Voice-Admit The attribute is named "trafficclass", for traffic classification. The following is an example of an 'm' line with a 'trafficclass' attribute: m=audio 50000 RTP/AVP 0 a=trafficclass multimedia conferencing The above indicates a desktop video type of session. 3.0 Offer/Answer Behavior Polk & Dhesikan Expires April 18, 2011 [Page 5] Internet-Draft SDP servclass Attribute Oct 2010 Through the inclusion of the 'trafficclass' attribute, an offer/answer exchange identifies the application type for use by endpoints within a session. Policy elements can use this attribute to determine the acceptability and/or treatment of that session through lower layers. One specific use-case is for setting of the DSCP specific for that application type (say Broadcast Video instead of Real-time Interactive video), decided on a per domain basis - instead of exclusively by the offering domain. 3.1 Offer Behavior Offerers include the 'trafficclass' attribute with a single well known token (from list in Section 2) to obtain configurable and predictable treatment between the answerer and the offerer. It can also instead include a private token within a single domain (e.g., enterprise networks). Offerers of this 'trafficclass' attribute MUST NOT change the token in transit (e.g., wrt to B2BUAs). SBCs at domain boundaries can change this attribute through local policy. Offers containing a 'trafficclass' token not understood are ignored by default (i.e., as if there was no 'trafficclass' attribute in the Offer). 3.2 Answer Behavior Upon receiving an offer containing a 'trafficclass' attribute, if the offer is accepted, the answerer will use this attribute to set the session or media (level) traffic accordingly towards the offerer. The answerer will answer the offer with its own 'trafficclass' attribute, which will likely be the same value, although this is not mandatory (at this time). The answerer should expect to receive RTP packets marked as indicated by its 'trafficclass' attribute in the answer itself. An Answer MAY have a 'trafficclass' attribute when one was not in the offer. This will at least aid the local domain, and perhaps each domain the session transits, to categorize the application type of this RTP session. Answerers that are middleboxes can use the 'trafficclass' attribute to classify the RTP traffic within this session however local policy determines. In other words, this attribute can help in deciding which DSCP an RTP stream is assigned within a domain, if the answerer were an inbound SBC to a domain. Polk & Dhesikan Expires April 18, 2011 [Page 6] Internet-Draft SDP servclass Attribute Oct 2010 4. Are Additional Tags Required? The authors have already discounted (or dropped) two tags to this "a=trafficclass" line (the optional/mandatory tag and the sendonly/recvonly/sendrecv tag), but are considering another tag for 'desired bidirectional or symmetric'. 4.1 Is the "trafficclass" 'desired bidirectional or symmetric'? Should the offerer be able to indicate that it believes the session's traffic classification be the same in both directions? a=servclass real-time interactive des-bidirectional (or symmetric) [Editor's Note: The authors are not sure if this parameter works in all (or most) situations. We would like feedback on scenarios in which this should be included.] 5. Security considerations RFC 5897 [RFC5897] discusses many of the pitfalls of service classification, which is similar enough to this idea of traffic classification to apply here as well. That document highly recommends the user not being able to set any classification. Barring a hack within an endpoint (i.e., to intentionally mis-classifying (i.e., lying) about which classification an RTP stream is), this document's solution makes the classification part of the signaling between endpoints, which is recommended by RFC 5897. 6. IANA considerations 6.1 Registration of the SDP 'trafficclass' Attribute This document requests IANA to register the following SDP att-field under the Session Description Protocol (SDP) Parameters registry: Contact name: jmpolk@cisco.com Attribute name: trafficclass Long-form attribute name: Traffic Classification Type of attribute: Session and Media levels Subject to charset: No Purpose of attribute: To indicate the Traffic Classification Polk & Dhesikan Expires April 18, 2011 [Page 7] Internet-Draft SDP servclass Attribute Oct 2010 application for this session Allowed attribute values: IANA Registered Tokens Registration Procedures: Specification Required Type SDP Name Reference ---- ------------------ --------- att-field (both session and media level) trafficclass [this document] 6.2 The Service Classification Application Registration This document requests IANA to create a new registry for the application service classes similar to the following table within the Session Description Protocol (SDP) Parameters registry: Registry Name: "trafficclass" SDP Attribute Values Reference: [this document] Registration Procedures: Specification Required Attribute Values Reference ---------------- --------- Broadcast video [this document] Real-time Interactive [this document] Multimedia Conferencing [this document] Multimedia Streaming [this document] VoIP [this document] Voice-Admit [this document] 7. Acknowledgments To Dave Oran for his comments and suggestions. 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code Polk & Dhesikan Expires April 18, 2011 [Page 8] Internet-Draft SDP servclass Attribute Oct 2010 Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010 [RFC5897] J. Rosenberg, "Identification of Communications Services in the Session Initiation Protocol (SIP)", RFC 5897, June 2010 [RFC4124] F. Le Faucheur, Ed., " Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering ", RFC 4124, June 2005 8.2. Informative References [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for Diffserv Service Classes", RFC 4594, August 2006 Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Subha Dhesikan 170 W Tasman St San Jose, CA, USA +1.408-902-3351 mailto: sdhesika@cisco.com Polk & Dhesikan Expires April 18, 2011 [Page 9]