doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc5127.txt b/doc/rfc/rfc5127.txt
new file mode 100644
index 0000000..4f4e7b5
--- /dev/null
+++ b/doc/rfc/rfc5127.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                            K. Chan
+Request for Comments: 5127                                    J. Babiarz
+Category: Informational                                           Nortel
+                                                                F. Baker
+                                                           Cisco Systems
+                                                           February 2008
+
+
+                Aggregation of Diffserv Service Classes
+
+Status of This Memo
+
+   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
+
+   In the core of a high-capacity network, service differentiation may
+   still be needed to support applications' utilization of the network.
+   Applications with similar traffic characteristics and performance
+   requirements are mapped into Diffserv service classes based on end-
+   to-end behavior requirements of the applications.  However, some
+   network segments may be configured in such a way that a single
+   forwarding treatment may satisfy the traffic characteristics and
+   performance requirements of two or more service classes.  In these
+   cases, it may be desirable to aggregate two or more Diffserv service
+   classes into a single forwarding treatment.  This document provides
+   guidelines for the aggregation of Diffserv service classes into
+   forwarding treatments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al.                 Informational                      [Page 1]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  4
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Overview of Service Class Aggregation  . . . . . . . . . . . .  5
+   4.  Service Classes to Treatment Aggregate Mapping . . . . . . . .  6
+     4.1.  Mapping Service Classes into Four Treatment Aggregates . .  7
+       4.1.1.  Network Control Treatment Aggregate  . . . . . . . . .  9
+       4.1.2.  Real-Time Treatment Aggregate  . . . . . . . . . . . . 10
+       4.1.3.  Assured Elastic Treatment Aggregate  . . . . . . . . . 10
+       4.1.4.  Elastic Treatment Aggregate  . . . . . . . . . . . . . 12
+   5.  Treatment Aggregates and Inter-Provider Relationships  . . . . 12
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
+   Appendix A.   Using MPLS for Treatment Aggregates  . . . . . . . . 15
+     A.1.  Network Control Treatment Aggregate with E-LSP . . . . . . 17
+     A.2.  Real-Time Treatment Aggregate with E-LSP . . . . . . . . . 17
+     A.3.  Assured Elastic Treatment Aggregate with E-LSP . . . . . . 17
+     A.4.  Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 17
+     A.5.  Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al.                 Informational                      [Page 2]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+1.  Introduction
+
+   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
+   can fail, and the result will be a routed network that still meets
+   ambient Service Level Agreements (SLAs).  The implications are that
+   there is sufficient capacity on any given link such that all SLAs
+   sold can be simultaneously supported at their respective maximum
+   rates, and that this remains true after re-routing (either IP re-
+   routing or Multiprotocol Label Switching (MPLS) protection-mode
+   switching) has occurred.
+
+   Over-provisioning is generally considered to meet the requirements of
+   all traffic without further quality of service (QoS) treatment, and
+   in the general case, that is true in high-capacity backbones.
+   However, as the process of network convergence continues, and with
+   the increasing speed of the access networks, certain services may
+   still have issues.  Delay, jitter, and occasional loss are perfectly
+   acceptable for elastic applications.  However, sub-second surges that
+   occur in the best-designed of networks [12] affect real-time
+   applications.  Moreover, denial of service (DoS) loads, worms, and
+   network disruptions such as that of 11 September 2001 affect routing
+   [13].  Our objective is to prevent disruption to routing (which in
+   turn affects all services) and to protect real-time jitter-sensitive
+   services, while minimizing loss and delay of sensitive elastic
+   traffic.
+
+   RFC 4594 [3] defines a set of basic Diffserv classes from the points
+   of view of the application requiring specific end-to-end behaviors
+   from the network.  The service classes are differentiated based on
+   the application payload's tolerance to packet loss, delay, and delay
+   variation (jitter).  Different degrees of these criteria form the
+   foundation for supporting the needs of real-time and elastic traffic.
+   RFC 4594 [3] also provides recommendations for the treatment method
+   of these service classes.  But, at some network segments of the end-
+   to-end path, the number of levels of network treatment
+   differentiation may be less than the number of service classes that
+   the network segment needs to support.  In such a situation, that
+   network segment may use the same treatment to support more than one
+   service class.  In this document, we provide guidelines on how
+   multiple service classes may be aggregated into a forwarding
+   treatment aggregate.  This entails having the IP traffic belonging to
+   service classes, expressed using the DSCP (Differentiated Services
+   Code Point), as described by RFC 4594 [3].  Note that in a given
+   domain, we may recommend that the supported service classes be
+   aggregated into forwarding treatment aggregates; however, this does
+   not mean all service classes need to be supported, and hence not all
+   forwarding treatment aggregates need to be supported.  A domain may
+
+
+
+Chan, et al.                 Informational                      [Page 3]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+   support a fewer or greater number of forwarding treatment aggregates
+   than recommended by this document.  Which service classes and which
+   forwarding treatment aggregates are supported by a domain is up to
+   the domain administration and may be influenced by business reasons
+   or other reasons (e.g., operational considerations).
+
+   In this document, we've provided:
+
+   o  definitions for terminology we use in this document,
+
+   o  requirements for performing this aggregation,
+
+   o  an example of performing the aggregation when four treatment
+      aggregates are used, and
+
+   o  an example (in the appendix) of performing this aggregation over
+      MPLS using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label
+      Switched Path (LSP).
+
+   The treatment aggregate recommendations are designed to aggregate the
+   service classes [3] in such a manner as to protect real-time traffic
+   and routing, on the assumption that real-time sessions are protected
+   from each other by admission at the edge.  The recommendation given
+   is one possible way of performing the aggregation; there may be other
+   ways of aggregation, for example, into fewer treatment aggregates or
+   more treatment aggregates.
+
+   In the appendix, an example of aggregation over MPLS networks using
+   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
+   of other methods.  This example only considers aggregation of IP
+   traffic into E-LSP.  The use of E-LSP by non-IP traffic is not
+   discussed.
+
+1.1.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+2.  Terminology
+
+   This document assumes the reader is familiar with the terms used in
+   differentiated services.  This document provides the definitions for
+   new terms introduced by this document and references information
+   defined in RFCs for existing terms not commonly used in
+   differentiated services.
+
+
+
+
+Chan, et al.                 Informational                      [Page 4]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+   For new terms introduced by this document, we provide the definition
+   here:
+
+   o  Treatment Aggregate.  This term is defined as the aggregate of
+      Diffserv service classes [3].  A treatment aggregate is concerned
+      only with the forwarding treatment of the aggregated traffic,
+      which may be marked with multiple DSCPs.  A treatment aggregate
+      differs from Behavior Aggregate [2] and Traffic Aggregate [14],
+      each of which indicate the aggregated traffic having a single
+      Diffserv codepoint and utilizing a single Per Hop Behavior (PHB).
+
+   For terms from existing RFCs, we provide the reference to the
+   appropriate section of the relevant RFC that contain the definition:
+
+   o  Real-Time and Elastic Applications and their traffic.  Section 3.1
+      of RFC 1633 [4].
+
+   o  Diffserv Service Class.  Section 1.3 of RFC 4594 [3].
+
+   o  MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched
+      Path (LSP).  Section 1.2 of RFC 3270 [6].
+
+   o  MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label
+      Switched Path (LSP).  Section 1.3 of RFC 3270 [6].
+
+3.  Overview of Service Class Aggregation
+
+   In Diffserv domains where less fine-grained traffic treatment
+   differentiation is provided, aggregation of the different service
+   classes [3] may be required.
+
+   These aggregations have the following requirements:
+
+   1.  The end-to-end network performance characteristic required by the
+       application MUST be supported.  This performance characteristic
+       is represented by the use of Diffserv service classes [3].
+
+   2.  The treatment aggregate MUST meet the strictest requirements of
+       its member service classes.
+
+   3.  The treatment aggregate SHOULD only contain member service
+       classes with similar traffic characteristic and performance
+       requirements.
+
+   4.  The notion of the individual end-to-end service classes MUST NOT
+       be destroyed when aggregation is performed.  Each domain along
+       the end-to-end path may perform aggregation differently, based on
+       the original end-to-end service classes.  We recommend an easy
+
+
+
+Chan, et al.                 Informational                      [Page 5]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+       way to accomplish this by not altering the DSCP used to indicate
+       the end-to-end service class.  But some administrative domains
+       may require the use of their own marking; when this is needed,
+       the original end-to-end service class indication must be restored
+       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
+       conditioning and/or admission control SHOULD be performed for
+       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.
+
+   In addition to the above requirements, we have the following
+   suggestions:
+
+   1.  The treatment aggregate and assigned resources may consider
+       historical traffic patterns and the variability of these
+       patterns.  For example, a point-point service (e.g., pseudowire)
+       may have a very predictable pattern, while a multipoint service
+       (e.g., VPLS, Virtual Private LAN Service) may have a much less
+       predictable pattern.
+
+   2.  In addition to Diffserv, other controls are available to
+       influence the traffic level offered to a particular traffic
+       aggregate.  These include adjustment of routing metrics, and
+       usage of MPLS-based traffic engineering techniques.
+
+   This document only describes the aggregation of IP traffic based on
+   the use of Diffserv service classes [3].
+
+4.  Service Classes to Treatment Aggregate Mapping
+
+   The service class and DSCP selection in RFC 4594 [3] has been defined
+   to allow, in many instances, mapping of two or possibly more service
+   classes into a single forwarding treatment aggregate.  Notice that
+   there is a relationship/trade-off between link speed, queue depth,
+   delay, and jitter.  The degree of aggregation and hence the number of
+   treatment aggregates will depend on the aggregation's impacts on
+   loss, delay, and jitter.  This depends on whether the speed of the
+   links and scheduler behavior, being used to implement the
+   aggregation, can minimize the effects of mixing traffic with
+   different packet sizes and transmit rates on queue depth.  A general
+   rule-of-thumb is that higher link speeds allow for more aggregation/
+   smaller number of treatment aggregates, assuming link utilization is
+   within the engineered level.
+
+
+
+
+Chan, et al.                 Informational                      [Page 6]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+4.1.  Mapping Service Classes into Four Treatment Aggregates
+
+   This section provides an example of mapping all the service classes
+   defined in RFC 4594 [3] into four treatment aggregates.  The use of
+   four treatment aggregates assumes that the resources allocated to
+   each treatment aggregate are sufficient to honor the required
+   behavior of each service class [3].  We use the performance
+   requirement (tolerance to loss, delay, and jitter) from the
+   application/end-user as a guide on how to map the service classes
+   into treatment aggregates.  We have also used section 3.1 of RFC 1633
+   [4] to provide us with guidance on the definition of Real-Time and
+   Elastic applications.  An overview of the mapping between service
+   classes and the four treatment aggregates is provided by Figure 1,
+   with the mapping being based on performance requirements.  In Figure
+   1, the right side columns of "Service Class" and "Tolerance to Loss/
+   Delay/Jitter" are from Figure 2 of RFC 4594 [3].
+
+   It is recommended that certain service classes be mapped into
+   specific treatment aggregates.  But this does not mean that all the
+   service classes recommended for that treatment aggregate need to be
+   supported.  Hence, for a given domain, a treatment aggregate may
+   contain only a subset of the service classes recommended in this
+   document, i.e., the service classes supported by that domain.  A
+   domain's treatment of non-supported service classes should be based
+   on the domain's local policy.  This local policy may be influenced by
+   its agreement with its customers.  Such treatment may use the Elastic
+   Treatment Aggregate, dropping the packets, or some other
+   arrangements.
+
+   Our example of four treatment aggregates is based on the basic
+   differences in performance requirement from the application/end-user
+   perspective.  A domain may choose to support more or fewer treatment
+   aggregates than the four recommended.  For example, a domain may
+   support only three treatment aggregates and map any network control
+   traffic into the Assured Elastic 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al.                 Informational                      [Page 7]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+  ---------------------------------------------------------------------
+ |Treatment |    Tolerance to    ||Service Class  |    Tolerance to    |
+ |Aggregate | Loss |Delay |Jitter||               | Loss |Delay |Jitter|
+ |==========+======+======+======++===============+======+======+======|
+ | Network  | Low  | Low  | Yes  || Network       |  Low |  Low | Yes  |
+ | Control  |      |      |      || Control       |      |      |      |
+ |==========+======+======+======++===============+======+======+======|
+ | Real-    | Very | Very | Very ||  Telephony    | VLow | VLow | VLow |
+ | Time     | Low  | Low  | Low  ||---------------+------+------+------|
+ |          |      |      |      ||   Signaling   | Low  | Low  | Yes  |
+ |          |      |      |      ||---------------+------+------+------|
+ |          |      |      |      ||  Multimedia   |Low - | Very | Low  |
+ |          |      |      |      || Conferencing  |Medium| Low  |      |
+ |          |      |      |      ||---------------+------+------+------|
+ |          |      |      |      ||   Real-time   | Low  | Very | Low  |
+ |          |      |      |      ||  Interactive  |      | Low  |      |
+ |          |      |      |      ||---------------+------+------+------|
+ |          |      |      |      ||   Broadcast   | Very |Medium| Low  |
+ |          |      |      |      ||     Video     | Low  |      |      |
+ |==========+======+======+======++===============+======+======+======|
+ | Assured  | Low  |Low - | Yes  ||  Multimedia   |Low - |Medium| Yes  |
+ | Elastic  |      |Medium|      ||   Streaming   |Medium|      |      |
+ |          |      |      |      ||---------------+------+------+------|
+ |          |      |      |      ||  Low-Latency  | Low  |Low - | Yes  |
+ |          |      |      |      ||      Data     |      |Medium|      |
+ |          |      |      |      ||---------------+------+------+------|
+ |          |      |      |      ||      OAM      | Low  |Medium| Yes  |
+ |          |      |      |      ||---------------+------+------+------|
+ |          |      |      |      ||High-Throughput| Low  |Medium| Yes  |
+ |          |      |      |      ||      Data     |      |- High|      |
+ |==========+======+======+======++===============+======+======+======|
+ | Elastic  |  Not Specified     ||   Standard    |  Not Specified     |
+ |          |      |      |      ||---------------+------+------+------|
+ |          |      |      |      || Low-Priority  | High | High | Yes  |
+ |          |      |      |      ||      Data     |      |      |      |
+  ---------------------------------------------------------------------
+
+        Figure 1: Treatment Aggregate and Service Class Performance
+                               Requirements
+
+   As we are recommending to preserve the notion of the individual end-
+   to-end service classes, we also recommend that the original DSCP
+   field marking not be changed when treatment aggregates are used.
+   Instead, classifiers that select packets based on the contents of the
+   DSCP field should be used to direct packets from the member Diffserv
+   service classes into the queue that handles each of the treatment
+   aggregates, without remarking the DSCP field of the packets.  This is
+
+
+
+
+Chan, et al.                 Informational                      [Page 8]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+   summarized in Figure 2, which shows the behavior each treatment
+   aggregate should have, and the DSCP field marking of the packets that
+   should be classified into each of the treatment aggregates.
+
+    ------------------------------------------------------------
+   |Treatment |Treatment || DSCP                                |
+   |Aggregate |Aggregate ||                                     |
+   |          |Behavior  ||                                     |
+   |==========+==========++=====================================|
+   | Network  | CS       || CS6                                 |
+   | Control  |(RFC 2474)||                                     |
+   |==========+==========++=====================================|
+   | Real-    | EF       || EF, CS5, AF41, AF42, AF43, CS4, CS3 |
+   | Time     |(RFC 3246)||                                     |
+   |==========+==========++=====================================|
+   | Assured  | AF       || CS2, AF31, AF21, AF11               |
+   | Elastic  |(RFC 2597)||-------------------------------------|
+   |          |          || AF32, AF22, AF12                    |
+   |          |          ||-------------------------------------|
+   |          |          || AF33, AF23, AF13                    |
+   |==========+==========++=====================================|
+   | Elastic  | Default  || Default, (CS0)                      |
+   |          |(RFC 2474)||-------------------------------------|
+   |          |          || CS1                                 |
+    ------------------------------------------------------------
+
+                  Figure 2: Treatment Aggregate Behavior
+
+   Notes for Figure 2: For Assured Elastic and Elastic Treatment
+   Aggregates, please see sections 4.1.3 and 4.1.4, respectively, for
+   details on additional priority within the treatment aggregate.
+
+4.1.1.  Network Control Treatment Aggregate
+
+   The Network Control Treatment Aggregate aggregates all service
+   classes that are functionally necessary for the survival of a network
+   during a DoS attack or other high-traffic load interval.  The theory
+   is that whatever else is true, the network must protect itself.  This
+   includes the traffic that RFC 4594 [3] characterizes as being
+   included in the Network Control service class.
+
+   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],
+   section 4.2.2.2 for Class Selector (CS).  This treatment aggregate
+   should have a lower probability of packet loss and bear a relatively
+   deep target mean queue depth (min-threshold if RED (Random Early
+   Detection) is being used).
+
+
+
+
+Chan, et al.                 Informational                      [Page 9]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+   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
+
+   The Real-Time Treatment Aggregate aggregates all real-time
+   (inelastic) service classes.  The theory is that real-time traffic is
+   admitted under some model and controlled by an SLA managed at the
+   edge of the network prior to aggregation.  As such, there is a
+   predictable and enforceable upper bound on the traffic that can enter
+   such a queue, and to provide predictable variation in delay it must
+   be protected from bursts of elastic traffic.  The predictability of
+   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
+   historical measurements.
+
+   This treatment aggregate may include the following service classes
+   from the Diffserv service classes [3], in addition to other locally
+   defined classes: Telephony, Signaling, Multimedia Conferencing, Real-
+   time Interactive, and Broadcast Video.
+
+   Traffic in each service class that is going to be aggregated into the
+   treatment aggregate should be conditioned prior to aggregation.  It
+   is recommended that per-service-class admission control procedures be
+   used, followed by per-service-class policing so that any individual
+   service class does not generate more than what it is allowed.
+   Furthermore, additional admission control and policing may be used on
+   the sum of all traffic aggregated into this treatment aggregate.
+
+   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
+   RFC 3246 [9] and RFC 3247 [10].
+
+4.1.3.  Assured Elastic Treatment Aggregate
+
+   The Assured Elastic Treatment Aggregate aggregates all elastic
+   traffic that uses the Assured Forwarding model as described in RFC
+   2597 [8].  The premise of such a service is that an SLA that is
+   negotiated includes a "committed rate" and the ability to exceed that
+   rate (and perhaps a second "excess rate") in exchange for a higher
+   probability of loss using Active Queue Management (AQM) [7] or
+   Explicit Congestion Notification (ECN) marking [11] for the portion
+   of traffic deemed to be in excess.
+
+
+
+
+
+Chan, et al.                 Informational                     [Page 10]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+   This treatment aggregate may include the following service classes
+   from the Diffserv service classes [3], in addition to other locally
+   defined classes: Multimedia Streaming, Low Latency Data, OAM, and
+   High-Throughput Data.
+
+   The DSCP values belonging to the Assured Forwarding (AF) PHB group
+   and class selector of the original service classes remain an
+   important consideration and should be preserved during aggregation.
+   This treatment aggregate should maintain the AF PHB group marking of
+   the original packet.  For example, AF3x marked packets should remain
+   AF3x marked within this treatment aggregate.  In addition, the class
+   selector DSCP value should not be changed.  Traffic bearing these
+   DSCPs is carried in a common queue or class with a PHB as described
+   in RFC 2597 [8].  In effect, appropriate target rate thresholds have
+   been applied at the edge, dividing traffic into AFn1 (committed, for
+   any value of n), AFn2, and AFn3 (excess).  The service should be
+   engineered so that AFn1 and CS2 marked packet flows have sufficient
+   bandwidth in the network to provide high assurance of delivery.
+   Since the traffic is elastic and responds dynamically to packet loss,
+   Active Queue Management [7] should be used primarily to reduce the
+   forwarding rate to the minimum assured rate at congestion points.
+   The probability of loss of AFn1 and CS2 traffic must not exceed the
+   probability of loss of AFn2 traffic, which in turn must not exceed
+   the probability of loss of AFn3 traffic.
+
+   If RED [7] is used as an AQM algorithm, the min-threshold specifies a
+   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
+   a DSCP is dropped or ECN marked.  Thus, in this treatment aggregate,
+   the following inequalities SHOULD hold in queue configurations:
+
+   o  min-threshold AFn3 < max-threshold AFn3
+
+   o  max-threshold AFn3 <= min-threshold AFn2
+
+   o  min-threshold AFn2 < max-threshold AFn2
+
+   o  max-threshold AFn2 <= min-threshold AFn1+CS2
+
+   o  min-threshold AFn1+CS2 < max-threshold AFn1+CS2
+
+   o  max-threshold AFn1+CS2 <= memory assigned to the queue
+
+   Note: This configuration tends to drop AFn3 traffic before AFn2, and
+   AFn2 before AFn1 and CS2.  Many other AQM algorithms exist and are
+   used; they should be configured to achieve a similar result.
+
+
+
+
+
+Chan, et al.                 Informational                     [Page 11]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+4.1.4.  Elastic Treatment Aggregate
+
+   The Elastic Treatment Aggregate aggregates all remaining elastic
+   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]
+   is appropriate for such traffic.
+
+   This treatment aggregate may include the following service classes
+   from the Diffserv service classes [3], in addition to other locally
+   defined classes: Standard and 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.
+
+   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 4.1, "A Default PHB".  The AQM thresholds for Elastic traffic
+   MAY be separately set, so that Low Priority Data traffic is dropped
+   before Standard traffic, but this is not a requirement.
+
+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 [3].  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 [15], where details on supporting real-time
+   services between service providers are discussed.  Some related work
+   in ITU-T provided by Appendix VI of Y.1541 [16] may also help with
+   inter-provider relationships, especially with international
+   providers.
+
+
+
+
+
+
+
+Chan, et al.                 Informational                     [Page 12]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+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.
+
+   As this document is based on RFC 4594 [3], the Security Consideration
+   discussion of no new security issues indicated by RFC 4594 [3] also
+   applies to treatment aggregates of this document.
+
+7.  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 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.
+
+
+
+
+
+
+
+
+Chan, et al.                 Informational                     [Page 13]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+   [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.
+
+
+
+
+Chan, et al.                 Informational                     [Page 14]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+Appendix A.  Using MPLS for Treatment Aggregates
+
+   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
+   document provides an example of using the E-LSP, EXP Inferred PHB
+   Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS
+   Support of Diffserv [6] for realizing the Treatment Aggregates.
+
+   When treatment aggregates are represented in MPLS using EXP Inferred
+   PSC LSP, we recommend the following usage of the MPLS EXP field for
+   treatment aggregates.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al.                 Informational                     [Page 15]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+    -------------------------------------------
+   |Treatment || MPLS ||  DSCP   |   DSCP      |
+   |Aggregate || EXP  ||  name   |   value     |
+   |==========++======++=========|=============|
+   | Network  || 110  ||  CS6    |   110000    |
+   | Control  ||      ||         |             |
+   |==========++======++=========|=============|
+   | Real-    || 100  ||  EF     |   101110    |
+   | Time     ||      ||---------|-------------|
+   |          ||      ||  CS5    |   101000    |
+   |          ||      ||---------|-------------|
+   |          ||      ||AF41,AF42|100010,100100|
+   |          ||      ||  AF43   |   100110    |
+   |          ||      ||---------|-------------|
+   |          ||      ||  CS4    |   100000    |
+   |          ||      ||---------|-------------|
+   |          ||      ||  CS3    |   011000    |
+   |==========++======++=========|=============|
+   | Assured  || 010* ||  CS2    |   010000    |
+   | Elastic  ||      ||  AF31   |   011010    |
+   |          ||      ||  AF21   |   010010    |
+   |          ||      ||  AF11   |   001010    |
+   |          ||------||---------|-------------|
+   |          || 011* ||  AF32   |   011100    |
+   |          ||      ||  AF22   |   010100    |
+   |          ||      ||  AF12   |   001100    |
+   |          ||      ||  AF33   |   011110    |
+   |          ||      ||  AF23   |   010110    |
+   |          ||      ||  AF13   |   001110    |
+   |==========++======++=========|=============|
+   | Elastic  || 000* || Default |   000000    |
+   |          ||      || (CS0)   |             |
+   |          ||------||---------|-------------|
+   |          || 001* ||  CS1    |   001000    |
+    -------------------------------------------
+
+          Figure 3: Treatment Aggregate and MPLS EXP Field Usage
+
+      * Note: For Assured Elastic (and Elastic) Treatment Aggregate, 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)
+      have a higher probability of being dropped than packets with an
+      EXP field of 010 (000).
+
+
+
+
+
+
+
+
+Chan, et al.                 Informational                     [Page 16]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+   The above table indicates the recommended usage of EXP fields for
+   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 may use a different EXP field allocation for the domain's
+   supported treatment aggregates.
+
+A.1.  Network Control Treatment Aggregate with E-LSP
+
+   The usage of E-LSP for Network Control Treatment Aggregate needs to
+   adhere to the recommendations indicated in section 4.1.1 of this
+   document and section 3.2 of RFC 4594 [3].  Reinforcing these
+   recommendations, there should be no drop precedence associated with
+   the MPLS PSC used for Network Control Treatment Aggregate because
+   dropping of Network Control Treatment Aggregate traffic should be
+   prevented.
+
+A.2.  Real-Time Treatment Aggregate with E-LSP
+
+   In addition to the recommendations provided in section 4.1.2 of this
+   document and in member service classes' sections of RFC 4594 [3], we
+   want to indicate that Real-Time Treatment Aggregate traffic should
+   not be dropped, as some of the applications whose 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 document, admission
+   control should be performed on each service class contributing to the
+   Real-Time Treatment Aggregate to prevent packet loss due to
+   insufficient resources allocated to Real-Time Treatment Aggregate.
+   Further, admission control and policing may also be applied on the
+   sum of all traffic aggregated into this treatment aggregate.
+
+A.3.  Assured Elastic Treatment Aggregate with E-LSP
+
+   EXP field markings of 010 and 011 are used for the Assured Elastic
+   Treatment Aggregate.  The two encodings are used to provide two
+   levels of drop precedence indications, with 010 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
+   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
+   aggregate, we recommend the use of 010 for EXP field marking.
+
+A.4.  Elastic Treatment Aggregate with E-LSP
+
+   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
+   precedence indications, with 000 encoded traffic having a lower
+   probability of being dropped than 001 encoded traffic.  This provides
+   for the mapping of Default/CS0 into 000; and CS1 into 001.  Notice
+
+
+
+Chan, et al.                 Informational                     [Page 17]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+   that with this mapping, during congestion, CS1-marked traffic may be
+   starved.  If the domain chooses to support only one drop precedence
+   for this treatment aggregate, we recommend the use of 000 for EXP
+   field marking.
+
+A.5.  Treatment Aggregates and L-LSP
+
+   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.
+   This document does not further specify any additional recommendation
+   (beyond what has been indicated in section 4 of this document) for
+   treatment aggregate to L-LSP mapping, leaving this to each individual
+   MPLS domain administration.
+
+Authors' Addresses
+
+   Kwok Ho Chan
+   Nortel
+   600 Technology Park Drive
+   Billerica, MA  01821
+   US
+
+   Phone: +1-978-288-8175
+   Fax:   +1-978-288-8700
+   EMail: khchan@nortel.com
+
+
+   Jozef Z. Babiarz
+   Nortel
+   3500 Carling Avenue
+   Ottawa, Ont.  K2H 8E9
+   Canada
+
+   Phone: +1-613-763-6098
+   Fax:   +1-613-768-2231
+   EMail: babiarz@nortel.com
+
+
+   Fred Baker
+   Cisco Systems
+   1121 Via Del Rey
+   Santa Barbara, CA  93117
+   US
+
+   Phone: +1-408-526-4257
+   Fax:   +1-413-473-2403
+   EMail: fred@cisco.com
+
+
+
+
+Chan, et al.                 Informational                     [Page 18]
+
+RFC 5127        Aggregation of Diffserv Service Classes    February 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al.                 Informational                     [Page 19]
+