One document matched: draft-polk-mmusic-dscp-attribute-00.txt
MMUSIC Working Group James Polk
Internet-Draft Cisco Systems
Expires: April 16th, 2007 Oct 16th, 2006
Configuring the Differentiated Services Codepoint of
Session Description Protocol Established Media Streams
draft-polk-mmusic-dscp-attribute-00
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 April 16th, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The offer/answer model for SDP currently is without a mechanism for
the 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, lending
itself to a PHB, 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 Oct 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SDP Attributes Definition . . . . . . . . . . . . . . . . . . 3
3. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 4
3.1 Offerer Behavior . . . . . . . . . . . . . . . . . . . . . 5
3.2 Answerer Behavior . . . . . . . . . . . . . . . . . . . . . 5
4. Changing the 'dscp' Attribute in an Established Session . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1 Registration of the SDP 'dscp' Attribute . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . 8
1. Introduction
The offer/answer model for SDP [RFC4566] currently is neutral to any
domain per hop behaviors (PHB) that exist, and therefore any layer 3
indications 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 [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 within each offer
[RFC3264], possibly with each stream needing to use different DSCPs
per stream. Thus, it seem 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.
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). There are times, and environments, in
which the DSCP for a voice session will be different than other
voice sessions from a particular endpoint. 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
Polk Expires April 2007 [Page 2]
Internet-Draft Stream DSCP Configuration in SDP Oct 2006
decide which DSCP, and ultimately which PHB, a media stream is to
have within an environment (i.e. within a domain).
Thinking of SIP as a transport of SDP for a moment, SIP message
routing servers are called proxies. 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, and there is the
Session Border Controller (SBC) form, 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 UA, in each direction.
SBCs are typically at a domain boundary, meaning these devices are
SIP and SDP aware, and are a relay point of RTP. 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.
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)
Polk Expires April 2007 [Page 3]
Internet-Draft Stream DSCP Configuration in SDP Oct 2006
dscp-value = numeric-sting / alpha-string
numeric-sting = 0-63 (range)
alpha-string = token
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].
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 Intermediary Bob
| Offer | |
|----------------->| Offer |
| | a=dscp 46 |
| |------------------>|
| | Answer |
| | a=dscp 46 |
| Answer |<------------------|
| a=dscp 46 | |
|<-----------------| |
| | |
| 2-way RTP (DSCP=46 or EF) |
|<====================================>|
| | |
Figure 1. Diagram with B2BUA setting initial DSCPs
Polk Expires April 2007 [Page 4]
Internet-Draft Stream DSCP Configuration in SDP Oct 2006
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
The above "a=" line would set the media packets for this stream to
Expedited Forwarding (EF) as defined by [RFC3246].
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
thereby setting this media stream to what is considered Best Effort
PHB.
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.
3.2 Answerer Behavior
An answerer 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.
Polk Expires April 2007 [Page 5]
Internet-Draft Stream DSCP Configuration in SDP Oct 2006
Alice Intermediary Bob
| |
| 2-way RTP (dscp=46 or EF) |
| established |
|<====================================>|
| | |
| Offer | Offer |
| a=dscp 41 | a=dscp 41 |
|<-----------------|------------------>|
| 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
Polk Expires April 2007 [Page 6]
Internet-Draft Stream DSCP Configuration in SDP Oct 2006
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
Allowed attribute values: One Decimal value in the range of 0
through 63,
and IANA Registered Tokens (there are no
tokens being registered in this document)
Reference: This document (if an RFC)
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. Acknowledgements
Kevin McMenamy and Subha Dhesikan helped form/focus this effort. As
well as to Scott Brim for reviewing it.
8. References
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.
Polk Expires April 2007 [Page 7]
Internet-Draft Stream DSCP Configuration in SDP Oct 2006
[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
Email: jmpolk@cisco.com
Intellectual Property Statement
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
Polk Expires April 2007 [Page 8]
Internet-Draft Stream DSCP Configuration in SDP Oct 2006
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Polk Expires April 2007 [Page 9]| PAFTECH AB 2003-2026 | 2026-04-22 22:07:18 |