draft-ietf-mmusic-traffic-class-for-sdp-01.txt   draft-ietf-mmusic-traffic-class-for-sdp-02.txt 
Network WG James Polk Network WG James Polk
Internet-Draft Subha Dhesikan Internet-Draft Subha Dhesikan
Expires: Sept 12, 2012 Paul Jones Expires: January 16, 2013 Paul Jones
Intended Status: Standards Track (PS) Cisco Systems Intended Status: Standards Track (PS) Cisco Systems
March 12, 2012 July 16, 2012
The Session Description Protocol (SDP) 'trafficclass' Attribute The Session Description Protocol (SDP) 'trafficclass' Attribute
draft-ietf-mmusic-traffic-class-for-sdp-01 draft-ietf-mmusic-traffic-class-for-sdp-02
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 September 12, 2012. This Internet-Draft will expire on January 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 String Definitions . . . . . . . 5
3. Traffic Class Attribute Definition . . . . . . . . . . . . . 11 3. Traffic Class Attribute Definition . . . . . . . . . . . . . 11
4. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 15 4. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 14
4.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 15 4.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 14
4.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 15 4.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 15
5. Security considerations . . . . . . . . . . . . . . . . . . . 16 5. Security considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 3, line 35 skipping to change at page 3, line 17
- inform the network on how to treat the traffic if the network is - inform the network on how to treat the traffic if the network is
configured to differentiate session treatments based on the type configured to differentiate session treatments based on the type
of session the RTP is, including the ability to provide call of session the RTP is, including the ability to provide call
admission control based on the type of traffic in the network. admission control based on the type of traffic in the network.
- 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 perhaps makes up a network such as a campus or series of links that make up a network such as a campus or WAN, or a
WAN, or a backbone. For example, a call center voice application backbone. For example, a call center voice application might get at
gets at least 20% of a link as a minimum bandwidth allocation. 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 to during busy hours of the day. For example, all desktop video might
operate at 1080p during non-peak times, but curtail a similar operate at 1080p during non-peak times, but a similar session might
session between the same users or devices to 720p or 360p during be curtailed between the same users or devices to 720p or 360p
peak hours. Another example would be to reduce the frames per during peak hours. Another example would be to reduce the frames
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 telepresense 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 Codepoints (DSCP)
that apply to many traffic types (table 3 of [RFC4594]), including that apply to many traffic types (table 3 of [RFC4594]), including
RTP based voice and video traffic sessions. The RFC also defines the RTP based voice and video traffic sessions. The RFC also defines the
per hop network behavior that is strongly encouraged for each of per hop network behavior that is strongly encouraged for each of
these application traffic types based on the traffic characteristics these application traffic types based on the traffic characteristics
and tolerances to delay, loss and jitter within each traffic class. 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 4 categories in that RFC, and voice into
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.
A question arises about once we properly label the traffic, what
does that get us? This is a fair question, but out of scope for
this document because that answer lies within other RFCs and IDs in
other WGs and/or Areas (specifically the Transport Area). That
said, we can discuss some of the ideas here for completeness.
If the application becomes aware of traffic labeling, 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 likely will be best effort (BE),
Within the corporate LAN, this is usually completely configurable or reset to BE when ingressing a provider's network. Within the
and a local IT department can take full advantage of this labeling corporate LAN, this is usually completely configurable and a local
to shape and manage their network as they see fit. Communications IT department can take full advantage of this labeling to shape and
between enterprise networks will likely have to take advantage of manage their network as they see fit.
MPLS.
Within a network core, where only MPLS is used, Diffserv typically Within a network core, DiffServ typically does not apply. That said,
does not apply. That said, Diffserv can be used to identify which DiffServ can be used to identify which traffic goes into which MPLS
traffic goes into which MPLS tunnels [RFC4124]. tunnel [RFC4124].
Labeling realtime traffic types using a layer 4 protocol would Labeling realtime traffic types using a layer 4 protocol would
likely mean 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 with this mechanism is for the label to 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 (set by each domain allow each domain to adjust the appropriate DSCP value (set by each
for use within that domain). Meaning, if a DSCP is set by an domain for use within that domain). Meaning, if a DSCP value is set
endpoint or a router in the first domain and gets reset by a SP, the by an endpoint or a router in the first domain and gets reset by a
far end domain will be able to reset the DSCP to the intended service provider, the far-end domain will be able to reset the DSCP
traffic class. There is a proposed extension to RSVP which creates value to the intended traffic class. There is a proposed extension
individual profiles for what goes into each app-ID field to describe to RSVP which creates individual profiles for what goes into each
these traffic classes [ID-RSVP-PROF], which will take advantage of app-ID field to describe these traffic classes [ID-RSVP-PROF], which
what is described in this document. will take advantage of what is described in this document.
There are several proprietary mechanisms to take advantage of this There are several proprietary mechanisms that can take advantage of
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 but one reason allowed to assign any identification (fraud is one reason given). In
given). In addition, RFC 5897 recommends that service identification addition, RFC 5897 recommends that service identification should be
should be done in signaling, rather than guessing or deep packet done in signaling, rather than guessing or deep packet inspection.
inspection. The network will have to currently guess or perform deep Any network currently would have to currently guess or perform deep
packet inspection to classify and offer the service as per RFC 4594 packet inspection to classify traffic and offer the service as per
since such service identification information is currently not RFC 4594 since such service identification information is currently
available in SDP and therefore to the network elements. Since SDP not available in SDP and therefore to the network elements. Since
understands how each stream is created (i.e., the particulars of the SDP understands how each stream is created (i.e., the particulars of
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 is only "service identification", but this document only
wanting to discuss and propose traffic indications discuss and propose traffic indications in SDP.]
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 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 String 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, allowing for several more to be included. The intention is to
have a parent class (e.g., Conversational) that merely serves as the have a category class (e.g., Conversational) that merely serves as
anchor point for an application component that when paired together, the anchor point for an application component that when paired
form the highest level traffic class. An adjective component together, form the highest level traffic class. An adjective
provides further granularity for the application. There can be more component provides further granularity for the application. There
than one adjective within a traffic class label to further refine can be more than one adjective within a traffic class label to
the uniqueness of a traffic class being described. further refine the uniqueness of a traffic class being described.
The traffic class label will have the following structure, The traffic class label will have the following structure,
parent.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 exactly the ABNF to be used.
The order is right. The parent and application The order is right. The category and application
MUST appear (each only once) and zero or more MUST appear first (each only once) and zero or more
adjectives can appear.] adjectives can appear following the application
component.]
Where Where
1) the 1st component is the human understandable category; 1) the 1st component is the human understandable category;
2) the 2nd component is the application; 2) the 2nd component is the application;
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;
and
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 parent 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 [Editor's Note: We're not yet sure how much of what's below will be
proposed for IANA registration, but the 5 parent proposed for IANA registration, but the 5 category
components will be, as well as at least some components will be, as well as at least some
application components per parent component. Some application components per category component. Some
adjective components will also likely be proposed adjective components will also likely be proposed
for IANA registration. for IANA registration.
The 5 parent components of the traffic class attribute are as The 5 category components of the traffic class attribute are as
follows: follows:
o Conversational o Conversational
o Multimedia Conferencing o Multimedia-Conferencing
o Real-Time Interactive o Realtime-Interactive
o Multimedia Streaming o Multimedia-Streaming
o Broadcast o Broadcast
The following application components of the traffic class attribute The following application components of the traffic class attribute
are as follows: are as follows:
o Audio o Audio
o Video o Video
o Text o Text
o application-sharing o application-sharing
o Presentation-data o Presentation-data
o Whiteboarding o Whiteboarding
o Web (conference) chat/instant messaging o Webchat/IM
o Gaming o Gaming
o Virtual-desktop (interactive) o Virtual-desktop (interactive)
o Remote-desktop o Remote-desktop
o Telemetry (e.g., NORAD missile control) o Telemetry (e.g., NORAD missile control)
o Multiplex (i.e., combined streams) o Multiplex (i.e., combined streams)
o Webcast o Webcast
o IPTV o IPTV
o Live-events (though not the buffered ones) o Live-events (one-way, in realtime)
o surveillance o surveillance
The following adjective components of the traffic class attribute The following adjective components of the traffic class attribute
are as follows: are as follows:
o Immersive o Immersive
o avconf o avconf
o Realtime-Text o Realtime-Text
o web o web
Each of the above 3 lists will be defined in the following Each of the above 3 lists will be defined in the following
subsections. subsections.
2.1 Conversational Parent Traffic Class 2.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 real-time, bi-directional person-to-person or enable realtime, bi-directional person-to-person or
multi-directional via an MTP communication, such as the following multi-directional via an MCU communication. The following
application components: application components are appropriate for use with 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 Text (i.e., real-time text required by deaf users)
**The above applications will also be used within Multimedia **The above applications will also be used within Multimedia
Streaming and Broadcast Streaming and Broadcast
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.
Desktop-video - An interactive audio-visual communication Avconf - An interactive audio-visual communication experience
experience that is not immersive in nature, though can have a that is not immersive in nature, though can have a high
high resolution video component. resolution video component.
Realtime-Text (RTT) - a term for real-time transmission of text in Realtime-Text (RTT) - 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 Web - for realtime aspects of web conferencing; mutually exclusive
of both Immersive and Desktop video experiences of both Immersive and Desktop video experiences
skipping to change at page 8, line 32 skipping to change at page 8, line 9
|Conversational | small packets (large video | Low | Low | Low | |Conversational | small packets (large video | Low | Low | Low |
| | frames produce large packets),| | | | | | frames produce large packets),| | | |
| | generally sustained high | | | | | | generally sustained high | | | |
| | packet rate, low inter-packet | | | | | | packet rate, low inter-packet | | | |
| | transmission interval, | | | | | | transmission interval, | | | |
| | usually UDP framed in (S)RTP | | | | | | usually UDP framed in (S)RTP | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 1. Conversational Traffic Characteristics Figure 1. Conversational Traffic Characteristics
2.2 Multimedia-Conferencing Parent Traffic Class 2.2 Multimedia-Conferencing Category Traffic Class
Multimedia-Conferencing traffic class is best suited for 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, such as the following application component: rates. The following application components are appropriate for use
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
skipping to change at page 9, line 21 skipping to change at page 8, line 49
| 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, usually TCP-based | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 2. Multimedia Conferencing Traffic Characteristics Figure 2. Multimedia Conferencing Traffic Characteristics
2.3 Realtime-Interactive Parent Traffic Class 2.3 Realtime-Interactive Category Traffic Class
Realtime-Interactive traffic class is intended for interactive Realtime-Interactive traffic class is intended for interactive
variable rate inelastic applications that require low jitter and variable rate inelastic applications that require low jitter and
loss and very low delay, such as the following application loss and very low delay. The following application components are
components: 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 Virtualized desktop (interactive) - similar to an X-windows
station, has no local hard drive, or is operating an station, has no local hard drive, or is operating an
application with nolocal storage application with no local storage
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)
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|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 3. Realtime Interactive Traffic Characteristics Figure 3. Realtime Interactive Traffic Characteristics
2.4 Multimedia-Streaming Parent Traffic Class 2.4 Multimedia-Streaming Category Traffic Class
Multimedia-Streaming traffic class is best suited for variable rate Multimedia-Streaming traffic class is best suited for variable rate
elastic streaming media applications where a human is waiting for elastic streaming media applications where a human is waiting for
output and where the application has the capability to react to output and where the application has the capability to react to
packet loss by reducing its transmission rate, such as the following packet loss by reducing its transmission rate. The following
application components: application components are appropriate for use with the
Multimedia-Streaming category:
o Audio o Audio (see Section 2.1)
o Video o Video (see Section 2.1)
o Multiplex (i.e., combined a/v streams) o Multiplex (i.e., combined a/v streams)
With adjective substrings to the above (which may or may not get With adjective substrings to the above (which may or may not get
IANA registered) IANA registered)
Webcast Webcast
The primary difference from the Multimedia-streaming parent class The primary difference from the Multimedia-streaming category class
and the Broadcast parent class is about the length of time for and the Broadcast category class is about the length of time for
buffering. Buffered streaming audio and/or video which are initiated buffering. Buffered streaming audio and/or video which are initiated
by SDP, and not HTTP. Buffering here can be from many seconds to by SDP, and not HTTP. Buffering here can be from many seconds to
hours, and is typically at the destination end (as opposed to hours, and is typically at the destination end (as opposed to
Broadcast buffering which is minimal at the destination). The Broadcast buffering which is minimal at the destination). The
buffering aspect is what differentiates this parent class from the buffering aspect is what differentiates this category class from the
Broadcast class (which has minimal or no buffering). 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 4. Multimedia Streaming Traffic Characteristics
2.5 Broadcast Parent Traffic Class 2.5 Broadcast Category Traffic Class
Broadcast traffic class is best suited for inelastic streaming media Broadcast traffic class is best suited for inelastic streaming media
Applications, which might have a 'wardrobe malfunction' delay at or Applications, which might have a 'wardrobe malfunction' delay at or
near the source but not typically at the destination, that may be of near the source but not typically at the destination, that may be of
constant or variable rate, requiring low jitter and very low packet constant or variable rate, requiring low jitter and very low packet
loss, such as the following application components: loss. The following application components are appropriate for use
with the Broadcast category:
o Audio o Audio (see Section 2.1)
o Video o Video (see Section 2.1)
o Multiplex (i.e., combined a/v streams) o Multiplex (i.e., combined a/v streams)
With adjective substrings to the above: With adjective substrings to the above:
o IPTV o IPTV
o Live events (non-buffered) o Live events (non-buffered)
o Video surveillance - one way video from a camera (e.g., observing o surveillance - one way audio from a microphone or video from a
a parking lot or building exit), typically enabled for camera (e.g., observing a parking lot or building exit),
long periods of time, usually stored at the destination. typically enabled for long periods of time, usually stored
at the destination.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|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 | | | |
skipping to change at page 11, line 36 skipping to change at page 11, line 17
Figure 5. Broadcast Traffic Characteristics Figure 5. Broadcast Traffic Characteristics
3. SDP Attribute Definition 3. SDP Attribute Definition
This document proposes the 'trafficclass' session and media-level This document proposes the 'trafficclass' session and media-level
SDP [RFC4566] attribute. The following is the Augmented SDP [RFC4566] attribute. The following is the Augmented
Backus-Naur Form (ABNF) [RFC5234] syntax for this attribute, which Backus-Naur Form (ABNF) [RFC5234] syntax for this attribute, which
is based on the SDP [RFC4566] grammar: is based on the SDP [RFC4566] grammar:
attribute =/ traffic-classification attribute =/ traffic-class-label
traffic-classification = "trafficclass" ":" [SP] parent-class traffic-class-label = "trafficclass" ":" [SP] category
"." app-type *( adj-param ) "." application *( "." adjective )
parent-class = "Broadcast" / category = "Broadcast" /
"Realtime-Interactive" / "Realtime-Interactive" /
"Multimedia-Conferencing" / "Multimedia-Conferencing" /
"Multimedia-Streaming" / "Multimedia-Streaming" /
"Conversational" / "Conversational" / tcl-token
extension-mech
extension-mech = token
app-type = "audio" / "video" / "text" /
"application-sharing" /
"presentation-data" / "whiteboarding" /
"webchat/IM" / "gaming" /
"virtual-desktop" / "remote-desktop" /
"telemetry"/ "multiplex" / "webcast" /
"IPTV" / "live-events" /
"surveillance" / extension-mech
adj-param = "." unqualified-adjective / application = tcl-token
"." qualified-adjective
unqualified-adjective = "immersive" / "avconf" / adjective = classified-adjective /
"Realtime-Text" /"web" / unclassified-adjective
generic-param ; from RFC3261
qualified-adjective = qual-category ":" q-adjective classified-adjective = tcl-token ":" tcl-token
qual-category = "aq" / extension-mech unclassified-adjective = tcl-token
q-adjective = "admitted" / "non-admitted" / "none" / tcl-token = %2D / %30-%39 / %41-%5A / %61-7A
generic-param ; from RFC3261
The attribute is named "trafficclass", for traffic classification, The attribute is named "trafficclass", for traffic classification,
identifying which one of the five traffic classes applies to the identifying which one of the five categories applies to the
media stream. There MUST NOT be more than one trafficclass attribute media stream associated with this m-line. There MUST NOT be more
per media line. Confusion would result in where more than one exists than one category component per media line.
per m= line.
The parent classes in this document are an augmented version of the The category in this document are an augmented version of the
application labels introduced by table 3 of RFC 4595 (which will be application labels introduced by table 3 of RFC 4595 (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 | Parent Classes Defined | | Application Labels | Category Classes Defined |
| Defined in RFC 4594 | in this document | | Defined in RFC 4594 | in this document |
+=========================+==============================+ +=========================+==============================+
| Broadcast-video | Broadcast | | Broadcast-video | Broadcast |
+-------------------------+------------------------------+ +-------------------------+------------------------------+
| Realtime-Interactive | Realtime-Interactive | | Realtime-Interactive | Realtime-Interactive |
+-------------------------+------------------------------+ +-------------------------+------------------------------+
| Multimedia-Conferencing | Multimedia-Conferencing | | Multimedia-Conferencing | Multimedia-Conferencing |
+-------------------------+------------------------------+ +-------------------------+------------------------------+
| Multimedia-Streaming | Multimedia-Streaming | | Multimedia-Streaming | Multimedia-Streaming |
+-------------------------+------------------------------+ +-------------------------+------------------------------+
| Telephony | Conversational | | Telephony | Conversational |
+-------------------------+------------------------------+ +-------------------------+------------------------------+
Figure 6. Label Changes from RFC 4594 Figure 6. Label Change Differences from RFC 4594
As is evident from the changes above, from left to right, two labels As is evident from the changes above, from left to right, two labels
are different and each of the meanings are different in this are different and each of the meanings are different in this
document relative to how RFC 4594 defined them. These differences document relative to how RFC 4594 defined them. These differences
are articulated in Section 2 of this document. are articulated in Section 2 of this document.
A parent class is a human understandable categorization, and MUST A category is a human understandable categorization, and MUST NOT be
NOT be the only part of the traffic class label present in the the only component of the traffic class label present in the
attribute. The parent class string MUST always be paired with an attribute. The category string MUST always be paired with an
application type, with a "." as the component separator. application component, with a "." as the component separator.
The application types (app-type) define the application of a The application types define the application of a particular traffic
particular traffic flow. The application types are listed both in flow, for example, audio or video. The application types are listed
the ABNF and defined in Section 2 of this document. Not every and defined in Section 2 of this document. Not every category is
combination parent class is paired with application types, at least paired with application each listed, at least as defined in this
as defined in this document. Section 2.1 through 2.5 list many of document. Section 2.1 through 2.5 list many of the expected
the expected combinations. combinations.
For additional application type granularity, adjective components For additional application type granularity, adjective components
can be added (also listed in Section 2). One or more adjectives can 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 be within the same traffic class attribute. It is also permitted to
include one or more non-IANA registered adjective component, but include one or more non-IANA registered adjective component, but
these MUST be prefaced by the additional delimiter "_", creating a these MUST be prefaced by the additional delimiter "_", creating a
possibility such as possibility such as
parent-class.application-type.adjective._non-standard-adjective category.application-type.adjective._non-standard-adjective
^^^^ ^^^^
See the underscore See the underscore
For example, this is valid: For example, this is valid:
m=video 50000 RTP/AVP 112 m=video 50000 RTP/AVP 112
a=trafficclass Conversational.video.immersive._foo._bar a=trafficclass Conversational.video.immersive._foo._bar
where both "foo" and "bar" are not IANA registered adjectives, but where both "foo" and "bar" are not IANA registered adjectives, but
"immersive" is IANA registered. However, including non-registered "immersive" is IANA registered. However, including non-registered
adjectives without the "_" delimiter are not valid, such as the adjectives without the "_" delimiter MUST NOT occur, such as the
following: following:
m=video 50000 RTP/AVP 112 m=video 50000 RTP/AVP 112
a=trafficclass Conversational.video.immersive.foo.bar a=trafficclass Conversational.video.immersive.foo.bar
There is no limit to the number of adjectives allowed, without There is no limit to the number of adjectives allowed, without
regard for whether they are registered or not. These non-registered regard for whether they are registered or not. These non-registered
adjectives can be vendor generated, or merely considered to be adjectives can be vendor generated, or merely considered to be
proprietary in nature. proprietary in nature.
It is important to note that the order of component types matter, It is important to note that the order of component types matter,
but not the order of the adjective components. There might be local but not the order of the adjective components. There might be local
significance to the ordering though. In other words, the parent significance to the ordering of adjectives though. In other words,
class component MUST be before the application component, which MUST the category class component MUST be before the application
be before the adjective component. component, which MUST be before any and all adjective component(s).
Some algorithm such as alphabetizing the list and matching the Some algorithm such as alphabetizing the list and matching the
understood strings SHOULD be used. understood strings SHOULD be used.
Adjectives can be either unqualified or qualified. Qualified Adjectives can be either unqualified or qualified. Qualified
adjectives have a designation it is qualified and a ":" separating adjectives have a delimiter ":" after the previous "." separating
the string component into two parts. We define this qualifying the string component into two parts.
designation to have the form of a two or three letter qualifier, in
which the last letter is always "q" (i.e., for "qualified").
We are proposing in this document to have a single qualified The tcl-token "aq" is the first part of an adjective if it is
adjective indicating whether this trafficclass has had or will have qualified, and either the "admitted", "non-admitted" or "none"
capacity-admission applied to it. Here we define the admission tcl-token is the second part of the qualified adjective allowable
qualifier ("aq") with three possible values for this adjective: according to this specification. In the form
admitted, non-admitted and none, that will have the form
aq:admitted|non-admitted|none 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 Like all adjectives, it is OPTIONAL to include this adjective in any
trafficclass attribute, and has the following meanings: trafficclass attribute, and has the following meanings:
- aq - for 'admission qualifier' to indicate the purpose of
the following adjective parts with respect to the
capacity admission status of this traffic flow
described by this m-line.
- admitted - capacity admission mechanisms or protocols are to be or - admitted - capacity admission mechanisms or protocols are to be or
were used for the full amount of bandwidth in relation were used for the full amount of bandwidth in relation
to this m= line. to this m= line.
- non-admitted - capacity admission mechanisms or protocols were - non-admitted - capacity admission mechanisms or protocols were
attempted but failed in relation to this m= line. This attempted but failed in relation to this m= line. This
does not mean the flow described by this m= line does not mean the flow described by this m= line
failed. It just failed to attain the capacity admission failed. It just failed to attain the capacity admission
mechanism or protocol necessary for a predictable mechanism or protocol necessary for a predictable
quality of service, and is likely to continue with only quality of service, and is likely to continue with only
a class of service marking or best effort. a class of service marking or best effort.
- none - no capacity admission mechanisms or protocols are or - none - no capacity admission mechanisms or protocols are or
were attempted in relation to this m= line. were attempted in relation to this m= line.
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.
Any parent class, application, or adjective string component within Any category class, application, or adjective string component
this attribute that is not understood MUST be ignored, leaving all within this attribute that is not understood MUST be ignored,
that is understood to be processed. Ignored string components SHOULD leaving all that is understood to be processed. Ignored string
NOT be deleted, as a downstream entity could understand the components SHOULD NOT be deleted, as a downstream entity could
component(s) and use it/them. understand the component(s) and use it/them during processing.
Not understanding the parent class string SHOULD mean that this Not understanding the category class string SHOULD mean that this
attribute is ignored. attribute is ignored.
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 a telepresence session that has had capacity The above indicates a Telepresence session that has had capacity
admission process applied to its media flow. admission process applied to its media flow.
4. Offer/Answer Behavior 4. 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
skipping to change at page 15, line 44 skipping to change at page 15, line 17
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
1 - does the answerer understand the parent component? 1 - does the answerer understand 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 - does the answerer understand 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 parent component was not understand, situation is as if the category component was not understand,
the attribute SHOULD be ignored. the attribute SHOULD be ignored.
If yes, it checks to see if there are any other 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 - does the answerer understand the adjective component or
components if any are present? 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. ignored, as if they are not present. Match all remaining
understood components according to local policy and process
attribute.
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.
The answerer should expect to receive RTP packets marked as The answerer should expect to receive RTP packets marked as
indicated by its 'trafficclass' attribute in the answer itself. indicated by its 'trafficclass' attribute in the answer itself.
skipping to change at page 17, line 32 skipping to change at page 17, line 4
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 Application Type Registration 6.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 application 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 Application Type Attribute Values Registry Name: "trafficclass" SDP Category Attribute Values
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Standards-Track document Required
Parent 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 6.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" Attribute Application Type Values
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required
Application Values Reference Application Values Reference
------------------ --------- ------------------ ---------
skipping to change at page 18, line 20 skipping to change at page 17, line 42
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/instant messaging [this document] Webchat/IM [this document]
Gaming [this document] Gaming [this document]
Virtualized-desktop [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] Live-event [this document]
surveillance [this document] surveillance [this document]
6.4 The Traffic Classification Unqualified Adjective Registration 6.4 The Traffic Classification Unqualified 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 unqualified 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 Unqualified Adjective Values Registry Name: "trafficclass" Attribute Adjective Values
Reference: [this document] Reference: [this document]
Registration Procedures: Specification Required Registration Procedures: Specification Required
Application Values Reference Adjective Values Reference
------------------ --------- ------------------ ---------
Immersive [this document] Immersive [this document]
Desktop-video [this document] Desktop-video [this document]
Realtime-Text [this document] Realtime-Text [this document]
web [this document] web [this document]
aq [this document]
6.5 The Traffic Classification Attribute Qualified Adjective Values admitted [this document]
Registration non-admitted [this document]
none [this document]
This document requests IANA to create a new registry Qualified
Adjective Values similar to the following table within the Session
Description Protocol (SDP) Parameters registry:
Registry Name: "trafficclass" Attribute Qualified Adjective Values
Reference: [this document]
Registration Procedures: Specification Required
Qualification Category Attribute Values Reference
---------------------- ---------------- ---------
AQ Admitted [this document]
AQ Non-admitted [this document]
AQ None [this document]
7. Acknowledgments 7. 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,
and Greg Edwards for their comments and suggestions. Paul Kyzivat and Greg Edwards for their comments and suggestions.
8. References 8. References
8.1. Normative References 8.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
skipping to change at page 20, line 40 skipping to change at page 20, 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.
Research Triangle Park, NC, USA
+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 -00 to -01 A.1 From -01 to -02
These are the following changes made between the WG -01 version and
the -02 version:
- converged the use of terms 'parent' and 'category' to just
'category' for consistency.
- changed ABNF to reflect extensibility by not having applications
and adjectives named in the ABNF, rather have them merely IANA
registered.
- merged the qualified and unqualified adjective sections into a
single section on adjectives, but allowing some to have a
preceding qualifier.
- text clean-up
A.2 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.
- clarified the differences between Multimedia-Streaming and - clarified the differences between Multimedia-Streaming and
Broadcast parent categories. Broadcast category categories.
- defined Video surveillance - defined Video surveillance
- added the concept of a 'qualified' adjective, and modified the - added the concept of a 'qualified' adjective, and modified the
ABNF. ABNF.
- deleted the idea of a 'cac-class' as a separate component, and - deleted the idea of a 'cac-class' as a separate component, and
made the equivalent a qualified adjective. made the equivalent a qualified adjective.
- modified the answerer behavior because of the removal of the - modified the answerer behavior because of the removal of the
skipping to change at page 21, line 34 skipping to change at page 21, line 15
- created an IANA registry for qualified adjectives - created an IANA registry for qualified adjectives
- general clean-up of the doc. - general clean-up of the doc.
Did *not* do the following in this version: Did *not* do the following in this version:
- add the ability to have more than one trafficclass attribute based - add the ability to have more than one trafficclass attribute based
on the codec chosen, as feedback indicated this was a bad idea. on the codec chosen, as feedback indicated this was a bad idea.
- no swap of the Multimedia-Conferencing parent category with the - no swap of the Multimedia-Conferencing category with the
offered Collaboration parent category, as doing this did not solve offered Collaboration category, as doing this did not solve
any perceived problems. any perceived problems.
- add more to the 'how does this get processed' portion of Section - add more to the 'how does this get processed' portion of Section
3. That will come in the next revision. 3. That will come in the next revision.
 End of changes. 98 change blocks. 
213 lines changed or deleted 212 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/