draft-ietf-mmusic-traffic-class-for-sdp-04.txt   draft-ietf-mmusic-traffic-class-for-sdp-05.txt 
Network WG James Polk Network WG James Polk
Internet-Draft Subha Dhesikan Internet-Draft Subha Dhesikan
Expires: January 14, 2014 Paul Jones Expires: January 3, 2015 Paul Jones
Intended Status: Standards Track (PS) Cisco Systems Intended Status: Standards Track (PS) Cisco Systems
July 14, 2013 July 3, 2014
The Session Description Protocol (SDP) 'trafficclass' Attribute The Session Description Protocol (SDP) 'trafficclass' Attribute
draft-ietf-mmusic-traffic-class-for-sdp-04 draft-ietf-mmusic-traffic-class-for-sdp-05
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 14, 2014. This Internet-Draft will expire on July 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
5.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 20 5.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 20
6. Security considerations . . . . . . . . . . . . . . . . . . . 21 6. Security considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 27
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction 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
specifics to the offerer. These session specifics include offering specifics to the offerer. These session specifics include offering
the codec or codecs to choose from, the specific IP address and port 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 number the offerer wants to receive the RTP stream(s) on/at, the
particulars about the codecs the offerer wants considered or particulars about the codecs the offerer wants considered or
mandated, and so on. mandated, and so on.
skipping to change at page 4, line 18 skipping to change at page 4, line 15
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 A lower layer mechanism for differentiating traffic is either the
number or the Differentiated Services Codepoint (DSCP) value port 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 value likely will be best effort part of a managed service, the DSCP value likely will be best effort
(BE), or reset to BE when ingressing a provider's network. Within (BE), or reset to BE, at ingress to a provider's network. Within
the corporate LAN, this is usually completely configurable and a the corporate LAN, this is usually completely configurable and a
local IT department can take full advantage of this labeling to local IT department can take full advantage of this labeling to
shape and 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
skipping to change at page 5, line 24 skipping to change at page 5, line 21
[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
discusses and proposes traffic indications in SDP.] discusses and proposes traffic indications in SDP.]
This document proposes a simple attribute line to identify the This document proposes a simple attribute line to identify the
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 utilizes the traffic classes originally created in RFC
4594 in Section 2, incrementing each class with application 4594 in Section 2, enhancing each class with application identifiers
identifiers and optional adjective strings. Section 3 defines the and optional adjective strings. Section 3 defines the new SDP
new SDP attribute "trafficclass". Section 4 discusses the offerer attribute "trafficclass". Section 4 discusses the offerer and
and answerer behavior when generating or receiving this attribute. 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 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, called components, allowing for several more to be included parts, called components, allowing for several more to be included
further distinguishing a particular session's traffic classification further distinguishing a particular session's traffic classification
from another session's traffic classification. The amount of from another session's traffic classification. The amount of
indicated differentiation between sessions is not a goal, and should indicated differentiation between sessions is not a goal, and should
only have additional components for differentiation if there is a only have additional components for differentiation if there is a
need to uniquely identify traffic in different sessions. need to uniquely identify traffic in different sessions.
skipping to change at page 6, line 7 skipping to change at page 6, line 11
packets are in this session? packets are in this session?
The optional adjective component(s) (e.g., immersive) help to The optional adjective component(s) (e.g., immersive) help to
further refine the traffic within a session by providing more further refine the traffic within a session by providing more
description. For instance, if a session is two-way voice, what description. For instance, if a session is two-way voice, what
additional information can be given about this particular session to additional information can be given about this particular session to
refine its description? Is it part of a conference or telepresence refine its description? Is it part of a conference or telepresence
session? Is it just standalone voice call? Has a capacity admission session? Is it just standalone voice call? Has a capacity admission
protocol or mechanism been applied to this session? protocol or mechanism been applied to this session?
The traffic class label will have the following structure, The 'traffic class label' (TCL) will have the following structure,
category.application(.adjective)(.adjective)... category.application(.adjective)(.adjective)...
[Editor's Note: the above is not the exact 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
skipping to change at page 6, line 36 skipping to change at page 6, line 40
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. 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.
3. Traffic Class Attribute Definition 3. Traffic Class Attribute Definition
This document proposes the 'trafficclass' session and media-level This document defines the 'trafficclass' media-level SDP attribute.
SDP attribute. The following is the Augmented Backus-Naur Form The following is the Augmented Backus-Naur Form (ABNF) [RFC5234]
(ABNF) [RFC5234] syntax for this attribute, which is based on the syntax for this attribute, which is based on the SDP [RFC4566]
SDP [RFC4566] grammar: grammar:
attribute =/ traffic-class-label attribute =/ traffic-class-label
traffic-class-label = "trafficclass" ":" [SP] category traffic-class-label = "trafficclass" ":" [SP] category
"." application *( "." adjective ) "." application *( "." adjective )
category = "broadcast" / category = "broadcast" /
"realtime-interactive" / "realtime-interactive" /
"multimedia-conferencing" / "multimedia-conferencing" /
"multimedia-streaming" / "multimedia-streaming" /
skipping to change at page 7, line 17 skipping to change at page 7, line 35
adjective = classified-adjective / adjective = classified-adjective /
unclassified-adjective unclassified-adjective
classified-adjective = tcl-token ":" tcl-token classified-adjective = tcl-token ":" tcl-token
unclassified-adjective = tcl-token unclassified-adjective = tcl-token
tcl-token = ALPHA *( [ "-" ] ALPHA / DIGIT ) 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, The attribute is named "trafficclass", for traffic classification,
identifying which one of the six categories applies to the identifying which one of the six categories applies to the
media stream associated with this m-line. There MUST NOT be more media stream associated with this m-line. There MUST NOT be more
than one category component per media line. than one category component per SDP media line.
The categories in this document are an augmented version of the The categories in this document are an augmented version of the
application labels introduced by table 3 of RFC 4594 (which will be application labels introduced by table 3 of RFC 4594 (which will be
rewritten based on the updated labels and treatments expected for rewritten based on the updated labels and treatments expected for
each traffic class defined in this document). each traffic class defined in this document).
+-------------------------+------------------------------+ +-------------------------+------------------------------+
| Application Labels | Category Classes Defined | | Application Labels | Category Classes Defined |
| Defined in RFC 4594 | in this document | | Defined in RFC 4594 | in this document |
+=========================+==============================+ +=========================+==============================+
skipping to change at page 8, line 17 skipping to change at page 8, line 41
Any category, application, or adjective string component within this Any category, application, or adjective string component within this
attribute that is not understood MUST be ignored, leaving all that attribute that is not understood MUST be ignored, leaving all that
is understood to be processed. Ignored components SHOULD NOT be is understood to be processed. Ignored components SHOULD NOT be
deleted, as a downstream entity could understand the component(s) deleted, as a downstream entity could understand the component(s)
and use it/them during processing. and use it/them during processing.
The following is an example of media level description with a The following is an example of media level description with a
'trafficclass' attribute: 'trafficclass' attribute:
m=video 50000 RTP/AVP 112 m=video 50000 RTP/AVP 112
a=trafficclass conversational.video.immersive.aq:admitted a=trafficclass:conversational.video.immersive.aq:admitted
The above indicates the video part of a Telepresence session that The above indicates the video part of a Telepresence session that
has had capacity admission process applied to its media flow. has had capacity admission process applied to its media flow.
3.1 Categories within the SDP Traffic Class Label 3.1 Categories within the SDP Traffic Class Label
The category component within the traffic class attribute describes The category component within the traffic class attribute describes
the type of communication that will occur within that session. It the type of communication that will occur within that session. It
answers these questions, is the traffic answers these questions, is the traffic
- one-way or two-or-more-way interactive? - one-way or two-or-more-way interactive?
- elastic or inelastic (as far as retransmissions)?
- buffered or (virtually) non-buffered? - buffered or (virtually) non-buffered?
- media or non-media (data)? - media or non-media (data)?
The six category components of the traffic class attribute defined The six category components of the traffic class attribute defined
within this specification are as follows: within this specification are as follows:
o conversational o conversational
o multimedia-conferencing o multimedia-conferencing
o realtime-interactive o realtime-interactive
o multimedia-streaming o multimedia-streaming
o broadcast o broadcast
skipping to change at page 9, line 11 skipping to change at page 9, line 32
Not understanding the category component SHOULD mean that this Not understanding the category component SHOULD mean that this
attribute is ignored, because of the information about the attribute is ignored, because of the information about the
expected behavior of this communication flow is identified by or expected behavior of this communication flow is identified by or
within that component. within that component.
3.2 Applications within the SDP Traffic Class Label 3.2 Applications within the SDP Traffic Class Label
The application component identifies the application of a particular The application component identifies the application of a particular
traffic flow, for example, audio or video. The application types are traffic flow, for example, audio or video. The application types are
listed and defined in Section 2 of this document. Not every category listed and defined in Section 4 of this document. Not every category
is paired with every application listed, at least as defined in this is paired with every application listed, at least as defined in this
document. One or more applications are inappropriate in one or more document. One or more applications are inappropriate in one or more
categories. For example, iptv is a single directional traffic categories.
application that is suited for the broadcast (one-way) category
rather than categories like realtime-interactive or conversational.
Section 4.1 through 4.6 list many of the expected combinations. Section 4.1 through 4.6 list many of the expected combinations.
3.3 Adjectives within the SDP Traffic Class Label 3.3 Adjectives within the SDP Traffic Class Label
For additional application type granularity, adjective components For additional application type granularity, adjective components
can be added. One or more adjectives can be within the same traffic can be added. One or more adjectives can be within the same traffic
class attribute to provide more differentiation. class attribute to provide more differentiation.
It is important to note that while the order of component types It is important to note that while the order of component types
matter, the order of the adjective components do not. There might be matter, the order of the adjective components do not. In other
local significance to the ordering of adjectives though, such as words, the category class component MUST be before the application
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). component, which MUST be before any and all adjective component(s).
There is no limit to the number of adjectives allowed. There is no limit to the number of adjectives allowed.
Adjective components come in two versions, unqualified and Adjective components come in two versions, unqualified and
qualified. One has a prefix (qualified), the other (unqualified) qualified. One has a prefix (qualified), the other (unqualified)
does not. A defined qualified adjective MUST NOT appear without its does not. A defined qualified adjective MUST NOT appear without its
qualifier name, even in future extensions to this specification. qualifier name, even in future extensions to this specification.
Some implementations will likely perform a search within this Some implementations will likely perform a search within this
attribute for the presence of qualifiers, which might be as simple attribute for the presence of qualifiers, which might be as simple
skipping to change at page 10, line 5 skipping to change at page 10, line 21
necessary. necessary.
3.3.1 Qualified Adjectives 3.3.1 Qualified Adjectives
Adjectives can be either unqualified or qualified. Qualified Adjectives can be either unqualified or qualified. Qualified
adjectives have a delimiter ":" character between the "qualifier adjectives have a delimiter ":" character between the "qualifier
name" and the "qualifier value". As one example, we introduce in name" and the "qualifier value". As one example, we introduce in
this specification the "admission qualifier" and it has a qualifier this specification the "admission qualifier" and it has a qualifier
name of "aq". We also define several possible qualifier values for name of "aq". We also define several possible qualifier values for
the admission qualifier, namely "admitted", "non-admitted", the admission qualifier, namely "admitted", "non-admitted",
"partial", and "none". When present in a TCL string, the qualified "partial", and "none". When present in a TCL component, the
adjectives look like these admission qualifier adjectives: qualified adjectives look like these admission qualifier adjectives:
aq:admitted aq:admitted
aq:non-admitted aq:non-admitted
aq:partial aq:partial
aq:none aq:none
Defining some adjectives as qualified adjectives allows entities Defining some adjectives as qualified adjectives allows entities
processing the traffic class label to potentially recognize a processing the traffic class label to potentially recognize a
particular qualifier name and act on it, even if it does not particular qualifier name and act on it, even if it does not
understand the qualifier value. In the future, a new admission understand the qualifier value. In the future, a new admission
skipping to change at page 11, line 11 skipping to change at page 11, line 28
The default for any flow generated from an m-line not having a The default for any flow generated from an m-line not having a
trafficclass adjective of 'aq:admitted' or 'aq:non-admitted' MUST be trafficclass adjective of 'aq:admitted' or 'aq:non-admitted' MUST be
the equivalent of 'aq:none', whether or not it is present. the equivalent of 'aq:none', whether or not it is present.
4. Matching Categories with Applications and Adjectives 4. Matching Categories with Applications and Adjectives
This section describes each component within this document, as well This section describes each component within this document, as well
as provides the combinations of categories and applications and as provides the combinations of categories and applications and
adjectives. Given that not every combination makes sense, we express adjectives. Given that not every combination makes sense, we express
the limits here - which will be IANA registered. 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 4.1 Conversational Category Traffic Class
The "conversational" traffic class is best suited for applications 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. Conversational flows are multi-directional via an MCU communication. Conversational flows are
inelastic, and with few exceptions, use a UDP transport. inelastic, and with few exceptions, use a UDP transport.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Traffic Class | | Tolerance to | | Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| | High priority, typically | Very | Very | Very | | | High priority, typically | Very | Very | Very |
|conversational | small packets (large video | Low | Low | Low | |conversational | consistent sized packets | Low | Low | Low |
| | frames produce large packets),| | | | | | (small audio samples produce | | | |
| | generally sustained high | | | | | small packets and large video | | | |
| samples produce large packets),| | | |
| | generally sustained at a high | | | |
| | packet rate, low inter-packet | | | | | | packet rate, low inter-packet | | | |
| | transmission interval, | | | | | | transmission interval | | | |
| | usually UDP framed in (S)RTP | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 2. Conversational Traffic Characteristics Figure 2. Conversational Traffic Characteristics
The following application components are appropriate for use with The following application components are appropriate for use with
the Conversational category: the Conversational category:
o audio (voice) o audio (voice)
o video o video
o text (i.e., real-time text required by deaf users) o multiplex (i.e., combined a/v streams) an application wherein
media of different forms (e.g., audio and video) is multiplexed
o multiplex (i.e., combined a/v streams) within the same media flow.
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.
text - a term for real-time transmission of text in
a character-by-character fashion for use in conversational
services, often as a text equivalent to voice-based
conversational services. Conversational text is defined in the
ITU-T Framework for multimedia services, Recommendation F.700
[RFC5194].
Multiplex - an application wherein media of different forms (e.g.,
audio and video) is multiplexed within the same media flow.
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| Category | Application | Adjective | | Category | Application | Adjective |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| conversational | audio | immersive | | conversational | audio | immersive |
| | | avconf | | | | avconf |
| | | aq:admitted | | | | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | video | immersive | | | video | immersive |
| | | avconf | | | | avconf |
| | | aq:admitted | | | | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | text | aq:admitted | | | multiplex | immersive |
| | | aq:non-admitted | | | | avconf |
| | | aq:partial | | | | aq:admitted |
| | | aq:none |
| | | |
| | multiplex | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
Figure 3. Conversational Applications and Adjective Combinations Figure 3. Conversational Applications and Adjective Combinations
4.2 Multimedia-Conferencing Category Traffic Class 4.2 Multimedia-Conferencing Category Traffic Class
The "multimedia-conferencing" traffic class is best suited for The "multimedia-conferencing" traffic class is best suited for
skipping to change at page 13, line 22 skipping to change at page 13, line 25
change encoding rate (rate adaptive) or transmit data at varying change encoding rate (rate adaptive) or transmit data at varying
rates. rates.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| 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 | | multimedia- | Variable size packets, | Low | Low | Low |
| conferencing | Variable transmit interval, | - | - | - | | conferencing | Variable transmit interval, | - | - | - |
| | rate adaptive, reacts to |Medium|Medium|Medium| | | rate adaptive, reacts to |Medium|Medium|Medium|
| | loss, usually TCP-based | | | | | | loss, often one-way or | | | |
| | unidirectional | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 4. Multimedia Conferencing Traffic Characteristics Figure 4. Multimedia Conferencing Traffic Characteristics
Multimedia-conferencing flows are not to be media based. Media Multimedia-conferencing flows are not media flows which are
sessions use other categories. Multimedia-conferencing flows are conversational in nature. Multimedia-conferencing flows are those
those data flows that are typically transmitted in parallel to data flows that are typically transmitted in parallel to currently
currently active media flows. For example, a two-way conference active conversational media flows. For example, a two-way conference
session in which the users share a presentation. The presentation session in which the users share a presentation. The presentation
part of that conference call uses the Multimedia-conferencing part of that conference call uses the Multimedia-conferencing
category, whereas the audio and any video uses the conversational category, whereas the audio and any video uses the conversational
category indication. category indication.
The following application components are appropriate for use 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; could be at a
video. 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
part of a presentation.
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 as defined in RFC 5547
o instant messaging o instant messaging
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| Category | Application | Adjective | | Category | Application | Adjective |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| multimedia- | application-sharing | aq:admitted | | multimedia- | application-sharing | aq:admitted |
| conferencing | | aq:non-admitted | | conferencing | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | whiteboarding | aq:admitted | | | whiteboarding | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
skipping to change at page 14, line 22 skipping to change at page 14, line 33
| | whiteboarding | aq:admitted | | | whiteboarding | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | presentation-data | aq:admitted | | | presentation-data | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | 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 | | | instant-messaging | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | file-transfer | aq:admitted | | | file-transfer | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
skipping to change at page 15, line 5 skipping to change at page 15, line 25
| Traffic Class | | Tolerance to | | Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| realtime- | Inelastic, mostly variable | Low | Very | Low | | realtime- | Inelastic, mostly variable | Low | Very | Low |
| interactive | rate, rate increases with | | Low | | | interactive | rate, rate increases with | | Low | |
| | user activity | | | | | | user activity | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 6. Realtime Interactive Traffic Characteristics Figure 6. Realtime Interactive Traffic Characteristics
The following application components are The following application components are appropriate for use with
appropriate for use with the Realtime-Interactive category: 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 remote-desktop - controlling a remote node with local peripherals 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 With adjective substrings to the above
o virtual - To be used with the remote-desktop application component o virtual - To be used with the remote-desktop application component
specifically when the traffic is a virtual desktop similar to specifically when the traffic is a virtual desktop similar to
an X-windows station, has no local hard drive, or is operating an X-windows station, has no local hard drive, or is operating
an computer application with no local storage. a computer application with no local storage.
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| Category | Application | Adjective | | Category | Application | Adjective |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| realtime-interactive | gaming | aq:admitted | | realtime-interactive | gaming | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | remote-desktop | virtual | | | remote-desktop | virtual |
skipping to change at page 16, line 28 skipping to change at page 16, line 46
o audio (see Section 4.1) o audio (see Section 4.1)
o video (see Section 4.1) o video (see Section 4.1)
o webcast - is a media file distributed over the Internet or o webcast - is a media file distributed over the Internet or
enterprise network using streaming media technology. enterprise network using streaming media technology.
o multiplex (see Section 4.1) o multiplex (see Section 4.1)
The primary difference from the multimedia-streaming category and The primary difference between the multimedia-streaming category and
the broadcast category is about the length of time for buffering. the broadcast category is the length of time for buffering. Buffered
Buffered streaming audio and/or video which are initiated by SDP, streaming of audio and/or video which is often initiated by HTTP,
and not HTTP. Buffering here can be from many seconds to hours, and and not SDP. Buffering here can be from many seconds to hours, and
is typically at the destination end (as opposed to Broadcast is typically at the destination end (as opposed to Broadcast
buffering which is minimal at the destination). The buffering aspect buffering which is minimal at the destination). The buffering
is what differentiates this category class from the broadcast aspect is what differentiates this category class from the broadcast
category (which has minimal or no buffering). category (which has minimal or no buffering).
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| Category | Application | Adjective | | Category | Application | Adjective |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| multimedia-streaming | audio | aq:admitted | | multimedia-streaming | audio | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | video | aq:admitted | | | video | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | webcast | live | | | webcast | aq:admitted |
| | | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | multiplex | aq:admitted | | | multiplex | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
skipping to change at page 17, line 34 skipping to change at page 17, line 52
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| 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 | | | |
| | in (S)RTP | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 10. Broadcast Traffic Characteristics Figure 10. Broadcast Traffic Characteristics
The following application components are appropriate for use with The following application components are appropriate for use with
the Broadcast category: the Broadcast category:
o audio (see Section 4.1) o audio (see Section 4.1)
o video (see Section 4.1) o video (see Section 4.1)
o iptv - is one-way television content that, instead of being
delivered through traditional broadcast and cable formats,
is received by the viewer through the technologies used for
computer networks. IPTV is can be service provider or
enterprise network based.
o multiplex (see Section 4.1) o multiplex (see Section 4.1)
With adjective substrings to the above: With adjective substrings to the above:
o live (non-buffered) - refers to various types of media broadcast o live (non-buffered) - refers to various types of media broadcast
without a significant delay, typically measured in without a significant delay, typically measured in
milliseconds to a few seconds only. milliseconds to a few seconds only.
o surveillance - one way audio from a microphone or video from a o surveillance - one way audio from a microphone or video from a
camera (e.g., observing a parking lot or building exit), camera (e.g., observing a parking lot or building exit),
typically enabled for long periods of time, usually stored typically enabled for long periods of time, usually stored
at the destination. at the destination.
skipping to change at page 18, line 32 skipping to change at page 18, line 43
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | video | surveillance | | | video | surveillance |
| | | live | | | | live |
| | | aq:admitted | | | | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | | | | | |
| | iptv | live | | | multiplex | surveillance |
| | | live |
| | | aq:admitted | | | | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
| | | |
| | multiplex | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
Figure 11. Broadcast Applications and Adjective Combinations Figure 11. Broadcast Applications and Adjective Combinations
4.6 Intermittent Category Traffic Class 4.6 Intermittent Category Traffic Class
The "intermittent" traffic class is best suited for inconstant rate The "intermittent" traffic class is best suited for inconstant rate
applications such as those from a sensor device, where tolerance to applications such as those from a sensor device, where tolerance to
loss, delay and jitter is often medium to high in nature. This 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 category is not to be used for bulk file transfers, rather it can be
skipping to change at page 19, line 15 skipping to change at page 19, line 24
transmission, no matter how long the interval. transmission, no matter how long the interval.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Traffic Class | | Tolerance to | | Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| intermittent | Inconstant rate, infrequent |Medium|Medium| High | | intermittent | Inconstant rate, infrequent |Medium|Medium| High |
| | but sometimes bursty flows, |- High|- High| | | | but sometimes bursty flows, |- High|- High| |
| | generally non-regular, | | | | | | generally non-regular, | | | |
| | variable inter-packet | | | | | | variable inter-packet | | | |
| | transmission interval, can be | | | | | | transmission interval | | | |
| | UDP framed in (S)RTP or in | | | |
| | TCP/SCTP | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 12. Intermittent Traffic Characteristics Figure 12. Intermittent Traffic Characteristics
The following application components are appropriate for use with The following application components are appropriate for use with
the Broadcast category: 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, o sensor - a flow containing information obtained from a sensor,
such as a temperature or motion sensor. such as a temperature or motion sensor.
With adjective substrings to the above: With adjective substrings to the above:
o there are no defined adjectives for the 'sensor' application at o there are no defined adjectives for the 'sensor' application at
this time. There are many examples one could think would be viable this time. There are many examples one could think would be viable
adjectives, such as light, motion, temperature, magnetic fields, adjectives, such as light, motion, temperature, magnetic fields,
gravity, humidity, moisture, vibration, pressure, electrical gravity, humidity, moisture, vibration, pressure, electrical
fields, and other physical aspects of the external environment fields, and other physical aspects of the external environment
measured by the sensor. measured by the sensor.
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| Category | Application | Adjective | | Category | Application | Adjective |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| intermittent | sensor | (undefined at this | | intermittent | sensor | (undefined at this |
| | | time) | | | | time) |
| | | |
| | text | aq:admitted |
| | | aq:non-admitted |
| | | aq:partial |
| | | aq:none |
| | | |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
Figure 13. Intermittent Applications and Adjective Combinations Figure 13. Intermittent Applications and Adjective Combinations
5. 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(s) for use by
endpoints within a session. Policy elements can use this attribute the endpoints within the media streams of a session. Signaling
to determine the acceptability and/or treatment of that session elements can use this attribute to determine the acceptability
through lower layers. One specific use-case is for setting of the and/or treatment of that session through lower layers, communicating
DSCP specific for that application type (say a broadcast instead a desired treatment for a particular flow to endpoints using SDP,
of a conversational video), decided on a per domain basis - interacting with network elements using some unspecified mechanism,
instead of exclusively by the offering domain. or having endpoints communicate with network elements using some
unspecified mechanism.
5.1 Offer Behavior
Offerers include the 'trafficclass' attribute with a single string
comprised of two or more components (from the list in Section 2) to
obtain configurable and predictable classification between the
answerer and the offerer. The offerer can also include a private set
of components, or a combination of IANA registered and private
components within a single domain (e.g., enterprise networks).
Offerers of this 'trafficclass' attribute MUST NOT change the label
in transit (e.g., wrt to B2BUAs). Session Border Controllers (SBC)
at domain boundaries can change this attribute through local policy.
Offers containing a 'trafficclass' label not understood are ignored
by default (i.e., as if there was no 'trafficclass' attribute in the
offer).
5.2 Answer Behavior
Upon receiving an offer containing a 'trafficclass' attribute, if In order to understand the traffic class attribute, the SDP entity
the offer is accepted, the answerer will use this attribute to MUST check several components within the Traffic Class Label. By
classify the session or media (level) traffic accordingly towards understand, we mean that the value of each component of the TCL is
the offerer. This answer does not need to match the traffic class in recognized, i.e., both the category and application components
the offer, though this will likely be the case most of the time. 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.
In order to understand the traffic class attribute, the answerer The following pertains to both the receiver of an offer and receiver
MUST check several components within the attribute, such as of an answer when either or both contain a Traffic Class Label
attribute.
1 - does the answerer understand the category component? 1 - can the receiver of the SDP containing a trafficclass attribute
successfully process the category component?
If not, the attribute SHOULD be ignored. If not, the attribute SHOULD be ignored.
If yes, it checks the application component. If yes, it checks the application component.
2 - does the answerer understand 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 If not, the answerer needs to check if it has a local policy to
proceed without an application component. The default for this proceed without an application component. The default for this
situation is as if the category component was not understand, situation is as if the category component was not understood,
the attribute SHOULD be ignored. meaning the attribute SHOULD be ignored.
If yes, it checks to see if there are any adjective components If yes, it checks to see if there are any adjective components
present in this attribute to start its classification. present in this attribute to start its classification.
3 - does the answerer understand the adjective component or 3 - can the receiver of the SDP containing a trafficclass attribute
components if any are present? successfully process the adjective component or components if
any are present?
If not present, process and match the trafficclass label value If not present, process and match the trafficclass label value
as is. as is.
If yes, determine if there is more than one. Search for each If yes, determine if there is more than one. Search for each
that is understood. Any adjectives not understood are to be that is understood. Any adjectives not understood are to be
ignored, as if they are not present. Match all remaining ignored, as if they are not present. Match all remaining
understood components according to local policy and process understood components according to local policy and process
attribute. 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' The answerer will answer the offer with its own 'trafficclass'
attribute, which will likely be the same value, although this is not attribute, which will likely be the same value, although this is not
mandatory (at this time). The Offerer will process the received mandatory (at this time). The Offerer will process the received
answer just as the answerer processed the offer. In other words, the answer just as the answerer processed the offer. In other words, the
processing steps and rules are identical for each end. processing steps and rules are identical for each end (see Section
5).
The answerer should expect to receive RTP packets marked as
indicated by its 'trafficclass' attribute in the answer itself.
An Answer MAY have a 'trafficclass' attribute when one was not in An Answer MAY have a 'trafficclass' attribute when one was not in
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 and in some cases
of this RTP session. group the media-types of this session.
Answerers that are middleboxes can use the 'trafficclass' attribute
to classify the RTP traffic within this session however local policy
determines. In other words, this attribute can help in deciding
which DSCP an RTP stream is assigned within a domain, if the
answerer were an inbound SBC to a domain.
6. Security considerations 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 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.
skipping to change at page 22, line 4 skipping to change at page 22, line 34
7. IANA considerations 7. IANA considerations
7.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
Type of attribute: Session and Media levels Type of attribute: 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: (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 Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
att-field (both session and media level) att-field (media level)
trafficclass [this document] trafficclass [this document]
7.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 Action Required [RFC5226]
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]
intermittent [this document]
7.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" SDP Application Attribute Type Values Registry Name: "trafficclass" SDP Application Attribute Values
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required [RFC5226]
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]
presentation-video [this document]
presentation-audio [this document]
whiteboarding [this document] whiteboarding [this document]
instant-messaging [this document] instant-messaging [this document]
gaming [this document] gaming [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] sensor [this document]
7.4 The Traffic Classification 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" SDP Adjective Attribute Values Registry Name: "trafficclass" SDP Adjective Attribute Values
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required [RFC5226]
Adjective Values Reference Adjective Values Reference
------------------ --------- ------------------ ---------
immersive [this document] immersive [this document]
avconf [this document] avconf [this document]
realtime [this document] realtime [this document]
web [this document] web [this document]
virtual [this document] virtual [this document]
live [this document] live [this document]
surveillance [this document] surveillance [this document]
skipping to change at page 24, line 6 skipping to change at page 24, line 41
7.5.1 Broadcast Applications and Adjective Combinations 7.5.1 Broadcast Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
Broadcast category mapping similar to Figure 11 in Section 4.5 of Broadcast category mapping similar to Figure 11 in Section 4.5 of
this document within the Session Description Protocol (SDP) this document within the Session Description Protocol (SDP)
Parameters registry: Parameters registry:
Registry Name: Broadcast Applications and Adjective Combinations Registry Name: Broadcast Applications and Adjective Combinations
Table Table
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required [RFC5226]
7.5.2 Realtime Interactive Applications and Adjective Combinations 7.5.2 Realtime Interactive Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
Realtime Interactive category mapping similar to Figure 7 in Section Realtime Interactive category mapping similar to Figure 7 in Section
4.3 of this document within the Session Description Protocol (SDP) 4.3 of this document within the Session Description Protocol (SDP)
Parameters registry: Parameters registry:
Registry Name: Realtime Interactive Applications and Adjective Registry Name: Realtime Interactive Applications and Adjective
Combinations Table Combinations Table
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required [RFC5226]
7.5.3 Multimedia Conferencing Applications and Adjective Combinations 7.5.3 Multimedia Conferencing Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
Multimedia Conferencing category mapping similar to Figure 5 in Multimedia Conferencing category mapping similar to Figure 5 in
Section 4.2 of this document within the Session Description Protocol Section 4.2 of this document within the Session Description Protocol
(SDP) Parameters registry: (SDP) Parameters registry:
Registry Name: Multimedia Conferencing Applications and Adjective Registry Name: Multimedia Conferencing Applications and Adjective
Combinations Table Combinations Table
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required [RFC5226]
7.5.4 Multimedia-Streaming 7.5.4 Multimedia-Streaming Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
Multimedia-Streaming category mapping similar to Figure 9 in Section Multimedia-Streaming category mapping similar to Figure 9 in Section
4.4 of this document within the Session Description Protocol (SDP) 4.4 of this document within the Session Description Protocol (SDP)
Parameters registry: Parameters registry:
Registry Name: Multimedia-Streaming Applications and Adjective Registry Name: Multimedia-Streaming Applications and Adjective
Combinations Table Combinations Table
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required [RFC5226]
7.5.5 Conversational Applications and Adjective Combinations 7.5.5 Conversational Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
conversational category mapping similar to Figure 3 in Section 4.1 conversational category mapping similar to Figure 3 in Section 4.1
of this document within the Session Description Protocol (SDP) of this document within the Session Description Protocol (SDP)
Parameters registry: Parameters registry:
Registry Name: Conversational Applications and Adjective Registry Name: Conversational Applications and Adjective
Combinations Table Combinations Table
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required [RFC5226]
7.5.6 Intermittent Applications and Adjective Combinations 7.5.6 Intermittent Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
intermittent category mapping similar to Table 13 in Section 4.6 of intermittent category mapping similar to Table 13 in Section 4.6 of
this document within the Session Description Protocol (SDP) this document within the Session Description Protocol (SDP)
Parameters registry: Parameters registry:
Registry Name: Intermittent Applications and Adjective Registry Name: Intermittent Applications and Adjective
Combinations Table Combinations Table
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required [RFC5226]
7.6 Designated Expert Reviewers
The following will be the designated expert reviewers of new
'trafficclass' registry requests:
- James Polk <jmpolk@cisco.com>
- Paul E. Jones <paulej@packetizer.com>
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 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, Greg Edwards, Charles Eckel, Dan Wing, Cullen Jennings Paul Kyzivat, Greg Edwards, Charles Eckel, Dan Wing, Cullen Jennings
and Peter Saint-Andre for their comments and suggestions. and Peter Saint-Andre for their comments and suggestions.
9. References 9. References
skipping to change at page 26, line 13 skipping to change at page 27, line 10
2005 2005
[RFC4124] F. Le Faucheur, Ed., " Protocol Extensions for Support of [RFC4124] F. Le Faucheur, Ed., " Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering ", RFC 4124, Diffserv-aware MPLS Traffic Engineering ", RFC 4124,
June 2005 June 2005
[RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session [RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006 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 [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.
[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 [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
9.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
skipping to change at page 26, line 47 skipping to change at page 28, line 4
+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 -03 to -04 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 These are the following changes made between the WG -03 version and
the -04 version: the -04 version:
- minimal text changes. - minimal text changes.
- introduced the "intermittent" category based on IETF86 feedback in - introduced the "intermittent" category based on IETF86 feedback in
the WG. the WG.
A.2 From -02 to -03 A.3 From -02 to -03
These are the following changes made between the WG -02 version and These are the following changes made between the WG -02 version and
the -03 version: the -03 version:
- Rearranged a fair amount of text - Rearranged a fair amount of text
- Separated and defined the components into separate subsections. - Separated and defined the components into separate subsections.
- built 5 different tables, one per category, that lists within each - built 5 different tables, one per category, that lists within each
category - what applications are appropriate as well as what category - what applications are appropriate as well as what
adjectives are appropriate for each application within that adjectives are appropriate for each application within that
category. category.
- added the 'partial' admission qualifier for those flows that have - added the 'partial' admission qualifier for those flows that have
only part of their respective flow admitted (i.e., CAC'd). only part of their respective flow admitted (i.e., CAC'd).
A.3 From -01 to -02 A.4 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.
- text clean-up - text clean-up
A.4 From -00 to -01 A.5 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. 86 change blocks. 
175 lines changed or deleted 251 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/