One document matched: draft-polk-mmusic-dscp-attribute-01.txt
Differences from draft-polk-mmusic-dscp-attribute-00.txt
MMUSIC Working Group James Polk
Internet-Draft Cisco Systems
Expires: Sept 5th, 2007 Mar 5th, 2007
Intended Status: Standards Track
Configuring the Differentiated Services Codepoint of
Session Description Protocol Established Media Streams
draft-polk-mmusic-dscp-attribute-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 September 5th, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The offer/answer model for SDP currently is without a mechanism for
dynamic configuration of the Differentiated Services Codepoint to
use for the media streams endpoints establish. Endpoints in more
controlled environments, typically bounded within a domain, require
intermediary servers to notify them what specific DSCP a media
stream should be set to, as granular as at the media stream level,
when more than one stream is in a session description, or changed
to, based on dynamic network conditions.
Polk Expires April 2007 [Page 1]
Internet-Draft Stream DSCP Configuration in SDP Mar 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. SDP Attributes Definition . . . . . . . . . . . . . . . . . . 4
3. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 5
3.1 Offerer Behavior . . . . . . . . . . . . . . . . . . . . . 6
3.2 Answerer Behavior . . . . . . . . . . . . . . . . . . . . . 6
4. Changing the 'dscp' Attribute in an Established Session . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1 Registration of the SDP 'dscp' Attribute . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1 Normative References . . . . . . . . . . . . . . . . . . 9
9.2 Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
1. Introduction
The Session Description Protocol (SDP) [RFC4566] currently is
neutral with respect to indicating any domain per hop behaviors
(PHB) that exist for a session, and therefore any layer 3
indications which endpoints establish, somehow, for the media
streams they establish. Differentiated Services [RFC2474]
established a set of per hop behaviors indications at layer 3,
called Differentiated Services Codepoints (DSCP). Endpoints in more
controlled environments (with more aware intermediary servers such
as SIP Back-to-Back-User-Agents (B2BUA) [RFC3261] for example)
typically have a limited, if any, means of dynamically setting or
altering the DSCP of established media stream packets. There is no
current means in control plane signaling (including SDP) for an
endpoint or intermediary server to suggest, indicate or set a DSCP
of a media stream. SDP can include more than one stream description
within an offer [RFC3264], possibly with each stream needing to use
a different DSCP. Thus, it seems appropriate to provide a means of
indicating what DSCP a stream is to have by a protocol that has the
visibility and knowledge of each stream, as well as knowing the
desired characteristics of the packet flow. This document addresses
this lack of ability - in SDP.
In some environments, endpoints do not typically have decision
making control over what DSCP a media stream is to be set to. Yet,
each type of media will not necessarily always have the same DSCP
marking (i.e. voice is always the same, or video is always the same
- but different than voice). See RFC 4594 [RFC4594] for IETF
guidelines of this. There are times and environments in which the
DSCP for a voice session will be different than other voice sessions
Polk Expires April 2007 [Page 2]
Internet-Draft Stream DSCP Configuration in SDP Mar 2007
from a particular endpoint. See [ID-EF-ADMIT], which
describes/creates a new Expedited Forwarding DSCP for mission
critical communicates. There are times in which, from the same
endpoint, the DSCP will be different based on the conditions of the
network. Servers are in a better position to decide which DSCP, and
ultimately which PHB, a media stream is to have within an
environment (i.e. within a domain). [ID-EF-ADMIT] dynamically
assigns a new DSCP to a voice call once the network has admitted
this call's importance - perhaps to provide this session with
elevated treatment, or an indication how these packets are placed
into which MPLS tunnel. This elevated treatment can be achieved on
a per interface basis, if a router is configured to schedule/police
this traffic differently than other RTP.
Thinking of SIP as a transport of SDP for a moment, SIP message
routing servers are called proxy servers. There are several
instances of a SIP proxy. There are stateless and stateful proxies.
There is a Back-to-Back-User-Agent (B2BUA) form of proxy. These
servers are typically are session/dialog stateful (i.e. all messages
within a dialog pass through that server instance). There is the
Session Border Controller (SBC) form of SIP server, which is
essentially (in SIP) a B2BUA, but typically does other functions
like being a NAT, a firewall, etc.
In a B2BUA arrangement, all offers terminate in the B2BUA's UAS
side, and are regenerated on the UAC side. This type of server can
manipulate everything within a message, including the SDP offer of a
message. The SBC form of B2BUA will reset the offer's IP
address(es) to the SBC's, and not to the endpoint within its domain.
The SBC will relay the offer and the media stream from the sender to
the receiving UA, in each direction.
SBCs are typically at a network/domain boundary, meaning these
devices are SIP and SDP aware, and are a relay point of RTP between
source and destination UAs. Creating a means in SDP to set and/or
modify the DSCP for a media stream in an offer (or more than one
media stream if there is more than one in that offer), coupled with
a network topology of a B2BUA and SBC, allows SDP to control the
DSCPs of the media streams in both directions within that same
domain.
This document specifies an extension to SDP for a new media level
attribute to set or modify the DSCP value of a media stream, per
stream within an offer and answer. This extension is not useful in
all environments, but more likely to be found in more controlled
environments where a network administrator wants to have granular
control of stream treatments. An example of this may be a service
provider wants to grant its customers greater service than roaming
endpoints into that network. Knowing that DSCPs can be reset at
each router or border, within a network, that administrator can
provide differentiated treatment even within RTP streams from the
endpoint to the network boundary.
Polk Expires April 2007 [Page 3]
Internet-Draft Stream DSCP Configuration in SDP Mar 2007
1.1 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.
2. SDP Attributes Definition
This document defines the 'dscp' media-level SDP [RFC4566]
attribute. The following is the ABNF syntax [RFC4234], which is
based on the SDP [2] grammar:
attribute = dscp
dscp = "dscp" *(SP dscp-value-pair)
dscp-value-pair = dscp-value-rtp "/" dscp-value-rtcp
dscp-value-rtp = numeric-sting / alpha-string
dscp-value-rtcp = numeric-sting / alpha-string
numeric-sting = 0-63 (range)
alpha-string = token
The dscp-value-pair is the combination of the DSCP for RTP and the
DSCP value of RTCP. The dscp-value-rtcp is an optional entry here
for when there is a DSCP assigned to the RTCP for a stream.
The dscp-value is a decimal form of the 6 bit DSCP field of an IP
header [RFC2474]. There can be only one dscp-value in this
attribute. The numeric-string is limited to within a range of
decimal zero through decimal sixty-three. If used consistently
throughout a domain, with consistent behavior in underlying routers,
this can become a Per Domain Behavior (PDB) for the media packets
throughout a domain.
The following is an example of an "m=" line with a 'dscp' attribute:
m=audio 50001 RTP/AVP 0
a=dscp 46
The above "a=" line would set the media packets for this stream to
Expedited Forwarding (EF) as defined by [RFC3246].
An empty "a=dscp" attribute, with no value (numeric or alpha) MAY be
present in an offer or answer to indicate support for this extension
in SDP.
Polk Expires April 2007 [Page 4]
Internet-Draft Stream DSCP Configuration in SDP Mar 2007
3. Offer/Answer Behavior
An offer/answer exchange using the 'dscp' attribute allows endpoints
provide media packets the desired DSCP through a routed
infrastructure. Including the 'dscp' in an offer or answer
attribute is not a negotiation. This is a presentation of a value
to be used as a binary DSCP in the media packets. 2-way media
packets use the same DSCP value. An offer received by a
intermediary that is allowed to modify SDP, MAY do so based on local
policy. In other words, an offer from an endpoint may start with
one 'dscp' value when the message is sent towards the server; but
may have a different, server modified 'dscp' value from that server
towards the receiving endpoint. Figure 1. shows this exchange, and
change in 'dscp' at the server:
Alice Dialog Stateful Bob
| Intermediary |
| Offer | |
|----------------->| Offer |
| | a=dscp 46/16 |
| |------------------>|
| | Answer |
| | a=dscp 46/16 |
| Answer |<------------------|
| a=dscp 46/16 | |
|<-----------------| |
| | |
| 2-way RTP (DSCP=46 or EF) |
|<====================================>|
| | |
Figure 1. Diagram with B2BUA setting initial DSCPs
The following is an example of the "m=" line in Figure 1. with a
'dscp' attribute:
m=audio 50001 RTP/AVP 0
a=dscp 46/16
The above "a=" line would set the media packets for this stream to
Expedited Forwarding (EF) as defined by [RFC3246]. The RTCP packets
would be set to CS2 (16), or the OAM class according to [RFC4594].
If, at some point during the session, an entity (for example an SBC
or B2BUA in the signaling plane) wanted to change the DSCP markings
of the RTP packets within this media stream, it could sent this
offer (illustrated in Figure 2.) in both directions:
m=audio 50001 RTP/AVP 0
a=dscp 0/16
thereby setting this media stream to what is considered Best Effort
Polk Expires April 2007 [Page 5]
Internet-Draft Stream DSCP Configuration in SDP Mar 2007
PHB, but not changing the DSCP of the RTCP.
3.1 Offerer Behavior
An offerer MAY include a 'dscp' attribute in a offer, with its value
subject to change by any intermediary allowed to modify the offer.
An offerer receiving the 'dscp' attribute in an answer, per media
stream included, MUST use this value in the DSCP field of the media
stream packets indicated in the answer.
An offerer MAY include a 'dscp' attribute in a offer for the
purposes of indicating which level of support or service the offerer
wants this session to have. Consider the case in which a customer
(the offerer) has a contract with a network that allows multiple
service levels, fr example a gold/silver/bronze package. An offerer
MAY include this "a=dscp <value>" attribute to indicate which
service level this session is desired to achieve. This allows Alice
to offer to Bob one of three different service levels of RTP to Bob,
with the 5-tuple being the same for each of the sessions.
3.2 Answerer Behavior
An answerer supporting this extension MUST adhere to the 'dscp'
attribute in the offer if the offer in whole is acceptable to the
answerer. The 'dscp' attribute of each media stream MUST be used by
the answerer to set the DSCP field of the respective media stream
packets from the answerer. An answerer MUST NOT delete or change
the 'dscp' attribute from offer to answer (analogous to copying from
offer to answer), and SHOULD NOT ignore the 'dscp' attribute of the
offer when setting the respective media stream packets towards the
offerer.
4. Changing the 'dscp' Attribute in an Established Session
Whether or not the 'dscp' attribute was used in the initial
offer/answer exchange, an intermediary allowed to generate offers
can change 'dscp' attribute during a session. Maintaining
compliance with Section 3 above, here in Figure 2. is one example of
a 'dscp' attribute being changed for a media stream.
Alice Dialog Stateful Bob
| Intermediary |
| | |
| 2-way RTP (dscp=46 or EF) |
| established |
|<====================================>|
| | |
| Offer | Offer |
| a=dscp 41 | a=dscp 41 |
Polk Expires April 2007 [Page 6]
Internet-Draft Stream DSCP Configuration in SDP Mar 2007
|<-----------------|------------------>|
| Answer | Answer |
| a=dscp 41 | a=dscp 41 |
|----------------->|<------------------|
| |
| 2-way RTP (DSCP=41) |
|<====================================>|
| | |
Figure 2. Diagram with Intermediary setting initial DSCPs
In Figure 2. an intermediary server sends new offers to both Alice
and Bob, each with a new 'dscp' attribute of 41. This changes the
marking of the media stream packets between the two endpoints. This
MAY be how an IMS x-CSCF changes the DSCP of a particular session.
If an SBC were between Alice and Bob, it would be a focus point of
the media stream (i.e. the RTP packets would traverse the SBC just
as the signaling messages do). Such a topology would ensure the
media packets were marked according to domain policy for that part
of the end-to-end flow. This SBC could attempt to continue into the
adjacent domain with an appropriate 'dscp' attribute for the next
leg of the session.
5. IANA Considerations
This specification registers one new media level SDP attribute in
the att-field (media level only) table.
5.1. Registration of the SDP 'dscp' Attribute
This section instructs the IANA to register the following SDP att-
field under the Session Description Protocol (SDP) Parameters
registry:
Contact name: James Polk <jmpolk@cisco.com>, +1.817.271.3552
Attribute name: dscp
Long-form attribute name: Mechanism for Configuring the DSCP of a
Media Stream and related RTCP indication
for that stream
Type of attribute: Media level only
Subject to charset: No
Purpose of attribute: To configure a new DSCP for one or more (i.e.
possibly each) media stream within an SDP
during session establishment or session
modification, as well as each related RTCP
Polk Expires April 2007 [Page 7]
Internet-Draft Stream DSCP Configuration in SDP Mar 2007
DSCP value
Allowed attribute values: - One Decimal value in the range of 0
through 63 for DSCP of RTP,
and IANA Registered Tokens (there are no
tokens being registered in this document)
- One Decimal value in the range of 0
through 63 for DSCP of RTCP,
and IANA Registered Tokens (there are no
tokens being registered in this document)
Reference: This document (if published)
6. Security Considerations
An attacker may attempt to add, modify, or remove the 'dscp'
attribute(s) from a session description. This could result in a
media stream receiving undesirable behavior through a network. For
example, the endpoints under attack may receive more or less
desirable PHB.
Consequently, it is strongly RECOMMENDED that integrity protection
be applied to SDP session descriptions carrying these attributes.
For session descriptions carried in SIP [RFC3261], S/MIME [RFC3851]
is the natural choice to provide such end-to-end integrity
protection, as described in [RFC3261]. Other applications MAY use a
different form of integrity protection.
7. Open Issues
Here is a list of known open issues understood to the author as
needing to be addressed:
#1 - Is there a need for a direction tag, allowing the session to be
established with one DSCP in one direction and another in the
opposite direction. The author is asking for a use-case for
this, and how strong this function is desired (i.e. nice-to-
have, really-want-this, showstopper-without-it).
8. Acknowledgements
Kevin McMenamy and Subha Dhesikan helped form/focus this effort. As
well as to Scott Brim for reviewing it. Thanks to Dan Wing, Shida
Schubert, Francois Audet, Martin Dolly, and Janet Gunn for helpful
comments, recommendations and support for this effort.
9. References
Polk Expires April 2007 [Page 8]
Internet-Draft Stream DSCP Configuration in SDP Mar 2007
8.1 Normative References
[RFC4566] M. Handley, V. Jacobson, C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with
Session Description Protocol", RFC 3264, June 2002
[RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for
Diffserv Service Classes", RFC4594, August 2006
[ID-EF-ADMIT] F. Baker, J. Polk, M. Dolly, "An EF DSCP for Capacity-
Admitted Traffic", draft-ietf-tsvwg-admitted-realtime-dscp-
00, "work in progress", December 06
[RFC3246] B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le
Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
8.2 Informative References
None
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Polk Expires April 2007 [Page 9]
Internet-Draft Stream DSCP Configuration in SDP Mar 2007
Email: jmpolk@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Polk Expires April 2007 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-22 22:01:13 |