draft-ietf-tsvwg-diffserv-class-aggr-03.txt   draft-ietf-tsvwg-diffserv-class-aggr-04.txt 
TSVWG K. Chan TSVWG K. Chan
Internet-Draft J. Babiarz Internet-Draft J. Babiarz
Intended status: Informational Nortel Intended status: Informational Nortel
Expires: January 10, 2008 F. Baker Expires: February 4, 2008 F. Baker
Cisco Systems Cisco Systems
July 9, 2007 August 3, 2007
Aggregation of DiffServ Service Classes Aggregation of DiffServ Service Classes
draft-ietf-tsvwg-diffserv-class-aggr-03 draft-ietf-tsvwg-diffserv-class-aggr-04
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 January 10, 2008. This Internet-Draft will expire on February 4, 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 may
still 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 as indicated by to-end behavior requirements of the applications as indicated by
Diffserv Service Classes [5]. However, some network segments may be Diffserv Service Classes [5]. However, some network segments may be
configured in such a way that a single forwarding treatment may configured in such a way that a single forwarding treatment may
satisfy the traffic characteristics and performance requirements of satisfy the traffic characteristics and performance requirements of
two or more service classes. In these cases, it may be desirable to two or more service classes. In these cases, it may be desirable to
aggregate two or more Diffserv Service Classes [5] into a single aggregate two or more Diffserv Service Classes [5] into a single
forwarding treatment. This document provides guidelines for the forwarding treatment. This document provides guidelines for the
aggregation of Diffserv Service Classes [5] into forwarding aggregation of Diffserv Service Classes [5] into forwarding
treatments. 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 . . 6 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 . . . . . . . . . . . . . 11 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 11
5. Treatment Aggregates and Inter-Provider Relationships . . . . 12 5. Treatment Aggregates and Inter-Provider Relationships . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 13 Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 13
Appendix A.1. Network Control Treatment Aggregate with E-LSP . . . 15 Appendix A.1. Network Control Treatment Aggregate with E-LSP . . . 15
skipping to change at page 3, line 20 skipping to change at page 3, line 20
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
this remains true after re-routing (either IP re-routing or MPLS this remains true after re-routing (either IP re-routing or MPLS
protection-mode switching) has occurred. protection-mode 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 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 may still have issues. Delay,
and occasional loss are perfectly acceptable for elastic jitter, 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), protect disruption to routing (which in turn affects all services), protect
real-time jitter-sensitive services, while minimizing loss and delay real-time jitter-sensitive services, while minimizing loss and delay
of sensitive elastic traffic. of sensitive elastic traffic.
The document "Diffserv Service Classes" [5] defines the basic The document "Diffserv Service Classes" [5] defines a set of 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 application payload's tolerance to
loss, delay, and delay variation (jitter). Different degrees of packet loss, delay, and delay variation (jitter). Different degrees
these criteria form the foundation for supporting the needs of real- of these criteria form the foundation for supporting the needs of
time and elastic traffic. The "Diffserv Service Classes" [5] real-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 Having the IP traffic belonging to service classes, expressed using
DSCP, as described by "Diffserv Service Classes" [5]. Note that in a the DSCP, as described by "Diffserv Service Classes" [5]. Note that
given domain, we may recommend that the supported service classes be in a given domain, we may recommend that the supported service
aggregated into forwarding treatment aggregates; however, this does classes be aggregated into forwarding treatment aggregates; however,
not mean all service classes need to be supported and hence not all this does not mean all service classes need to be supported and hence
forwarding treatment aggregates need to be supported. A domain may not all forwarding treatment aggregates need to be supported. A
support fewer or greater number of forwarding treatment aggregates. domain may support fewer or greater number of forwarding treatment
Which service classes and which forwarding treatment aggregates are aggregates. Which service classes and which forwarding treatment
supported by a domain is up to the domain administration and may be aggregates are supported by a domain is up to the domain
influenced by business reasons. administration and may be influenced by business reasons 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 this aggregation over MPLS using E-LSP. o an example of performing the aggregation when four treatment
aggregates are used,
o an example (in the appendix) 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. The recommendation given
is one possible way of performing the aggregation, there may be other
way of aggregation, for example into fewer treatment aggregates or
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, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path
(LSP), to realize the treatment aggregates is provided. Note that (LSP), to realize the treatment aggregates is provided. Note that
the MPLS E-LSP is just an example; this document does not exclude the the MPLS E-LSP is just an example; this document does not exclude the
use of other methods. This example only considers aggregation of IP use 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 none-IP traffic is not
discussed. discussed.
1.1. Requirements Notation 1.1. Requirements Notation
skipping to change at page 5, line 21 skipping to change at page 5, line 29
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
Path (LSP). Section 1.2 of RFC 3270 [8]. Path (LSP). Section 1.2 of RFC 3270 [8].
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 [8]. Switched Path (LSP). Section 1.3 of RFC 3270 [8].
3. Overview of Service Class Aggregation 3. Overview of Service Class Aggregation
In diffserv domains where less granular 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 [5] may be required. classes [5] 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 [5]. is represented by the use of Diffserv Service Classes [5].
2. The treatment aggregate must exhibit the strictest requirement 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. upon exiting such administrative domains. One possible way of
achieving this is with the use of tunnels to encapsulate the end-
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.
with the following suggestions: In addition to the above requirements, we have 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.
traffic patterns within the Internet may vary widely.
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, usage of
MPLS-based traffic engineering techniques. 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 [5]. the use of Diffserv Service Classes [5].
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 "Diffserv Service Classes"
[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 effects 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-
rule-of-thumb is that higher link speeds allow for more aggregation/ 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 [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 are sufficient to honor the required
of each service class [5] in each of the four treatment aggregates. behavior of each service class [5] in each of the four treatment
We use the performance requirement (tolerance to loss, delay, and aggregates. We use the performance requirement (tolerance to loss,
jitter) from the application/end-user as a guide on how to map the delay, and jitter) from the application/end-user as a guide on how to
service classes into treatment aggregates. We have also used Section map the service classes into treatment aggregates. We have also used
3.1 of RFC 1633 [6] to provide us with guidance on the definition of Section 3.1 of RFC 1633 [6] to provide us with guidance on the
Real-Time and Elastic applications. An overview of the mapping definition of Real-Time and Elastic applications. An overview of the
between service classes and the four treatment aggregates is provided mapping between service classes and the four treatment aggregates is
by Figure 1, with the mapping being based on performance provided by Figure 1, with the mapping being based on performance
requirements. In Figure 1, the right side columns of "Service requirements. In Figure 1, the right side columns of "Service
Class", "Tolerance to Loss/Delay/Jitter" are from Figure 2 of Class", "Tolerance to Loss/Delay/Jitter" are from Figure 2 of
Diffserv Service Classes [5]. Diffserv Service Classes [5].
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, they being 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 less treatment perspective. A domain may choose to support more or fewer 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 Hence this example of four treatment aggregates does not represent a
minimum required set of treatment aggregates one must implement; nor minimum required set of treatment aggregates one must implement; nor
does it represent the maximum set of treatment aggregates one can does it represent the maximum set of treatment aggregates one can
implement. implement.
--------------------------------------------------------------------- ---------------------------------------------------------------------
|Treatment | Tolerance to ||Service Class | Tolerance to | |Treatment | Tolerance to ||Service Class | Tolerance to |
skipping to change at page 9, line 40 skipping to change at page 9, line 40
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" [5] includes the traffic that "Diffserv Service Classes" [5]
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 Traffic in the Network Control treatment aggregate should be carried
consideration and should be preserved during aggregation. Traffic in in a common queue or class with a PHB as described in RFC 2474 [4]
the Network Control treatment aggregate should be carried in a common section 4.2.2.2. This treatment aggregate should have a lower
queue or class with a PHB as described in RFC 2474 [4] section probability of packet loss, bearing a relatively deep target mean
4.2.2.2. This treatment aggregate should have a lower probability of queue depth (min-threshold if RED is being used).
packet loss, bearing a relatively deep target mean queue depth (min-
threshold if RED 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
skipping to change at page 10, line 32 skipping to change at page 10, line 31
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 traffic aggregated into this treatment aggregate. the sum of all traffic aggregated into this treatment aggregate.
The DSCPs of the original service classes remain an important Traffic in the Real Time treatment aggregate should be carried in a
consideration and should be preserved during aggregation. Traffic common queue or class with a PHB as described in RFC 3246 [11] and
bearing these DSCPs is carried in a common queue or class with a PHB 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
2597 [10]. The premise of such a service is that a SLA is negotiated 2597 [10]. The premise of such a service is that a SLA is negotiated
which includes a "committed rate" and the ability to exceed that rate which includes a "committed rate" and the ability to exceed that rate
(and perhaps a second "excess rate") in exchange for a higher (and perhaps a second "excess rate") in exchange for a higher
probability of loss using AQM [9] or ECN flagging [13] for the probability of loss using AQM [9] or ECN marking [13] for the portion
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 [5], in addition to other locally from the Diffserv Service Classes [5], in addition to other locally
defined classes: Multimedia Streaming, Low Latency Data, OAM, High defined classes: Multimedia Streaming, Low Latency Data, OAM, High
Throughput Data. Throughput Data.
The DSCP values belonging to the AF PHB group and class selector of The DSCP values belonging to the AF PHB group and class selector of
the original service classes remain an important consideration and the original service classes remain an important consideration and
should be preserved during aggregation. This treatment aggregate should be preserved during aggregation. This treatment aggregate
should maintain the AF PHB group marking of the original packet. For should maintain the AF PHB group marking of the original packet. For
skipping to change at page 12, line 16 skipping to change at page 12, line 13
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 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.
The DSCPs of the original service classes remain an important Traffic in the Elastic treatment aggregate should be carried in a
consideration and should be preserved during aggregation. Traffic common queue or class with a PHB as described in RFC 2474 [4] section
bearing these DSCPs is carried in a common queue or class with a PHB 4.1: A Default PHB. The AQM thresholds for Elastic traffic MAY be
as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM separately set, so that Low Priority Data traffic is dropped before
thresholds for Elastic traffic MAY be separately set, so that Low Standard traffic, but this is not a requirement.
Priority Data traffic is dropped 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 [5]. This allows the admission control into each Service Classes [5]. 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.
skipping to change at page 13, line 32 skipping to change at page 13, line 28
7. IANA Considerations 7. IANA Considerations
This document does not request any IANA considerations. This document does not request any IANA considerations.
8. Acknowledgements 8. 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 Davies, Fil Dickinson, and Julie Ann Connary. Bruce Davie, Fil Dickinson, and Julie Ann Connary.
Appendix A. Using MPLS for Treatment Aggregates 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
 End of changes. 26 change blocks. 
67 lines changed or deleted 72 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/