Internet DRAFT - draft-polk-tsvwg-new-dscp-assignments
draft-polk-tsvwg-new-dscp-assignments
Network WG James Polk
Internet-Draft Cisco
Intended status: Standards Track (PS) Feb 25, 2013
Expires: August 25, 2013
New Differentiated Services Code Point Assignments
for Rich Media Traffic
draft-polk-tsvwg-new-dscp-assignments-02.txt
Abstract
This document requests five new Differentiated Services Code Point
(DSCP) values (DSCP) from the Internet Assigned Numbers Authority
(IANA) for new classes of rich media traffic and one additional DSCP
value for the signaling of multimedia sessions.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 25, 2013.
Copyright Notice
Copyright (c) 2013 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 Simplified BSD License.
Polk Expires August 25, 2013 [Page 1]
Internet-Draft New Rich Media (Video) DSCPs Feb 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Evolution of the Proposed DSCPs . . . . . . . . . . . . . . . 4
4. New DSCP Assignments. . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1 Normative References . . . . . . . . . . . . . . . . . 9
8.2 Informative References . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document requests five new Differentiated Services Code Point
(DSCP) values (DSCP) from the Internet Assigned Numbers Authority
(IANA) for new classes of rich media traffic and one additional DSCP
value for the signaling of multimedia sessions. Four of the six new
DSCP values are for traffic classes that are admitted by the network
using an additional Capacity-Admission signaling procedure to the
normal signaling that occurs between multiple endpoints establishing
a traffic flow between endpoints. The additional capacity-admission
signaling procedure is offered in RFC 5865 [RFC5865], which defined
the Voice-Admit per hop behavior (PHB) DSCP. Each of these four
traffic classes can conform to the Expedited Forwarding Per-Hop
Behavior, if configured to do so, using the Priority Queuing system
such as that defined in Section 1.4.1.1 of [ID-4594-UP].
It is expected that voice and video media samples will be carried
using the Real-time Transport Protocol (RTP) [RFC3550], thus making
voice by itself indistinguishable from video to routers and
switches, unless one of two things occurs:
o Deep packet inspection (DPI) at the ingress of each DiffServ edge
node to determine that the packet is an RTP packet with a certain
codec that properly identifies it as either a voice or video
packet, or
o have a separate marking for the packets (i.e., a different DSCP).
It is certainly the case that voice samples/frames can be in the
same packet as video frames, thus making the packet marked either
voice or video, but that will have to be left to the application to
decide if that is a good idea. For what it is worth, most current
implementations of mixing the media types have the packets marked as
a video.
Polk Expires August 25, 2013 [Page 2]
Internet-Draft New Rich Media (Video) DSCPs Feb 2013
This effort is based on the work started in RFC 5865 [RFC5865], a
Differentiated Services Code Point for Capacity-Admitted Traffic
voice only traffic, which recommends the classes created within RFC
4594 [RFC4594] be extended for video traffic flows of different
types. Nearly all of what is requested and referenced here is based
on what started in RFC 4594, but with video as the dominant
application as RFC 5865 recommends. Presently, RFC 4594 is being
updated by [ID-4594-UP] for many reasons, including the inclusion of
these six new DSCPs.
These four new video classes differ from their existing counterparts
in behavior by not being subjected to capacity admission. All of the
mentioned traffic classes and subsequent DSCPs within RFC 4594 are
non-binding, given that it is a non-normative RFC. RFC 4594 also did
not recommend the need for capacity admission traffic classes (aka
with associated DSCP values). This document is symbiotic with
[ID-4594-UP] which intends to replace RFC 4594 as a standards track
update which includes the new DSCP assignments created within this
document.
Thus, RFC 4594 defined the need for application assignment of
certain DSCPs, but only non-normatively. RFC 5865 defined updated
DSCP values for a capacity-admitted voice traffic class that is
normative. This document takes what was in RFC 4594, creates 4 new
capacity-admitted traffic classes and associated DSCPs. This
document also moves one non-capacity-admitted traffic class as well
as moves the recommended audio/video signaling DSCP value to another
value.
Within RFC 5865, there is the specific call for additional DSCPs for
capacity-admitted traffic flows of real-time rich media (video)
flows in Section 3 of that document under the heading "Summary:
Changes from RFC 4594".
It should be noted here that these flows are typically video flows,
and frequently include the audio with the adjoining video traffic
within that flow. The details of how that gets sorted out are
outside the scope of this document. DiffServ is a known and proven
mechanism. This document does not change or challenge the idea that
Differentiated Services is a Per Hop Behavior (PHB) mechanism, and
does not create a service. Here we merely want to add new DSCP
assignments because of how at least some of the world is (or wants
to) differentiate video from other traffic, including other video
traffic.
Section 3 will discuss some of the evolution of DSCP assignments,
focusing on those aspects pertinent to the creation of these six new
DSCP values. Section 4 describes and defines each of the six DSCP
values being requested. Heavy reliance exists on the text of RFC
5865 for its diagrams and charts. Those were not brought into this
document at this time, but could be in the future.
Polk Expires August 25, 2013 [Page 3]
Internet-Draft New Rich Media (Video) DSCPs Feb 2013
2. Terminology
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].
CAC - defined in RFC 5865
PHB - defined in RFC 5865
DSCP - defined in RFC 5865
Queue - defined in RFC 5865
3. Evolution of the Proposed DSCPs
First of all, full consideration of PHBs and DSCPs needs to
originate with RFC 2474. Section 6 of that document states the
following:
"The DSCP field within the DS field is capable of conveying 64
distinct codepoints. The codepoint space is divided into
three pools for the purpose of codepoint assignment and
management: a pool of 32 RECOMMENDED codepoints (Pool 1) to
be assigned by Standards Action as defined in [CONS], a pool
of 16 codepoints (Pool 2) to be reserved for experimental or
Local Use (EXP/LU) as defined in [CONS], and a pool of 16
codepoints (Pool 3) which are initially available for
experimental or local use, but which should be preferentially
utilized for standardized assignments if Pool 1 is ever
exhausted. The pools are defined in the following table
(where 'x' refers to either '0' or '1'):
Pool Codepoint space Assignment Policy
---- --------------- -----------------
1 xxxxx0 Standards Action
2 xxxx11 EXP/LU
3 xxxx01 EXP/LU (*)
(*) may be utilized for future Standards Action allocations as
Necessary"
The key part of the above quote is
"... which should be preferentially utilized for standardized
assignments if Pool 1 is ever exhausted..."
which we here take to mean 'SHOULD NOT use unless you have a really
good reason to use'. We propose what we consider a really good
Polk Expires August 25, 2013 [Page 4]
Internet-Draft New Rich Media (Video) DSCPs Feb 2013
reason to use some of the assignments from Pool 3 before Pool 1 is
exhausted. One reason for assigning out of Pool 3 is to get similar
marking from layer 2 technologies that only have 3 bits to use for
their value, not 6 bits. Technologies such as 802.3 Ethernet, 802.11
Wireless Ethernet, and MPLS are 3 examples of technologies that only
have 3 bits to use.
[Editor's Note: If this aspect of assigning DSCPs from Pool 3 before
Pool 1 is exhausted requires an update to RFC 2474,
please let the authors know so we can point this out
to the community for additional feedback.]
Just as RFC 5865 matched the first 3 (or 4) bits with EF for
Voice-Admit (101110 and 101100), we RECOMMEND the admitted DSCP for
an existing value be its XXXX01 version of the non-admitted DSCP
(XXXXX0). We note that the last two bits MUST NOT be x11 because
that would mean the value is a Pool 2 value, which is forbidden
currently by RFC 2474.
Thus, a DSCP value commonly traverses a layer 2 device by ignoring
the last 3 bits of the DSCP value, i.e., taking EF, which is 101110,
and reducing it to 101 only, and transmitting this over the layer 2
infrastructure.
RFC 4954, and its intended replacement document [ID-4594-UP], create
several service classes primarily intended for video traffic with
slightly different characteristics. It was stated there that not all
video DSCP values from RFC 4594 are expected to be within the same
network, but that could be the case.
RFC 4594 listed these voice and video services classes:
o "Telephony" using the EF DSCP
o "Realtime Interactive" using the CS4 DSCP
o "Multimedia Conferencing" using the AF4X DSCP
o "Multimedia Streaming" using the AF3X DSCP
o "Broadcast Video" using the CS3 DSCP
Plus, for Telephony Signaling
o "Signaling" using the CS5 DSCP
[ID-4594-UP] lists these 'non-admitted' voice and video services
classes (some with changed service names, as well as some DSCPs
changed):
o Audio using the EF DSCP
Polk Expires August 25, 2013 [Page 5]
Internet-Draft New Rich Media (Video) DSCPs Feb 2013
o Video using the AF4X DSCP
o Hi-Res using the CS4 DSCP
o Realtime-Interactive using the CS5 DSCP
o Multimedia Streaming using the AF3X DSCP
o Broadcast using the CS3 DSCP
The Multimedia Conferencing purpose and meaning has been changed
within [ID-DSCP-UP], as has its DSCPs, which will be listed in the
next set of bullets and defined within this document.
RFC 5865 created the new capacity-admitted Voice-Admit, which
mentions specifically that a reservation protocol, "such as RSVP" is
used to establish those sessions or traffic flows.
This document creates six additional services classes that are
incorporated into [ID-4594-UP]:
o Hi-Res-Admit using the CS4-Admit (100001) DSCP
o Realtime-Interactive-Admit using the CS5-Admit (101001) DSCP
o Multimedia Conferencing using the MC (011101) DSCP
o Multimedia Conferencing-Admit using the MC-Admit (100101) DSCP
o Broadcast-Admit using the CS3-Admit (011001) DSCP
Plus, for Conversational Signaling (a term described in
[ID-4594-UP]), which is no longer to use the CS5 DSCP,
o "A/V-Sig" using the 010001 DSCP
The results of this are that the
- CS4-Admit is the xxxxx1 version of CS4.
- CS5-Admit is the xxxxx1 version of CS5.
- CS3-Admit is the xxxxx1 version of CS3.
MC-Admit is not the xxxxx1 version of the new MC DSCP value
(100101), because there are no more 100xxx values that are
available, outside of the two x11 values from Pool 2, which cannot
be assigned for public use.
[Editor's Note: The author is open to suggestions from the
community for how to resolve this issue, if anyone
considers it an issue.]
Polk Expires August 25, 2013 [Page 6]
Internet-Draft New Rich Media (Video) DSCPs Feb 2013
The new goal for the signaling service class is to not be starved.
It has been shown that mission critical voice and video call set-up
does not require expedited forwarding as a PHB. However, this
service class MUST NOT be starved, and so it is RECOMMENDED to use a
codepoint similar in characteristics to the RFC 4594 (and
[ID-4594-UP] defined Low-Latency Data service class of 010xxx.
4. New DSCP Assignments
4.1 The CS5-Admit PHB
'CS5-Admit' MUST be used with a capacity-admission signaling
procedure similar to what is required of 'Voice-Admit' [RFC5865].
RSVP [RFC2205] and NSIS [RFC4080] are two good examples for
data-path signaling for capacity-admission. Neither is mandatory,
but one of them SHOULD be used.
CS5-Admit has traffic characteristics described in [ID-4594-UP].
The DSCP value requested for CS5-Admit is 101001.
4.2 The CS4-Admit DSCP
'CS4-Admit' MUST be used with a capacity-admission signaling
procedure similar to what is required of 'Voice-Admit' [RFC5865].
RSVP [RFC2205] and NSIS [RFC4080] are two good examples for
data-path signaling for capacity-admission. Neither is mandatory,
but one of them SHOULD be used.
CS4-Admit has traffic characteristics described in [ID-4594-UP].
The DSCP value requested for CS4-Admit is 100001.
4.3 The CS3-Admit DSCP
'CS3-Admit' MUST be used with a capacity-admission signaling
procedure similar to what is required of 'Voice-Admit' [RFC5865].
RSVP [RFC2205] and NSIS [RFC4080] are two good examples for
data-path signaling for capacity-admission. Neither is mandatory,
but one of them SHOULD be used.
CS3-Admit has traffic characteristics described in [ID-4594-UP].
The DSCP value requested for CS3-Admit is 011001.
Polk Expires August 25, 2013 [Page 7]
Internet-Draft New Rich Media (Video) DSCPs Feb 2013
4.4 The MC DSCP
'MC' SHOULD NOT use a capacity-admission signaling procedure.
Rather, the MC-Admit is used with a capacity-admission signaling
procedure if needed. This PHB MUST be non-admitted.
MC has traffic characteristics described in [ID-4594-UP].
The DSCP value requested for MC is 011001.
4.5 The MC-Admit DSCP
'MC-Admit' MUST be used with a capacity-admission signaling
procedure similar to what is required of 'Voice-Admit' [RFC5865].
RSVP [RFC2205] and NSIS [RFC4080] are two good examples for
data-path signaling for capacity-admission. Neither is mandatory,
but one of them SHOULD be used.
MC-Admit has traffic characteristics described in [ID-4594-UP].
The DSCP value requested for MC-Admit is 100101.
4.6 The Conversational Signaling (A/V-Sig) DSCP
'A/V-Sig' MUST be used with a capacity-admission signaling procedure
similar to what is required of 'Voice-Admit' [RFC5865]. RSVP
[RFC2205] and NSIS [RFC4080] are two good examples for data-path
signaling for capacity-admission. Neither is mandatory, but one of
them SHOULD be used.
A/V-Sig has traffic characteristics described in [ID-4594-UP].
The DSCP value requested for A/V-Sig is 010001.
5. Acknowledgements
The author would like to thank Paul Jones, Glen Lavers, Mo Zanaty,
David Benham, Michael Ramalho for their comments and questions about
this effort that ultimately helped shape this document.
6. IANA Considerations
IANA is requested to make the following registry assignments from
Pool 1 and Pool 3 from the dscp-parameters section within IANA.
Justification for assigning from Pool 3 is in Section 3 of this
document, and are the only possible parallel assignments to existing
assignments of similar registries - very much for the reason
Voice-Admit [RFC5865] was assigned a codepoint similar to EF. That
Polk Expires August 25, 2013 [Page 8]
Internet-Draft New Rich Media (Video) DSCPs Feb 2013
aspect is the main point of this document.
6.1 DSCP Assignments from Pool 1
The code point described in this document is requested to be added
to the Pool 1 Codepoint table as follows:
Sub-registry: Pool 1 Codepoints
Reference: [RFC2474]
Registration Procedures: Standards Action
Registry:
Name Space Reference
--------- ------- ---------
A/V-Sig 010010 [this document]
6.2 DSCP Assignments from Pool 3
A new "Pool 3 Codepoints" table is requested to be built by IANA
similar to the Pool 1 Codepoint table in the form:
Sub-registry: Pool 3 Codepoints
Reference: [RFC2474]
Registration Procedures: Standards Action
Registry:
Name Space Reference
--------- ------- ---------
CS5-Admit 101001 [this document]
CS4-Admit 100001 [this document]
CS3-Admit 011001 [this document]
MC-Admit 100101 [this document]
MC 011001 [this document]
7. Security Considerations
The Security Considerations are identical to those of RFC 5865.
Every newly proposed DSCP (save A/V-Sig) serves the same security
risk and properties of the Voice-Admit DSCP. Section 3 of this
document discusses why these DSCP values are should be parallel to
their non-admitted counterparts, just as Voice-Admit states in RFC
5865 it is parallel to the existing (at the time) EF.
The A/V-Sig merely has a new DSCP name, RFC 4594 currently has this
service class called "Signaling", serving the same purpose.
8. References
8.1 Normative References
Polk Expires August 25, 2013 [Page 9]
Internet-Draft New Rich Media (Video) DSCPs Feb 2013
[ID-4594-UP] J. Polk, "Standard Configuration of DiffServ Service
Classes", "work in progress", February 2013
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997
[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
[RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code
Point (DSCP) for Capacity-Admitted Traffic", RFC 5865,
May 2010
8.2 Informative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch,
"Next Steps in Signaling (NSIS): Framework", RFC 4080, June
2005
[RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for
Diffserv Service Classes", RFC 4594, August 2006
Author's Addresses
James Polk
3913 Treemont Circle
Colleyville, Texas 76034
Phone: +1.817.271.3552
Email: jmpolk@cisco.com
Polk Expires August 25, 2013 [Page 10]
