Aggregation of Diffserv Service Classes
RFC 5127

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