draft-ietf-tsvwg-diffserv-class-aggr-02.txt   draft-ietf-tsvwg-diffserv-class-aggr-03.txt 
TSVWG K. Chan TSVWG K. Chan
Internet-Draft J. Babiarz Internet-Draft J. Babiarz
Intended status: Informational Nortel Networks Intended status: Informational Nortel
Expires: September 6, 2007 F. Baker Expires: January 10, 2008 F. Baker
Cisco Systems Cisco Systems
March 5, 2007 July 9, 2007
Aggregation of DiffServ Service Classes Aggregation of DiffServ Service Classes
draft-ietf-tsvwg-diffserv-class-aggr-02 draft-ietf-tsvwg-diffserv-class-aggr-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
In the core of a high capacity network, service differentiation is In the core of a high capacity network, service differentiation is
still needed to support applications' utilization of the network. still needed to support applications' utilization of the network.
Applications with similar traffic characteristics and performance Applications with similar traffic characteristics and performance
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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 . . 6 4.1. Mapping Service Classes into Four Treatment Aggregates . . 6
4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9 4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9
4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . 11 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 11
5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 12 5. Treatment Aggregates and Inter-Provider Relationships . . . . 12
5.1. Network Control Treatment Aggregate with E-LSP . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.2. Real Time Treatment Aggregate with E-LSP . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 14 Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 13
5.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 15 Appendix A.1. Network Control Treatment Aggregate with E-LSP . . . 15
6. Treatment Aggregates and Inter-Provider Relationships . . . . 15 Appendix A.2. Real Time Treatment Aggregate with E-LSP . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 Appendix A.3. Assured Elastic Treatment Aggregate with E-LSP . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 Appendix A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 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. The implication of this is that there is sufficient ambient SLAs. The implication of this is that there is sufficient
capacity on any given link such that all SLAs sold can be capacity on any given link such that all SLAs sold can be
simultaneously supported at their respective maximum rates, and that simultaneously supported at their respective maximum rates, and that
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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 QoS treatment, and in the general case
that is true in high capacity backbones. However, as the process of that is true in high capacity backbones. However, as the process of
network convergence continues, and with the increasing speed of the network convergence continues, and with the increasing speed of the
access networks, certain services still have issues. Delay, jitter, access networks, certain services still have issues. Delay, jitter,
and occasional loss are perfectly acceptable for elastic and occasional loss are perfectly acceptable for elastic
applications. However, sub-second surges that occur in the best- applications. However, sub-second surges that occur in the best-
designed of networks [14] affect real-time applications. Moreover, designed of networks [14] affect real-time applications. Moreover,
DOS loads, worms, and network disruptions such as that of 11 DOS loads, worms, and network disruptions such as that of 11
September 2001 affect routing [15]. Our objective is to prevent September 2001 affect routing [15]. Our objective is to prevent
disruption to routing (which in turn affects all services), and disruption to routing (which in turn affects all services), protect
jitter-sensitive services that may be revenue-bearing. real-time jitter-sensitive services, while minimizing loss and delay
of sensitive elastic traffic.
The document "Diffserv Service Classes" [5] defines the basic The document "Diffserv Service Classes" [5] defines the basic
diffserv classes from the points of view of the application requiring diffserv classes from the points of view of the application requiring
specific end-to-end behaviors from the network. The service classes specific end-to-end behaviors from the network. The service classes
are differentiated based on the traffic-payload's tolerance to packet are differentiated based on the traffic-payload's tolerance to packet
loss, delay, and delay variation (jitter). Different degrees of loss, delay, and delay variation (jitter). Different degrees of
these criterions form the foundation for supporting the needs of these criteria form the foundation for supporting the needs of real-
real-time and elastic traffic. The "Diffserv Service Classes" [5] time and elastic traffic. The "Diffserv Service Classes" [5]
document also provides recommendations for the treatment method of document also provides recommendations for the treatment method of
these service classes. But, at some network segments of the end-to- these service classes. But, at some network segments of the end-to-
end path, the number of levels of network treatment differentiation end path, the number of levels of network treatment differentiation
may be less than the number of service classes that the network may be less than the number of service classes that the network
segment needs to support. In such a situation, that network segment segment needs to support. In such a situation, that network segment
may use the same treatment to support more than one service class. may use the same treatment to support more than one service class.
In this document we provide guidelines on how multiple service In this document we provide guidelines on how multiple service
classes may be aggregated into a forwarding treatment aggregate. classes may be aggregated into a forwarding treatment aggregate.
With the IP traffic belonging to service classes, expressed using the With the IP traffic belonging to service classes, expressed using the
DSCP, as described by "Diffserv Service Classes" [5]. Note that in a DSCP, as described by "Diffserv Service Classes" [5]. Note that in a
skipping to change at page 4, line 19 skipping to change at page 4, line 20
o requirements for performing this aggregation, o requirements for performing this aggregation,
o an example of performing this aggregation over MPLS using E-LSP. o an example of performing this aggregation over MPLS using E-LSP.
The treatment aggregate recommendations are designed to aggregate the The treatment aggregate recommendations are designed to aggregate the
service classes [5] in such a manner as to protect real-time traffic service classes [5] 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. from each other by admission at the edge.
An example of aggregation over MPLS networks using E-LSP, EXP In the appendix, an example of aggregation over MPLS networks using
Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path
realize the treatment aggregates is provided. Note that the MPLS (LSP), to realize the treatment aggregates is provided. Note that
E-LSP is just an example; this document does not exclude the use of the MPLS E-LSP is just an example; this document does not exclude the
other methods. This example only considers aggregation of IP traffic use of other methods. This example only considers aggregation of IP
into E-LSP. The use of E-LSP by none-IP traffic is not discussed. traffic into E-LSP. The use of E-LSP by none-IP traffic is not
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 [3]. document are to be interpreted as described in RFC 2119 [3].
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 referencing information for new terms introduced by this document and referencing information for
existing none differentiated services terms defined in existing RFCs. existing none differentiated services terms defined in existing RFCs.
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 used here to indicate the o Treatment Aggregate. This term is defined as the aggregate of
aggregate of DiffServ service classes. This is different from DiffServ service classes [5]. A Treatment Aggregate is concerned
Behavior Aggregate and Traffic Aggregate because Treatment only with the forwarding treatment of the aggregated traffic,
Aggregate is only concerned with the treatment of the aggregated which may be marked with multiple DSCPs. A Treatment Aggregate
traffic. It does not concern itself with how the aggregated differs from Behavior Aggregate [4] and Traffic Aggregate [16],
traffic is marked, and hence does not put a restriction on the each of which indicate the aggregated traffic having a single
aggregated traffic having a single diffserv codepoint that have a diffserv codepoint and utilizing a single PHB.
single 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 [6]. of RFC 1633 [6].
o Diffserv Service Class. Section 1.3 of RFC 4594 [5]. o Diffserv Service Class. Section 1.3 of RFC 4594 [5].
o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched
skipping to change at page 5, line 49 skipping to change at page 5, line 49
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. upon exiting such administrative domains.
5. Each treatment aggregate has limited resources, hence traffic 5. Each treatment aggregate has limited resources, hence traffic
conditioning and/or admission control must be performed for each conditioning and/or admission control should be performed for
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
of all traffic aggregated into the treatment aggregate.
with the following suggestions: with the following 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) may have a much less predictable pattern. Even the (e.g., VPLS) may have a much less predictable pattern. Even the
traffic patterns within the Internet may vary widely. traffic patterns within the Internet may vary widely.
skipping to change at page 6, line 35 skipping to change at page 6, line 36
[5] has been defined to allow, in many instances, mapping of two or [5] has been defined to allow, in many instances, mapping of two or
possibly more service classes into a single forwarding treatment possibly more service classes into a single forwarding treatment
aggregate. Notice that there is a relationship/trade-off between aggregate. Notice that there is a relationship/trade-off between
link speed, queue depth, delay, and jitter. The degree of link speed, queue depth, delay, and jitter. The degree of
aggregation and hence the number of treatment aggregates will depend aggregation and hence the number of treatment aggregates will depend
on whether the speed of the links and scheduler behavior, being used on whether the speed of the links and scheduler behavior, being used
to implement the aggregation, can minimize the affects of mixing to implement the aggregation, can minimize the affects of mixing
traffic with different packet sizes and transmit rates on queue traffic with different packet sizes and transmit rates on queue
depth. And their impacts on loss, delay, and jitter. A general depth. And their impacts on loss, delay, and jitter. A general
rule-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. smaller number of treatment aggregates. Assuming link utilization is
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 [5] into four treatment aggregates. The use of defined in RFC 4594 [5] 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 is sufficient to honor the required behavior each treatment aggregate is sufficient to honor the required behavior
of each service class [5] in each of the four treatment aggregates. of each service class [5] in each of the four treatment aggregates.
We use the performance requirement (tolerance to loss, delay, and We use the performance requirement (tolerance to loss, delay, and
jitter) from the application/end-user as a guide on how to map the jitter) from the application/end-user as a guide on how to map the
skipping to change at page 8, line 4 skipping to change at page 7, line 28
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 less treatment perspective. A domain may choose to support more or less treatment
aggregates. For example, only supporting three treatment aggregates, aggregates. For example, only supporting three treatment aggregates,
and with mapping any network control traffic into the Assured Elastic and with mapping any network control traffic into the Assured Elastic
treatment aggregate. This is a choice the administrative domain has. treatment aggregate. This is a choice the administrative domain has.
Hence this example of four treatment aggregates does not represent a
minimum required set of treatment aggregates one must implement; nor
does it represent the 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 ||---------------+------+------+------|
skipping to change at page 9, line 48 skipping to change at page 9, line 48
characterizes as being included in the Network Control Service Class. characterizes as being included in the Network Control Service Class.
The DSCPs of the original service class remain an important The DSCPs of the original service class remain an important
consideration and should be preserved during aggregation. Traffic in consideration and should be preserved during aggregation. Traffic in
the Network Control treatment aggregate should be carried in a common the Network Control treatment aggregate should be carried in a common
queue or class with a PHB as described in RFC 2474 [4] section queue or class with a PHB as described in RFC 2474 [4] section
4.2.2.2. This treatment aggregate should have a lower probability of 4.2.2.2. This treatment aggregate should have a lower probability of
packet loss, bearing a relatively deep target mean queue depth (min- packet loss, bearing a relatively deep target mean queue depth (min-
threshold if RED is being used). threshold if RED is being used).
Please notice this Network Control Treatment Aggregate is meant to be
used for the customer's network control traffic. The provider may
choose to treat its own network control traffic differently, perhaps
in its own service class that is not aggregated with the customer's
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 a SLA managed at the edge
of the network prior to aggregation. As such, there is a predictable of the network prior to aggregation. As such, there is a predictable
and enforceable upper bound on the traffic that can enter such a and enforceable upper bound on the traffic that can enter such a
queue, and to provide predictable variation in delay it must be queue, and to provide predictable variation in delay it must be
protected from bursts of elastic traffic. The predictability of 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
skipping to change at page 10, line 24 skipping to change at page 10, line 30
from the Diffserv Service Classes [5], in addition to other locally from the Diffserv Service Classes [5], 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, 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 service classes aggregated. the sum of all traffic aggregated into this treatment aggregate.
The DSCPs of the original service classes remain an important The DSCPs of the original service classes remain an important
consideration and should be preserved during aggregation. Traffic consideration and should be preserved during aggregation. Traffic
bearing these DSCPs is carried in a common queue or class with a PHB bearing these DSCPs is carried in a common queue or class with a PHB
as described in RFC 3246 [11] and RFC 3247 [12]. as described in RFC 3246 [11] and RFC 3247 [12].
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
skipping to change at page 11, line 51 skipping to change at page 12, line 9
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 [9] or ECN flagging [13] SLA differentiation of traffic, but that AQM [9] or ECN flagging [13]
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 [5], in addition to other locally from the Diffserv Service Classes [5], in addition to other locally
defined classes: Standard, Low Priority Data. defined classes: Standard, Low Priority Data.
Treatment aggregates should be well specified, each indicating the
service classes it will handle. But in cases where unspecified or
unknown service classes are encountered, they may be dropped or be
treated using the Elastic Treatment Aggregate. The choice of how to
treat unspecified service classes should be well defined, based on
some agreements.
The DSCPs of the original service classes remain an important The DSCPs of the original service classes remain an important
consideration and should be preserved during aggregation. Traffic consideration and should be preserved during aggregation. Traffic
bearing these DSCPs is carried in a common queue or class with a PHB bearing these DSCPs is carried in a common queue or class with a PHB
as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM
thresholds for Elastic traffic MAY be separately set, so that Low thresholds for Elastic traffic MAY be separately set, so that Low
Priority Data traffic is dropped before Standard traffic, but this is Priority Data traffic is dropped before Standard traffic, but this is
not a requirement. not a requirement.
5. Using MPLS for Treatment Aggregates 5. Treatment Aggregates and Inter-Provider Relationships
When Treatment Aggregates are used at provider boundaries, we
recommend that the Inter-Provider Relationship be based on Diffserv
Service Classes [5]. This allows the admission control into each
Treatment Aggregate of a provider domain to be based on the admission
control of traffic into the supported Service Classes, as indicated
by the discussion in section 4 of this document.
If the Inter-Provider Relationship needs to be based on Treatment
Aggregates specified by this document, then the exact Treatment
Aggregate content and representation must be agreed to by the peering
providers.
Some additional work on Inter-Provider Relationships is provided by
Inter-provider QoS [17], where details on supporting realtime
services between service providers are discussed. Some related work
in ITU-T provided by Appendix VI of Y.1541 [18] may also help with
inter-provider relationships, especially with international
providers.
6. Security Considerations
This document discusses the policy of using Differentiated Services
and its service classes. If implemented as described, it should
require that the network do nothing that the network has not already
allowed. If that is the case, no new security issues should arise
from the use of such a policy.
It is possible for the policy to be applied incorrectly, or for a
wrong policy to be applied in the network for the defined
aggregation. In that case, a policy issue exists that the network
must detect, assess, and deal with. This is a known security issue
in any network dependent on policy-directed behavior.
A well known flaw appears when bandwidth is reserved or enabled for a
service (for example, voice transport) and another service or an
attacking traffic stream uses it. This possibility is inherent in
DiffServ technology, which depends on appropriate packet markings.
When bandwidth reservation or a priority queuing system is used in a
vulnerable network, the use of authentication and flow admission is
recommended. To the best of the authors' knowledge, there is no
known technical way to respond to or act upon a data stream that has
been admitted for service but that it is not intended for
authenticated use.
7. IANA Considerations
This document does not request any IANA considerations.
8. Acknowledgements
This document has benefited from discussions with numerous people,
especially Shane Amante, Brian Carpenter, and Dave McDysan. It has
also benefited from detailed reviews by David Black, Marvin Krym,
Bruce Davies, Fil Dickinson, and Julie Ann Connary.
Appendix A. Using MPLS for Treatment Aggregates
RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of
DiffServ [8] provide a very good background on this topic. This DiffServ [8] 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 [8] for realizing the Treatment Aggregates. Support of DiffServ [8] 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.
skipping to change at page 14, line 6 skipping to change at page 15, line 6
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 EXP
field of 010 (000). 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.
5.1. Network Control Treatment Aggregate with E-LSP Appendix 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" [5]. document and section 3.2 of "Diffserv Service Classes" [5].
Reinforcing these recommendations, there should be no drop precedence Reinforcing these recommendations, there should be no drop precedence
associated with the MPLS PSC used for Network Control Treatment associated with the MPLS PSC used for Network Control Treatment
Aggregate because dropping of Network Control Treatment Aggregate Aggregate because dropping of Network Control Treatment Aggregate
traffic should be prevented. traffic should be prevented.
5.2. Real Time Treatment Aggregate with E-LSP Appendix 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 "Diffserv Service
Classes" [5], we want to indicate that Real Time Treatment Aggregate Classes" [5], we want to indicate that Real Time Treatment Aggregate
traffic should not be dropped, as some of the applications whose traffic should not be dropped, as some of the applications whose
traffic is carried in the Real Time Treatment Aggregate do not react traffic is carried in the Real Time Treatment Aggregate do not react
well to dropped packets. As indicated in section 4.1.2 of this well to dropped packets. As indicated in section 4.1.2 of this
document, admission control should be performed on each Service Class document, admission control should be performed on each Service Class
contributing to the Real Time Treatment Aggregate to prevent packet contributing to the Real Time Treatment Aggregate to prevent packet
loss due to insufficient resources allocated to Real Time Treatment loss due to insufficient resources allocated to Real Time Treatment
Aggregate. Further, admission control and policing may also be Aggregate. Further, admission control and policing may also be
applied on the sum of all traffic aggregated into this treatment applied on the sum of all traffic aggregated into this treatment
aggregate. aggregate.
5.3. Assured Elastic Treatment Aggregate with E-LSP Appendix 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.
5.4. Elastic Treatment Aggregate with E-LSP Appendix 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.
5.5. Treatment Aggregates and L-LSP Appendix 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 administrations.
6. Treatment Aggregates and Inter-Provider Relationships 9. References
When Treatment Aggregates are used at provider boundaries, we
recommend that the Inter-Provider Relationship be based on Diffserv
Service Classes [5]. This allows the admission control into each
Treatment Aggregate of a provider domain to be based on the admission
control of traffic into the supported Service Classes, as indicated
by the discussion in section 4 of this document.
If the Inter-Provider Relationship needs to be based on Treatment
Aggregates specified by this document, then the exact Treatment
Aggregate content and representation must be agreed to by the peering
providers.
Some additional work on Inter-Provider Relationships is provided by
Inter-provider QoS [16], where details on supporting realtime
services between service providers are discussed. Some related work
in ITU-T provided by Appendix VI of Y.1541 [17] may also help with
inter-provider relationships, especially with international
providers.
7. Security Considerations
This document discusses the policy of using Differentiated Services
and its service classes. If implemented as described, it should
require that the network do nothing that the network has not already
allowed. If that is the case, no new security issues should arise
from the use of such a policy.
It is possible for the policy to be applied incorrectly, or for a
wrong policy to be applied in the network for the defined
aggregation. In that case, a policy issue exists that the network
must detect, assess, and deal with. This is a known security issue
in any network dependent on policy-directed behavior.
A well known flaw appears when bandwidth is reserved or enabled for a
service (for example, voice transport) and another service or an
attacking traffic stream uses it. This possibility is inherent in
DiffServ technology, which depends on appropriate packet markings.
When bandwidth reservation or a priority queuing system is used in a
vulnerable network, the use of authentication and flow admission is
recommended. To the best of the authors' knowledge, there is no
known technical way to respond to or act upon a data stream that has
been admitted for service but that it is not intended for
authenticated use.
8. IANA Considerations
This document does not request any IANA considerations.
9. Acknowledgements
This document has benefited from discussions with numerous people,
especially Shane Amante, Brian Carpenter, and Dave McDysan. It has
also benefited from detailed reviews by David Black and Marvin Krym.
10. References
10.1. Normative References 9.1. Normative References
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, [1] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[2] Bradner, S., "The Internet Standards Process -- Revision 3", [2] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 17, line 35 skipping to change at page 17, line 23
[12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., [12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New Definition Ramakrishnan, "Supplemental Information for the New Definition
of the EF PHB (Expedited Forwarding Per-Hop Behavior)", of the EF PHB (Expedited Forwarding Per-Hop Behavior)",
RFC 3247, March 2002. RFC 3247, March 2002.
[13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of [13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168, Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001. September 2001.
10.2. Informative References 9.2. Informative References
[14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, [14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot,
"Analysis of Point-To-Point Packet Delay in an Operational "Analysis of Point-To-Point Packet Delay in an Operational
Network", INFOCOMM 2004, March 2004, Network", INFOCOMM 2004, March 2004,
<http://www.ieee-infocom.org/2004/Papers/37_4.PDF>. <http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.
[15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", [15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11",
March 2002, <http://www.renesys.com/tech/presentations/pdf/ March 2002, <http://www.renesys.com/tech/presentations/pdf/
renesys-030502-NRC-911.pdf>. renesys-030502-NRC-911.pdf>.
[16] MIT Communications Futures Program, "Inter-provider Quality of [16] Nichols, K. and B. Carpenter, "Definition of Differentiated
Services Per Domain Behaviors and Rules for their
Specification", RFC 3086, April 2001.
[17] MIT Communications Futures Program, "Inter-provider Quality of
Service", November 2006, < Service", November 2006, <
http://cfp.mit.edu/resources/papers/Interprovider QoS http://cfp.mit.edu/resources/papers/Interprovider QoS
MIT_CFP_WP_9_14_06.pdf>. MIT_CFP_WP_9_14_06.pdf>.
[17] International Telecommunications Union, "Network performance [18] International Telecommunications Union, "Network performance
objectives for IP-based services", February 2006. objectives for IP-based services", February 2006.
Authors' Addresses Authors' Addresses
Kwok Ho Chan Kwok Ho Chan
Nortel Networks 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 Networks 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
 End of changes. 29 change blocks. 
111 lines changed or deleted 137 lines changed or added

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