GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5127

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

  1. ——————————————————————–

|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 | | | |

  1. ——————————————————————–
      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.
  1. ———————————————————–

|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

  1. ——————————————

|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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5127.txt · Last modified: 2008/02/15 00:03 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki