< draft-polk-tsvwg-rfc4594-update-02.txt   draft-polk-tsvwg-rfc4594-update-03.txt >
Network WG James Polk, ed. Network WG James Polk, ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track (PS) Oct 22, 2012 Intended status: Standards Track (PS) Feb, 2013
Obsoletes: RFC 4594 Obsoletes: RFC 4594
Updates: RFC 5865 Updates: RFC 5865
Expires: April 22, 2013 Expires: August 25, 2013
Standard Configuration of DiffServ Service Classes Standard Configuration of DiffServ Service Classes
draft-polk-tsvwg-rfc4594-update-02.txt draft-polk-tsvwg-rfc4594-update-03.txt
Abstract Abstract
This document describes service classes configured with DiffServ and This document describes service classes configured with DiffServ and
identifies how they are used and how to construct them using identifies how they are used and how to construct them using
Differentiated Services Code Points (DSCPs), traffic conditioners, Differentiated Services Code Points (DSCPs), traffic conditioners,
Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) Per-Hop Behaviors (PHBs), and Active Queue Management (AQM)
mechanisms. There is no intrinsic requirement that particular mechanisms. There is no intrinsic requirement that particular
DSCPs, traffic conditioners, PHBs, and AQM be used for a certain DSCPs, traffic conditioners, PHBs, and AQM be used for a certain
service class, but for consistent behavior under the same network service class, but for consistent behavior under the same network
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2013. This Internet-Draft will expire on August 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ...................................................3 1. Introduction ...................................................3
1.1. Requirements Notation .....................................8 1.1. Requirements Notation .....................................
1.2. Expected Use in the Network ...............................8 1.2. Expected Use in the Network ...............................
1.3. Service Class Definition ..................................8 1.3. Service Class Definition ..................................
1.4. Key Differentiated Services Concepts .....................10 1.4. Key Differentiated Services Concepts ......................
1.4.1. Queuing .............................................10 1.4.1. Queuing ..............................................
1.4.1.1. Priority Queuing ...........................10 1.4.1.1. Priority Queuing ............................
1.4.1.2. Rate Queuing ...............................11 1.4.1.2. Rate Queuing ................................
1.4.2. Active Queue Management .............................11 1.4.2. Active Queue Management ..............................
1.4.3. Traffic Conditioning ................................12 1.4.3. Traffic Conditioning .................................
1.4.4. Differentiated Services Code Point (DSCP) ...........12 1.4.4. Differentiated Services Code Point (DSCP) ............
1.4.5. Per-Hop Behavior (PHB) ..............................13 1.4.5. Per-Hop Behavior (PHB) ...............................
1.5. Key Service Concepts .....................................13 1.5. Key Service Concepts ......................................
1.5.1. Default Forwarding (DF) .............................13 1.5.1. Default Forwarding (DF) ..............................
1.5.2. Assured Forwarding (AF) .............................14 1.5.2. Assured Forwarding (AF) ..............................
1.5.3. Expedited Forwarding (EF) ...........................14 1.5.3. Expedited Forwarding (EF) ...........................1
1.5.4. Class Selector (CS) .................................15 1.5.4. Class Selector (CS) .................................1
1.5.5. Admission Control ...................................15 1.5.5. Admission Control ...................................1
2. Service Differentiation .......................................16 1.6 What Changes are Proposed Here from RFC 4594?..............1
2.1. Service Classes ..........................................16 2. Service Differentiation .......................................1
2.2. Categorization of User Oriented Service Classes ..........18 2.1. Service Classes ..........................................1
2.3. Service Class Characteristics ............................22 2.2. Categorization of User Oriented Service Classes ..........1
2.4. Service Classes vs. Treatment Aggregate (from RFC 5127)...27 2.3. Service Class Characteristics ............................1
2.4.1 Examples of Service Classes in Treatment Aggregates...29 2.4. Service Classes vs. Treatment Aggregate (from RFC 5127)...2
3. Network Control Traffic .......................................31 2.4.1 Examples of Service Classes in Treatment Aggregates...2
3.1. Current Practice in the Internet .........................32 3. Network Control Traffic .......................................2
3.2. Network Control Service Class ............................32 3.1. Current Practice in the Internet .........................2
3.3. OAM Service Class ........................................34 3.2. Network Control Service Class ............................2
4. User Oriented Traffic .........................................36 3.3. OAM Service Class ........................................2
4.1. Conversational Service Class Group .......................36 4. User Oriented Traffic .........................................3
4.1.1 Audio Service Class ..................................37 4.1. Conversational Service Class Group .......................3
4.1.2 Video Service Class ..................................40 4.1.1 Audio Service Class ..................................3
4.1.3 Hi-Res Service Class .................................44 4.1.2 Video Service Class ..................................3
4.2. Realtime-Interactive Service Class ...................... 47 4.1.3 Hi-Res Service Class .................................3
4.3. Multimedia Conferencing Service Class ....................50 4.2. Realtime-Interactive Service Class ...................... 3
4.4. Multimedia Streaming Service Class .......................52 4.3. Multimedia Conferencing Service Class ....................3
4.5. Broadcast Video Service Class ............................55 4.4. Multimedia Streaming Service Class .......................3
4.6. Low-Latency Data Service Class ...........................58 4.5. Broadcast Video Service Class ............................4
4.7. Conversational Signaling Service Class ...................60 4.6. Low-Latency Data Service Class ...........................4
4.8. High-Throughput Data Service Class .......................62 4.7. Conversational Signaling Service Class ...................4
4.9. Standard Service Class ...................................65 4.8. High-Throughput Data Service Class .......................4
4.10. Low-Priority Data .......................................66 4.9. Standard Service Class ...................................4
5. Additional Information on Service Class Usage .................67 4.10. Low-Priority Data .......................................4
5.1. Mapping for NTP ..........................................67 5. Additional Information on Service Class Usage .................4
5.2. VPN Service Mapping ......................................67 5.1. Mapping for NTP ..........................................5
5.2. VPN Service Mapping ......................................5
6. Security Considerations .......................................68 6. Security Considerations .......................................5
7. Contributing Authors ..........................................68 7. Contributing Authors ..........................................5
8. Acknowledgements ..............................................69 8. Acknowledgements ..............................................5
9. References ....................................................70 9. References ....................................................5
9.1. Normative References .....................................70 9.1. Normative References .....................................5
9.2. Informative References ...................................71 9.2. Informative References ...................................5
Author's Address .................................................72 Author's Address .................................................5
Appendix A - Changes .............................................72 Appendix A - Changes .............................................5
1. Introduction 1. Introduction
Differentiated Services [RFC2474][RFC2475] provides the ability to Differentiated Services [RFC2474][RFC2475] provides the ability to
mark/label/classify IP packets differently to distinguish how mark/label/classify IP packets differently to distinguish how
individual packets need to be treated differently through (or individual packets need to be treated differently through (or
throughout) a network on a per hop basis. Local administrators are throughout) a network on a per hop basis. Local administrators are
who configure each router for which Differentiated Services Code who configure each router for which Differentiated Services Code
Points (DSCP) are to be treated differently, which are to be Points (DSCP) are to be treated differently, which are to be
ignored (i.e., no differentiated treatment), and which DSCPs are to ignored (i.e., no differentiated treatment), and which DSCPs are to
skipping to change at page 7, line 21 skipping to change at page 7, line 22
Forwarding by having the packets marked be for admitted traffic. Forwarding by having the packets marked be for admitted traffic.
This concept of "admitted" traffic is spread throughout the real This concept of "admitted" traffic is spread throughout the real
time traffic classes. time traffic classes.
Thus, the document flow is as follows: Thus, the document flow is as follows:
o maintain the general format of RFC 4594; o maintain the general format of RFC 4594;
o augment the content with the concept of capacity-admission; o augment the content with the concept of capacity-admission;
o incorporate much more video into this document, as it has become o incorporate more video into this document, as it has become a
a dominant application in enterprises and other managed networks, dominant application in enterprises and other managed networks,
as well as on the open public Internet; as well as on the open public Internet;
o reduce the discussion on voice and its examples; o reduce the discussion on voice and its examples;
o articulate the subtle differences learned since RFC 4594 was o articulate the subtle differences learned since RFC 4594 was
published. published.
The goal here is to provide a standard configuration for DiffServ The goal here is to provide a standard configuration for DiffServ
DSCP assignments and expected PHBs for enterprises and other managed DSCP assignments and expected PHBs for enterprises and other managed
networks, as well as towards the public Internet with specific networks, as well as towards the public Internet with specific
traffic characteristics per Service class/DSCP, and example traffic characteristics per Service class/DSCP, and example
applications shown for each. applications shown for each.
This document describes service classes configured with DiffServ and This document describes service classes configured with DiffServ and
defines how they can be used and how to construct them using defines how they can be used and how to construct them using
Differentiated Services Code Points (DSCPs), and recommends how to Differentiated Services Code Points (DSCPs), and recommends how to
construct them using traffic conditioners, Per-Hop Behaviors (PHBs), construct them using traffic conditioners, Per-Hop Behaviors (PHBs),
and Active Queue Management (AQM) mechanisms. There is no intrinsic and Active Queue Management (AQM) mechanisms. There is no intrinsic
requirement that particular traffic conditioners, PHBs, and AQM be requirement that particular traffic conditioners, PHBs, and AQM be
used for a certain service class, but as a policy and for used for a certain service class, but as a policy and for
interoperability it is useful to apply them consistently. This interoperability it is useful to apply them consistently.
document explicitly states there is a fundamental requirement that a
particular DSCP or DSCPs be used for each service class.
We differentiate services and their characteristics in Section 2. We differentiate services and their characteristics in Section 2.
Network control traffic, as well as user oriented traffic are Network control traffic, as well as user oriented traffic are
discussed in Sections 3 and 4, respectively. We analyze the security discussed in Sections 3 and 4, respectively. We analyze the security
considerations in Section 6. Section 7 offers a tribute to the considerations in Section 6. Section 7 offers a tribute to the
authors of RFC 4594, from which this document is based. It is in its authors of RFC 4594, from which this document is based. It is in its
own section, and not part of the normal acknowledgements portion of own section, and not part of the normal acknowledgements portion of
each IETF document. each IETF document.
1.1. Requirements Notation 1.1. Requirements Notation
skipping to change at page 15, line 23 skipping to change at page 15, line 23
- First, there are per-hop behaviors that are already in widespread - First, there are per-hop behaviors that are already in widespread
use (e.g., those satisfying the IPv4 Precedence queuing use (e.g., those satisfying the IPv4 Precedence queuing
requirements specified in [RFC1812]), and requirements specified in [RFC1812]), and
- this document will continue to permit their use in DS-compliant - this document will continue to permit their use in DS-compliant
networks. networks.
In addition, there are some DSCPs that correspond to historical use In addition, there are some DSCPs that correspond to historical use
of the IP Precedence field, of the IP Precedence field,
- CS0 (000000) will remain 'Default Forwarding' (also know as 'Best - CS0 (000000) will remain 'Default Forwarding' (also known as 'Best
Effort') Effort')
- 11xxxx will remain for routing traffic - 11xxxx will remain for routing traffic
and will map to PHBs that meet the general requirements specified in and will map to PHBs that meet the general requirements specified in
[RFC2474], Section 4.2.2.2. [RFC2474], Section 4.2.2.2.
No attempt is made to maintain backward compatibility with the "DTR" No attempt is made to maintain backward compatibility with the "DTR"
or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in
[RFC0791] and [RFC1349]. [RFC0791] and [RFC1349].
skipping to change at page 16, line 29 skipping to change at page 16, line 29
transits and the load on each transited network. There are a series transits and the load on each transited network. There are a series
of new DSCPs proposed in [ID-DSCP], each specifying unique of new DSCPs proposed in [ID-DSCP], each specifying unique
characteristics necessitating a separate marking from what existing characteristics necessitating a separate marking from what existing
before that document. before that document.
This document will import in four new '*-Admit' DSCPs from This document will import in four new '*-Admit' DSCPs from
[ID-DSCP], 2 others that are new but not capacity-admitted, one from [ID-DSCP], 2 others that are new but not capacity-admitted, one from
RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594. RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594.
This is discussed throughout the rest of this document. This is discussed throughout the rest of this document.
1.6 What Changes are Proposed Here from RFC 4594?
Changing an entire network DiffServ configuration has proven to be a
painful experience for both individuals and companies. It is not
done very often, and for good reason. This effort is based on
experience learned since the publication of RFC 4594 (circa 2006).
Audio, once thought to be ok grouped with video, needs to be in
separate service classes. Collaboration has taken off, mostly
because of mobility, but also because of a worldwide recession that
has limited physical travel, and relying on people to do more with
their computers. With that in mind, there has been an explosion in
application development for the individual (seems everyone has an
"app-store"). The following set of bullets has this world - that
needs a robust layer 3 - in mind.
o Scope of document is changed to tighten it up for standards track
consideration.
o This document explicitly states there is a fundamental requirement
that a particular DSCP(s) be used for each service class, each
with a recommended set of applications to be used by that service
class - at least on that individual's externally facing (public)
interface.
o Created the Conversational group of service classes to focus on
realtime, mostly bidirectional communications (unless multicast is
used).
o "Realtime-Interactive"
Moved to (near) realtime TCP-based apps
Why the change? TCP based transports have proven, in certain
environments, to be a bidirectional realtime transport, e.g., for
multiplayer gaming and virtual desktops applications.
o "Audio"
Same as Telephony (which is now gone), adds Voice-Admit for
capacity-admitted traffic
Why the change? RFC 5865 (Voice-Admit) needed to be added to the
Audio service class. Video needed to be separate from audio, hence
the name change from Telephony (which includes video) to just audio.
o "Video"
NEW for video and audio/video conferencing, was in
Multimedia-Conferencing service classification
Why the change? Many networks are using the AF4X for video, but
others are throwing anything "multimedia" into the same service
class (like elastic TCP flows). Video has become so dominant that it
should be what mostly goes into one service class.
o "Hi-Res"
NEW for video and audio/video conferencing
Why the change? This entirely new service class is for local policy
based higher end video (think Telepresence). Without congestion,
this service class has the same treatment as Video, but if there is
any pushback from the network, Hi-Res (note: not married to the
name) has a better PHB.
o "Multimedia-Conferencing"
Now without audio or human video
Why the change? The change is taking bidirectional human audio and
video out of this service class. This is all about non-realtime
collaboration - even in conjunction with an audio and/or video flow.
o "Broadcast"
Remains the same, added CS3-Admit for capacity-admitted
Why the change? Removing the "-Video" from the name because there
are so many more flows that are Broadcast in realtime than video.
o "Low-Latency Data"
Remains the same, adds IM & Presence traffic explicitly
Why the change? Merely explicitly stating a place for some
additional traffic types that otherwise could go elsewhere.
o "Conversational Signaling" (A/V-Sig)
Was 'Signaling'
Why the change? This change is merely a renaming of a service class,
and acknowledgement that some of the previous authors inaccurate
beliefs that DSCPs were linearly ordered with those values having a
higher value definitely getting better treatment than lower values.
2. Service Differentiation 2. Service Differentiation
There are practical limits on the level of service differentiation There are practical limits on the level of service differentiation
that should be offered in the IP networks. We believe we have that should be offered in the IP networks. We believe we have
defined a practical approach in delivering service differentiation defined a practical approach in delivering service differentiation
by defining different service classes that networks may choose to by defining different service classes that networks may choose to
support in order to provide the appropriate level of behaviors and support in order to provide the appropriate level of behaviors and
performance needed by current and future applications and services. performance needed by current and future applications and services.
The defined structure for providing services allows several The defined structure for providing services allows several
applications having similar traffic characteristics and performance applications having similar traffic characteristics and performance
skipping to change at page 46, line 4 skipping to change at page 47, line 39
However, it is typically the case that the Hi-Res conferencing flows However, it is typically the case that the Hi-Res conferencing flows
have more rigid requirements for quality and business-wise, need to have more rigid requirements for quality and business-wise, need to
be experience far less errors than the regular video service on the be experience far less errors than the regular video service on the
same network. same network.
Note that it is likely the case in these networks that the Note that it is likely the case in these networks that the
accompanying audio to the Hi-Res video call will be marked as the accompanying audio to the Hi-Res video call will be marked as the
Hi-Res video is marked (i.e., using the same DSCP. Hi-Res video is marked (i.e., using the same DSCP.
The Hi-Res service class MUST use the Class Selector 5 (CS4) PHB, The Hi-Res service class MUST use the Class Selector 5 (CS4) PHB,
defined in [RFC2474], for non-capacity-admitted conferences. While defined in [RFC2474], for non-capacity-admitted conferences. While
the capacity-admitted Hi-Res conferences MUST use the CS4-Admit PHB, the capacity-admitted Hi-Res conferences MUST use the CS4-Admit PHB,
defined in [ID-DSCP]. This service class MUST be configured to defined in [ID-DSCP]. This service class MUST be configured to
provide a bandwidth assurance for CS4 and CS4-Admit marked packets provide a bandwidth assurance for CS4 and CS4-Admit marked packets
to ensure that they get forwarded. The Hi-Res service class SHOULD to ensure that they get forwarded. The Hi-Res service class SHOULD
be configured to use a Priority Queuing system such as that defined be configured to use a Priority Queuing system such as that defined
in Section 1.4.1.1 of this document. Further, CS4-Admit will be in Section 1.4.1.1 of this document. Further, CS4-Admit will be
designated as the DSCP for use when capacity-admission signaling has designated as the DSCP for use when capacity-admission signaling has
been used, such as RSVP or NSIS, to guarantee delivery through the been used, such as RSVP or NSIS, to guarantee delivery through the
network. CS4 will be used for non-admitted Hi-Res conferences, as network. CS4 will be used for non-admitted Hi-Res conferences, as
well as overflows from CS4-Admit sources that send more packets than well as overflows from CS4-Admit sources that send more packets than
skipping to change at page 73, line 6 skipping to change at page 74, line 38
Phone: +1.817.271.3552 Phone: +1.817.271.3552
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Appendix A - Changes Appendix A - Changes
Here is a list of all the changes that were captured during the Here is a list of all the changes that were captured during the
editing process. This will not be a complete list, and others are editing process. This will not be a complete list, and others are
free to point out what the authors missed, and we'll include that in free to point out what the authors missed, and we'll include that in
the next release. the next release.
A.1 Since Individual -01 to -02 A.1 Since Individual -02 to -03
o Inserted section 1.6 to explain fundamentally what has changed
since RFC 4594, and why changes are necessary.
A.2 Since Individual -01 to -02
o Added text to the Intro section on the justification from o Added text to the Intro section on the justification from
DiffServ Problem Statement draft, as to more of why this update DiffServ Problem Statement draft, as to more of why this update
is necessary. is necessary.
o Added text to the Intro section expanding on the concept of o Added text to the Intro section expanding on the concept of
service classes vs. treatment aggregates (from RFC 5127). service classes vs. treatment aggregates (from RFC 5127).
A.2 Since Individual -00 to -01 A.3 Since Individual -00 to -01
o Added Section 2.4 which covers the conflation issues regarding o Added Section 2.4 which covers the conflation issues regarding
the differences between service classes and treatment aggregates. the differences between service classes and treatment aggregates.
o Added example operational configurations of treatment aggregates o Added example operational configurations of treatment aggregates
applied to this draft's new set of service classes and additional applied to this draft's new set of service classes and additional
DSCPs. DSCPs.
o Added references RFC 5865, RFC 5462, IEEE 802.1E and IEEE 802.1Q. o Added references RFC 5865, RFC 5462, IEEE 802.1E and IEEE 802.1Q.
A.3 Since RFC 4594 to Individual Update -00 A.4 Since RFC 4594 to Individual Update -00
o rewrote Intro to emphasize current topics o rewrote Intro to emphasize current topics
o Created a Conversational Service group, comprising the audio, o Created a Conversational Service group, comprising the audio,
video and Hi-Res service classes - because they have similar video and Hi-Res service classes - because they have similar
characteristics. characteristics.
o Incorporated the 6 new DSCPs from [ID-DSCP]. o Incorporated the 6 new DSCPs from [ID-DSCP].
o moved the example section, en mass, to an appendix that might not o moved the example section, en mass, to an appendix that might not
 End of changes. 13 change blocks. 
67 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/