Network WG James Polk Internet-Draft Cisco Intended status: Standards Track (PS) Oct 22, 2012 Expires: April 22, 2013 New Differentiated Services Code Point Assignments for Rich Media Traffic draft-polk-tsvwg-new-dscp-assignments-01.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 April 22, 2013. Copyright Notice Copyright (c) 2012 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 April 22, 2013 [Page 1] Internet-Draft New Rich Media (Video) DSCPs Oct 2012 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 April 22, 2013 [Page 2] Internet-Draft New Rich Media (Video) DSCPs Oct 2012 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 April 22, 2013 [Page 3] Internet-Draft New Rich Media (Video) DSCPs Oct 2012 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 April 22, 2013 [Page 4] Internet-Draft New Rich Media (Video) DSCPs Oct 2012 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 April 22, 2013 [Page 5] Internet-Draft New Rich Media (Video) DSCPs Oct 2012 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 April 22, 2013 [Page 6] Internet-Draft New Rich Media (Video) DSCPs Oct 2012 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 April 22, 2013 [Page 7] Internet-Draft New Rich Media (Video) DSCPs Oct 2012 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 April 22, 2013 [Page 8] Internet-Draft New Rich Media (Video) DSCPs Oct 2012 aspect is the main point of this document. 6.1 DSCP Assignments from Pool 1 The code points described in this document is referred to as the following from Pool 1 and has been requested 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 The code points described in this document is referred to as the following from Pool 3 and has been requested as follows: 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 April 22, 2013 [Page 9] Internet-Draft New Rich Media (Video) DSCPs Oct 2012 [ID-4594-UP] J. Polk, "Standard Configuration of DiffServ Service Classes", "work in progress", March 2012 [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 April 22, 2013 [Page 10]