Network WG James Polk Internet-Draft Subha Dhesikan Expires: January 3, 2015 Paul Jones Intended Status: Standards Track (PS) Cisco Systems July 3, 2014 The Session Description Protocol (SDP) 'trafficclass' Attribute draft-ietf-mmusic-traffic-class-for-sdp-05 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 4, 2015. Copyright Notice Copyright (c) 2014 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 Simplified BSD License. Polk, et al. Expires Jan 4, 2015 [Page 1] Internet-Draft SDP trafficclass Attribute July 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Traffic Class Framework and Component Definitions . . . . . . 5 3. Traffic Class Attribute Definition . . . . . . . . . . . . . 6 3.1 Categories within the SDP Traffic Class Label . . . . . . 8 3.2 Applications within the SDP Traffic Class Label . . . . . 9 3.3 Adjectives within the SDP Traffic Class Label . . . . . . 9 3.3.1 Qualified Adjectives . . . . . . . . . . . . . . . . . 9 4. Matching Categories with Applications and Adjectives . . . . 11 4.1 Conversational Category Traffic Class . . . . . . . . . . 11 4.2 Multimedia-Conferencing Category Traffic Class . . . . . 12 4.3 Realtime-Interactive Category Traffic Class . . . . . . . 14 4.4 Multimedia-Streaming Category Traffic Class . . . . . . . 15 4.5 Broadcast Category Traffic Class . . . . . . . . . . . . 17 4.6 Intermittent Category Traffic Class . . . . . . . . . . . 18 5. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 19 5.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 20 5.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 20 6. Security considerations . . . . . . . . . . . . . . . . . . . 21 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 27 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. 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 Polk, et al. Expires Jan 4, 2015 [Page 2] Internet-Draft SDP trafficclass Attribute July 2014 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 make up a network such as a campus or WAN, or a backbone. For example, a call center voice application might get at least 20% of the available link 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 might operate at 1080p during non-peak times, but a similar session might be curtailed between the same users or devices to 720p or 360p during peak hours. Another example would be to reduce the frames per second (fps) rate, say from 30fps to 15fps. 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 Telepresence 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 Codepoint (DSCP) values that apply to many traffic types (table 3 of [RFC4594]), including RTP based voice and video traffic sessions. The RFC also defined the per hop network behavior that is strongly encouraged for each of these application traffic types based on the traffic characteristics and tolerances to delay, loss and jitter within each traffic class. Video was broken down into four categories in that RFC, and voice in another single category. We do not believe this satisfies the Polk, et al. Expires Jan 4, 2015 [Page 3] Internet-Draft SDP trafficclass Attribute July 2014 technical and business requirements to accomplish sufficiently unique labeling of RTP traffic. 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. A lower layer 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 value likely will be best effort (BE), or reset to BE, at ingress to a provider's network. 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. Within a network core, DiffServ typically does not apply. That said, DiffServ can be used to identify which traffic goes into which MPLS tunnel [RFC4124]. Labeling realtime traffic types using a layer 4 protocol would likely involve 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 media path. An advantage of this mechanism is that the label can inform each domain along the media path what type of traffic this traffic flow is, and allow each domain to adjust the appropriate DSCP value (set by each domain for use within that domain). Meaning, if a DSCP value is set by an endpoint or a router in the first domain and gets reset by a service provider, the far-end domain will be able to reset the DSCP value appropriate for 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 that can 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, 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 one reason given). In addition, RFC 5897 recommends that service identification should be done in signaling, rather than guessing or deep packet inspection. Currently, any network would have to guess or perform deep packet inspection to classify traffic and offer the service as per Polk, et al. Expires Jan 4, 2015 [Page 4] Internet-Draft SDP trafficclass Attribute July 2014 RFC 4594 as 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 only discusses and proposes 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 utilizes the traffic classes originally created in RFC 4594 in Section 2, enhancing 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. 1.1 Terminology 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]. 2. Traffic Class Framework and Component Definitions The framework of the traffic class attribute will have at least two parts, called components, allowing for several more to be included further distinguishing a particular session's traffic classification from another session's traffic classification. The amount of indicated differentiation between sessions is not a goal, and should only have additional components for differentiation if there is a need to uniquely identify traffic in different sessions. The intention is to have a category component (e.g., conversational) that identifies the traffic pattern for a session. Is the traffic within a session one-way or two-way? Can the traffic be buffered before reaching the destination or not? What is this session's tolerance to packet loss and can there be retransmissions? The application component (e.g., video) identifies the basic type of traffic within a category. Is it media or data packets? If media, which type of media? If data packets, which application of data packets are in this session? The optional adjective component(s) (e.g., immersive) help to Polk, et al. Expires Jan 4, 2015 [Page 5] Internet-Draft SDP trafficclass Attribute July 2014 further refine the traffic within a session by providing more description. For instance, if a session is two-way voice, what additional information can be given about this particular session to refine its description? Is it part of a conference or telepresence session? Is it just standalone voice call? Has a capacity admission protocol or mechanism been applied to this session? The 'traffic class label' (TCL) will have the following structure, category.application(.adjective)(.adjective)... [Editor's Note: the above is not the exact ABNF to be used. The order is right. The category and application MUST appear first (each only once) and zero or more adjectives can appear following the application component.] Where 1) the 1st component is the category, and is mandatory; 2) the 2nd component is the application, and is mandatory; 3) an optional 3rd component or series of components are adjective(s) used to further refine the application component; The construction of the traffic class label for Telepresence video would follow the minimum form of: conversational.video.immersive where there might be one or more adjective after '.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 category component is defined below, as are several of application and adjective strings. This is shown in [ID-RSVP-PROF] for the RSVP mapping of distinguishable traffic types. Mapping a specific Traffic Class Label to a DSCP value might be accomplished in any of the following ways: o statically within the offerer and/or answerer; or o taken from a local mapping table/file, which might be downloaded once, periodically or as changes in the network are observed; or o from feedback from the network. Polk, et al. Expires Jan 4, 2015 [Page 6] Internet-Draft SDP trafficclass Attribute July 2014 3. Traffic Class Attribute Definition This document defines the 'trafficclass' media-level SDP 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-class-label traffic-class-label = "trafficclass" ":" [SP] category "." application *( "." adjective ) category = "broadcast" / "realtime-interactive" / "multimedia-conferencing" / "multimedia-streaming" / "conversational" / "intermittent / tcl-token application = tcl-token adjective = classified-adjective / unclassified-adjective classified-adjective = tcl-token ":" tcl-token unclassified-adjective = tcl-token tcl-token = ALPHA *( [ "-" ] ALPHA / DIGIT ) A TCL "component" is any of the following: - category, - application, or - adjective (which is the only optional component, and can have zero or more of these type of components) The attribute is named "trafficclass", for traffic classification, identifying which one of the six categories applies to the media stream associated with this m-line. There MUST NOT be more than one category component per SDP media line. The categories in this document are an augmented version of the application labels introduced by table 3 of RFC 4594 (which will be rewritten based on the updated labels and treatments expected for each traffic class defined in this document). +-------------------------+------------------------------+ | Application Labels | Category Classes Defined | | Defined in RFC 4594 | in this document | +=========================+==============================+ | broadcast-video | broadcast | Polk, et al. Expires Jan 4, 2015 [Page 7] Internet-Draft SDP trafficclass Attribute July 2014 +-------------------------+------------------------------+ | realtime-interactive | realtime-interactive | +-------------------------+------------------------------+ | multimedia-conferencing | multimedia-conferencing | +-------------------------+------------------------------+ | multimedia-streaming | multimedia-streaming | +-------------------------+------------------------------+ | telephony | conversational | +-------------------------+------------------------------+ Figure 1. Label Differences 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 4 of this document. Applications and adjectives are defined using the syntax of "tcl-token" defined above. RFC 4566 defined SDP as case sensitive. Everything is here as well. An algorithm such as alphabetizing the list of components and matching the understood strings SHOULD be used for determining the traffic within a session. Strings not understood by an entity MUST be ignored during processing, but MUST NOT be deleted. Any category, application, or adjective string component within this attribute that is not understood MUST be ignored, leaving all that is understood to be processed. Ignored components SHOULD NOT be deleted, as a downstream entity could understand the component(s) and use it/them during processing. The following is an example of media level description with a 'trafficclass' attribute: m=video 50000 RTP/AVP 112 a=trafficclass:conversational.video.immersive.aq:admitted The above indicates the video part of a Telepresence session that has had capacity admission process applied to its media flow. 3.1 Categories within the SDP Traffic Class Label The category component within the traffic class attribute describes the type of communication that will occur within that session. It answers these questions, is the traffic - one-way or two-or-more-way interactive? - buffered or (virtually) non-buffered? Polk, et al. Expires Jan 4, 2015 [Page 8] Internet-Draft SDP trafficclass Attribute July 2014 - media or non-media (data)? The six category components of the traffic class attribute defined within this specification are as follows: o conversational o multimedia-conferencing o realtime-interactive o multimedia-streaming o broadcast o intermittent Sections 4.1 through 4.6 define each of the above. The category component MUST NOT be the only component present in a traffic class attribute. The category component MUST BE paired with an 'application' component to give enough meaning to the traffic class labeling goal. Not understanding the category component SHOULD mean that this attribute is ignored, because of the information about the expected behavior of this communication flow is identified by or within that component. 3.2 Applications within the SDP Traffic Class Label The application component identifies the application of a particular traffic flow, for example, audio or video. The application types are listed and defined in Section 4 of this document. Not every category is paired with every application listed, at least as defined in this document. One or more applications are inappropriate in one or more categories. Section 4.1 through 4.6 list many of the expected combinations. 3.3 Adjectives within the SDP Traffic Class Label For additional application type granularity, adjective components can be added. One or more adjectives can be within the same traffic class attribute to provide more differentiation. It is important to note that while the order of component types matter, the order of the adjective components do not. In other words, the category class component MUST be before the application component, which MUST be before any and all adjective component(s). There is no limit to the number of adjectives allowed. Adjective components come in two versions, unqualified and Polk, et al. Expires Jan 4, 2015 [Page 9] Internet-Draft SDP trafficclass Attribute July 2014 qualified. One has a prefix (qualified), the other (unqualified) does not. A defined qualified adjective MUST NOT appear without its qualifier name, even in future extensions to this specification. Some implementations will likely perform a search within this attribute for the presence of qualifiers, which might be as simple as searching for the ":" COLON character. Implementations will be confused with inconsistent coding, therefore strict adherence is necessary. 3.3.1 Qualified Adjectives Adjectives can be either unqualified or qualified. Qualified adjectives have a delimiter ":" character between the "qualifier name" and the "qualifier value". As one example, we introduce in this specification the "admission qualifier" and it has a qualifier name of "aq". We also define several possible qualifier values for the admission qualifier, namely "admitted", "non-admitted", "partial", and "none". When present in a TCL component, the qualified adjectives look like these admission qualifier adjectives: aq:admitted aq:non-admitted aq:partial aq:none Defining some adjectives as qualified adjectives allows entities processing the traffic class label to potentially recognize a particular qualifier name and act on it, even if it does not understand the qualifier value. In the future, a new admission qualifier value might be defined, e.g. "foo", and entities could at least recognize the admission qualifier adjective, even if it did not understand the qualifier value "foo". Like all adjectives, it is OPTIONAL to include the admission qualifier adjective in any trafficclass attribute. The admission qualifier and its qualifier values are defined as: - aq - 'admission qualifier' - this is the qualifier name for the admission qualifier adjectives, wherein the following qualifier values indicate the admission status for the traffic flow described by this m-line. - admitted - capacity admission mechanisms or protocols are to be or were used for the full amount of bandwidth in relation to this m= line. - non-admitted - capacity admission mechanisms or protocols were attempted but failed in relation to this m= line. This does not mean the flow described by this m= line failed. It just failed to attain the capacity admission Polk, et al. Expires Jan 4, 2015 [Page 10] Internet-Draft SDP trafficclass Attribute July 2014 mechanism or protocol necessary for a predictable quality of service, and is likely to continue with only a class of service marking or best effort. - partial - capacity admission mechanisms or protocols are to be or were used for the part of the amount of bandwidth in relation to this m= line. All traffic above a certain amount will have no capacity admission mechanisms applied. In other words, there is more traffic sent than was agreed to. The burden is on the sender and receiver to deal with any sent and lost information. - none - no capacity admission mechanisms or protocols are or were attempted in relation to this m= line. The default for any flow generated from an m-line not having a trafficclass adjective of 'aq:admitted' or 'aq:non-admitted' MUST be the equivalent of 'aq:none', whether or not it is present. 4. Matching Categories with Applications and Adjectives This section describes each component within this document, as well as provides the combinations of categories and applications and adjectives. Given that not every combination makes sense, we express the limits here - which will be IANA registered. The majority of these TCLs in this document are found in [ID-RSVP-PROF], where RSVP is appropriate. Look at that other document for example usage of a specified TCL here. 4.1 Conversational Category Traffic Class The "conversational" traffic class is best suited for applications that require very low delay variation and generally intended to enable realtime, bi-directional person-to-person or multi-directional via an MCU communication. Conversational flows are inelastic, and with few exceptions, use a UDP transport. +--------------------------------------------------------------------+ | Traffic Class | | Tolerance to | | Name | Traffic Characteristics | Loss |Delay |Jitter| |===============+===============================+======+======+======| | | High priority, typically | Very | Very | Very | |conversational | consistent sized packets | Low | Low | Low | | | (small audio samples produce | | | | | small packets and large video | | | | | samples produce large packets),| | | | | | generally sustained at a high | | | | | | packet rate, low inter-packet | | | | | | transmission interval | | | | +---------------+-------------------------------+------+------+------+ Polk, et al. Expires Jan 4, 2015 [Page 11] Internet-Draft SDP trafficclass Attribute July 2014 Figure 2. Conversational Traffic Characteristics The following application components are appropriate for use with the Conversational category: o audio (voice) o video o multiplex (i.e., combined a/v streams) an application wherein media of different forms (e.g., audio and video) is multiplexed within the same media flow. With adjective substrings to the above 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. avconf - An interactive audio-visual communication experience that is not immersive in nature, though can have a high resolution video component. +----------------------+---------------------+---------------------+ | Category | Application | Adjective | +----------------------+---------------------+---------------------+ | conversational | audio | immersive | | | | avconf | | | | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | video | immersive | | | | avconf | | | | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | multiplex | immersive | | | | avconf | | | | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | Polk, et al. Expires Jan 4, 2015 [Page 12] Internet-Draft SDP trafficclass Attribute July 2014 +----------------------+---------------------+---------------------+ Figure 3. Conversational Applications and Adjective Combinations 4.2 Multimedia-Conferencing Category Traffic Class The "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. +--------------------------------------------------------------------+ | 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, often one-way or | | | | | | unidirectional | | | | +---------------+-------------------------------+------+------+------+ Figure 4. Multimedia Conferencing Traffic Characteristics Multimedia-conferencing flows are not media flows which are conversational in nature. Multimedia-conferencing flows are those data flows that are typically transmitted in parallel to currently active conversational media flows. For example, a two-way conference session in which the users share a presentation. The presentation part of that conference call uses the Multimedia-conferencing category, whereas the audio and any video uses the conversational category indication. The following application components are appropriate for use with the Multimedia-Conferencing category: 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; could be at a rapid or busty rate, just not a continuous 24 fps or greater. o presentation-video - motion video that is transmitted and rendered as part of a presentation. o presentation-audio - the audio that is transmitted and rendered as Polk, et al. Expires Jan 4, 2015 [Page 13] Internet-Draft SDP trafficclass Attribute July 2014 part of a presentation. 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 as defined in RFC 5547 o instant messaging +----------------------+---------------------+---------------------+ | Category | Application | Adjective | +----------------------+---------------------+---------------------+ | multimedia- | application-sharing | aq:admitted | | conferencing | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | whiteboarding | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | presentation-data | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | presentation-video | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | presentation-audio | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | instant-messaging | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | file-transfer | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | +----------------------+---------------------+---------------------+ Figure 5. Multimedia Conferencing Applications and Adjective Combinations Polk, et al. Expires Jan 4, 2015 [Page 14] Internet-Draft SDP trafficclass Attribute July 2014 4.3 Realtime-Interactive Category Traffic Class The "Realtime-Interactive" traffic class is intended for interactive variable rate inelastic applications that require low jitter and loss and very low delay. Many of the applications that use the Realtime-Interactive category use TCP or SCTP, even gaming, because lost packets is information that is still required - therefore it is retransmitted. +--------------------------------------------------------------------+ | 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 | | | | +---------------+-------------------------------+------+------+------+ Figure 6. Realtime Interactive Traffic Characteristics The following application components are appropriate for use with the Realtime-Interactive category: o gaming - interactive player video games with other users on other hosts (e.g., Doom) 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) With adjective substrings to the above o virtual - To be used with the remote-desktop application component specifically when the traffic is a virtual desktop similar to an X-windows station, has no local hard drive, or is operating a computer application with no local storage. +----------------------+---------------------+---------------------+ | Category | Application | Adjective | +----------------------+---------------------+---------------------+ | realtime-interactive | gaming | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | remote-desktop | virtual | | | | aq:admitted | | | | aq:non-admitted | Polk, et al. Expires Jan 4, 2015 [Page 15] Internet-Draft SDP trafficclass Attribute July 2014 | | | aq:partial | | | | aq:none | | | | | | | telemetry | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | +----------------------+---------------------+---------------------+ Figure 7. Realtime-Interactive Applications and Adjective Combinations 4.4 Multimedia-Streaming Category Traffic Class The "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. +--------------------------------------------------------------------+ | Traffic Class | | Tolerance to | | Name | Traffic Characteristics | Loss |Delay |Jitter| |===============+===============================+======+======+======| | multimedia- | Variable size packets, |Low - |Medium| High | | streaming | elastic with variable rate |Medium|- High| | | | | | | | +---------------+-------------------------------+------+------+------+ Figure 8. Multimedia Streaming Traffic Characteristics The following application components are appropriate for use with the Multimedia-Streaming category: o audio (see Section 4.1) o video (see Section 4.1) o webcast - is a media file distributed over the Internet or enterprise network using streaming media technology. o multiplex (see Section 4.1) The primary difference between the multimedia-streaming category and the broadcast category is the length of time for buffering. Buffered streaming of audio and/or video which is often initiated by HTTP, and not SDP. Buffering here can be from many seconds to hours, and is typically at the destination end (as opposed to Broadcast buffering which is minimal at the destination). The buffering aspect is what differentiates this category class from the broadcast category (which has minimal or no buffering). Polk, et al. Expires Jan 4, 2015 [Page 16] Internet-Draft SDP trafficclass Attribute July 2014 +----------------------+---------------------+---------------------+ | Category | Application | Adjective | +----------------------+---------------------+---------------------+ | multimedia-streaming | audio | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | video | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | webcast | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | multiplex | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | +----------------------+---------------------+---------------------+ Figure 9. Multimedia Streaming Applications and Adjective Combinations 4.5 Broadcast Category Traffic Class The "broadcast" traffic class is best suited for inelastic streaming media Applications, which might have a 'wardrobe malfunction' delay at or near the source but not typically at the destination, that may be of constant or variable rate, requiring low jitter and very low packet loss. See Section 4.4 for the difference between Multimedia-Streaming and Broadcast; it all has to do with buffering. +--------------------------------------------------------------------+ | 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 | | | | +---------------+-------------------------------+------+------+------+ Polk, et al. Expires Jan 4, 2015 [Page 17] Internet-Draft SDP trafficclass Attribute July 2014 Figure 10. Broadcast Traffic Characteristics The following application components are appropriate for use with the Broadcast category: o audio (see Section 4.1) o video (see Section 4.1) o multiplex (see Section 4.1) With adjective substrings to the above: o live (non-buffered) - refers to various types of media broadcast without a significant delay, typically measured in milliseconds to a few seconds only. o surveillance - one way audio from a microphone or video from a camera (e.g., observing a parking lot or building exit), typically enabled for long periods of time, usually stored at the destination. +----------------------+---------------------+---------------------+ | Category | Application | Adjective | +----------------------+---------------------+---------------------+ | broadcast | audio | surveillance | | | | live | | | | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | video | surveillance | | | | live | | | | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | | | multiplex | surveillance | | | | live | | | | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | +----------------------+---------------------+---------------------+ Figure 11. Broadcast Applications and Adjective Combinations Polk, et al. Expires Jan 4, 2015 [Page 18] Internet-Draft SDP trafficclass Attribute July 2014 4.6 Intermittent Category Traffic Class The "intermittent" traffic class is best suited for inconstant rate applications such as those from a sensor device, where tolerance to loss, delay and jitter is often medium to high in nature. This category is not to be used for bulk file transfers, rather it can be sometimes bursty for brief periods of time, but then not produce traffic for short or long (i.e., hours or days) durations. Nor is this category to be used for any kind of regular paced rate of transmission, no matter how long the interval. +--------------------------------------------------------------------+ | Traffic Class | | Tolerance to | | Name | Traffic Characteristics | Loss |Delay |Jitter| |===============+===============================+======+======+======| | intermittent | Inconstant rate, infrequent |Medium|Medium| High | | | but sometimes bursty flows, |- High|- High| | | | generally non-regular, | | | | | | variable inter-packet | | | | | | transmission interval | | | | +---------------+-------------------------------+------+------+------+ Figure 12. Intermittent Traffic Characteristics The following application components are appropriate for use with the Broadcast category: o text (i.e., text required by deaf users) a term for seemingly real-time transmission of text in a character-by-character fashion, often as a text equivalent to voice-based conversational services, without the timing constraints of conversational text is defined in the ITU-T Framework for multimedia services, Recommendation F.700 [RFC5194]. o sensor - a flow containing information obtained from a sensor, such as a temperature or motion sensor. With adjective substrings to the above: o there are no defined adjectives for the 'sensor' application at this time. There are many examples one could think would be viable adjectives, such as light, motion, temperature, magnetic fields, gravity, humidity, moisture, vibration, pressure, electrical fields, and other physical aspects of the external environment measured by the sensor. +----------------------+---------------------+---------------------+ | Category | Application | Adjective | +----------------------+---------------------+---------------------+ | intermittent | sensor | (undefined at this | | | | time) | | | | | Polk, et al. Expires Jan 4, 2015 [Page 19] Internet-Draft SDP trafficclass Attribute July 2014 | | text | aq:admitted | | | | aq:non-admitted | | | | aq:partial | | | | aq:none | | | | | +----------------------+---------------------+---------------------+ Figure 13. Intermittent Applications and Adjective Combinations 5. Offer/Answer Behavior Through the inclusion of the 'trafficclass' attribute, an offer/answer exchange identifies the application type(s) for use by the endpoints within the media streams of a session. Signaling elements can use this attribute to determine the acceptability and/or treatment of that session through lower layers, communicating a desired treatment for a particular flow to endpoints using SDP, interacting with network elements using some unspecified mechanism, or having endpoints communicate with network elements using some unspecified mechanism. In order to understand the traffic class attribute, the SDP entity MUST check several components within the Traffic Class Label. By understand, we mean that the value of each component of the TCL is recognized, i.e., both the category and application components MUST be a recognized set for a TCL to be understood. Adjectives that are not recognized are simply ignored and MAY be discarded, however many there are. Adjectives which are not understood SHOULD NOT be discarded, as each/any adjective might be understood by some or all other downstream nodes in the signaling path. The following pertains to both the receiver of an offer and receiver of an answer when either or both contain a Traffic Class Label attribute. 1 - can the receiver of the SDP containing a trafficclass attribute successfully process the category component? If not, the attribute SHOULD be ignored. If yes, it checks the application component. 2 - can the receiver of the SDP containing a trafficclass attribute successfully process 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 category component was not understood, meaning the attribute SHOULD be ignored. If yes, it checks to see if there are any adjective components Polk, et al. Expires Jan 4, 2015 [Page 20] Internet-Draft SDP trafficclass Attribute July 2014 present in this attribute to start its classification. 3 - can the receiver of the SDP containing a trafficclass attribute successfully process the adjective component or components if any are present? If not present, process and match the trafficclass label value as is. If yes, determine if there is more than one. Search for each that is understood. Any adjectives not understood are to be ignored, as if they are not present. Match all remaining understood components according to local policy and process attribute. 5.1 Offer Behavior Offerers include the 'trafficclass' attribute within a single string per m= line comprised of at least a category and application component (see Section 4) to establish the non-generic classification of the media stream between the answerer and the offerer. The offerer can also include one or more adjective components, which might be a combination of registered and private adjectives to further refine the identification of what this particular media stream is. Session Border Controllers (SBC) at domain boundaries can change this attribute through local policy. 5.2 Answer Behavior Upon receiving an offer containing a 'trafficclass' attribute, if the offer is accepted - including the ability to process the 3 bulleted rules in Section 5.0, the answerer will use this attribute to classify the 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 Offerer will process the received answer just as the answerer processed the offer. In other words, the processing steps and rules are identical for each end (see Section 5). 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 and in some cases group the media-types of this session. Polk, et al. Expires Jan 4, 2015 [Page 21] Internet-Draft SDP trafficclass Attribute July 2014 6. Security considerations The security considerations from RFC 4566 are also applicable, particularly since intermediary devices might be able to look at an m= line and determine, not only is it audio, but that it is presentation-audio (i.e., 'multimedia-conferencing.presentation-audio') versus conversational audio. 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 misclassifying (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. 7. IANA considerations 7.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: 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: (there are multiple RFC5226 registration procedures; see below within each sub-section) Designated Experts: James Polk (jmpolk@cisco.com) Paul Jones (paulej@packetizer.com) Type SDP Name Reference ---- ------------------ --------- att-field (media level) Polk, et al. Expires Jan 4, 2015 [Page 22] Internet-Draft SDP trafficclass Attribute July 2014 trafficclass [this document] 7.2 The Traffic Classification Category Registration This document requests IANA to create a new registry for the traffic category classes similar to the following table within the Session Description Protocol (SDP) Parameters registry: Registry Name: "trafficclass" SDP Category Attribute Values Reference: [this document] Registration Procedures: Standards Action Required [RFC5226] Category Values Reference ---------------- --------- broadcast [this document] realtime-interactive [this document] multimedia-conferencing [this document] multimedia-streaming [this document] conversational [this document] intermittent [this document] 7.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" SDP Application Attribute Values Reference: [this document] Registration Procedures: Specification Required [RFC5226] Application Values Reference ------------------ --------- audio [this document] video [this document] text [this document] application-sharing [this document] presentation-data [this document] presentation-video [this document] presentation-audio [this document] whiteboarding [this document] instant-messaging [this document] gaming [this document] remote-desktop [this document] telemetry [this document] multiplex [this document] webcast [this document] sensor [this document] Polk, et al. Expires Jan 4, 2015 [Page 23] Internet-Draft SDP trafficclass Attribute July 2014 7.4 The Traffic Classification Adjective Registration This document requests IANA to create a new registry for the traffic adjective values similar to the following table within the Session Description Protocol (SDP) Parameters registry: Registry Name: "trafficclass" SDP Adjective Attribute Values Reference: [this document] Registration Procedures: Specification Required [RFC5226] Adjective Values Reference ------------------ --------- immersive [this document] avconf [this document] realtime [this document] web [this document] virtual [this document] live [this document] surveillance [this document] aq:admitted [this document] aq:non-admitted [this document] aq:partial [this document] aq:none [this document] 7.5 The Traffic Classification Component Mapping 7.5.1 Broadcast Applications and Adjective Combinations This document requests IANA to create a new registry for the Broadcast category mapping similar to Figure 11 in Section 4.5 of this document within the Session Description Protocol (SDP) Parameters registry: Registry Name: Broadcast Applications and Adjective Combinations Table Reference: [this document] Registration Procedures: Specification Required [RFC5226] 7.5.2 Realtime Interactive Applications and Adjective Combinations This document requests IANA to create a new registry for the Realtime Interactive category mapping similar to Figure 7 in Section 4.3 of this document within the Session Description Protocol (SDP) Parameters registry: Registry Name: Realtime Interactive Applications and Adjective Combinations Table Reference: [this document] Registration Procedures: Specification Required [RFC5226] Polk, et al. Expires Jan 4, 2015 [Page 24] Internet-Draft SDP trafficclass Attribute July 2014 7.5.3 Multimedia Conferencing Applications and Adjective Combinations This document requests IANA to create a new registry for the Multimedia Conferencing category mapping similar to Figure 5 in Section 4.2 of this document within the Session Description Protocol (SDP) Parameters registry: Registry Name: Multimedia Conferencing Applications and Adjective Combinations Table Reference: [this document] Registration Procedures: Specification Required [RFC5226] 7.5.4 Multimedia-Streaming Applications and Adjective Combinations This document requests IANA to create a new registry for the Multimedia-Streaming category mapping similar to Figure 9 in Section 4.4 of this document within the Session Description Protocol (SDP) Parameters registry: Registry Name: Multimedia-Streaming Applications and Adjective Combinations Table Reference: [this document] Registration Procedures: Specification Required [RFC5226] 7.5.5 Conversational Applications and Adjective Combinations This document requests IANA to create a new registry for the conversational category mapping similar to Figure 3 in Section 4.1 of this document within the Session Description Protocol (SDP) Parameters registry: Registry Name: Conversational Applications and Adjective Combinations Table Reference: [this document] Registration Procedures: Specification Required [RFC5226] 7.5.6 Intermittent Applications and Adjective Combinations This document requests IANA to create a new registry for the intermittent category mapping similar to Table 13 in Section 4.6 of this document within the Session Description Protocol (SDP) Parameters registry: Registry Name: Intermittent Applications and Adjective Combinations Table Reference: [this document] Registration Procedures: Specification Required [RFC5226] Polk, et al. Expires Jan 4, 2015 [Page 25] Internet-Draft SDP trafficclass Attribute July 2014 7.6 Designated Expert Reviewers The following will be the designated expert reviewers of new 'trafficclass' registry requests: - James Polk - Paul E. Jones There SHALL remain two designated Expert reviewers at all times. The MMUSIC WG chairs should be consulted for replacements, if one or both are needed. 8. Acknowledgments To Dave Oran, Toerless Eckert, Henry Chen, David Benham, David Benham, Mo Zanty, Michael Ramalho, Glen Lavers, Charles Ganzhorn, Paul Kyzivat, Greg Edwards, Charles Eckel, Dan Wing, Cullen Jennings and Peter Saint-Andre for their comments and suggestions. 9. References 9.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 [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 [RFC2872] Y. Bernet, R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005 [RFC4124] F. Le Faucheur, Ed., " Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering ", RFC 4124, Polk, et al. Expires Jan 4, 2015 [Page 26] Internet-Draft SDP trafficclass Attribute July 2014 June 2005 [RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5547] M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. , Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer ", RFC 5547, May 2009 [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code 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 9.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, Feb 2013 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 Polk, et al. Expires Jan 4, 2015 [Page 27] Internet-Draft SDP trafficclass Attribute July 2014 Paul E. Jones 7025 Kit Creek Rd. Research Triangle Park, NC, USA +1 919 476 2048 mailto: paulej@packetizer.com Appendix - Changes from Previous Versions A.1 From -04 to -05 These are the following changes made between the WG -03 version and the -04 version: - general clean-up of text. - added presentation-video and presentation-audio to the multimedia-conferencing section. - brought forward the text describing how a SDP entity handles receiving a session description containing the trafficclass attribute to Section 5, from 5.2. - added RFC 5547 as a normative reference. - expended the security considerations section. A.2 From -03 to -04 These are the following changes made between the WG -03 version and the -04 version: - minimal text changes. - introduced the "intermittent" category based on IETF86 feedback in the WG. A.3 From -02 to -03 These are the following changes made between the WG -02 version and the -03 version: - Rearranged a fair amount of text - Separated and defined the components into separate subsections. - built 5 different tables, one per category, that lists within each category - what applications are appropriate as well as what adjectives are appropriate for each application within that Polk, et al. Expires Jan 4, 2015 [Page 28] Internet-Draft SDP trafficclass Attribute July 2014 category. - added the 'partial' admission qualifier for those flows that have only part of their respective flow admitted (i.e., CAC'd). A.4 From -01 to -02 These are the following changes made between the WG -01 version and the -02 version: - converged the use of terms 'parent' and 'category' to just 'category' for consistency. - changed ABNF to reflect extensibility by not having applications and adjectives named in the ABNF, rather have them merely IANA registered. - merged the qualified and unqualified adjective sections into a single section on adjectives, but allowing some to have a preceding qualifier. - text clean-up A.5 From -00 to -01 These are the following changes made between the WG -00 version and the -01 version: - removed the non-SDP applications Netflix and VOD - switched the adjective 'desktop' to 'avconf' - Labeled each of the figures. - clarified the differences between Multimedia-Streaming and Broadcast category categories. - defined Video surveillance - added the concept of a 'qualified' adjective, and modified the ABNF. - deleted the idea of a 'cac-class' as a separate component, and made the equivalent a qualified adjective. - modified the answerer behavior because of the removal of the 'cac-class' component. - created an IANA registry for qualified adjectives - general clean-up of the doc. Polk, et al. Expires Jan 4, 2015 [Page 29]