draft-ietf-tsvwg-diffserv-class-aggr-07.txt   rfc5127.txt 
TSVWG K. Chan Network Working Group K. Chan
Internet-Draft J. Babiarz Request for Comments: 5127 J. Babiarz
Intended status: Informational Nortel Category: Informational Nortel
Expires: May 9, 2008 F. Baker F. Baker
Cisco Systems Cisco Systems
November 6, 2007 February 2008
Aggregation of DiffServ Service Classes
draft-ietf-tsvwg-diffserv-class-aggr-07
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 May 9, 2008. Aggregation of Diffserv Service Classes
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2007). This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
In the core of a high capacity network, service differentiation may In the core of a high-capacity network, service differentiation may
still be needed to support applications' utilization of the network. still be needed to support applications' utilization of the network.
Applications with similar traffic characteristics and performance Applications with similar traffic characteristics and performance
requirements are mapped into diffserv service classes based on end- requirements are mapped into Diffserv service classes based on end-
to-end behavior requirements of the applications. However, some to-end behavior requirements of the applications. However, some
network segments may be configured in such a way that a single network segments may be configured in such a way that a single
forwarding treatment may satisfy the traffic characteristics and forwarding treatment may satisfy the traffic characteristics and
performance requirements of two or more service classes. In these performance requirements of two or more service classes. In these
cases, it may be desirable to aggregate two or more diffserv service cases, it may be desirable to aggregate two or more Diffserv service
classes into a single forwarding treatment. This document provides classes into a single forwarding treatment. This document provides
guidelines for the aggregation of diffserv service classes into guidelines for the aggregation of Diffserv service classes into
forwarding treatments. forwarding treatments.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Service Class Aggregation . . . . . . . . . . . . 5 3. Overview of Service Class Aggregation . . . . . . . . . . . . 5
4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6
4.1. Mapping Service Classes into Four Treatment Aggregates . . 7 4.1. Mapping Service Classes into Four Treatment Aggregates . . 7
4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9 4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9
4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 10 4.1.2. Real-Time Treatment Aggregate . . . . . . . . . . . . 10
4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10
4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 12 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 12
5. Treatment Aggregates and Inter-Provider Relationships . . . . 12 5. Treatment Aggregates and Inter-Provider Relationships . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Appendix A.1. Network Control Treatment Aggregate with E-LSP . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A.2. Real Time Treatment Aggregate with E-LSP . . . . . . 15 Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 15
Appendix A.3. Assured Elastic Treatment Aggregate with E-LSP . . . 15 A.1. Network Control Treatment Aggregate with E-LSP . . . . . . 17
Appendix A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . 15 A.2. Real-Time Treatment Aggregate with E-LSP . . . . . . . . . 17
Appendix A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . 16 A.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
In the core of a high capacity network, it is common for the network In the core of a high capacity network, it is common for the network
to be engineered in such a way that a major link, switch, or router to be engineered in such a way that a major link, switch, or router
can fail and the result will be a routed network that still meets can fail, and the result will be a routed network that still meets
ambient SLAs (Service Level Agreements). The implication of this is ambient Service Level Agreements (SLAs). The implications are that
that there is sufficient capacity on any given link such that all there is sufficient capacity on any given link such that all SLAs
SLAs sold can be simultaneously supported at their respective maximum sold can be simultaneously supported at their respective maximum
rates, and that this remains true after re-routing (either IP re- rates, and that this remains true after re-routing (either IP re-
routing or MPLS (Multi Protocol Label Switching) protection-mode routing or Multiprotocol Label Switching (MPLS) protection-mode
switching) has occurred. switching) has occurred.
Over-provisioning is generally considered to meet the requirements of Over-provisioning is generally considered to meet the requirements of
all traffic without further QoS treatment, and in the general case all traffic without further quality of service (QoS) treatment, and
that is true in high capacity backbones. However, as the process of in the general case, that is true in high-capacity backbones.
network convergence continues, and with the increasing speed of the However, as the process of network convergence continues, and with
access networks, certain services may still have issues. Delay, the increasing speed of the access networks, certain services may
jitter, and occasional loss are perfectly acceptable for elastic still have issues. Delay, jitter, and occasional loss are perfectly
applications. However, sub-second surges that occur in the best- acceptable for elastic applications. However, sub-second surges that
designed of networks [12] affect real-time applications. Moreover, occur in the best-designed of networks [12] affect real-time
DOS loads, worms, and network disruptions such as that of 11 applications. Moreover, denial of service (DoS) loads, worms, and
September 2001 affect routing [13]. Our objective is to prevent network disruptions such as that of 11 September 2001 affect routing
disruption to routing (which in turn affects all services), protect [13]. Our objective is to prevent disruption to routing (which in
real-time jitter-sensitive services, while minimizing loss and delay turn affects all services) and to protect real-time jitter-sensitive
of sensitive elastic traffic. services, while minimizing loss and delay of sensitive elastic
traffic.
The document "Diffserv Service Classes" [3] defines a set of basic RFC 4594 [3] defines a set of basic Diffserv classes from the points
diffserv classes from the points of view of the application requiring of view of the application requiring specific end-to-end behaviors
specific end-to-end behaviors from the network. The service classes from the network. The service classes are differentiated based on
are differentiated based on the application payload's tolerance to the application payload's tolerance to packet loss, delay, and delay
packet loss, delay, and delay variation (jitter). Different degrees variation (jitter). Different degrees of these criteria form the
of these criteria form the foundation for supporting the needs of foundation for supporting the needs of real-time and elastic traffic.
real-time and elastic traffic. The "Diffserv Service Classes" [3] RFC 4594 [3] also provides recommendations for the treatment method
document also provides recommendations for the treatment method of of these service classes. But, at some network segments of the end-
these service classes. But, at some network segments of the end-to- to-end path, the number of levels of network treatment
end path, the number of levels of network treatment differentiation differentiation may be less than the number of service classes that
may be less than the number of service classes that the network the network segment needs to support. In such a situation, that
segment needs to support. In such a situation, that network segment network segment may use the same treatment to support more than one
may use the same treatment to support more than one service class. service class. In this document, we provide guidelines on how
In this document we provide guidelines on how multiple service multiple service classes may be aggregated into a forwarding
classes may be aggregated into a forwarding treatment aggregate. treatment aggregate. This entails having the IP traffic belonging to
Having the IP traffic belonging to service classes, expressed using service classes, expressed using the DSCP (Differentiated Services
the DSCP (DiffServ Code Point), as described by "Diffserv Service Code Point), as described by RFC 4594 [3]. Note that in a given
Classes" [3]. Note that in a given domain, we may recommend that the domain, we may recommend that the supported service classes be
supported service classes be aggregated into forwarding treatment aggregated into forwarding treatment aggregates; however, this does
aggregates; however, this does not mean all service classes need to not mean all service classes need to be supported, and hence not all
be supported and hence not all forwarding treatment aggregates need forwarding treatment aggregates need to be supported. A domain may
to be supported. A domain may support fewer or greater number of support a fewer or greater number of forwarding treatment aggregates
forwarding treatment aggregates. Which service classes and which than recommended by this document. Which service classes and which
forwarding treatment aggregates are supported by a domain is up to forwarding treatment aggregates are supported by a domain is up to
the domain administration and may be influenced by business reasons the domain administration and may be influenced by business reasons
or other reasons (e.g. operational considerations). or other reasons (e.g., operational considerations).
In this document, we've provided: In this document, we've provided:
o definitions for terminology we use in this document, o definitions for terminology we use in this document,
o requirements for performing this aggregation, o requirements for performing this aggregation,
o an example of performing the aggregation when four treatment o an example of performing the aggregation when four treatment
aggregates are used, aggregates are used, and
o an example (in the appendix) of performing this aggregation over o an example (in the appendix) of performing this aggregation over
MPLS using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label MPLS using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label
Switched Path (LSP). Switched Path (LSP).
The treatment aggregate recommendations are designed to aggregate the The treatment aggregate recommendations are designed to aggregate the
service classes [3] in such a manner as to protect real-time traffic service classes [3] in such a manner as to protect real-time traffic
and routing, on the assumption that real-time sessions are protected and routing, on the assumption that real-time sessions are protected
from each other by admission at the edge. The recommendation given from each other by admission at the edge. The recommendation given
is one possible way of performing the aggregation, there may be other is one possible way of performing the aggregation; there may be other
way of aggregation, for example into fewer treatment aggregates or ways of aggregation, for example, into fewer treatment aggregates or
more treatment aggregates. more treatment aggregates.
In the appendix, an example of aggregation over MPLS networks using In the appendix, an example of aggregation over MPLS networks using
E-LSP to realize the treatment aggregates is provided. Note that the E-LSP to realize the treatment aggregates is provided. Note that the
MPLS E-LSP is just an example; this document does not exclude the use MPLS E-LSP is just an example; this document does not exclude the use
of other methods. This example only considers aggregation of IP of other methods. This example only considers aggregation of IP
traffic into E-LSP. The use of E-LSP by none-IP traffic is not traffic into E-LSP. The use of E-LSP by non-IP traffic is not
discussed. discussed.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
2. Terminology 2. Terminology
This document assumes the reader is familiar with the terms used in This document assumes the reader is familiar with the terms used in
differentiated services. This document provides the definitions for differentiated services. This document provides the definitions for
new terms introduced by this document and references information new terms introduced by this document and references information
defined in RFCs for existing terms not commonly used in defined in RFCs for existing terms not commonly used in
differentiated services. differentiated services.
For new terms introduced by this document, we provide the definition For new terms introduced by this document, we provide the definition
here: here:
o Treatment Aggregate. This term is defined as the aggregate of o Treatment Aggregate. This term is defined as the aggregate of
DiffServ service classes [3]. A Treatment Aggregate is concerned Diffserv service classes [3]. A treatment aggregate is concerned
only with the forwarding treatment of the aggregated traffic, only with the forwarding treatment of the aggregated traffic,
which may be marked with multiple DSCPs. A Treatment Aggregate which may be marked with multiple DSCPs. A treatment aggregate
differs from Behavior Aggregate [2] and Traffic Aggregate [14], differs from Behavior Aggregate [2] and Traffic Aggregate [14],
each of which indicate the aggregated traffic having a single each of which indicate the aggregated traffic having a single
diffserv codepoint and utilizing a single PHB. Diffserv codepoint and utilizing a single Per Hop Behavior (PHB).
For terms from existing RFCs, we provide the reference to the For terms from existing RFCs, we provide the reference to the
appropriate section of the relevant RFC that contain the definition: appropriate section of the relevant RFC that contain the definition:
o Real-Time and Elastic Applications and their traffic. Section 3.1 o Real-Time and Elastic Applications and their traffic. Section 3.1
of RFC 1633 [4]. of RFC 1633 [4].
o Diffserv Service Class. Section 1.3 of RFC 4594 [3]. o Diffserv Service Class. Section 1.3 of RFC 4594 [3].
o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched
Path (LSP). Section 1.2 of RFC 3270 [6]. Path (LSP). Section 1.2 of RFC 3270 [6].
o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label
Switched Path (LSP). Section 1.3 of RFC 3270 [6]. Switched Path (LSP). Section 1.3 of RFC 3270 [6].
3. Overview of Service Class Aggregation 3. Overview of Service Class Aggregation
In diffserv domains where less fine-grained traffic treatment In Diffserv domains where less fine-grained traffic treatment
differentiation is provided, aggregation of the different service differentiation is provided, aggregation of the different service
classes [3] may be required. classes [3] may be required.
These aggregations have the following requirements: These aggregations have the following requirements:
1. The end-to-end network performance characteristic required by the 1. The end-to-end network performance characteristic required by the
application MUST be supported. This performance characteristic application MUST be supported. This performance characteristic
is represented by the use of Diffserv Service Classes [3]. is represented by the use of Diffserv service classes [3].
2. The treatment aggregate MUST meet the strictest requirements of 2. The treatment aggregate MUST meet the strictest requirements of
its member service classes. its member service classes.
3. The treatment aggregate SHOULD only contain member service 3. The treatment aggregate SHOULD only contain member service
classes with similar traffic characteristic and performance classes with similar traffic characteristic and performance
requirements. requirements.
4. The notion of the individual end-to-end service classes MUST NOT 4. The notion of the individual end-to-end service classes MUST NOT
be destroyed when aggregation is performed. Each domain along be destroyed when aggregation is performed. Each domain along
the end-to-end path may perform aggregation differently, based on the end-to-end path may perform aggregation differently, based on
the original end-to-end service classes. We recommend an easy the original end-to-end service classes. We recommend an easy
way to accomplish this by not altering the DSCP used to indicate way to accomplish this by not altering the DSCP used to indicate
the end-to-end service class. But some administrative domains the end-to-end service class. But some administrative domains
may require the use of their own marking; when this is needed, may require the use of their own marking; when this is needed,
the original end-to-end service class indication must be restored the original end-to-end service class indication must be restored
upon exiting such administrative domains. One possible way of upon exiting such administrative domains. One possible way of
achieving this is with the use of tunnels to encapsulate the end- achieving this is with the use of tunnels to encapsulate the end-
to-end traffic. to-end traffic.
5. Each treatment aggregate has limited resources, hence traffic 5. Each treatment aggregate has limited resources; hence, traffic
conditioning and/or admission control SHOULD be performed for conditioning and/or admission control SHOULD be performed for
each service class aggregated into the treatment aggregate. each service class aggregated into the treatment aggregate.
Additional admission control and policing may be used on the sum Additional admission control and policing may be used on the sum
of all traffic aggregated into the treatment aggregate. of all traffic aggregated into the treatment aggregate.
In addition to the above requirements, we have the following In addition to the above requirements, we have the following
suggestions: suggestions:
1. The treatment aggregate and assigned resources may consider 1. The treatment aggregate and assigned resources may consider
historical traffic patterns and the variability of these historical traffic patterns and the variability of these
patterns. For example, a point-point service (e.g., pseudowire) patterns. For example, a point-point service (e.g., pseudowire)
may have a very predictable pattern, while a multipoint service may have a very predictable pattern, while a multipoint service
(e.g., VPLS, Virtual Private LAN Service) may have a much less (e.g., VPLS, Virtual Private LAN Service) may have a much less
predictable pattern. predictable pattern.
2. In addition to Diffserv, other controls are available to 2. In addition to Diffserv, other controls are available to
influence the traffic level offered to a particular traffic influence the traffic level offered to a particular traffic
aggregate. These include adjustment of routing metrics, usage of aggregate. These include adjustment of routing metrics, and
MPLS-based traffic engineering techniques. usage of MPLS-based traffic engineering techniques.
This document only describes the aggregation of IP traffic based on This document only describes the aggregation of IP traffic based on
the use of Diffserv Service Classes [3]. the use of Diffserv service classes [3].
4. Service Classes to Treatment Aggregate Mapping 4. Service Classes to Treatment Aggregate Mapping
The service class and DSCP selection in "Diffserv Service Classes" The service class and DSCP selection in RFC 4594 [3] has been defined
[3] has been defined to allow, in many instances, mapping of two or to allow, in many instances, mapping of two or possibly more service
possibly more service classes into a single forwarding treatment classes into a single forwarding treatment aggregate. Notice that
aggregate. Notice that there is a relationship/trade-off between there is a relationship/trade-off between link speed, queue depth,
link speed, queue depth, delay, and jitter. The degree of delay, and jitter. The degree of aggregation and hence the number of
aggregation and hence the number of treatment aggregates will depend treatment aggregates will depend on the aggregation's impacts on
on whether the speed of the links and scheduler behavior, being used loss, delay, and jitter. This depends on whether the speed of the
to implement the aggregation, can minimize the effects of mixing links and scheduler behavior, being used to implement the
traffic with different packet sizes and transmit rates on queue aggregation, can minimize the effects of mixing traffic with
depth, and their impacts on loss, delay, and jitter. A general rule- different packet sizes and transmit rates on queue depth. A general
of-thumb is that higher link speeds allow for more aggregation/ rule-of-thumb is that higher link speeds allow for more aggregation/
smaller number of treatment aggregates, assuming link utilization is smaller number of treatment aggregates, assuming link utilization is
within the engineered level. within the engineered level.
4.1. Mapping Service Classes into Four Treatment Aggregates 4.1. Mapping Service Classes into Four Treatment Aggregates
This section provides an example of mapping all the service classes This section provides an example of mapping all the service classes
defined in RFC 4594 [3] into four treatment aggregates. The use of defined in RFC 4594 [3] into four treatment aggregates. The use of
four treatment aggregates assumes that the resources allocated to four treatment aggregates assumes that the resources allocated to
each treatment aggregate are sufficient to honor the required each treatment aggregate are sufficient to honor the required
behavior of each service class [3] in each of the four treatment behavior of each service class [3]. We use the performance
aggregates. We use the performance requirement (tolerance to loss, requirement (tolerance to loss, delay, and jitter) from the
delay, and jitter) from the application/end-user as a guide on how to application/end-user as a guide on how to map the service classes
map the service classes into treatment aggregates. We have also used into treatment aggregates. We have also used section 3.1 of RFC 1633
Section 3.1 of RFC 1633 [4] to provide us with guidance on the [4] to provide us with guidance on the definition of Real-Time and
definition of Real-Time and Elastic applications. An overview of the Elastic applications. An overview of the mapping between service
mapping between service classes and the four treatment aggregates is classes and the four treatment aggregates is provided by Figure 1,
provided by Figure 1, with the mapping being based on performance with the mapping being based on performance requirements. In Figure
requirements. In Figure 1, the right side columns of "Service 1, the right side columns of "Service Class" and "Tolerance to Loss/
Class", "Tolerance to Loss/Delay/Jitter" are from Figure 2 of Delay/Jitter" are from Figure 2 of RFC 4594 [3].
Diffserv Service Classes [3].
It is recommended that certain service classes be mapped into It is recommended that certain service classes be mapped into
specific treatment aggregates. But this does not mean that all the specific treatment aggregates. But this does not mean that all the
service classes recommended for that treatment aggregate need to be service classes recommended for that treatment aggregate need to be
supported. Hence, for a given domain, a treatment aggregate may supported. Hence, for a given domain, a treatment aggregate may
contain only a subset of the service classes recommended in this contain only a subset of the service classes recommended in this
document, they being the service classes supported by that domain. A document, i.e., the service classes supported by that domain. A
domain's treatment of non-supported service classes should be based domain's treatment of non-supported service classes should be based
on the domain's local policy. This local policy may be influenced by on the domain's local policy. This local policy may be influenced by
its agreement with its customers. Such treatment may use the Elastic its agreement with its customers. Such treatment may use the Elastic
Treatment Aggregate, dropping the packets, or some other Treatment Aggregate, dropping the packets, or some other
arrangements. arrangements.
Our example of four treatment aggregates is based on the basic Our example of four treatment aggregates is based on the basic
differences in performance requirement from the application/end-user differences in performance requirement from the application/end-user
perspective. A domain may choose to support more or fewer treatment perspective. A domain may choose to support more or fewer treatment
aggregates. For example, only supporting three treatment aggregates, aggregates than the four recommended. For example, a domain may
and with mapping any network control traffic into the Assured Elastic support only three treatment aggregates and map any network control
treatment aggregate. This is a choice the administrative domain has. traffic into the Assured Elastic treatment aggregate. This is a
Hence this example of four treatment aggregates does not represent a choice the administrative domain has. Hence, this example of four
minimum required set of treatment aggregates one must implement; nor treatment aggregates does not represent a minimum required set of
does it represent the maximum set of treatment aggregates one can treatment aggregates one must implement; nor does it represent the
implement. maximum set of treatment aggregates one can implement.
--------------------------------------------------------------------- ---------------------------------------------------------------------
|Treatment | Tolerance to ||Service Class | Tolerance to | |Treatment | Tolerance to ||Service Class | Tolerance to |
|Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter| |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter|
|==========+======+======+======++===============+======+======+======| |==========+======+======+======++===============+======+======+======|
| Network | Low | Low | Yes || Network | Low | Low | Yes | | Network | Low | Low | Yes || Network | Low | Low | Yes |
| Control | | | || Control | | | | | Control | | | || Control | | | |
|==========+======+======+======++===============+======+======+======| |==========+======+======+======++===============+======+======+======|
| Real | Very | Very | Very || Telephony | VLow | VLow | VLow | | Real- | Very | Very | Very || Telephony | VLow | VLow | VLow |
| Time | Low | Low | Low ||---------------+------+------+------| | Time | Low | Low | Low ||---------------+------+------+------|
| | | | || Signaling | Low | Low | Yes | | | | | || Signaling | Low | Low | Yes |
| | | | ||---------------+------+------+------| | | | | ||---------------+------+------+------|
| | | | || Multimedia |Low - | Very | Low | | | | | || Multimedia |Low - | Very | Low |
| | | | || Conferencing |Medium| Low | | | | | | || Conferencing |Medium| Low | |
| | | | ||---------------+------+------+------| | | | | ||---------------+------+------+------|
| | | | || Real-time | Low | Very | Low | | | | | || Real-time | Low | Very | Low |
| | | | || Interactive | | Low | | | | | | || Interactive | | Low | |
| | | | ||---------------+------+------+------| | | | | ||---------------+------+------+------|
| | | | || Broadcast | Very |Medium| Low | | | | | || Broadcast | Very |Medium| Low |
| | | | || Video | Low | | | | | | | || Video | Low | | |
|==========+======+======+======++===============+======+======+======| |==========+======+======+======++===============+======+======+======|
| Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes | | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes |
| Elastic | |Medium| || Streaming |Medium| | | | Elastic | |Medium| || Streaming |Medium| | |
| | | | ||---------------+------+------+------| | | | | ||---------------+------+------+------|
| | | | || Low Latency | Low |Low - | Yes | | | | | || Low-Latency | Low |Low - | Yes |
| | | | || Data | |Medium| | | | | | || Data | |Medium| |
| | | | ||---------------+------+------+------| | | | | ||---------------+------+------+------|
| | | | || OAM | Low |Medium| Yes | | | | | || OAM | Low |Medium| Yes |
| | | | ||---------------+------+------+------| | | | | ||---------------+------+------+------|
| | | | ||High Throughput| Low |Medium| Yes | | | | | ||High-Throughput| Low |Medium| Yes |
| | | | || Data | |- High| | | | | | || Data | |- High| |
|==========+======+======+======++===============+======+======+======| |==========+======+======+======++===============+======+======+======|
| Elastic | Not Specified || Standard | Not Specified | | Elastic | Not Specified || Standard | Not Specified |
| | | | ||---------------+------+------+------| | | | | ||---------------+------+------+------|
| | | | || Low Priority | High | High | Yes | | | | | || Low-Priority | High | High | Yes |
| | | | || Data | | | | | | | | || Data | | | |
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 1: Treatment Aggregate and Service Class Performance Figure 1: Treatment Aggregate and Service Class Performance
Requirements Requirements
As we are recommending to preserve the notion of the individual end- As we are recommending to preserve the notion of the individual end-
to-end service classes, we also recommend that the original DSCP to-end service classes, we also recommend that the original DSCP
field marking not be changed when treatment aggregates are used. field marking not be changed when treatment aggregates are used.
Instead, classifiers that select packets based on the contents of the Instead, classifiers that select packets based on the contents of the
DSCP field should be used to direct packets from the member DiffServ DSCP field should be used to direct packets from the member Diffserv
Service Classes into the queue that handles each of the treatment service classes into the queue that handles each of the treatment
aggregates, without remarking the DSCP field of the packets. This is aggregates, without remarking the DSCP field of the packets. This is
summarized in Figure 2, which shows the behavior each Treatment summarized in Figure 2, which shows the behavior each treatment
Aggregate should have, and the DSCP field marking of the packets that aggregate should have, and the DSCP field marking of the packets that
should be classified into each of the treatment aggregates. should be classified into each of the treatment aggregates.
------------------------------------------------------------ ------------------------------------------------------------
|Treatment |Treatment || DSCP | |Treatment |Treatment || DSCP |
|Aggregate |Aggregate || | |Aggregate |Aggregate || |
| |Behavior || | | |Behavior || |
|==========+==========++=====================================| |==========+==========++=====================================|
| Network | CS || CS6 | | Network | CS || CS6 |
| Control |(RFC 2474)|| | | Control |(RFC 2474)|| |
|==========+==========++=====================================| |==========+==========++=====================================|
| Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | | Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 |
| Time |(RFC 3246)|| | | Time |(RFC 3246)|| |
|==========+==========++=====================================| |==========+==========++=====================================|
| Assured | AF || CS2, AF31, AF21, AF11 | | Assured | AF || CS2, AF31, AF21, AF11 |
| Elastic |(RFC 2597)||-------------------------------------| | Elastic |(RFC 2597)||-------------------------------------|
| | || AF32, AF22, AF12 | | | || AF32, AF22, AF12 |
| | ||-------------------------------------| | | ||-------------------------------------|
| | || AF33, AF23, AF13 | | | || AF33, AF23, AF13 |
|==========+==========++=====================================| |==========+==========++=====================================|
| Elastic | Default || Default, (CS0) | | Elastic | Default || Default, (CS0) |
| |(RFC 2474)||-------------------------------------| | |(RFC 2474)||-------------------------------------|
| | || CS1 | | | || CS1 |
------------------------------------------------------------ ------------------------------------------------------------
Figure 2: Treatment Aggregate Behavior Figure 2: Treatment Aggregate Behavior
Notes for Figure 2: For Assured Elastic and Elastic Treatment Notes for Figure 2: For Assured Elastic and Elastic Treatment
Aggregates, please see sections 4.1.3 and 4.1.4, respectively, for Aggregates, please see sections 4.1.3 and 4.1.4, respectively, for
details on additional priority within the Treatment Aggregate. details on additional priority within the treatment aggregate.
4.1.1. Network Control Treatment Aggregate 4.1.1. Network Control Treatment Aggregate
The Network Control Treatment Aggregate aggregates all service The Network Control Treatment Aggregate aggregates all service
classes that are functionally necessary for the survival of a network classes that are functionally necessary for the survival of a network
during a DOS attack or other high traffic load interval. The theory during a DoS attack or other high-traffic load interval. The theory
is that whatever else is true, the network must protect itself. This is that whatever else is true, the network must protect itself. This
includes the traffic that "Diffserv Service Classes" [3] includes the traffic that RFC 4594 [3] characterizes as being
characterizes as being included in the Network Control Service Class. included in the Network Control service class.
Traffic in the Network Control treatment aggregate should be carried Traffic in the Network Control Treatment Aggregate should be carried
in a common queue or class with a PHB as described in RFC 2474 [2] in a common queue or class with a PHB as described in RFC 2474 [2],
section 4.2.2.2 for Class Selector (CS). This treatment aggregate section 4.2.2.2 for Class Selector (CS). This treatment aggregate
should have a lower probability of packet loss, bearing a relatively should have a lower probability of packet loss and bear a relatively
deep target mean queue depth (min-threshold if RED (Random Early deep target mean queue depth (min-threshold if RED (Random Early
Detection) is being used). Detection) is being used).
Please notice this Network Control Treatment Aggregate is meant to be Please notice this Network Control Treatment Aggregate is meant to be
used for the customer's network control traffic. The provider may used for the customer's network control traffic. The provider may
choose to treat its own network control traffic differently, perhaps choose to treat its own network control traffic differently, perhaps
in its own service class that is not aggregated with the customer's in its own service class that is not aggregated with the customer's
network control traffic. network control traffic.
4.1.2. Real Time Treatment Aggregate 4.1.2. Real-Time Treatment Aggregate
The Real Time Treatment Aggregate aggregates all real-time The Real-Time Treatment Aggregate aggregates all real-time
(inelastic) service classes. The theory is that real-time traffic is (inelastic) service classes. The theory is that real-time traffic is
admitted under some model and controlled by a SLA managed at the edge admitted under some model and controlled by an SLA managed at the
of the network prior to aggregation. As such, there is a predictable edge of the network prior to aggregation. As such, there is a
and enforceable upper bound on the traffic that can enter such a predictable and enforceable upper bound on the traffic that can enter
queue, and to provide predictable variation in delay it must be such a queue, and to provide predictable variation in delay it must
protected from bursts of elastic traffic. The predictability of be protected from bursts of elastic traffic. The predictability of
traffic level may be based upon admission control for a well known traffic level may be based upon admission control for a well-known
community of interest (e.g., a point-point service) and/or based upon community of interest (e.g., a point-point service) and/or based upon
historical measurements. historical measurements.
This treatment aggregate may include the following service classes This treatment aggregate may include the following service classes
from the Diffserv Service Classes [3], in addition to other locally from the Diffserv service classes [3], in addition to other locally
defined classes: Telephony, Signaling, Multimedia Conferencing, Real- defined classes: Telephony, Signaling, Multimedia Conferencing, Real-
time Interactive, Broadcast Video. time Interactive, and Broadcast Video.
Traffic in each service class that is going to be aggregated into the Traffic in each service class that is going to be aggregated into the
treatment aggregate should be conditioned prior to aggregation. It treatment aggregate should be conditioned prior to aggregation. It
is recommended that per service class admission control procedures be is recommended that per-service-class admission control procedures be
used followed by per service class policing so that any individual used, followed by per-service-class policing so that any individual
service class does not generate more than what it is allowed. service class does not generate more than what it is allowed.
Furthermore, additional admission control and policing may be used on Furthermore, additional admission control and policing may be used on
the sum of all traffic aggregated into this treatment aggregate. the sum of all traffic aggregated into this treatment aggregate.
Traffic in the Real Time treatment aggregate should be carried in a Traffic in the Real-Time Treatment Aggregate should be carried in a
common queue or class with a PHB (Per Hop Behavior) as described in common queue or class with a PHB (Per Hop Behavior) as described in
RFC 3246 [9] and RFC 3247 [10]. RFC 3246 [9] and RFC 3247 [10].
4.1.3. Assured Elastic Treatment Aggregate 4.1.3. Assured Elastic Treatment Aggregate
The Assured Elastic Treatment Aggregate aggregates all elastic The Assured Elastic Treatment Aggregate aggregates all elastic
traffic that uses the Assured Forwarding model as described in RFC traffic that uses the Assured Forwarding model as described in RFC
2597 [8]. The premise of such a service is that a SLA is negotiated 2597 [8]. The premise of such a service is that an SLA that is
which includes a "committed rate" and the ability to exceed that rate negotiated includes a "committed rate" and the ability to exceed that
(and perhaps a second "excess rate") in exchange for a higher rate (and perhaps a second "excess rate") in exchange for a higher
probability of loss using Active Queue Management (AQM) [7] or probability of loss using Active Queue Management (AQM) [7] or
Explicit Congestion Notification (ECN) marking [11] for the portion Explicit Congestion Notification (ECN) marking [11] for the portion
of traffic deemed to be in excess. of traffic deemed to be in excess.
This treatment aggregate may include the following service classes This treatment aggregate may include the following service classes
from the Diffserv Service Classes [3], in addition to other locally from the Diffserv service classes [3], in addition to other locally
defined classes: Multimedia Streaming, Low Latency Data, OAM, High defined classes: Multimedia Streaming, Low Latency Data, OAM, and
Throughput Data. High-Throughput Data.
The DSCP values belonging to the AF PHB group and class selector of The DSCP values belonging to the Assured Forwarding (AF) PHB group
the original service classes remain an important consideration and and class selector of the original service classes remain an
should be preserved during aggregation. This treatment aggregate important consideration and should be preserved during aggregation.
should maintain the AF PHB group marking of the original packet. For This treatment aggregate should maintain the AF PHB group marking of
example, AF3x marked packets should remain AF3x marked within this the original packet. For example, AF3x marked packets should remain
treatment aggregate. In addition, the class selector DSCP value AF3x marked within this treatment aggregate. In addition, the class
should not be changed. Traffic bearing these DSCPs is carried in a selector DSCP value should not be changed. Traffic bearing these
common queue or class with a PHB as described in RFC 2597 [8]. In DSCPs is carried in a common queue or class with a PHB as described
effect, appropriate target rate thresholds have been applied at the in RFC 2597 [8]. In effect, appropriate target rate thresholds have
edge, dividing traffic into AFn1 (committed, for any value of n), been applied at the edge, dividing traffic into AFn1 (committed, for
AFn2, and AFn3 (excess). The service should be engineered so that any value of n), AFn2, and AFn3 (excess). The service should be
AFn1 and CS2 marked packet flows have sufficient bandwidth in the engineered so that AFn1 and CS2 marked packet flows have sufficient
network to provide high assurance of delivery. Since the traffic is bandwidth in the network to provide high assurance of delivery.
elastic and responds dynamically to packet loss, Active Queue Since the traffic is elastic and responds dynamically to packet loss,
Management [7] should be used primarily to reduce the forwarding rate Active Queue Management [7] should be used primarily to reduce the
to the minimum assured rate at congestion points. The probability of forwarding rate to the minimum assured rate at congestion points.
loss of AFn1 and CS2 traffic must not exceed the probability of loss The probability of loss of AFn1 and CS2 traffic must not exceed the
of AFn2 traffic, which in turn must not exceed the probability of probability of loss of AFn2 traffic, which in turn must not exceed
loss of AFn3 traffic. the probability of loss of AFn3 traffic.
If RED [7] is used as an AQM algorithm, the min-threshold specifies a If RED [7] is used as an AQM algorithm, the min-threshold specifies a
target queue depth for each of AFn1+CS2, AFn2, AFn3, and the max- target queue depth for each of AFn1+CS2, AFn2, and AFn3, and the max-
threshold specifies the queue depth above which all traffic with such threshold specifies the queue depth above which all traffic with such
a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate, a DSCP is dropped or ECN marked. Thus, in this treatment aggregate,
the following inequalities SHOULD hold in queue configurations: the following inequalities SHOULD hold in queue configurations:
o min-threshold AFn3 < max-threshold AFn3 o min-threshold AFn3 < max-threshold AFn3
o max-threshold AFn3 <= min-threshold AFn2 o max-threshold AFn3 <= min-threshold AFn2
o min-threshold AFn2 < max-threshold AFn2 o min-threshold AFn2 < max-threshold AFn2
o max-threshold AFn2 <= min-threshold AFn1+CS2 o max-threshold AFn2 <= min-threshold AFn1+CS2
o min-threshold AFn1+CS2 < max-threshold AFn1+CS2 o min-threshold AFn1+CS2 < max-threshold AFn1+CS2
o max-threshold AFn1+CS2 <= memory assigned to the queue o max-threshold AFn1+CS2 <= memory assigned to the queue
Note: This configuration tends to drop AFn3 traffic before AFn2 and Note: This configuration tends to drop AFn3 traffic before AFn2, and
AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are
used; they should be configured to achieve a similar result. used; they should be configured to achieve a similar result.
4.1.4. Elastic Treatment Aggregate 4.1.4. Elastic Treatment Aggregate
The Elastic Treatment Aggregate aggregates all remaining elastic The Elastic Treatment Aggregate aggregates all remaining elastic
traffic. The premise of such a service is that there is no intrinsic traffic. The premise of such a service is that there is no intrinsic
SLA differentiation of traffic, but that AQM [7] or ECN flagging [11] SLA differentiation of traffic, but that AQM [7] or ECN flagging [11]
is appropriate for such traffic. is appropriate for such traffic.
This treatment aggregate may include the following service classes This treatment aggregate may include the following service classes
from the Diffserv Service Classes [3], in addition to other locally from the Diffserv service classes [3], in addition to other locally
defined classes: Standard, Low Priority Data. defined classes: Standard and Low-Priority Data.
Treatment aggregates should be well specified, each indicating the Treatment aggregates should be well specified, each indicating the
service classes it will handle. But in cases where unspecified or service classes it will handle. But in cases where unspecified or
unknown service classes are encountered, they may be dropped or be unknown service classes are encountered, they may be dropped or be
treated using the Elastic Treatment Aggregate. The choice of how to treated using the Elastic Treatment Aggregate. The choice of how to
treat unspecified service classes should be well defined, based on treat unspecified service classes should be well defined, based on
some agreements. some agreements.
Traffic in the Elastic treatment aggregate should be carried in a Traffic in the Elastic Treatment Aggregate should be carried in a
common queue or class with a PHB as described in RFC 2474 [2] section common queue or class with a PHB as described in RFC 2474 [2],
4.1: A Default PHB. The AQM thresholds for Elastic traffic MAY be section 4.1, "A Default PHB". The AQM thresholds for Elastic traffic
separately set, so that Low Priority Data traffic is dropped before MAY be separately set, so that Low Priority Data traffic is dropped
Standard traffic, but this is not a requirement. before Standard traffic, but this is not a requirement.
5. Treatment Aggregates and Inter-Provider Relationships 5. Treatment Aggregates and Inter-Provider Relationships
When Treatment Aggregates are used at provider boundaries, we When treatment aggregates are used at provider boundaries, we
recommend that the Inter-Provider Relationship be based on Diffserv recommend that the inter-provider relationship be based on Diffserv
Service Classes [3]. This allows the admission control into each service classes [3]. This allows the admission control into each
Treatment Aggregate of a provider domain to be based on the admission treatment aggregate of a provider domain to be based on the admission
control of traffic into the supported Service Classes, as indicated control of traffic into the supported service classes, as indicated
by the discussion in section 4 of this document. by the discussion in section 4 of this document.
If the Inter-Provider Relationship needs to be based on Treatment If the inter-provider relationship needs to be based on treatment
Aggregates specified by this document, then the exact Treatment aggregates specified by this document, then the exact treatment
Aggregate content and representation must be agreed to by the peering aggregate content and representation must be agreed to by the peering
providers. providers.
Some additional work on Inter-Provider Relationships is provided by Some additional work on inter-provider relationships is provided by
Inter-provider QoS [15], where details on supporting realtime inter-provider QoS [15], where details on supporting real-time
services between service providers are discussed. Some related work services between service providers are discussed. Some related work
in ITU-T provided by Appendix VI of Y.1541 [16] may also help with in ITU-T provided by Appendix VI of Y.1541 [16] may also help with
inter-provider relationships, especially with international inter-provider relationships, especially with international
providers. providers.
6. Security Considerations 6. Security Considerations
This document discusses the policy of using Differentiated Services This document discusses the policy of using Differentiated Services
and its service classes. If implemented as described, it should and its service classes. If implemented as described, it should
require that the network do nothing that the network has not already require that the network do nothing that the network has not already
allowed. If that is the case, no new security issues should arise allowed. If that is the case, no new security issues should arise
from the use of such a policy. from the use of such a policy.
As this document is based on Diffserv Service Classes [3], the As this document is based on RFC 4594 [3], the Security Consideration
Security Consideration discussion of no new security issues indicated discussion of no new security issues indicated by RFC 4594 [3] also
by Diffserv Service Classes [3] also applies to treatment aggregates applies to treatment aggregates of this document.
of this document.
7. IANA Considerations
This document does not request any IANA considerations.
8. Acknowledgements 7. Acknowledgements
This document has benefited from discussions with numerous people, This document has benefited from discussions with numerous people,
especially Shane Amante, Brian Carpenter, and Dave McDysan. It has especially Shane Amante, Brian Carpenter, and Dave McDysan. It has
also benefited from detailed reviews by David Black, Marvin Krym, also benefited from detailed reviews by David Black, Marvin Krym,
Bruce Davie, Fil Dickinson, and Julie Ann Connary. Bruce Davie, Fil Dickinson, and Julie Ann Connary.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[3] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
for DiffServ Service Classes", RFC 4594, August 2006.
[4] Braden, B., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983,
October 2000.
[6] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol
Label Switching (MPLS) Support of Differentiated Services",
RFC 3270, May 2002.
[7] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
J., and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[8] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[9] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002.
[10] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New Definition
of the EF PHB (Expedited Forwarding Per-Hop Behavior)",
RFC 3247, March 2002.
[11] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
8.2. Informative References
[12] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot,
"Analysis of Point-To-Point Packet Delay in an Operational
Network", INFOCOMM 2004, March 2004,
<http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.
[13] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11",
March 2002, <http://www.renesys.com/tech/presentations/pdf/
renesys-030502-NRC-911.pdf>.
[14] Nichols, K. and B. Carpenter, "Definition of Differentiated
Services Per Domain Behaviors and Rules for their
Specification", RFC 3086, April 2001.
[15] MIT Communications Futures Program, "Inter-provider Quality of
Service", November 2006, <
http://cfp.mit.edu/resources/papers/Interprovider QoS
MIT_CFP_WP_9_14_06.pdf>.
[16] International Telecommunications Union, "Network Performance
Objectives for IP-Based Services", Recommendation Y.1541,
February 2006.
Appendix A. Using MPLS for Treatment Aggregates Appendix A. Using MPLS for Treatment Aggregates
RFC 2983 on DiffServ and Tunnels [5] and RFC 3270 on MPLS Support of RFC 2983 on Diffserv and Tunnels [5] and RFC 3270 on MPLS Support of
DiffServ [6] provide a very good background on this topic. This Diffserv [6] provide a very good background on this topic. This
document provides an example of using the E-LSP, EXP Inferred PHB document provides an example of using the E-LSP, EXP Inferred PHB
Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS
Support of DiffServ [6] for realizing the Treatment Aggregates. Support of Diffserv [6] for realizing the Treatment Aggregates.
When Treatment Aggregates are represented in MPLS using EXP Inferred When treatment aggregates are represented in MPLS using EXP Inferred
PSC LSP, we recommend the following usage of the MPLS EXP field for PSC LSP, we recommend the following usage of the MPLS EXP field for
Treatment Aggregates. treatment aggregates.
------------------------------------------- -------------------------------------------
|Treatment || MPLS || DSCP | DSCP | |Treatment || MPLS || DSCP | DSCP |
|Aggregate || EXP || name | value | |Aggregate || EXP || name | value |
|==========++======++=========|=============| |==========++======++=========|=============|
| Network || 110 || CS6 | 110000 | | Network || 110 || CS6 | 110000 |
| Control || || | | | Control || || | |
|==========++======++=========|=============| |==========++======++=========|=============|
| Real || 100 || EF | 101110 | | Real- || 100 || EF | 101110 |
| Time || ||---------|-------------| | Time || ||---------|-------------|
| || || CS5 | 101000 | | || || CS5 | 101000 |
| || ||---------|-------------| | || ||---------|-------------|
| || ||AF41,AF42|100010,100100| | || ||AF41,AF42|100010,100100|
| || || AF43 | 100110 | | || || AF43 | 100110 |
| || ||---------|-------------| | || ||---------|-------------|
| || || CS4 | 100000 | | || || CS4 | 100000 |
| || ||---------|-------------| | || ||---------|-------------|
| || || CS3 | 011000 | | || || CS3 | 011000 |
|==========++======++=========|=============| |==========++======++=========|=============|
skipping to change at page 14, line 43 skipping to change at page 16, line 43
| || || AF13 | 001110 | | || || AF13 | 001110 |
|==========++======++=========|=============| |==========++======++=========|=============|
| Elastic || 000* || Default | 000000 | | Elastic || 000* || Default | 000000 |
| || || (CS0) | | | || || (CS0) | |
| ||------||---------|-------------| | ||------||---------|-------------|
| || 001* || CS1 | 001000 | | || 001* || CS1 | 001000 |
------------------------------------------- -------------------------------------------
Figure 3: Treatment Aggregate and MPLS EXP Field Usage Figure 3: Treatment Aggregate and MPLS EXP Field Usage
Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the * Note: For Assured Elastic (and Elastic) Treatment Aggregate, the
usage of 010 or 011 (000 or 001) as EXP field value depends on the usage of 010 or 011 (000 or 001) as EXP field value depends on the
drop probability. Packets in the LSP with EXP field of 011 (001) drop probability. Packets in the LSP with EXP field of 011 (001)
have a higher probability of being dropped than packets with an EXP have a higher probability of being dropped than packets with an
field of 010 (000). EXP field of 010 (000).
The above table indicates the recommended usage of EXP fields for The above table indicates the recommended usage of EXP fields for
Treatment Aggregates. Because many deployments of MPLS are on a per treatment aggregates. Because many deployments of MPLS are on a per-
domain basis, each domain has total control of its EXP usage and each domain basis, each domain has total control of its EXP usage and each
domain may use a different EXP field allocation for the domain's domain may use a different EXP field allocation for the domain's
supported Treatment Aggregates. supported treatment aggregates.
Appendix A.1. Network Control Treatment Aggregate with E-LSP A.1. Network Control Treatment Aggregate with E-LSP
The usage of E-LSP for Network Control Treatment Aggregate needs to The usage of E-LSP for Network Control Treatment Aggregate needs to
adhere to the recommendations indicated in section 4.1.1 of this adhere to the recommendations indicated in section 4.1.1 of this
document and section 3.2 of "Diffserv Service Classes" [3]. document and section 3.2 of RFC 4594 [3]. Reinforcing these
Reinforcing these recommendations, there should be no drop precedence recommendations, there should be no drop precedence associated with
associated with the MPLS PSC used for Network Control Treatment the MPLS PSC used for Network Control Treatment Aggregate because
Aggregate because dropping of Network Control Treatment Aggregate dropping of Network Control Treatment Aggregate traffic should be
traffic should be prevented. prevented.
Appendix A.2. Real Time Treatment Aggregate with E-LSP A.2. Real-Time Treatment Aggregate with E-LSP
In addition to the recommendations provided in section 4.1.2 of this In addition to the recommendations provided in section 4.1.2 of this
document and in member service classes' sections of "Diffserv Service document and in member service classes' sections of RFC 4594 [3], we
Classes" [3], we want to indicate that Real Time Treatment Aggregate want to indicate that Real-Time Treatment Aggregate traffic should
traffic should not be dropped, as some of the applications whose not be dropped, as some of the applications whose traffic is carried
traffic is carried in the Real Time Treatment Aggregate do not react in the Real-Time Treatment Aggregate do not react well to dropped
well to dropped packets. As indicated in section 4.1.2 of this packets. As indicated in section 4.1.2 of this document, admission
document, admission control should be performed on each Service Class control should be performed on each service class contributing to the
contributing to the Real Time Treatment Aggregate to prevent packet Real-Time Treatment Aggregate to prevent packet loss due to
loss due to insufficient resources allocated to Real Time Treatment insufficient resources allocated to Real-Time Treatment Aggregate.
Aggregate. Further, admission control and policing may also be Further, admission control and policing may also be applied on the
applied on the sum of all traffic aggregated into this treatment sum of all traffic aggregated into this treatment aggregate.
aggregate.
Appendix A.3. Assured Elastic Treatment Aggregate with E-LSP A.3. Assured Elastic Treatment Aggregate with E-LSP
EXP field markings of 010 and 011 are used for the Assured Elastic EXP field markings of 010 and 011 are used for the Assured Elastic
Treatment Aggregate. The two encodings are used to provide two Treatment Aggregate. The two encodings are used to provide two
levels of drop precedence indications, with 010 encoded traffic levels of drop precedence indications, with 010 encoded traffic
having a lower probability of being dropped than 011 encoded traffic. having a lower probability of being dropped than 011 encoded traffic.
This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP
010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. If the 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. If the
domain chooses to support only one drop precedence for this treatment domain chooses to support only one drop precedence for this treatment
aggregate, we recommend the use of 010 for EXP field marking. aggregate, we recommend the use of 010 for EXP field marking.
Appendix A.4. Elastic Treatment Aggregate with E-LSP A.4. Elastic Treatment Aggregate with E-LSP
EXP field markings of 000 and 001 are used for the Elastic Treatment EXP field markings of 000 and 001 are used for the Elastic Treatment
Aggregate. The two encodings are used to provide two levels of drop Aggregate. The two encodings are used to provide two levels of drop
precedence indications, with 000 encoded traffic having a lower precedence indications, with 000 encoded traffic having a lower
probability of being dropped than 001 encoded traffic. This provides probability of being dropped than 001 encoded traffic. This provides
for the mapping of Default/CS0 into 000; and CS1 into 001. Notice for the mapping of Default/CS0 into 000; and CS1 into 001. Notice
that with this mapping, during congestion, CS1 marked traffic may be that with this mapping, during congestion, CS1-marked traffic may be
starved. If the domain chooses to support only one drop precedence starved. If the domain chooses to support only one drop precedence
for this treatment aggregate, we recommend the use of 000 for EXP for this treatment aggregate, we recommend the use of 000 for EXP
field marking. field marking.
Appendix A.5. Treatment Aggregates and L-LSP A.5. Treatment Aggregates and L-LSP
Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per
LSP, the support of each Treatment Aggregate is on a per LSP basis. LSP, the support of each treatment aggregate is on a per-LSP basis.
This document does not further specify any additional recommendation This document does not further specify any additional recommendation
(beyond what has been indicated in section 4 of this document) for (beyond what has been indicated in section 4 of this document) for
Treatment Aggregate to L-LSP mapping, leaving this to each individual treatment aggregate to L-LSP mapping, leaving this to each individual
MPLS domain administrations. MPLS domain administration.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[3] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
for DiffServ Service Classes", RFC 4594, August 2006.
[4] Braden, B., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983,
October 2000.
[6] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol
Label Switching (MPLS) Support of Differentiated Services",
RFC 3270, May 2002.
[7] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
J., and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[8] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[9] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002.
[10] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New Definition
of the EF PHB (Expedited Forwarding Per-Hop Behavior)",
RFC 3247, March 2002.
[11] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
9.2. Informative References
[12] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot,
"Analysis of Point-To-Point Packet Delay in an Operational
Network", INFOCOMM 2004, March 2004,
<http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.
[13] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11",
March 2002, <http://www.renesys.com/tech/presentations/pdf/
renesys-030502-NRC-911.pdf>.
[14] Nichols, K. and B. Carpenter, "Definition of Differentiated
Services Per Domain Behaviors and Rules for their
Specification", RFC 3086, April 2001.
[15] MIT Communications Futures Program, "Inter-provider Quality of
Service", November 2006, <
http://cfp.mit.edu/resources/papers/Interprovider QoS
MIT_CFP_WP_9_14_06.pdf>.
[16] International Telecommunications Union, "Network performance
objectives for IP-based services", February 2006.
Authors' Addresses Authors' Addresses
Kwok Ho Chan Kwok Ho Chan
Nortel Nortel
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01821 Billerica, MA 01821
US US
Phone: +1-978-288-8175 Phone: +1-978-288-8175
Fax: +1-978-288-8700 Fax: +1-978-288-8700
Email: khchan@nortel.com EMail: khchan@nortel.com
Jozef Z. Babiarz Jozef Z. Babiarz
Nortel Nortel
3500 Carling Avenue 3500 Carling Avenue
Ottawa, Ont. K2H 8E9 Ottawa, Ont. K2H 8E9
Canada Canada
Phone: +1-613-763-6098 Phone: +1-613-763-6098
Fax: +1-613-768-2231 Fax: +1-613-768-2231
Email: babiarz@nortel.com EMail: babiarz@nortel.com
Fred Baker Fred Baker
Cisco Systems Cisco Systems
1121 Via Del Rey 1121 Via Del Rey
Santa Barbara, CA 93117 Santa Barbara, CA 93117
US US
Phone: +1-408-526-4257 Phone: +1-408-526-4257
Fax: +1-413-473-2403 Fax: +1-413-473-2403
Email: fred@cisco.com EMail: fred@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 19, line 44 skipping to change at line 804
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 88 change blocks. 
331 lines changed or deleted 299 lines changed or added

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