draft-ietf-mmusic-traffic-class-for-sdp-02.txt   draft-ietf-mmusic-traffic-class-for-sdp-03.txt 
Network WG James Polk Network WG James Polk
Internet-Draft Subha Dhesikan Internet-Draft Subha Dhesikan
Expires: January 16, 2013 Paul Jones Expires: August 18, 2013 Paul Jones
Intended Status: Standards Track (PS) Cisco Systems Intended Status: Standards Track (PS) Cisco Systems
July 16, 2012 Feb 18, 2013
The Session Description Protocol (SDP) 'trafficclass' Attribute The Session Description Protocol (SDP) 'trafficclass' Attribute
draft-ietf-mmusic-traffic-class-for-sdp-02 draft-ietf-mmusic-traffic-class-for-sdp-03
Abstract Abstract
This document proposes a new Session Description Protocol (SDP) This document proposes a new Session Description Protocol (SDP)
attribute to identify the traffic class a session is requesting attribute to identify the traffic class a session is requesting
in its offer/answer exchange. in its offer/answer exchange.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2013. This Internet-Draft will expire on August 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Traffic Class Framework and String Definitions . . . . . . . 5 2. Traffic Class Framework and Component Definitions . . . . . . 5
3. Traffic Class Attribute Definition . . . . . . . . . . . . . 11 3. Traffic Class Attribute Definition . . . . . . . . . . . . . 6
4. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 14 3.1 Categories within the SDP Traffic Class Label . . . . . . 8
4.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 14 3.2 Applications within the SDP Traffic Class Label . . . . . 9
4.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 15 3.3 Adjectives within the SDP Traffic Class Label . . . . . . 9
5. Security considerations . . . . . . . . . . . . . . . . . . . 16 3.3.1 Qualified Adjectives . . . . . . . . . . . . . . . . . 9
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 4. Matching Categories with Applications and Adjectives . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 4.1 Conversational Category Traffic Class . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Multimedia-Conferencing Category Traffic Class . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . 18 4.3 Realtime-Interactive Category Traffic Class . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . 19 4.4 Multimedia-Streaming Category Traffic Class . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 4.5 Broadcast Category Traffic Class . . . . . . . . . . . . 17
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 18
5.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 18
5.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 19
6. Security considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 25
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] provides a means The Session Description Protocol (SDP) [RFC4566] provides a means
for an offerer to describe the specifics of a session to an for an offerer to describe the specifics of a session to an
answerer, and for the answerer to respond back with its session answerer, and for the answerer to respond back with its session
skipping to change at page 3, line 22 skipping to change at page 3, line 34
- allow network monitoring/management of traffic types realtime and - allow network monitoring/management of traffic types realtime and
after-the-fact analysis. after-the-fact analysis.
Some network operators want the ability to guarantee certain traffic Some network operators want the ability to guarantee certain traffic
gets a minimum amount of network bandwidth per link or through a 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 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 backbone. For example, a call center voice application might get at
least 20% of the available link bandwidth. least 20% of the available link bandwidth.
Some network operators want the ability to allow certain users or Some network operators want the ability to allow certain users or
devices access to greater bandwidth during non-busy hours, than devices access to greater bandwidth during non-busy hours than
during busy hours of the day. For example, all desktop video might during busy hours of the day. For example, all desktop video might
operate at 1080p during non-peak times, but a similar session 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 be curtailed between the same users or devices to 720p or 360p
during peak hours. Another example would be to reduce the frames 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 per second (fps) rate, say from 30fps to 15fps. This case is not as
clear as accepting or denying similar sessions during different clear as accepting or denying similar sessions during different
times of the day, but tuning the access to the bandwidth based on 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 the type of session. In other words, tune down the bandwidth for
desktop video during peak hours to allow a 3-screen Telepresence desktop video during peak hours to allow a 3-screen Telepresence
session that would otherwise look like the same type of traffic session that would otherwise look like the same type of traffic
(RTP, and more granular, video). (RTP, and more granular, video).
RFC 4594 established a guideline for classifying the various flows RFC 4594 established a guideline for classifying the various flows
in the network and the Differentiated Services Codepoints (DSCP) in the network and the Differentiated Services Codepoint (DSCP)
that apply to many traffic types (table 3 of [RFC4594]), including values that apply to many traffic types (table 3 of [RFC4594]),
RTP based voice and video traffic sessions. The RFC also defines the including RTP based voice and video traffic sessions. The RFC also
per hop network behavior that is strongly encouraged for each of defined the per hop network behavior that is strongly encouraged for
these application traffic types based on the traffic characteristics each of these application traffic types based on the traffic
and tolerances to delay, loss and jitter within each traffic class. characteristics and tolerances to delay, loss and jitter within each
traffic class.
Video was broken down into 4 categories in that RFC, and voice into Video was broken down into four categories in that RFC, and voice in
another single category. We do not believe this satisfies the another single category. We do not believe this satisfies the
technical and business requirements to accomplish sufficiently technical and business requirements to accomplish sufficiently
unique labeling of RTP traffic. unique labeling of RTP traffic.
If the application becomes aware of traffic labeling, If the application becomes aware of traffic labeling,
- this can be coded into layer 3 mechanisms. - this can be coded into layer 3 mechanisms.
- this can be coded into layer 4 protocols and/or mechanisms. - this can be coded into layer 4 protocols and/or mechanisms.
- this can be coded into a combination of mechanisms and protocols. - this can be coded into a combination of mechanisms and protocols.
The layer 3 mechanism for differentiating traffic is either the port The layer 3 mechanism for differentiating traffic is either the port
number or the Differentiated Services Codepoint (DSCP) value number or the Differentiated Services Codepoint (DSCP) value
[RFC2474]. Within the public Internet, if the application is not [RFC2474]. Within the public Internet, if the application is not
part of a managed service, the DSCP likely will be best effort (BE), part of a managed service, the DSCP value likely will be best effort
or reset to BE when ingressing a provider's network. Within the (BE), or reset to BE when ingressing a provider's network. Within
corporate LAN, this is usually completely configurable and a local the corporate LAN, this is usually completely configurable and a
IT department can take full advantage of this labeling to shape and local IT department can take full advantage of this labeling to
manage their network as they see fit. shape and manage their network as they see fit.
Within a network core, DiffServ typically does not apply. That said, Within a network core, DiffServ typically does not apply. That said,
DiffServ can be used to identify which traffic goes into which MPLS DiffServ can be used to identify which traffic goes into which MPLS
tunnel [RFC4124]. tunnel [RFC4124].
Labeling realtime traffic types using a layer 4 protocol would Labeling realtime traffic types using a layer 4 protocol would
likely involve RSVP [RFC2205] or NSIS [RFC4080]. RSVP has an likely involve RSVP [RFC2205] or NSIS [RFC4080]. RSVP has an
Application Identifier (app-ID) defined in [RFC2872] that provides a Application Identifier (app-ID) defined in [RFC2872] that provides a
means for carrying a traffic class label along the media path. An means for carrying a traffic class label along the media path. An
advantage of this mechanism is that the label can inform each domain 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 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 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 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 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 service provider, the far-end domain will be able to reset the DSCP
value to the intended traffic class. There is a proposed extension value appropriate for the intended traffic class. There is a
to RSVP which creates individual profiles for what goes into each proposed extension to RSVP which creates individual profiles for
app-ID field to describe these traffic classes [ID-RSVP-PROF], which what goes into each app-ID field to describe these traffic classes
will take advantage of what is described in this document. [ID-RSVP-PROF], which will take advantage of what is described in
this document.
There are several proprietary mechanisms that can take advantage of There are several proprietary mechanisms that can take advantage of
this labeling, but none of those will be discussed here. this labeling, but none of those will be discussed here.
The idea of traffic - or service - identification is not new; it has The idea of traffic - or service - identification is not new; it has
been described in [RFC5897]. If that RFC is used as a guideline, been described in [RFC5897]. If that RFC is used as a guideline,
identification that leads to stream differentiation can be quite identification that leads to stream differentiation can be quite
useful. One of the points within RFC 5897 is that users cannot be useful. One of the points within RFC 5897 is that users cannot be
allowed to assign any identification (fraud is one reason given). In allowed to assign any identification (fraud is one reason given). In
addition, RFC 5897 recommends that service identification should be addition, RFC 5897 recommends that service identification should be
done in signaling, rather than guessing or deep packet inspection. done in signaling, rather than guessing or deep packet inspection.
Any network currently would have to currently guess or perform deep Currently, any network would have to guess or perform deep
packet inspection to classify traffic and offer the service as per packet inspection to classify traffic and offer the service as per
RFC 4594 since such service identification information is currently RFC 4594 as such service identification information is currently
not available in SDP and therefore to the network elements. Since not available in SDP and therefore to the network elements. Since
SDP understands how each stream is created (i.e., the particulars of SDP understands how each stream is created (i.e., the particulars of
the RTP stream), this is the right place to have this service the RTP stream), this is the right place to have this service
differentiated. Such service differentiation can then be differentiated. Such service differentiation can then be
communicated to and leveraged by the network. communicated to and leveraged by the network.
[Editor's Note: the words "traffic" and "service" are similar enough [Editor's Note: the words "traffic" and "service" are similar enough
that the above paragraph talks about RFC 5897's that the above paragraph talks about RFC 5897's
"service identification", but this document only "service identification", but this document only
discuss and propose traffic indications in SDP.] discuss and propose traffic indications in SDP.]
skipping to change at page 5, line 16 skipping to change at page 5, line 28
application a session is requesting in its offer/answer exchange. application a session is requesting in its offer/answer exchange.
This document uses previously defined service class strings for This document uses previously defined service class strings for
consistency between IETF documents. consistency between IETF documents.
This document modifies the traffic classes originally created in RFC This document modifies the traffic classes originally created in RFC
4594 in Section 2, incrementing each class with application 4594 in Section 2, incrementing each class with application
identifiers and optional adjective strings. Section 3 defines the identifiers and optional adjective strings. Section 3 defines the
new SDP attribute "trafficclass". Section 4 discusses the offerer new SDP attribute "trafficclass". Section 4 discusses the offerer
and answerer behavior when generating or receiving this attribute. and answerer behavior when generating or receiving this attribute.
2. Traffic Class Framework and String Definitions 2. Traffic Class Framework and Component Definitions
The framework of the traffic class attribute will have at least two The framework of the traffic class attribute will have at least two
parts, allowing for several more to be included. The intention is to parts, called components, allowing for several more to be included
have a category class (e.g., Conversational) that merely serves as further distinguishing a particular session's traffic classification
the anchor point for an application component that when paired from another session's traffic classification. The amount of
together, form the highest level traffic class. An adjective indicated differentiation between sessions is not a goal, and should
component provides further granularity for the application. There only have additional components for differentiation if there is a
can be more than one adjective within a traffic class label to need to uniquely identify traffic in different sessions.
further refine the uniqueness of a traffic class being described.
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
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 will have the following structure, The traffic class label will have the following structure,
category.application(.adjective)(.adjective) category.application(.adjective)(.adjective)...
[Editor's Note: the above is not exactly the ABNF to be used. [Editor's Note: the above is not the exact ABNF to be used.
The order is right. The category and application The order is right. The category and application
MUST appear first (each only once) and zero or more MUST appear first (each only once) and zero or more
adjectives can appear following the application adjectives can appear following the application
component.] component.]
Where Where
1) the 1st component is the human understandable category; 1) the 1st component is the category, and is mandatory;
2) the 2nd component is the application; 2) the 2nd component is the application, and is mandatory;
3) an optional 3rd component or series of components are 3) an optional 3rd component or series of components are
adjective(s) used to further refine the application component; adjective(s) used to further refine the application component;
The construction of the traffic class label for Telepresence video The construction of the traffic class label for Telepresence video
would follow the minimum form of: would follow the minimum form of:
Conversational.video.immersive conversational.video.immersive
where there might be one or more adjective after '.immersive'. where there might be one or more adjective after '.immersive'.
There is no traffic class or DSCP value associated with just There is no traffic class or DSCP value associated with just
"Conversational". There is a traffic class associated with "conversational". There is a traffic class associated with
"Conversational.video", creating a differentiation between it and a "conversational.video", creating a differentiation between it and a
"Conversational.video.immersive" traffic class, which would have "conversational.video.immersive" traffic class, which would have
DSCP associated with the latter traffic class, depending on local DSCP associated with the latter traffic class, depending on local
policy. Each category component is defined below, as are several of policy. Each category component is defined below, as are several of
application and adjective strings. application and adjective strings.
[Editor's Note: We're not yet sure how much of what's below will be 3. Traffic Class Attribute Definition
proposed for IANA registration, but the 5 category
components will be, as well as at least some
application components per category component. Some
adjective components will also likely be proposed
for IANA registration.
The 5 category components of the traffic class attribute are as This document proposes the 'trafficclass' session and media-level
follows: SDP attribute. The following is the Augmented Backus-Naur Form
(ABNF) [RFC5234] syntax for this attribute, which is based on the
SDP [RFC4566] grammar:
o Conversational attribute =/ traffic-class-label
o Multimedia-Conferencing
o Realtime-Interactive
o Multimedia-Streaming
o Broadcast
The following application components of the traffic class attribute traffic-class-label = "trafficclass" ":" [SP] category
are as follows: "." application *( "." adjective )
o Audio category = "broadcast" /
o Video "realtime-interactive" /
o Text "multimedia-conferencing" /
o application-sharing "multimedia-streaming" /
o Presentation-data "conversational" / tcl-token
o Whiteboarding
o Webchat/IM
o Gaming
o Virtual-desktop (interactive)
o Remote-desktop
o Telemetry (e.g., NORAD missile control)
o Multiplex (i.e., combined streams)
o Webcast
o IPTV
o Live-events (one-way, in realtime)
o surveillance
The following adjective components of the traffic class attribute application = tcl-token
are as follows:
o Immersive adjective = classified-adjective /
o avconf unclassified-adjective
o Realtime-Text
o web
Each of the above 3 lists will be defined in the following classified-adjective = tcl-token ":" tcl-token
subsections.
2.1 Conversational Category Traffic Class unclassified-adjective = tcl-token
The Conversational traffic class is best suited for applications tcl-token = ALPHA *( [ "-" ] ALPHA / DIGIT )
The attribute is named "trafficclass", for traffic classification,
identifying which one of the five categories applies to the
media stream associated with this m-line. There MUST NOT be more
than one category component per media line.
The categories 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 | Category 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 |
+-------------------------+------------------------------+
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.
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?
- elastic or inelastic (as far as retransmissions)?
- buffered or (virtually) non-buffered?
- media or non-media (data)?
The five 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
Sections 3.1 through 3.5 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
communication flow 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 2 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. For example, iptv is a single directional traffic
application that is suited for the broadcast (one-way) category
rather than categories like realtime-interactive or conversational.
Section 4.1 through 4.5 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. There might be
local significance to the ordering of adjectives though, such as
having a pattern matching algorithm in which labels are matched
exactly (i.e., the order matters), or not at all. 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
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 string, 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
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.
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 that require very low delay variation and generally intended to
enable realtime, bi-directional person-to-person or enable realtime, bi-directional person-to-person or
multi-directional via an MCU communication. The following multi-directional via an MCU communication. Conversational flows are
application components are appropriate for use with the inelastic, and with few exceptions, use a UDP transport.
Conversational category:
o Audio (voice)** +--------------------------------------------------------------------+
|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 | | | |
+---------------+-------------------------------+------+------+------+
o Video** Figure 2. Conversational Traffic Characteristics
o Text (i.e., real-time text required by deaf users) The following application components are appropriate for use with
the Conversational category:
**The above applications will also be used within Multimedia o audio (voice)
Streaming and Broadcast
o video
o text (i.e., real-time text required by deaf users)
o multiplex (i.e., combined a/v streams)
With adjective substrings to the above With adjective substrings to the above
Immersive (TP) - An interactive audio-visual communications immersive (TP) - An interactive audio-visual communications
experience between remote locations, where the users enjoy a experience between remote locations, where the users enjoy a
strong sense of realism and presence between all participants strong sense of realism and presence between all participants
by optimizing a variety of attributes such as audio and video by optimizing a variety of attributes such as audio and video
quality, eye contact, body language, spatial audio, quality, eye contact, body language, spatial audio,
coordinated environments and natural image size. coordinated environments and natural image size.
Avconf - An interactive audio-visual communication experience avconf - An interactive audio-visual communication experience
that is not immersive in nature, though can have a high that is not immersive in nature, though can have a high
resolution video component. resolution video component.
Realtime-Text (RTT) - a term for real-time transmission of text in text - a term for real-time transmission of text in
a character-by-character fashion for use in conversational a character-by-character fashion for use in conversational
services, often as a text equivalent to voice-based services, often as a text equivalent to voice-based
conversational services. Conversational text is defined in the conversational services. Conversational text is defined in the
ITU-T Framework for multimedia services, Recommendation F.700 ITU-T Framework for multimedia services, Recommendation F.700
[RFC5194]. [RFC5194].
Web - for realtime aspects of web conferencing; mutually exclusive Multiplex - an application wherein media of different forms (e.g.,
of both Immersive and Desktop video experiences audio and video) is multiplexed within the same media flow.
+--------------------------------------------------------------------+ +----------------------+---------------------+---------------------+
|Traffic Class | | Tolerance to | | Category | Application | Adjective |
| Name | Traffic Characteristics | Loss |Delay |Jitter| +----------------------+---------------------+---------------------+
|===============+===============================+======+======+======| | conversational | audio | immersive |
| | High priority, typically | Very | Very | Very | | | | avconf |
|Conversational | small packets (large video | Low | Low | Low | | | | aq:admitted |
| | frames produce large packets),| | | | | | | aq:non-admitted |
| | generally sustained high | | | | | | | aq:partial |
| | packet rate, low inter-packet | | | | | | | aq:none |
| | transmission interval, | | | | | | | |
| | usually UDP framed in (S)RTP | | | | | | video | immersive |
+---------------+-------------------------------+------+------+------+ | | | avconf |
| | | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
| | | |
| | text | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
| | | |
| | multiplex | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
+----------------------+---------------------+---------------------+
Figure 1. Conversational Traffic Characteristics Figure 3. Conversational Applications and Adjective Combinations
2.2 Multimedia-Conferencing Category Traffic Class 4.2 Multimedia-Conferencing Category Traffic Class
Multimedia-Conferencing traffic class is best suited for The "multimedia-conferencing" traffic class is best suited for
applications that are generally intended for communication between applications that are generally intended for communication between
human users, but are less demanding in terms of delay, packet loss, human users, but are less demanding in terms of delay, packet loss,
and jitter than what Conversational applications require. These and jitter than what conversational applications require. These
applications require low to medium delay and may have the ability to applications require low to medium delay and may have the ability to
change encoding rate (rate adaptive) or transmit data at varying change encoding rate (rate adaptive) or transmit data at varying
rates. The following application components are appropriate for use 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, usually TCP-based | | | |
+---------------+-------------------------------+------+------+------+
Figure 4. Multimedia Conferencing Traffic Characteristics
Multimedia-conferencing flows are not to be media based. Media
sessions use other categories. Multimedia-conferencing flows are
those data flows that are typically transmitted in parallel to
currently active 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: with the Multimedia-Conferencing category:
o application-sharing (that webex does or protocols like T.128) - o application-sharing (that webex does or protocols like T.128) -
An application that shares the output of one or more running An application that shares the output of one or more running
applications or the desktop on a host. This can utilize applications or the desktop on a host. This can utilize
vector graphics, raster graphics or video. vector graphics, raster graphics or video.
o Presentation-data - can be a series of still images or motion o presentation-data - can be a series of still images or motion
video. video.
o Whiteboarding - an application enabling the exchange of graphical o whiteboarding - an application enabling the exchange of graphical
information including images, pointers and filled and information including images, pointers and filled and
unfilled parametric drawing elements (points, lines, unfilled parametric drawing elements (points, lines,
polygons and ellipses). polygons and ellipses).
o (RTP-based) file transfer o (RTP-based) file-transfer
o Web (conference) chat/instant messaging 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 |
| | | |
| | 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
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 | |Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| Multimedia | Variable size packets, | Low | Low | Low | | realtime- | Inelastic, mostly variable | Low | Very | Low |
| Conferencing | Variable transmit interval, | - | - | - | | interactive | rate, rate increases with | | Low | |
| | rate adaptive, reacts to |Medium|Medium|Medium| | | user activity | | | |
| | loss, usually TCP-based | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 2. Multimedia Conferencing Traffic Characteristics Figure 6. Realtime Interactive Traffic Characteristics
2.3 Realtime-Interactive Category Traffic Class
Realtime-Interactive traffic class is intended for interactive The following application components are
variable rate inelastic applications that require low jitter and
loss and very low delay. The following application components are
appropriate for use with the Realtime-Interactive category: appropriate for use with the Realtime-Interactive category:
o Gaming - interactive player video games with other users on other o gaming - interactive player video games with other users on other
hosts (e.g., Doom) hosts (e.g., Doom)
o Virtualized desktop (interactive) - similar to an X-windows o remote-desktop - controlling a remote node with local peripherals
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) (i.e., monitor, keyboard and mouse)
o Telemetry - a communication that allows remote measurement and o telemetry - a communication that allows remote measurement and
reporting of information (e.g., post launch missile status or reporting of information (e.g., post launch missile status or
energy monitoring) energy monitoring)
+--------------------------------------------------------------------+ With adjective substrings to the above
|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 3. Realtime Interactive Traffic Characteristics
2.4 Multimedia-Streaming Category 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. The following
application components are appropriate for use with the
Multimedia-Streaming category:
o Audio (see Section 2.1)
o Video (see Section 2.1) 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
an computer application with no local storage.
o Multiplex (i.e., combined a/v streams) +----------------------+---------------------+---------------------+
| Category | Application | Adjective |
+----------------------+---------------------+---------------------+
| realtime-interactive | gaming | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
| | | |
| | remote-desktop | virtual |
| | | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
| | | |
| | telemetry | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
+----------------------+---------------------+---------------------+
With adjective substrings to the above (which may or may not get Figure 7. Realtime-Interactive Applications and Adjective
IANA registered) Combinations
Webcast 4.4 Multimedia-Streaming Category Traffic Class
The primary difference from the Multimedia-streaming category class The "multimedia-streaming" traffic class is best suited for variable
and the Broadcast category class is about the length of time for rate elastic streaming media applications where a human is waiting
buffering. Buffered streaming audio and/or video which are initiated for output and where the application has the capability to react to
by SDP, and not HTTP. Buffering here can be from many seconds to packet loss by reducing its transmission rate.
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 class (which has minimal or no buffering).
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|Traffic Class | | Tolerance to | |Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| Multimedia | Variable size packets, |Low - |Medium| High | | multimedia- | Variable size packets, |Low - |Medium| High |
| Streaming | elastic with variable rate |Medium|- High| | | streaming | elastic with variable rate |Medium|- High| |
| | | | | | | | | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 4. Multimedia Streaming Traffic Characteristics Figure 8. Multimedia Streaming Traffic Characteristics
2.5 Broadcast Category Traffic Class The following application components are appropriate for use with
the Multimedia-Streaming category:
Broadcast traffic class is best suited for inelastic streaming media o audio (see Section 4.1)
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. The following application components are appropriate for use
with the Broadcast category:
o Audio (see Section 2.1) o video (see Section 4.1)
o Video (see Section 2.1) o webcast
o Multiplex (i.e., combined a/v streams) o multiplex (see Section 4.1)
With adjective substrings to the above: The primary difference from the multimedia-streaming category and
the broadcast category is about the length of time for buffering.
Buffered streaming audio and/or video which are initiated by SDP,
and not HTTP. 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).
o IPTV +----------------------+---------------------+---------------------+
| 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 | live |
| | | 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
o Live events (non-buffered) 4.5 Broadcast Category Traffic Class
o surveillance - one way audio from a microphone or video from a The "broadcast" traffic class is best suited for inelastic streaming
camera (e.g., observing a parking lot or building exit), media Applications, which might have a 'wardrobe malfunction' delay
typically enabled for long periods of time, usually stored at or near the source but not typically at the destination, that may
at the destination. 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 | |Traffic Class | | Tolerance to |
--------------------------------------------------------------------+
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| Broadcast | Constant and variable rate, | Very |Low - |Low - | | broadcast | Constant and variable rate, | Very |Low - |Low - |
| | inelastic, generally | Low |Medium|Medium| | | inelastic, generally | Low |Medium|Medium|
| | non-bursty flows, generally | | | | | | non-bursty flows, generally | | | |
| | sustained high packet rate, | | | | | | sustained high packet rate, | | | |
| | low inter-packet transmission | | | | | | low inter-packet transmission | | | |
| | interval, usually UDP framed | | | | | | interval, usually UDP framed | | | |
| | in (S)RTP | | | | | | in (S)RTP | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 5. Broadcast Traffic Characteristics Figure 10. Broadcast Traffic Characteristics
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-class-label
traffic-class-label = "trafficclass" ":" [SP] category
"." application *( "." adjective )
category = "Broadcast" /
"Realtime-Interactive" /
"Multimedia-Conferencing" /
"Multimedia-Streaming" /
"Conversational" / tcl-token
application = tcl-token
adjective = classified-adjective /
unclassified-adjective
classified-adjective = tcl-token ":" tcl-token
unclassified-adjective = tcl-token
tcl-token = %2D / %30-%39 / %41-%5A / %61-7A
The attribute is named "trafficclass", for traffic classification,
identifying which one of the five categories applies to the
media stream associated with this m-line. There MUST NOT be more
than one category component per media line.
The category 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 | Category 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 |
+-------------------------+------------------------------+
Figure 6. Label Change 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 2 of this document.
A category is a human understandable categorization, and MUST NOT be
the only component of the traffic class label present in the
attribute. The category string MUST always be paired with an
application component, with a "." as the component separator.
The application types define the application of a particular traffic
flow, for example, audio or video. The application types are listed
and defined in Section 2 of this document. Not every category is
paired with application each listed, 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 components
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 component, but
these MUST be prefaced by the additional delimiter "_", creating a
possibility such as
category.application-type.adjective._non-standard-adjective
^^^^
See the underscore
For example, this is valid:
m=video 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 MUST NOT occur, such as the
following:
m=video 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 component types matter,
but not the order of the adjective components. There might be local
significance to the ordering of adjectives though. In other words,
the category class component MUST be before the application
component, which MUST be before any and all adjective component(s).
Some algorithm such as alphabetizing the list and matching the
understood strings SHOULD be used.
Adjectives can be either unqualified or qualified. Qualified
adjectives have a delimiter ":" after the previous "." separating
the string component into two parts.
The tcl-token "aq" is the first part of an adjective if it is
qualified, and either the "admitted", "non-admitted" or "none"
tcl-token is the second part of the qualified adjective allowable
according to this specification. In the form
aq:admitted|non-admitted|none
The only valid use of the tcl-token "aq" is to pair with either the
"admitted", "non-admitted" or "none" tcl-token. At the same time,
the tcl-tokens "admitted", "non-admitted" or "none" MUST NOT appear
without a preceding "aq:".
Like all adjectives, it is OPTIONAL to include this adjective in any
trafficclass attribute, and has the following meanings:
- aq - for 'admission qualifier' to indicate the purpose of The following application components are appropriate for use with
the following adjective parts with respect to the the Broadcast category:
capacity admission status of this traffic flow
described by this m-line.
- admitted - capacity admission mechanisms or protocols are to be or o audio (see Section 4.1)
were used for the full amount of bandwidth in relation
to this m= line.
- non-admitted - capacity admission mechanisms or protocols were o video (see Section 4.1)
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
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.
- none - no capacity admission mechanisms or protocols are or o iptv
were attempted in relation to this m= line.
The default for any flow generated from an m-line not having a o multiplex (see Section 4.1)
trafficclass adjective of 'aq:admitted' or 'aq:non-admitted' MUST be
the equivalent of 'aq:none', whether or not it is present.
Any category class, application, or adjective string component With adjective substrings to the above:
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 during processing.
Not understanding the category class string SHOULD mean that this o live (non-buffered)
attribute is ignored.
The following is an example of media level description with a o surveillance - one way audio from a microphone or video from a
'trafficclass' attribute: camera (e.g., observing a parking lot or building exit),
typically enabled for long periods of time, usually stored
at the destination.
m=video 50000 RTP/AVP 112 +----------------------+---------------------+---------------------+
a=trafficclass conversational.video.immersive.aq:admitted | 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 |
| | | |
| | iptv | live |
| | | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
| | | |
| | multiplex | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
+----------------------+---------------------+---------------------+
The above indicates a Telepresence session that has had capacity Figure 11. Broadcast Applications and Adjective Combinations
admission process applied to its media flow.
4. Offer/Answer Behavior 5. Offer/Answer Behavior
Through the inclusion of the 'trafficclass' attribute, an Through the inclusion of the 'trafficclass' attribute, an
offer/answer exchange identifies the application type for use by offer/answer exchange identifies the application type for use by
endpoints within a session. Policy elements can use this attribute endpoints within a session. Policy elements can use this attribute
to determine the acceptability and/or treatment of that session to determine the acceptability and/or treatment of that session
through lower layers. One specific use-case is for setting of the through lower layers. One specific use-case is for setting of the
DSCP specific for that application type (say a Broadcast instead DSCP specific for that application type (say a broadcast instead
of a Conversational video), decided on a per domain basis - of a conversational video), decided on a per domain basis -
instead of exclusively by the offering domain. instead of exclusively by the offering domain.
4.1 Offer Behavior 5.1 Offer Behavior
Offerers include the 'trafficclass' attribute with a single string Offerers include the 'trafficclass' attribute with a single string
comprised of two or more components (from the list in Section 2) to comprised of two or more components (from the list in Section 2) to
obtain configurable and predictable classification between the obtain configurable and predictable classification between the
answerer and the offerer. The offerer can also include a private set answerer and the offerer. The offerer can also include a private set
of components, or a combination of IANA registered and private of components, or a combination of IANA registered and private
components within a single domain (e.g., enterprise networks). components within a single domain (e.g., enterprise networks).
Offerers of this 'trafficclass' attribute MUST NOT change the label Offerers of this 'trafficclass' attribute MUST NOT change the label
in transit (e.g., wrt to B2BUAs). Session Border Controllers (SBC) in transit (e.g., wrt to B2BUAs). Session Border Controllers (SBC)
at domain boundaries can change this attribute through local policy. at domain boundaries can change this attribute through local policy.
Offers containing a 'trafficclass' label not understood are ignored Offers containing a 'trafficclass' label not understood are ignored
by default (i.e., as if there was no 'trafficclass' attribute in the by default (i.e., as if there was no 'trafficclass' attribute in the
offer). offer).
4.2 Answer Behavior 5.2 Answer Behavior
Upon receiving an offer containing a 'trafficclass' attribute, if Upon receiving an offer containing a 'trafficclass' attribute, if
the offer is accepted, the answerer will use this attribute to the offer is accepted, the answerer will use this attribute to
classify the session or media (level) traffic accordingly towards classify the session or media (level) traffic accordingly towards
the offerer. This answer does not need to match the traffic class in 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. the offer, though this will likely be the case most of the time.
In order to understand the traffic class attribute, the answerer In order to understand the traffic class attribute, the answerer
MUST check several components within the attribute, such as MUST check several components within the attribute, such as
skipping to change at page 16, line 14 skipping to change at page 20, line 21
the offer. This will at least aid the local domain, and perhaps the offer. This will at least aid the local domain, and perhaps
each domain the session transits, to categorize the application type each domain the session transits, to categorize the application type
of this RTP session. of this RTP session.
Answerers that are middleboxes can use the 'trafficclass' attribute Answerers that are middleboxes can use the 'trafficclass' attribute
to classify the RTP traffic within this session however local policy to classify the RTP traffic within this session however local policy
determines. In other words, this attribute can help in deciding determines. In other words, this attribute can help in deciding
which DSCP an RTP stream is assigned within a domain, if the which DSCP an RTP stream is assigned within a domain, if the
answerer were an inbound SBC to a domain. answerer were an inbound SBC to a domain.
5. Security considerations 6. Security considerations
RFC 5897 [RFC5897] discusses many of the pitfalls of service RFC 5897 [RFC5897] discusses many of the pitfalls of service
classification, which is similar enough to this idea of traffic classification, which is similar enough to this idea of traffic
classification to apply here as well. That document highly classification to apply here as well. That document highly
recommends the user not being able to set any classification. recommends the user not being able to set any classification.
Barring a hack within an endpoint (i.e., to intentionally Barring a hack within an endpoint (i.e., to intentionally
misclassifying (i.e., lying) about which classification an RTP misclassifying (i.e., lying) about which classification an RTP
stream is), this document's solution makes the classification part stream is), this document's solution makes the classification part
of the signaling between endpoints, which is recommended by RFC of the signaling between endpoints, which is recommended by RFC
5897. 5897.
6. IANA considerations 7. IANA considerations
6.1 Registration of the SDP 'trafficclass' Attribute 7.1 Registration of the SDP 'trafficclass' Attribute
This document requests IANA to register the following SDP att-field This document requests IANA to register the following SDP att-field
under the Session Description Protocol (SDP) Parameters registry: under the Session Description Protocol (SDP) Parameters registry:
Contact name: jmpolk@cisco.com Contact name: jmpolk@cisco.com
Attribute name: trafficclass Attribute name: trafficclass
Long-form attribute name: Traffic Classification Long-form attribute name: Traffic Classification
skipping to change at page 16, line 47 skipping to change at page 21, line 4
Long-form attribute name: Traffic Classification Long-form attribute name: Traffic Classification
Type of attribute: Session and Media levels Type of attribute: Session and Media levels
Subject to charset: No Subject to charset: No
Purpose of attribute: To indicate the Traffic Classification Purpose of attribute: To indicate the Traffic Classification
application for this session application for this session
Allowed attribute values: IANA Registered Tokens Allowed attribute values: IANA Registered Tokens
Registration Procedures: Specification Required Registration Procedures: Specification Required
Type SDP Name Reference Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
att-field (both session and media level) att-field (both session and media level)
trafficclass [this document] trafficclass [this document]
6.2 The Traffic Classification Category Registration 7.2 The Traffic Classification Category Registration
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
traffic Category classes similar to the following table within traffic Category classes similar to the following table within
the Session Description Protocol (SDP) Parameters registry: the Session Description Protocol (SDP) Parameters registry:
Registry Name: "trafficclass" SDP Category Attribute Values Registry Name: "trafficclass" SDP Category Attribute Values
Reference: [this document] Reference: [this document]
Registration Procedures: Standards-Track document Required Registration Procedures: Standards-Track document Required
Category Values Reference Category Values Reference
---------------- --------- ---------------- ---------
Broadcast [this document] broadcast [this document]
Realtime-Interactive [this document] realtime-interactive [this document]
Multimedia-Conferencing [this document] multimedia-conferencing [this document]
Multimedia-Streaming [this document] multimedia-streaming [this document]
Conversational [this document] conversational [this document]
6.3 The Traffic Classification Application Type Registration 7.3 The Traffic Classification Application Type Registration
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
traffic application classes similar to the following table traffic application classes similar to the following table
within the Session Description Protocol (SDP) Parameters registry: within the Session Description Protocol (SDP) Parameters registry:
Registry Name: "trafficclass" Attribute Application Type Values Registry Name: "trafficclass" SDP Application Attribute Type Values
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required
Application Values Reference Application Values Reference
------------------ --------- ------------------ ---------
Audio [this document] audio [this document]
Video [this document] video [this document]
Text [this document] text [this document]
Application-sharing [this document] application-sharing [this document]
Presentation-data [this document] presentation-data [this document]
Whiteboarding [this document] whiteboarding [this document]
Webchat/IM [this document] instant-messaging [this document]
Gaming [this document] gaming [this document]
Virtualized-desktop [this document] remote-desktop [this document]
Remote-desktop [this document] telemetry [this document]
Telemetry [this document] multiplex [this document]
Multiplex [this document] webcast [this document]
Webcast [this document] iptv [this document]
IPTV [this document]
Live-event [this document]
surveillance [this document]
6.4 The Traffic Classification Unqualified Adjective Registration 7.4 The Traffic Classification Adjective Registration
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
traffic adjective values similar to the following table traffic adjective values similar to the following table
within the Session Description Protocol (SDP) Parameters registry: within the Session Description Protocol (SDP) Parameters registry:
Registry Name: "trafficclass" Attribute Adjective Values Registry Name: "trafficclass" SDP Adjective Attribute Values
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required
Adjective Values Reference Adjective Values Reference
------------------ --------- ------------------ ---------
Immersive [this document] immersive [this document]
Desktop-video [this document] avconf [this document]
Realtime-Text [this document] realtime [this document]
web [this document] web [this document]
aq [this document] virtual [this document]
admitted [this document] live [this document]
non-admitted [this document] surveillance [this document]
none [this document] aq:admitted [this document]
aq:non-admitted [this document]
aq:partial [this document]
aq:none [this document]
7. Acknowledgments 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 Table 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: TBD
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 Table 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: TBD
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 Table 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: TBD
7.5.4 Multimedia-Streaming
This document requests IANA to create a new registry for the
Multimedia-Streaming category mapping similar to Table 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: TBD
7.5.5 Conversational Applications and Adjective Combinations
This document requests IANA to create a new registry for the
conversational category mapping similar to Table 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: TBD
8. Acknowledgments
To Dave Oran, Toerless Eckert, Henry Chen, David Benham, David To Dave Oran, Toerless Eckert, Henry Chen, David Benham, David
Benham, Mo Zanty, Michael Ramalho, Glen Lavers, Charles Ganzhorn, Benham, Mo Zanty, Michael Ramalho, Glen Lavers, Charles Ganzhorn,
Paul Kyzivat and Greg Edwards for their comments and suggestions. Paul Kyzivat, Greg Edwards, Charles Eckel, Dan Wing, Cullen Jennings
and Peter Saint-Andre for their comments and suggestions.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels", RFC 2119, March 1997
[RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997 Functional Specification", RFC 2205, September 1997
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and Differentiated Services Field (DS Field) in the IPv4 and
skipping to change at page 19, line 27 skipping to change at page 24, line 50
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code
Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, Point (DSCP) for Capacity-Admitted Traffic", RFC 5865,
May 2010 May 2010
[RFC5897] J. Rosenberg, "Identification of Communications Services in [RFC5897] J. Rosenberg, "Identification of Communications Services in
the Session Initiation Protocol (SIP)", RFC 5897, June 2010 the Session Initiation Protocol (SIP)", RFC 5897, June 2010
8.2. Informative References 9.2. Informative References
[RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for
Diffserv Service Classes", RFC 4594, August 2006 Diffserv Service Classes", RFC 4594, August 2006
[ID-RSVP-PROF] J. Polk, S. Dhesikan, "Resource Reservation Protocol [ID-RSVP-PROF] J. Polk, S. Dhesikan, "Resource Reservation Protocol
(RSVP) Application-ID Profiles for Voice and Video Streams", (RSVP) Application-ID Profiles for Voice and Video Streams",
work in progress, Mar 2011 work in progress, Feb 2013
Author's Addresses Author's Addresses
James Polk James Polk
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas, USA Colleyville, Texas, USA
+1.818.271.3552 +1.818.271.3552
mailto: jmpolk@cisco.com mailto: jmpolk@cisco.com
skipping to change at page 20, line 4 skipping to change at page 25, line 24
+1.818.271.3552 +1.818.271.3552
mailto: jmpolk@cisco.com mailto: jmpolk@cisco.com
Subha Dhesikan Subha Dhesikan
170 W Tasman St 170 W Tasman St
San Jose, CA, USA San Jose, CA, USA
+1.408-902-3351 +1.408-902-3351
mailto: sdhesika@cisco.com mailto: sdhesika@cisco.com
Paul E. Jones Paul E. Jones
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC, USA Research Triangle Park, NC, USA
+1 919 476 2048 +1 919 476 2048
mailto: paulej@packetizer.com mailto: paulej@packetizer.com
Appendix - Changes from Previous Versions Appendix - Changes from Previous Versions
A.1 From -01 to -02 A.1 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
category.
- added the 'partial' admission qualifier for those flows that have
only part of their respective flow admitted (i.e., CAC'd).
A.2 From -01 to -02
These are the following changes made between the WG -01 version and These are the following changes made between the WG -01 version and
the -02 version: the -02 version:
- converged the use of terms 'parent' and 'category' to just - converged the use of terms 'parent' and 'category' to just
'category' for consistency. 'category' for consistency.
- changed ABNF to reflect extensibility by not having applications - changed ABNF to reflect extensibility by not having applications
and adjectives named in the ABNF, rather have them merely IANA and adjectives named in the ABNF, rather have them merely IANA
registered. registered.
- merged the qualified and unqualified adjective sections into a - merged the qualified and unqualified adjective sections into a
single section on adjectives, but allowing some to have a single section on adjectives, but allowing some to have a
preceding qualifier. preceding qualifier.
skipping to change at page 20, line 31 skipping to change at page 26, line 22
- changed ABNF to reflect extensibility by not having applications - changed ABNF to reflect extensibility by not having applications
and adjectives named in the ABNF, rather have them merely IANA and adjectives named in the ABNF, rather have them merely IANA
registered. registered.
- merged the qualified and unqualified adjective sections into a - merged the qualified and unqualified adjective sections into a
single section on adjectives, but allowing some to have a single section on adjectives, but allowing some to have a
preceding qualifier. preceding qualifier.
- text clean-up - text clean-up
A.2 From -00 to -01 A.3 From -00 to -01
These are the following changes made between the WG -00 version and These are the following changes made between the WG -00 version and
the -01 version: the -01 version:
- removed the non-SDP applications Netflix and VOD - removed the non-SDP applications Netflix and VOD
- switched the adjective 'desktop' to 'avconf' - switched the adjective 'desktop' to 'avconf'
- Labeled each of the figures. - Labeled each of the figures.
 End of changes. 114 change blocks. 
415 lines changed or deleted 699 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/