The Session Description Protocol (SDP) 'trafficclass' Attribute
draft-ietf-mmusic-traffic-class-for-sdp-00

The information below is for an old version of the document
Document Type Active Internet-Draft (mmusic WG)
Authors James Polk  , Subha Dhesikan  , Paul Jones 
Last updated 2011-10-24
Stream IETF
Intended RFC status (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd None
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network WG                                                   James Polk
Internet-Draft                                           Subha Dhesikan
Expires: April 24, 2012                                      Paul Jones
Intended Status: Standards Track (PS)                     Cisco Systems
                                                       October 24, 2011

    The Session Description Protocol (SDP) 'trafficclass' Attribute
               draft-ietf-mmusic-traffic-class-for-sdp-00

Abstract

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

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 24, 2012.

Polk, et al.             Expires April 24, 2012                [Page 1]
Internet-Draft         SDP trafficclass Attribute              Oct 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.  Traffic Class Framework and String Definitions  . . . . . . .  5
   3.  Traffic Class Attribute Definition  . . . . . . . . . . . . . 11
   4.  Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 14
       4.1 Offer Behavior  . . . . . . . . . . . . . . . . . . . . . 14
       4.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 14
   5.  Security considerations . . . . . . . . . . . . . . . . . . . 16
   6.  IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgments   . . . . . . . . . . . . . . . . . . . . . . 18
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 18
       8.1.  Normative References  . . . . . . . . . . . . . . . . . 18
       8.2.  Informative References  . . . . . . . . . . . . . . . . 19
       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 20

   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 with its session 
   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 on.  

Polk, et al.             Expires April 24, 2012                [Page 2]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   There are many facets within SDP to determine the Real-time 
   Transport Protocol (RTP) [RFC3550] details for the session 
   establishment 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 
   indication to underlying network elements to treat traffic with 
   dissimilar ports in a different way, 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 based on the traffic characteristics

Polk, et al.             Expires April 24, 2012                [Page 3]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   and tolerances to delay, loss and jitter within each traffic class. 

   Video was broken down into 4 categories in that RFC, and voice into 
   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 
   MPLS.  

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

Polk, et al.             Expires April 24, 2012                [Page 4]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   The idea of traffic - or service - identification is not new; it has
   been described 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 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.

   This document modifies the traffic classes originally created in RFC
   4594 in Section 2, incrementing each class with application 
   identifiers and optional adjective strings.  Section 3 defines the 
   new SDP attribute "trafficclass". Section 4 discusses the offerer 
   and answerer behavior when generating or receiving this attribute.

2.  Traffic Class Framework and String Definitions

   The framework of the traffic class attribute will have at least two 
   parts, allowing for several more to be included. The intention is to
   have a parent class (e.g., Conversational) that merely serves as the
   anchor point for an application component that when paired together,
   form the highest level traffic class. An adjective component 
   provides further granularity for the application. 

   The traffic class label will have the following structure,

   parent.application(.adjective)(.adjective)(.admitted/non-admitted)

   [Editor's Note: the above is not exactly the ABNF to be used. 
                   The order is right. The parent and application 
                   MUST appear (each only once) and zero or more 
                   adjectives can appear.]

Polk, et al.             Expires April 24, 2012                [Page 5]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   Where 
   1) the 1st component is the human understandable category;
   2) the 2nd component is the application;
   3) an optional 3rd component or series of components are 
      adjective(s) used to further refine the application component; 
      and
   4) an optional 4th component is to classify this flow as a CAC 
      admitted or non-admitted traffic flow. The default is 
      non-admitted, whether present or not.

   The construction of the traffic class label for Telepresence video 
   would follow the form like this:

      Conversational.video.immersive 

   There is no traffic class or DSCP value associated with just 
   "Conversational".  There is a traffic class associated with 
   "Conversational.video", creating a differentiation between it and a 
   "Conversational.video.immersive" traffic class, which would have 
   DSCP associated with the latter traffic class, depending on local 
   policy. Each parent component is defined below, as are several of 
   application and adjective strings.  

   [Editor's Note: We're not yet sure how much of what's below will be 
                   proposed for IANA registration, but the 5 parent 
                   components will be, as well as at least some 
                   application components per parent component. Some 
                   adjective components will also likely be proposed 
                   for IANA registration.

   The 5 parent components of the traffic class attribute are as 
   follows:

   o Conversational
   o Multimedia Conferencing
   o Real-Time Interactive
   o Multimedia Streaming
   o Broadcast

   The following application components of the traffic class attribute 
   are as follows:

   o Audio
   o Video
   o Text
   o application-sharing
   o Presentation-data
   o Whiteboarding
   o Web (conference) chat/instant messaging
   o Gaming

Polk, et al.             Expires April 24, 2012                [Page 6]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   o Virtual-desktop (interactive)
   o Remote-desktop
   o Telemetry (e.g., NORAD missile control)
   o Multiplex (i.e., combined streams)
   o (something to cover theater quality Netflix movies)
   o (something to cover YouTube)
   o Webcast
   o IPTV
   o Live-events (though not the buffered ones)
   o surveillance

   The following adjective components of the traffic class attribute 
   are as follows:

   o Immersive
   o Desktop-video
   o Realtime-Text
   o web

   Each of the above 3 lists will be defined in the following 
   subsections.

2.1 Conversational Parent Traffic Class

   The Conversational traffic class is best suited for applications 
   that require very low delay variation and generally intended to 
   enable real-time, bi-directional person-to-person or
   multi-directional via an MTP communication, such as the following 
   application components:

   o Audio (voice)

   o Video

   o Text (i.e., real-time text required by deaf users)

   With adjective substrings to the above (which may or may not get 
   IANA registered)

   Immersive (TP) - An interactive audio-visual communications 
        experience between remote locations, where the users enjoy a 
        strong sense of realism and presence between all participants 
        by optimizing a variety of attributes such as audio and video 
        quality, eye contact, body language, spatial audio, 
        coordinated environments and natural image size.

   Desktop-video - An interactive audio-visual communication 
        experience that is not immersive in nature, though can have a 
        high resolution video component.

Polk, et al.             Expires April 24, 2012                [Page 7]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   Realtime-Text (RTT) - a term for real-time transmission of text in 
        a character-by-character fashion for use in conversational 
        services, often as a text equivalent to voice-based 
        conversational services. Conversational text is defined in the 
        ITU-T Framework for multimedia services, Recommendation F.700 
        [RFC5194].

   Web - for realtime aspects of web conferencing; mutually exclusive 
        of both Immersive and Desktop video experiences

   **The above substrings might also be used within Multimedia 
     Conferencing**

 +--------------------------------------------------------------------+
 |Traffic Class  |                               |    Tolerance to    |
 |    Name       |  Traffic Characteristics      | Loss |Delay |Jitter|
 |===============+===============================+======+======+======|
 |               | High priority, typically      | Very | Very | Very |
 |Conversational | small packets (large video    |  Low |  Low |  Low |
 |               | frames produce large packets),|      |      |      |
 |               | generally sustained high      |      |      |      |
 |               | packet rate, low inter-packet |      |      |      |
 |               | transmission interval,        |      |      |      |
 |               | usually UDP framed in (S)RTP  |      |      |      |
 +---------------+-------------------------------+------+------+------+

2.2 Multimedia-Conferencing Parent Traffic Class 

   Multimedia-Conferencing traffic class is best suited for 
   applications that are generally intended for communication between 
   human users, but are less demanding in terms of delay, packet loss, 
   and jitter than what Conversational applications require.  These 
   applications require low to medium delay and may have the ability to
   change encoding rate (rate adaptive) or transmit data at varying 
   rates, such as the following application components:

   o application-sharing (that webex does or protocols like T.128) - 
        An application that shares the output of one or more running 
        applications or the desktop on a host. This can utilize 
        vector graphics, raster graphics or video.

   o Presentation-data - can be a series of still images or motion 
        video.

   o Whiteboarding - an application enabling the exchange of graphical 
        information including images, pointers and filled and 
        unfilled parametric drawing elements (points, lines, 
        polygons and ellipses).

   o (RTP-based) file transfer

Polk, et al.             Expires April 24, 2012                [Page 8]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   o Web (conference) chat/instant messaging 

 +--------------------------------------------------------------------+
 |Traffic Class  |                               |    Tolerance to    |
 |    Name       |  Traffic Characteristics      | Loss |Delay |Jitter|
 |===============+===============================+======+======+======|
 |  Multimedia   | Variable size packets,        | Low  | Low  | Low  |
 | Conferencing  | Variable transmit interval,   |  -   |  -   |  -   |
 |               | rate adaptive, reacts to      |Medium|Medium|Medium|
 |               | loss, usually TCP-based       |      |      |      |
 +---------------+-------------------------------+------+------+------+

2.3 Realtime-Interactive Parent Traffic Class 

   Realtime-Interactive traffic class is intended for interactive 
   variable rate inelastic applications that require low jitter and 
   loss and very low delay, such as the following application 
   components:

   o Gaming - interactive player video games with other users on other 
        hosts (e.g., Doom)

   o Virtual desktop (interactive) - similar to an X-windows station, 
        has no local hard drive, or is operating an application with no
        local storage 

   o Remote Desktop - controlling a remote node with local peripherals 
        (i.e., monitor, keyboard and mouse)

   o Telemetry - a communication that allows remote measurement and 
        reporting of information (e.g., post launch missile status or 
        energy monitoring)

 +--------------------------------------------------------------------+
 |Traffic Class  |                               |    Tolerance to    |
 |    Name       |  Traffic Characteristics      | Loss |Delay |Jitter|
 |===============+===============================+======+======+======|
 |   Realtime    | Inelastic, mostly variable    | Low  | Very | Low  |
 |  Interactive  | rate, rate increases with     |      | Low  |      |
 |               | user activity                 |      |      |      |
 +---------------+-------------------------------+------+------+------+

2.4 Multimedia-Streaming Parent Traffic Class 

   Multimedia-Streaming traffic class is best suited for variable rate 
   elastic streaming media applications where a human is waiting for 
   output and where the application has the capability to react to 
   packet loss by reducing its transmission rate, such as the following
   application components:

Polk, et al.             Expires April 24, 2012                [Page 9]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   o Audio

   o Video

   o Multiplex (i.e., combined streams)

   With adjective substrings to the above (which may or may not get 
   IANA registered)

   (something to cover theater quality Netflix movies)

   (something to cover YouTube)

   Webcast

   The primary difference from the Multimedia-streaming parent class 
   and the Broadcast parent class is about the length of time for 
   buffering. Buffered streaming audio and/or video (e.g., Netflix or 
   previously-recorded videos on web sites like CNN, ESPN or from an 
   internal corporate server). Buffering here can be from seconds to 
   hours (as opposed to Broadcast buffering which is minimal). The 
   buffering aspect is what differentiates this parent class from the 
   Broadcast class (which has minimal or no buffering).

 +--------------------------------------------------------------------+
 |Traffic Class  |                               |    Tolerance to    |
 |    Name       |  Traffic Characteristics      | Loss |Delay |Jitter|
 |===============+===============================+======+======+======|
 |  Multimedia   | Variable size packets,        |Low - |Medium| High |
 |   Streaming   | elastic with variable rate    |Medium|- High|      |
 |               |                               |      |      |      |
 +---------------+-------------------------------+------+------+------+

2.5 Broadcast Parent Traffic Class

   Broadcast traffic class is best suited for inelastic streaming media
   applications that may be of constant or variable rate, requiring low
   jitter and very low packet loss, such as the following application 
   components:

   o IPTV

   o Live events (though not the buffered ones)

   o Video surveillance

Polk, et al.             Expires April 24, 2012               [Page 10]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

 +--------------------------------------------------------------------+
 |Traffic Class  |                               |    Tolerance to    |
 |    Name       |  Traffic Characteristics      | Loss |Delay |Jitter|
 |===============+===============================+======+======+======|
 |   Broadcast   | Constant and variable rate,   | Very |Low - |Low - |
 |               | inelastic, generally          | Low  |Medium|Medium|
 |               | non-bursty flows, generally   |      |      |      |
 |               | sustained high packet rate,   |      |      |      |
 |               | low inter-packet transmission |      |      |      |
 |               | interval, usually UDP framed  |      |      |      |
 |               | in (S)RTP                     |      |      |      |
 +---------------+-------------------------------+------+------+------+

3. 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] parent-class 
                                 "." app-type *( app-param )

      parent-class            = "Broadcast" / 
                                "Realtime-Interactive" / 
                                "Multimedia-Conferencing" / 
                                "Multimedia-Streaming" / 
                                "Conversational" /  
                                extension-mech

      extension-mech          = token

      app-type                = "audio" / "video" / "text" /
                                "application-sharing" /
                                "presentation-data" /
                                "whiteboarding" / "webchat/IM" /
                                "gaming" / "virtual-desktop" / 
                                "remote-desktop" / "telemetry"/
                                "multiplex" / "Netflix" / "youtube" /
                                "webcast" / "IPTV" / "live-events" /
                                "surveillance"

      app-param               = "." adjective / "." cac-class  

      adjective               = "immersive" / "desktop-video" /
                                "Realtime-Text" /"web" / 
                                 generic-param ; from RFC3261

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

Polk, et al.             Expires April 24, 2012               [Page 11]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   The attribute is named "trafficclass", for traffic classification, 
   identifying which one of the five 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 parent classes in this document are an augmented version of the 
   application labels introduced by table 3 of RFC 4595 (which will be 
   rewritten based on the updated labels and treatments expected for 
   each traffic class defined in this document).

    +-------------------------+------------------------------+
    | Application Labels      |   Parent Classes Defined     |
    | Defined in RFC 4594     |   in this document           |
    +=========================+==============================+
    | Broadcast-video         |   Broadcast                  |
    +-------------------------+------------------------------+
    | Realtime-Interactive    |   Realtime-Interactive       |
    +-------------------------+------------------------------+
    | Multimedia-Conferencing |   Multimedia-Conferencing    |
    +-------------------------+------------------------------+
    | Multimedia-Streaming    |   Multimedia-Streaming       |
    +-------------------------+------------------------------+
    | Telephony               |   Conversational             |
    +-------------------------+------------------------------+

    Table 6. Label Changes from RFC 4594 

   As is evident from the changes above, from left to right, two labels
   are different and each of the meanings are different in this 
   document relative to how RFC 4594 defined them. These differences 
   are articulated in Section 2 of this document.

   A parent class is a human understandable categorization, and MUST 
   NOT be the only part of the traffic class label present in the 
   attribute. The parent class string MUST always be paired with an 
   application type, with a "." as the string separator.

   The application types (app-type) define the application of a 
   particular traffic flow. The application types are listed both in 
   the ABNF and defined in Section 2 of this document. Not every 
   combination parent class is paired with application types, at least 
   as defined in this document. Section 2.1 through 2.5 list many of 
   the expected combinations.

   For additional application type granularity, adjective strings can 
   be added (also listed in Section 2). One or more adjectives can be 
   within the same traffic class attribute. It is also permitted to 
   include one or more non-IANA registered adjective label, but these 
   MUST be prefaced by the additional delimiter "_", creating a 
   possibility such as

Polk, et al.             Expires April 24, 2012               [Page 12]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

    parent-class.application-type.adjective._non-standard-adjective
                                          ^^^^
                                     See the underscore

   For example, this is valid:

      m=audio 50000 RTP/AVP 112
      a=trafficclass Conversational.video.immersive._foo._bar

   where both "foo" and "bar" are not IANA registered adjectives, but 
   "immersive" is IANA registered. However, including non-registered 
   adjectives without the "_" delimiter are not valid, such as the 
   following:

      m=audio 50000 RTP/AVP 112
      a=trafficclass Conversational.video.immersive.foo.bar

   There is no limit to the number of adjectives allowed, without 
   regard for whether they are registered or not. These non-registered 
   adjectives can be vendor generated, or merely considered to be 
   proprietary in nature.

   It is important to note that the order of components matters, but 
   only for the components. In other words, the parent class component 
   MUST be before the application component, which MUST be before the 
   adjective component, which MUST be before the cac-class component. 
   If there are no adjective components, the cac-class component is 
   immediately after the application component.  

   If there is more than one adjective component describing a traffic 
   class, the order of the adjectives MUST NOT matter. Some algorithm 
   such as alphabetizing the list and matching the understood strings 
   SHOULD be used.

   In addition to, or as an alternative to one or more adjectives, a 
   cac-class value MAY be present indicating whether or not a 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. There MUST NOT be more than one 
   cac-class sub-string per m=line.

   Any application, adjective or cac-class string component within this
   attribute that is not understood MUST be ignored, leaving all that 
   is understood to be processed. Ignored string components SHOULD NOT 
   be deleted, as a downstream entity could understand the component(s)
   and use it/them.

Polk, et al.             Expires April 24, 2012               [Page 13]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   Not understanding the parent class string SHOULD mean that this 
   attribute is ignored.

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

      m=audio 50000 RTP/AVP 112
      a=trafficclass conversational.video.immersive.admitted

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

4.  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 a Broadcast instead
   of a conversational video), decided on a per domain basis - 
   instead of exclusively by the offering domain.  

4.1 Offer Behavior

   Offerers include the 'trafficclass' attribute with a single well 
   string comprised of two or more components (from the list in Section 
   2) to obtain configurable and predictable classification between the 
   answerer and the offerer. The offerer can also include a private set 
   of components, or a combination of IANA registered and private 
   components within a single domain  (e.g., enterprise networks).  

   Offerers of this 'trafficclass' attribute MUST NOT change the label 
   in transit (e.g., wrt to B2BUAs).  SBCs at domain boundaries can 
   change this attribute through local policy. 

   Offers containing a 'trafficclass' label not understood are ignored 
   by default (i.e., as if there was no 'trafficclass' attribute in the
   offer).

4.2 Answer Behavior

   Upon receiving an offer containing a 'trafficclass' attribute, if 
   the offer is accepted, the answerer will use this attribute to 
   classify the session or media (level) traffic accordingly towards 
   the offerer. This answer does not need to match the traffic class in
   the offer, though this will likely be the case most of the time.

Polk, et al.             Expires April 24, 2012               [Page 14]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   In order to understand the traffic class attribute, the answerer 
   MUST check several components within the attribute, such as

   1 - does the answerer understand the parent component?

       If not, the attribute SHOULD be ignored. 

       If yes, it checks the application component.

   2 - does the answerer understand the application component?

       If not, the answerer needs to check if it has a local policy to 
       proceed without an application component. The default for this 
       situation is as if the parent component was not understand, 
       i.e., the attribute SHOULD be ignored.

       If yes, it checks there are any other component present in this 
       attribute to start its classification.

   3 - does the answerer understand the adjective component or 
       components if any are present?

       If not present, see if there is a cac-class component, and 
       before processing classification.

       If yes, determine if there are more than one. Alphabetize all of
       the adjective components and match the traffic classification. 

   4 - does the answerer understand the cac-class component if present?

       If not, consider the media flow for this m= line to be 
       nonadmitted.

       If yes, classify whether this component is CAC admitted or 
       nonadmitted.

   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

Polk, et al.             Expires April 24, 2012               [Page 15]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   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.

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

Polk, et al.             Expires April 24, 2012               [Page 16]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

   the Session Description Protocol (SDP) Parameters registry:

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

   Parent Values                 Reference
   ----------------              ---------
   Broadcast                     [this document]  
   Realtime-Interactive          [this document]  
   Multimedia-Conferencing       [this document]  
   Multimedia-Streaming          [this document]  
   Conversational                [this document]  

6.3 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" Attribute Application Type Values
   Reference: [this document]
   Registration Procedures: Specification Required 

   Application Values            Reference
   ------------------            ---------
   Audio                         [this document]  
   Video                         [this document]  
   Text                          [this document]  
   application-sharing           [this document]  
   Presentation-data             [this document]
   Whiteboarding                 [this document]
   Webchat/instant messaging     [this document]
   Gaming                        [this document]
   Virtual-desktop               [this document]
   Remote-desktop                [this document]
   Telemetry                     [this document]
   Multiplex                     [this document]
   Netflix*                      [this document]
   YouTube*                      [this document]
   Webcast                       [this document]
   IPTV                          [this document]
   Live-event                    [this document]
   surveillance                  [this document]

   [Editor's Note: these are placeholders until a more generic string 
             can be agreed to by the WG]

Polk, et al.             Expires April 24, 2012               [Page 17]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

6.4 The Traffic Classification Adjective 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" Attribute Adjective Values
   Reference: [this document]
   Registration Procedures: Specification Required 

   Application Values            Reference
   ------------------            ---------
   Immersive                     [this document]
   Desktop-video                 [this document]
   Realtime-Text                 [this document]
   web                           [this document]

6.5 The Traffic Classification Attribute Call Admission Control Class
                               Registration

   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]  

7.  Acknowledgments

   To Dave Oran, Toerless Eckert, Henry Chen, David Benham, David 
   Benham, Mo Zanty, Michael Ramalho, Glen Lavers, Charles Ganzhorn, 
   and Greg Edwards for their 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 

Polk, et al.             Expires April 24, 2012               [Page 18]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

           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 
           2005

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

8.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, et al.             Expires April 24, 2012               [Page 19]
Internet-Draft         SDP trafficclass Attribute              Oct 2011

Author's Addresses

   James Polk
   3913 Treemont Circle
   Colleyville, Texas, USA
   +1.818.271.3552

   mailto: jmpolk@cisco.com

   Subha Dhesikan
   170 W Tasman St
   San Jose, CA, USA
   +1.408-902-3351

   mailto: sdhesika@cisco.com

   Paul E. Jones

   mailto: paulej@packetizer.com

Polk, et al.             Expires April 24, 2012               [Page 20]