One document matched: draft-polk-mmusic-traffic-class-for-sdp-00.txt
Network WG James Polk
Internet-Draft Subha Dhesikan
Expires: April 18, 2011 Cisco Systems
Intended Status: Standards Track (PS) October 18, 2010
The Session Description Protocol (SDP) 'servclass' Attribute
draft-polk-mmusic-traffic-class-for-sdp-00
Abstract
This document proposes a new Session Description Protocol (SDP)
attribute line to identify the traffic class a session is requesting
in its offer/answer exchange. This document uses previously defined
traffic class strings for consistency between IETF documents.
Legal
This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2011.
Polk & Dhesikan Expires April 18, 2011 [Page 1]
Internet-Draft SDP servclass Attribute Oct 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. SDP Attribute Definition . . . . . . . . . . . . . . . . . . 5
3. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 5
3.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 6
3.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 6
4. Are Additional Tags Required? . . . . . . . . . . . . . . . . 7
5. Security considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction
The Session Description Protocol (SDP) [RFC4566] provides a means
for an offerer to describe the specifics of a session to an
answerer, and for the answerer to respond back to the offerer.
These specifics include offering the codec or codecs to choose from,
the specific IP address and port number the offerer wants to receive
the RTP stream(s) on/at, the particulars about the codecs the
offerer wants considered or mandated, and so on.
There are many facets within SDP to determine the Real-time
Transport Protocol (RTP) [RFC3550] specifics established between one
Polk & Dhesikan Expires April 18, 2011 [Page 2]
Internet-Draft SDP servclass Attribute Oct 2010
or more endpoints, but identifying how the underlying network should
process each stream still remains under-defined.
RFC 4594 [RFC4594] established a guideline for classifying the
various flows in the network and the Differentiated Services
Codepoints (DSCP) that apply to many traffic types, including RTP
based voice and video traffic sessions. It also defines the per hop
network behavior that is strongly suggested for each of these
application traffic types.
When looking at RTP from a voice and video standpoint, merely
separating RTP into either voice or video is not as granular as is
needed, as demonstrated by Differentiated Services Codepoint
guidelines in RFC 4594 [RFC4594]. Within that document, there are 4
distinct video traffic classifications of RTP:
- The Broadcast video (which is to use the CS5 per hop marking)
- The Real-time Interactive (which is to use the CS4 per hop
marking)
- The Multimedia Conferencing (per hop marking AF4x per hop marking)
- The Multimedia Streaming (per hop marking AF3x per hop marking)
In addition, there are 2 voice classes:
- The VOIP class (per hop marking EF per hop marking).
- the Voice-Admit (per hop marking Voice-Admit per hop marking) from
RFC 5865 [RFC5865]
The DSCP recommendations from RFC 4594 create a traffic
classification, i.e., a Class of Service (COS) for each different
type of traffic type, at least for those that are specified within
that RFC.
Looking at those traffic types carried in RTP, as sessions
established by SDP, an indication is necessary within the
offer/answer exchange to identify which type of traffic is being
offered. This is especially true if more than one traffic type can
be offered by the same offerer. Why is this needed? For several
reasons listed here
- to aid in the proper classification into the network, so network
nodes (i.e., switches and routers) treat each RTP packet as
desired/expected.
- to synchronize with call control entities (i.e., middleboxes)
which type of traffic is in both the offer and answer, allowing
policy decisions to occur when needed.
To the first point, some are looking into allocating different
amounts of available capacity within routers and switches based on
the type of traffic that is being sent. For example, unadmitted
voice gets X% of the available interface's capacity (i.e., router or
Polk & Dhesikan Expires April 18, 2011 [Page 3]
Internet-Draft SDP servclass Attribute Oct 2010
switch port), desktop video (what RFC 4594 calls 'multimedia
conferencing') can get up to Y% of an interface's capacity and
Telepresence video (what RFC 4594 calls Real-time Interactive) can
have Z% of an interface's capacity. The offerer and answerer, with
or without middleboxes, coordinate how to mark each traffic type.
Network configuration determines how much of each traffic type get
access to what percentage of each interface.
Networks that do not wish to allocate bandwidth availability to one
traffic type verses another can always us best effort markings.
Those that want to differentiate traffic types, and make sure one
traffic type does not starve out another (or all other) traffic
type(s) use (at least) differentiated services as the indication to
accomplish this. Within a network core, where only MPLS is used,
Diffserv obviously does not apply. That said, Diffserv can be used
to mark traffic into MPLS tunnels [RFC4124].
The idea of traffic - or service - identification is not new; it has
been defined in [RFC5897]. If that RFC is used as a guideline,
identification that leads to stream differentiation can be quite
useful. One of the points within RFC 5897 is that users cannot be
allowed to assign any identification (fraud is but one reason
given). In addition, RFC 5897 recommends that service identification
should be done in signaling, rather than guessing or deep packet
inspection. The network will have to currently guess or perform deep
packet inspection to classify and offer the service as per RFC 4594
since such service identification information is currently not
available in SDP and therefore to the network elements. Since SDP
understands how each stream is created (i.e., the particulars of the
RTP stream), this is the right place to have this service
differentiated. Such service differentiation can then be
communicated to and leveraged by the network.
[Editor's Note: the words "traffic" and "service" are similar enough
that the above paragraph talks about RFC 5897's
"service identification", but this document is only
wanting to discuss and propose traffic indications
in SDP.]
This document proposes how SDP [RFC4566] uniquely identifies which
Application class - as a traffic type - a stream is for network
handling and policy purposes. This can also be leveraged for call
signaling policies such as acceptance or rejection, authorization of
a certain type of application by call controlling entities, and
synchronization with lower layers for network handling.
This document proposes a simple attribute line to identify the
application a session is requesting in its offer/answer exchange.
This document uses previously defined service class strings for
consistency between IETF documents.
Polk & Dhesikan Expires April 18, 2011 [Page 4]
Internet-Draft SDP servclass Attribute Oct 2010
2. SDP Attribute Definition
This document proposes the 'trafficclass' session and media-level
SDP [RFC4566] attribute. The following is their Augmented
Backus-Naur Form (ABNF) [RFC5234] syntax, which is based on the SDP
[RFC4566] grammar:
attribute =/ traffic-classification
traffic-classification = "trafficclass" ":" [SP] app-type
app-type = "Broadcast video" /
"Real-time Interactive" /
"Multimedia Conferencing" /
"Multimedia Streaming" /
"VoIP" / "Voice-Admit" /
extension-mech
extension-mech = token
The attribute is named "trafficclass", for traffic classification,
identifying which one of the six traffic classes listed above
applies to the media stream.
The traffic classes defined in this document for SDP align with
the application labels introduced by table 3 of RFC 4594. RFC 5685
updates the guidelines set forth in RFC 4594 by creating a new voice
classification where call admission control (CAC) has been applied.
So, there are four video classifications and two voice
classifications
- Broadcast video
- Real-time Interactive
- Multimedia Conferencing
- Multimedia Streaming
- VoIP
- Voice-Admit
The attribute is named "trafficclass", for traffic classification.
The following is an example of an 'm' line with a 'trafficclass'
attribute:
m=audio 50000 RTP/AVP 0
a=trafficclass multimedia conferencing
The above indicates a desktop video type of session.
3.0 Offer/Answer Behavior
Polk & Dhesikan Expires April 18, 2011 [Page 5]
Internet-Draft SDP servclass Attribute Oct 2010
Through the inclusion of the 'trafficclass' attribute, an
offer/answer exchange identifies the application type for use by
endpoints within a session. Policy elements can use this attribute
to determine the acceptability and/or treatment of that session
through lower layers. One specific use-case is for setting of the
DSCP specific for that application type (say Broadcast Video instead
of Real-time Interactive video), decided on a per domain basis -
instead of exclusively by the offering domain.
3.1 Offer Behavior
Offerers include the 'trafficclass' attribute with a single well
known token (from list in Section 2) to obtain configurable and
predictable treatment between the answerer and the offerer. It can
also instead include a private token within a single domain (e.g.,
enterprise networks).
Offerers of this 'trafficclass' attribute MUST NOT change the token
in transit (e.g., wrt to B2BUAs). SBCs at domain boundaries can
change this attribute through local policy.
Offers containing a 'trafficclass' token not understood are ignored
by default (i.e., as if there was no 'trafficclass' attribute in the
Offer).
3.2 Answer Behavior
Upon receiving an offer containing a 'trafficclass' attribute, if
the offer is accepted, the answerer will use this attribute to set
the session or media (level) traffic accordingly towards the
offerer.
The answerer will answer the offer with its own 'trafficclass'
attribute, which will likely be the same value, although this is not
mandatory (at this time).
The answerer should expect to receive RTP packets marked as
indicated by its 'trafficclass' attribute in the answer itself.
An Answer MAY have a 'trafficclass' attribute when one was not in
the offer. This will at least aid the local domain, and perhaps
each domain the session transits, to categorize the application type
of this RTP session.
Answerers that are middleboxes can use the 'trafficclass' attribute
to classify the RTP traffic within this session however local policy
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.
Polk & Dhesikan Expires April 18, 2011 [Page 6]
Internet-Draft SDP servclass Attribute Oct 2010
4. Are Additional Tags Required?
The authors have already discounted (or dropped) two tags to this
"a=trafficclass" line (the optional/mandatory tag and the
sendonly/recvonly/sendrecv tag), but are considering another tag for
'desired bidirectional or symmetric'.
4.1 Is the "trafficclass" 'desired bidirectional or symmetric'?
Should the offerer be able to indicate that it believes the
session's traffic classification be the same in both directions?
a=servclass real-time interactive des-bidirectional (or symmetric)
[Editor's Note: The authors are not sure if this parameter works in
all (or most) situations. We would like feedback on
scenarios in which this should be included.]
5. Security considerations
RFC 5897 [RFC5897] discusses many of the pitfalls of service
classification, which is similar enough to this idea of traffic
classification to apply here as well. That document highly
recommends the user not being able to set any classification.
Barring a hack within an endpoint (i.e., to intentionally
mis-classifying (i.e., lying) about which classification an RTP
stream is), this document's solution makes the classification part
of the signaling between endpoints, which is recommended by RFC
5897.
6. IANA considerations
6.1 Registration of the SDP 'trafficclass' Attribute
This document requests IANA to register the following SDP att-field
under the Session Description Protocol (SDP) Parameters registry:
Contact name: jmpolk@cisco.com
Attribute name: trafficclass
Long-form attribute name: Traffic Classification
Type of attribute: Session and Media levels
Subject to charset: No
Purpose of attribute: To indicate the Traffic Classification
Polk & Dhesikan Expires April 18, 2011 [Page 7]
Internet-Draft SDP servclass Attribute Oct 2010
application for this session
Allowed attribute values: IANA Registered Tokens
Registration Procedures: Specification Required
Type SDP Name Reference
---- ------------------ ---------
att-field (both session and media level)
trafficclass [this document]
6.2 The Service Classification Application Registration
This document requests IANA to create a new registry for the
application service classes similar to the following table within
the Session Description Protocol (SDP) Parameters registry:
Registry Name: "trafficclass" SDP Attribute Values
Reference: [this document]
Registration Procedures: Specification Required
Attribute Values Reference
---------------- ---------
Broadcast video [this document]
Real-time Interactive [this document]
Multimedia Conferencing [this document]
Multimedia Streaming [this document]
VoIP [this document]
Voice-Admit [this document]
7. Acknowledgments
To Dave Oran for his comments and suggestions.
8. References
8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code
Polk & Dhesikan Expires April 18, 2011 [Page 8]
Internet-Draft SDP servclass Attribute Oct 2010
Point (DSCP) for Capacity-Admitted Traffic", RFC 5865,
May 2010
[RFC5897] J. Rosenberg, "Identification of Communications Services in
the Session Initiation Protocol (SIP)", RFC 5897, June 2010
[RFC4124] F. Le Faucheur, Ed., " Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering ", RFC 4124,
June 2005
8.2. Informative References
[RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for
Diffserv Service Classes", RFC 4594, August 2006
Authors' Addresses
James Polk
3913 Treemont Circle
Colleyville, Texas, USA
+1.817.271.3552
mailto: jmpolk@cisco.com
Subha Dhesikan
170 W Tasman St
San Jose, CA, USA
+1.408-902-3351
mailto: sdhesika@cisco.com
Polk & Dhesikan Expires April 18, 2011 [Page 9]| PAFTECH AB 2003-2026 | 2026-04-23 05:36:36 |