[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 draft-ietf-mmusic-traffic-class-for-sdp

Network WG                                                   James Polk
Internet-Draft                                           Subha Dhesikan
Expires: September 14, 2011                               Cisco Systems
Intended Status: Standards Track (PS)                    March 14, 2011

    The Session Description Protocol (SDP) 'trafficclass' Attribute


   This document proposes a new Session Description Protocol (SDP)
   attribute to identify the traffic class a session is requesting
   in its offer/answer exchange.


   This documents and the information contained therein are provided on

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 14, 2011.

Polk & Dhesikan      Expires September 14, 2011                [Page 1]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

Copyright Notice

   Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . .  7
       3.1 Offer Behavior  . . . . . . . . . . . . . . . . . . . . .  8
       3.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . .  8
   4.  Security considerations . . . . . . . . . . . . . . . . . . .  8
   5.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgments   . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       7.1.  Normative References  . . . . . . . . . . . . . . . . . 10
       7.2.  Informative References  . . . . . . . . . . . . . . . . 11
       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 12

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 with its specifics to
   the offerer.  These session 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

   There are many facets within SDP to determine the Real-time

Polk & Dhesikan      Expires September 14, 2011                [Page 2]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

   Transport Protocol (RTP) [RFC3550] details established between one
   or more endpoints, but identifying how the underlying network should
   process each stream still remains under-specified.

   The ability to identify a traffic flow by port number gives an
   indicate to underlying network elements treat traffic with different
   ports differently, the same or in groups the same - but different
   from other ports or groups of ports.

   Within the context of realtime communications, the labeling of an
   RTP session based on media descriptor lines as just a voice and/or
   video session is insufficient, and provides no guidelines to the
   underlying network on how to treat the traffic. A more granular
   labeling helps on several fronts to

   - inform application layer elements in the signaling path the
     intent of this session.

   - inform the network on how to treat the traffic if the network is
     configured to differentiate session treatments based on the type
     of session the RTP is, including the ability to provide call
     admission control based on the type of traffic in the network.

   - allow network monitoring/management of traffic types realtime and
     after-the-fact analysis.

   Some network operators want the ability to guarantee certain traffic
   gets a minimum amount of network bandwidth per link or through a
   series of links that perhaps makes up a network such as a campus or
   WAN, or a backbone. For example, a call center voice application
   gets at least 20% of a link as a minimum bandwidth.

   Some network operators want the ability to allow certain users or
   devices access to greater bandwidth during non-busy hours, than
   during busy hours of the day. For example, all desktop video to
   operate at 1080p during non-peak times, but curtail a similar
   session between the same users or devices to 720p or 360p during
   peak hours.  This case is not as clear as accepting or denying
   similar sessions during different times of the day, but tuning the
   access to the bandwidth based on the type of session. In other
   words, tune down the bandwidth for desktop video during peak hours
   to allow a 3-screen telepresense session that would otherwise look
   like the same type of traffic (RTP, and more granular, video).

   RFC 4594 established a guideline for classifying the various flows
   in the network and the Differentiated Services Codepoints (DSCP)
   that apply to many traffic types (table 3 of [RFC4594]), including
   RTP based voice and video traffic sessions. The RFC also defines the
   per hop network behavior that is strongly encouraged for each of
   these application traffic types.

   Video was broken down into 4 categories in that RFC, and voice into

Polk & Dhesikan      Expires September 14, 2011                [Page 3]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

   another single category.  We do not believe this satisfies the
   technical and business requirements to accomplish sufficiently
   unique labeling of RTP traffic.

   A question arises about once we properly label the traffic, what
   does that get us?  This is a fair question, but out of scope for
   this document because that answer lies within other RFCs and IDs in
   other WGs and/or Areas (specifically the Transport Area).  That
   said, we can discuss some of the ideas here for completeness.

   If the application becomes aware of traffic labeling,

   - this can be coded into layer 3 mechanisms.

   - this can be coded into layer 4 protocols and/or mechanisms.

   - this can be coded into a combination of mechanisms and protocols.

   The layer 3 mechanism for differentiating traffic is either the port
   number or the Differentiated Services Codepoint (DSCP) value
   [RFC2474]. Within the public Internet, if the application is not
   part of a managed service, the DSCP likely will be best effort (BE).
   Within the corporate LAN, this is usually completely configurable
   and a local IT department can take full advantage of this labeling
   to shape and manage their network as they see fit. Communications
   between enterprise networks will likely have to take advantage of

   Within a network core, where only MPLS is used, Diffserv typically
   does not apply. That said, Diffserv can be used to identify which
   traffic goes into which MPLS tunnels [RFC4124].

   Labeling realtime traffic types using a layer 4 protocol would
   likely mean RSVP [RFC2205] or NSIS [RFC4080]. RSVP has a Application
   Identifier (app-ID) defined in [RFC2872] that provides a means for
   carrying a traffic class label along the data path.  An advantage
   with this mechanism is for the label to inform each domain along the
   media path what type of traffic this traffic flow is, and allow
   each domain to adjust the appropriate DSCP (set by each domain for
   use within that domain). Meaning, if a DSCP is set by an endpoint or
   a router in the first domain and gets reset by a SP, the far end
   domain will be able to reset the DSCP to the intended traffic class.
   There is a proposed extension to RSVP which creates individual
   profiles for what goes into each app-ID field to describe these
   traffic classes [ID-RSVP-PROF], which will take advantage of what is
   described in this document.

   There are several proprietary mechanisms to take advantage of this
   labeling, but none of those will be discussed here.

   The idea of traffic - or service - identification is not new; it has
   been described in [RFC5897]. If that RFC is used as a guideline,

Polk & Dhesikan      Expires September 14, 2011                [Page 4]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

   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 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.

2. SDP Attribute Definition

   This document proposes the 'trafficclass' session and media-level
   SDP [RFC4566] attribute.  The following is the Augmented
   Backus-Naur Form (ABNF) [RFC5234] syntax for this attribute, which
   is based on the SDP [RFC4566] grammar:

      attribute               =/ traffic-classification

      traffic-classification  = "trafficclass" ":" [SP] app-type
                                  *( add-param )

      app-type                = "Broadcast-video" /
                                "Realtime-Interactive" /
                                "Multimedia-Conferencing" /
                                "Multimedia-Streaming" /
                                "Telephony" /  "Voice-Admit" /
                                "unknown" / extension-mech

      extension-mech          = token

      add-param               = "." sub-app-type / "." cac-class

      sub-app-type            = "telepresence" / "immersive" /
                                "desktop" / "personal" /"webex" /
                                "call center" / "trading floor" /

Polk & Dhesikan      Expires September 14, 2011                [Page 5]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

                                "handheld" / generic-param ; from

      cac-class               = "admitted" / "non-admitted"

   The attribute is named "trafficclass", for traffic classification,
   identifying which one of the six traffic classes applies to the
   media stream. There MUST NOT be more than one trafficclass attribute
   per media line. Confusion would result in where more than one exists
   per m= line.

   The application type traffic classes defined in this document for
   SDP are an augmented version of the application labels introduced by
   table 3 of RFC 4594.  RFC 5685 updated the guidelines set forth in
   RFC 4594 by creating a new voice classification where call admission
   control (CAC) has been applied. There are four video classifications
   and two voice classifications

   - Broadcast-video
   - Realtime-Interactive
   - Multimedia-Conferencing
   - Multimedia-Streaming
   - Telephony
   - Voice-Admit
   - unknown

   The "unknown" application type is for the scenario in which the
   application type is not known, but the sub-application type is.

   The application types (app-type) can be further subdivided into
   sub-application types with the sub-app-type identifiers for more
   granular application distinction of the traffic. Sub-application
   types are separated from traffic class by a "." if any are present
   in an instance of this attribute. One or more sub-app-types MAY be
   present in the trafficclass attribute. There MUST NOT be more than
   one application type in a single instance of the trafficclass
   attribute. If there is a sub-application type, there MUST be an
   application type, where the "unknown" is permissible.

   This document creates the following sub-application types

   - telepresence
   - immersive
   - desktop
   - personal
   - webex
   - call center
   - trading floor
   - handheld

   In addition to, of as an alternative to one or more sub-application
   types, a cac-class value MAY be present indicating whether or not a

Polk & Dhesikan      Expires September 14, 2011                [Page 6]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

   session has had call admission control applied to it.  The following
   two values are created by this document for the cac-class value:

   - admitted
   - nonadmitted

   The default cac-class value for any trafficclass attribute is
   nonadmitted, even if not present.

   Any application, sub-application or cac-class not understood MUST be
   ignored, leaving all that is understood to be processed.

   The following is an example of media level description with a
   'trafficclass' attribute:

      m=audio 50000 RTP/AVP 112
      a=trafficclass multimedia-conferencing.telepresence.immersive.

   The above indicates a multiscreen telepresence session that has had
   call admission control applied to the traffic.

   An sub-application type does not have to be defined within this
   document or an update/extension to this document to be used. The
   'trafficclass' attribute is allowed to have one or more vendor
   specific (i.e., proprietary) sub-application types. These vendor
   specific sub-application types MUST have an underscore "_" character
   immediately after one of the "." characters in the 'trafficclass'

   The following is an example of media level description with a
   'trafficclass' attribute that has proprietary sub-application

      m=audio 50000 RTP/AVP 0
      a=trafficclass multimedia-conferencing.telepresence._foo._bar

3.0 Offer/Answer Behavior

   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.

Polk & Dhesikan      Expires September 14, 2011                [Page 7]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

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

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

   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.

4.  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

Polk & Dhesikan      Expires September 14, 2011                [Page 8]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

   of the signaling between endpoints, which is recommended by RFC

5.  IANA considerations

5.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
                           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]

5.2 The Traffic Classification Application Type Registration

   This document requests IANA to create a new registry for the
   traffic application classes similar to the following table within
   the Session Description Protocol (SDP) Parameters registry:

   Registry Name: "trafficclass" SDP Application Type 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]
   Telephony                     [this document]
   Voice-Admit                   [this document]

Polk & Dhesikan      Expires September 14, 2011                [Page 9]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

5.3 The Traffic Classification Sub-Application Type Registration

   This document requests IANA to create a new registry for the
   traffic sub-application classes similar to the following table
   within the Session Description Protocol (SDP) Parameters registry:

   Registry Name: "trafficclass" Attribute Sub-Application Type
   Reference: [this document]
   Registration Procedures: Specification Required

   Attribute Values              Reference
   ----------------              ---------
   Telepresence                  [this document]
   immersive                     [this document]
   desktop                       [this document]
   personal                      [this document]
   webex                         [this document]
   call center                   [this document]
   trading floor                 [this document]
   handheld                      [this document]

5.4 The Traffic Classification Attribute Call Admission Control Class

   This document requests IANA to create a new registry for the
   Call Admission Control Class similar to the following table within
   the Session Description Protocol (SDP) Parameters registry:

   Registry Name: "trafficclass" SDP Call Admission Control Class
                                 (cac-class) Attribute Values
   Reference: [this document]
   Registration Procedures: Specification Required

   Attribute Values              Reference
   ----------------              ---------
   Admitted                      [this document]
   Non-admitted                  [this document]

6.  Acknowledgments

   To Dave Oran, Toerless Eckert, Henry Chen, David Benham and Paul
   Jones for their comments and suggestions.

7.  References

7.1.  Normative References

Polk & Dhesikan      Expires September 14, 2011               [Page 10]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

 [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
           Point (DSCP) for Capacity-Admitted Traffic", RFC 5865,
           May 2010

 [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

 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
           "Resource ReSerVation Protocol (RSVP) -- Version 1
           Functional Specification", RFC 2205, September 1997

 [RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch,
           "Next Steps in Signaling (NSIS): Framework", RFC 4080, June

 [RFC2872] Y. Bernet, R. Pabbati, "Application and Sub Application
           Identity Policy Element for Use with RSVP", RFC 2872,
           June 2000

 [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

 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234, January 2008.

7.2.  Informative References

 [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for
           Diffserv Service Classes", RFC 4594, August 2006

 [ID-RSVP-PROF] J. Polk, S. Dhesikan, "Resource Reservation Protocol
           (RSVP) Application-ID Profiles for Voice and Video Streams",
           work in progress, Mar 2011

Polk & Dhesikan      Expires September 14, 2011               [Page 11]

Internet-Draft       SDP trafficclass Attribute                Mar 2011

Author's Addresses

   James Polk
   3913 Treemont Circle
   Colleyville, Texas, USA

   mailto: jmpolk@cisco.com

   Subha Dhesikan
   170 W Tasman St
   San Jose, CA, USA

   mailto: sdhesika@cisco.com

Polk & Dhesikan      Expires September 14, 2011               [Page 12]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/