One document matched: draft-polk-mmusic-service-class-for-sdp-00.txt
Network WG James Polk
Internet-Draft Subha Dhesikan
Expires: January 5, 2011 Cisco Systems
Intended Status: Standards Track (PS) July 5, 2010
The Session Description Protocol (SDP) 'servclass' Attribute
draft-polk-mmusic-service-class-for-sdp-00
Abstract
This document proposes a simple Session Description Protocol (SDP)
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.
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 January 5, 2011.
Polk Expires January 5, 2011 [Page 1]
Internet-Draft SDP servclass Attribute July 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 . . . . . . . . . . . . . . . . . . 4
2.1 Are Tags Required? . . . . . . . . . . . . . . . . . . . 5
3. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 6
3.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 6
3.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 6
4. Security considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
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. 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
or more endpoints, but identifying how the underlying network should
Polk Expires January 5, 2011 [Page 2]
Internet-Draft SDP servclass Attribute July 2010
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 these traffic types. It also defines
the per hop network behavior that is required 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 classifications of RTP:
- The Broadcast video (CS5)
- The Real-time Interactive (CS4)
- The Multimedia Conferencing (AF4x)
- The Multimedia Streaming (AF3x)
In addition, there are 2 voice classes:
- The VOIP class (EF).
- the Voice-Admit (Voice-Admit) from RFC 5865 [RFC5865]
Each of the media type classifications may require different quality
of service handling in the network. However, the network does not
currently have sufficient information to perform the above
classification since such information is not available in the SDP
signaling.
The idea of 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.
This document proposes how SDP [RFC4566] uniquely identifies which
Application class 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.
Polk Expires January 5, 2011 [Page 3]
Internet-Draft SDP servclass Attribute July 2010
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.
2. SDP Attribute Definition
This document proposes the 'servclass' 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 =/ service-classification
service-classification = "servclass" ":" [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 "servclass", for service classification,
identifying, which one of the six service classes listed
above applies to the media stream.
The service 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
[Editor's Note: should Voice-admit (i.e., what is defined in RSVP
5865) be included in this list?]
The attribute is named "servclass", for service classification.
The following is an example of an 'm' line with a 'servclass'
Polk Expires January 5, 2011 [Page 4]
Internet-Draft SDP servclass Attribute July 2010
attribute:
m=audio 50000 RTP/AVP 0
a=servclass real-time interactive
The above signals a telepresence type of session.
2.1 Are Tags Required?
The authors are considering two tags to this "a=servclass" line,
- whether this "a=" line is optional or mandatory in the answer
and
- whether there should be a direction tag
If the WG believes either is necessary, this proposal will define a
default value for either (or both).
2.1.1 Is the "servclass" 'Optional' or 'Mandatory'?
There can be an optional or mandatory tag within the "a=servclass"
line for whether the offerer wants the answerer to include this
"a=servclass" in the answer.
a=servclass (optional/mandatory) real-time interactive
[Editor's Note: The authors are currently leaning away from
including this parameter. We would like feedback on
scenarios in which this should be included.]
2.1.2 Is a "servclass" Direction Tag Necessary?
Additionally, there can be a direction tag included in this
"a=servclass" proposal.
a=servclass Voice-Admit (sendonly/recvonly/sendrecv)
[Editor's Note: The authors believe that the direction of the
service class will be picked up by the direction of
the flow that the m-line(s) indicate. Since this is
an attribute of the flow, the flow's direction
determines the direction of the attribute.
Therefore, we are currently leaning away
from including this parameter. We would like
feedback on scenarios in which this should be
included.]
Polk Expires January 5, 2011 [Page 5]
Internet-Draft SDP servclass Attribute July 2010
3.0 Offer/Answer Behavior
Through the inclusion of the 'servclass' 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 'servclass' attribute with a single well known
token (from list in Section 2) to obtain predictable treatment. It
can also instead include a private token within a single domain
(e.g., enterprise networks).
Offerers of this 'servclass' attribute MUST NOT change the token in
transit (e.g., wrt to SBCs).
Offers containing a 'servclass' token not understood are ignored
(i.e., as if there was no 'servclass' attribute in the Offer).
3.2 Answer Behavior
Upon receiving an offer containing a 'servclass' attribute, the
answerer binds this session or media (level) attribute with the RTP
traffic received at the session or media level.
Offer 'servclass' attribute tokens SHOULD match what is in the
Answer, if the offer is accepted. An Answer MAY have a 'servclass'
attribute where 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 'servclass' 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.
4. Security considerations
RFC 5897 [RFC5897] discusses many of the pitfalls of service
classification. That document highly recommends the user not being
able to set any classification. Barring a hack within an endpoint
(i.e., to intentionally miss-classifying (i.e., lying) about which
classification an RTP stream is), this document's solution makes the
Polk Expires January 5, 2011 [Page 6]
Internet-Draft SDP servclass Attribute July 2010
classification part of the signaling between endpoints, which is
recommended by RFC 5897.
5. IANA considerations
5.1 Registration of the SDP 'servclass' 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: servclass
Long-form attribute name: Service Classification
Type of attribute: Session and Media levels
Subject to charset: No
Purpose of attribute: To indicate the Service Classification
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)
servclass [this document]
7.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: "servclass" 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]
Polk Expires January 5, 2011 [Page 7]
Internet-Draft SDP servclass Attribute July 2010
6. Acknowledgments
Your name here...
7. References
7.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
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
7.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 Expires January 5, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-22 23:03:30 |