tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3270

 Errata 
Proposed STD
Pages: 64
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

Multi-Protocol Label Switching (MPLS) Support of Differentiated Services

Part 1 of 3, p. 1 to 22
None       Next RFC Part

Updates:    3032
Updated by:    5462


Top       ToC       Page 1 
Network Working Group                             F. Le Faucheur, Editor
Request for Comments: 3270                                         L. Wu
Category: Standards Track                                       B. Davie
                                                           Cisco Systems
                                                               S. Davari
                                                         PMC-Sierra Inc.
                                                             P. Vaananen
                                                                   Nokia
                                                             R. Krishnan
                                                       Axiowave Networks
                                                               P. Cheval
                                                                 Alcatel
                                                             J. Heinanen
                                                           Song Networks
                                                                May 2002


                 Multi-Protocol Label Switching (MPLS)
                   Support of Differentiated Services

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines a flexible solution for support of
   Differentiated Services (Diff-Serv) over Multi-Protocol Label
   Switching (MPLS) networks.

   This solution allows the MPLS network administrator to select how
   Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched
   Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic
   Engineering and protection objectives within his/her particular
   network.  For instance, this solution allows the network
   administrator to decide whether different sets of BAs are to be
   mapped onto the same LSP or mapped onto separate LSPs.

Top       Page 2 
Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   1.1  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
   1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6
   1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7
   1.4 Overall Operations. . . . . . . . . . . . . . . . . . . . . . . 7
   1.5 Relationship between Label and FEC. . . . . . . . . . . . . . . 8
   1.6 Bandwidth Reservation for E-LSPs and L-LSPs . . . . . . . . . . 8
   2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models . 9
   2.1 Label Forwarding Model for Diff-Serv LSRs . . . . . . . . . . . 9
   2.2 Incoming PHB Determination. . . . . . . . . . . . . . . . . . .10
   2.3 Outgoing PHB Determination With Optional Traffic Conditioning .11
   2.4 Label Forwarding. . . . . . . . . . . . . . . . . . . . . . . .11
   2.5 Encoding Diff-Serv Information Into Encapsulation Layer . . . .13
   2.6 Diff-Serv Tunneling Models over MPLS. . . . . . . . . . . . . .13
   3. Detailed Operations of E-LSPs. . . . . . . . . . . . . . . . . .22
   3.1 E-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .22
   3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP . .23
   3.3 Incoming PHB Determination On Incoming E-LSP. . . . . . . . . .23
   3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
       E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
   3.5 Encoding Diff-Serv information into Encapsulation Layer On
       Outgoing E-LSP. . . . . . . . . . . . . . . . . . . . . . . . .26
   3.6 E-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .27
   4.  Detailed Operation of L-LSPs. . . . . . . . . . . . . . . . . .28
   4.1 L-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .28
   4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP . .28
   4.3 Incoming PHB Determination On Incoming L-LSP. . . . . . . . . .30
   4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
       L-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
   4.5 Encoding Diff-Serv Information into Encapsulation Layer on
       Outgoing L-LSP. . . . . . . . . . . . . . . . . . . . . . . . .33
   4.6 L-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .34
   5. RSVP Extension for Diff-Serv Support . . . . . . . . . . . . . .34
   5.1 Diff-Serv related RSVP Messages Format. . . . . . . . . . . . .34
   5.2 DIFFSERV Object . . . . . . . . . . . . . . . . . . . . . . . .35
   5.3 Handling DIFFSERV Object. . . . . . . . . . . . . . . . . . . .37
   5.4 Non-support of the DIFFSERV Object. . . . . . . . . . . . . . .40
   5.5 Error Codes For Diff-Serv . . . . . . . . . . . . . . . . . . .40
   5.6 Intserv Service Type. . . . . . . . . . . . . . . . . . . . . .41
   6. LDP Extensions for Diff-Serv Support . . . . . . . . . . . . . .41
   6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . . .42
   6.2 Diff-Serv Status Code Values. . . . . . . . . . . . . . . . . .44
   6.3 Diff-Serv Related LDP Messages. . . . . . . . . . . . . . . . .44
   6.4 Handling of the Diff-Serv TLV . . . . . . . . . . . . . . . . .46
   6.5 Non-Handling of the Diff-Serv TLV . . . . . . . . . . . . . . .49
   6.6 Bandwidth Information . . . . . . . . . . . . . . . . . . . . .49

Top      ToC       Page 3 
   7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and
      Non-LC-FR Interfaces . . . . . . . . . . . . . . . . . . . . . .49
   8. MPLS Support of Diff-Serv over LC-ATM Interfaces . . . . . . . .50
   8.1 Use of ATM Traffic Classes and Traffic Management mechanisms. .50
   8.2 LSR Implementation With LC-ATM Interfaces . . . . . . . . . . .50
   9. MPLS Support of Diff-Serv over LC-FR Interfaces. . . . . . . . .51
   9.1 Use of Frame Relay Traffic parameters and Traffic Management
       mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . .51
   9.2 LSR Implementation With LC-FR Interfaces. . . . . . . . . . . .51
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .52
   11. Security Considerations . . . . . . . . . . . . . . . . . . . .52
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .52
   Appendix A. Example Deployment Scenarios. . . . . . . . . . . . . .53
   Appendix B. Example Bandwidth Reservation Scenarios . . . . . . . .58
   References. . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
   Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .62
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .64

1. Introduction

   In an MPLS domain [MPLS_ARCH], when a stream of data traverses a
   common path, a Label Switched Path (LSP) can be established using
   MPLS signaling protocols.  At the ingress Label Switch Router (LSR),
   each packet is assigned a label and is transmitted downstream.  At
   each LSR along the LSP, the label is used to forward the packet to
   the next hop.

   In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the IP
   packets crossing a link and requiring the same Diff-Serv behavior are
   said to constitute a Behavior Aggregate (BA).  At the ingress node of
   the Diff-Serv domain, the packets are classified and marked with a
   Diff-Serv Code Point (DSCP) which corresponds to their Behavior
   Aggregate.  At each transit node, the DSCP is used to select the Per
   Hop Behavior (PHB) that determines the scheduling treatment and, in
   some cases, drop probability for each packet.

   This document specifies a solution for supporting the Diff-Serv
   Behavior Aggregates whose corresponding PHBs are currently defined
   (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network.  This
   solution also offers flexibility for easy support of PHBs that may be
   defined in the future.

   This solution relies on the combined use of two types of LSPs:

   -  LSPs which can transport multiple Ordered Aggregates, so that the
      EXP field of the MPLS Shim Header conveys to the LSR the PHB to be
      applied to the packet (covering both information about the
      packet's scheduling treatment and its drop precedence).

Top      ToC       Page 4 
   -  LSPs which only transport a single Ordered Aggregate, so that the
      packet's scheduling treatment is inferred by the LSR exclusively
      from the packet's label value while the packet's drop precedence
      is conveyed in the EXP field of the MPLS Shim Header or in the
      encapsulating link layer specific selective drop mechanism (ATM,
      Frame Relay, 802.1).

   As mentioned in [DIFF_HEADER], "Service providers are not required to
   use the same node mechanisms or configurations to enable service
   differentiation within their networks, and are free to configure the
   node parameters in whatever way that is appropriate for their service
   offerings and traffic engineering objectives".  Thus, the solution
   defined in this document gives Service Providers flexibility in
   selecting how Diff-Serv classes of service are Routed or Traffic
   Engineered within their domain (e.g., separate classes of services
   supported via separate LSPs and Routed separately, all classes of
   service supported on the same LSP and Routed together).

   Because MPLS is path-oriented it can potentially provide faster and
   more predictable protection and restoration capabilities in the face
   of topology changes than conventional hop by hop routed IP systems.
   In this document we refer to such capabilities as "MPLS protection".
   Although such capabilities and associated mechanisms are outside the
   scope of this specification, we note that they may offer different
   levels of protection to different LSPs.  Since the solution presented
   here allow Service Providers to choose how Diff-Serv classes of
   services are mapped onto LSPs, the solution also gives Service
   Providers flexibility in the level of protection provided to
   different Diff-Serv classes of service (e.g., some classes of service
   can be supported by LSPs which are protected while some other classes
   of service are supported by LSPs which are not protected).

   Furthermore, the solution specified in this document achieves label
   space conservation and reduces the volume of label set-up/tear-down
   signaling where possible by only resorting to multiple LSPs for a
   given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or
   required.

   This specification allows support of Differentiated Services for both
   IPv4 and IPv6 traffic transported over an MPLS network.  This
   document only describes operations for unicast.  Multicast support is
   for future study.

   The solution described in this document does not preclude the
   signaled or configured use of the EXP bits to support Explicit
   Congestion Notification [ECN] simultaneously with Diff-Serv over
   MPLS.  However, techniques for supporting ECN in an MPLS environment
   are outside the scope of this document.

Top      ToC       Page 5 
1.1  Terminology

   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.

   The reader is assumed to be familiar with the terminology of
   [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR], including the
   following:

      FEC        Forwarding Equivalency Class

      FTN        FEC-To-NHLFE Map

      ILM        Incoming Label Map

      LC-ATM     Label Switching Controlled-ATM (interface)

      LC-FR      Label Switching Controlled-Frame Relay (interface)

      LSP        Label Switched Path

      LSR        Label Switch Router

      MPLS       Multi-Protocol Label Switching

      NHLFE      Next Hop Label Forwarding Entry

   The reader is assumed to be familiar with the terminology of
   [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF], including the
   following:

      AF         Assured Forwarding

      BA         Behavior Aggregate

      CS         Class Selector

      DF         Default Forwarding

      DSCP       Differentiated Services Code Point

      EF         Expedited Forwarding

      PHB        Per Hop Behavior

Top      ToC       Page 6 
   The reader is assumed to be familiar with the terminology of
   [DIFF_NEW], including the following:

      OA        Ordered Aggregate.  The set of Behavior Aggregates which
                share an ordering constraint.

      PSC       PHB Scheduling Class.  The set of one or more PHB(s)
                that are applied to the Behavior Aggregate(s) belonging
                to a given OA.  For example, AF1x is a PSC comprising
                the AF11, AF12 and AF13 PHBs.  EF is an example of PSC
                comprising a single PHB, the EF PHB.

   The following acronyms are also used:

      CLP        Cell Loss Priority

      DE         Discard Eligibility

      SNMP       Simple Network Management Protocol

   Finally, the following acronyms are defined in this specification:

      E-LSP      EXP-Inferred-PSC LSP

      L-LSP      Label-Only-Inferred-PSC LSP

1.2 EXP-Inferred-PSC LSPs (E-LSP)

   A single LSP can be used to support one or more OAs.  Such LSPs can
   support up to eight BAs of a given FEC, regardless of how many OAs
   these BAs span.  With such LSPs, the EXP field of the MPLS Shim
   Header is used by the LSR to determine the PHB to be applied to the
   packet.  This includes both the PSC and the drop preference.

   We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the
   PSC of a packet transported on this LSP depends on the EXP field
   value for that packet.

   The mapping from the EXP field to the PHB (i.e., to PSC and drop
   precedence) for a given such LSP, is either explicitly signaled at
   label set-up or relies on a pre-configured mapping.

   Detailed operations of E-LSPs are specified in section 3 below.

Top      ToC       Page 7 
1.3 Label-Only-Inferred-PSC LSPs (L-LSP)

   A separate LSP can be established for a single <FEC, OA> pair.  With
   such LSPs, the PSC is explicitly signaled at the time of label
   establishment, so that after label establishment, the LSR can infer
   exclusively from the label value the PSC to be applied to a labeled
   packet.  When the Shim Header is used, the Drop Precedence to be
   applied by the LSR to the labeled packet, is conveyed inside the
   labeled packet MPLS Shim Header using the EXP field.  When the Shim
   Header is not used (e.g., MPLS Over ATM), the Drop Precedence to be
   applied by the LSR to the labeled packet is conveyed inside the link
   layer header encapsulation using link layer specific drop precedence
   fields (e.g., ATM CLP).

   We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP) since
   the PSC can be fully inferred from the label without any other
   information (e.g., regardless of the EXP field value).  Detailed
   operations of L-LSPs are specified in section 4 below.

1.4 Overall Operations

   For a given FEC, and unless media specific restrictions apply as
   identified in the sections 7, 8 and 9 below, this specification
   allows any one of the following combinations within an MPLS Diff-Serv
   domain:

      -  zero or any number of E-LSPs, and

      -  zero or any number of L-LSPs.

   The network administrator selects the actual combination of LSPs from
   the set of allowed combinations and selects how the Behavior
   Aggregates are actually transported over this combination of LSPs, in
   order to best match his/her environment and objectives in terms of
   Diff-Serv support, Traffic Engineering and MPLS Protection.  Criteria
   for selecting such a combination are outside the scope of this
   specification.

   For a given FEC, there may be more than one LSP carrying the same OA,
   for example for purposes of load balancing of the OA; However in
   order to respect ordering constraints, all packets of a given
   microflow, possibly spanning multiple BAs of a given Ordered
   Aggregate, MUST be transported over the same LSP.  Conversely, each
   LSP MUST be capable of supporting all the (active) BAs of a given OA.

   Examples of deployment scenarios are provided for information in
   APPENDIX A.

Top      ToC       Page 8 
1.5 Relationship between Label and FEC

   [MPLS_ARCH] states in section `2.1. Overview' that:  `Some routers
   analyze a packet's network layer header not merely to choose the
   packet's next hop, but also to determine a packet's "precedence" or
   "class of service".  They may then apply different discard thresholds
   or scheduling disciplines to different packets.  MPLS allows (but
   does not require) the precedence or class of service to be fully or
   partially inferred from the label.  In this case, one may say that
   the label represents the combination of a FEC and a precedence or
   class of service.'

   In line with this, we observe that:

   -  With E-LSPs, the label represents the combination of a FEC and the
      set of BAs transported over the E-LSP.  Where all the supported
      BAs are transported over an E-LSP, the label then represents the
      complete FEC.

   -  With L-LSPs, the label represents the combination of a FEC and an
      OA.

1.6 Bandwidth Reservation for E-LSPs and L-LSPs

   Regardless of which label binding protocol is used, E-LSPs and L-LSPs
   may be established with or without bandwidth reservation.

   Establishing an E-LSP or L-LSP with bandwidth reservation means that
   bandwidth requirements for the LSP are signaled at LSP establishment
   time.  Such signaled bandwidth requirements may be used by LSRs at
   establishment time to perform admission control of the signaled LSP
   over the Diff-Serv resources provisioned (e.g., via configuration,
   SNMP or policy protocols) for the relevant PSC(s).  Such signaled
   bandwidth requirements may also be used by LSRs at establishment time
   to perform adjustment to the Diff-Serv resources associated with the
   relevant PSC(s) (e.g., adjust PSC scheduling weight).

   Note that establishing an E-LSP or L-LSP with bandwidth reservation
   does not mean that per-LSP scheduling is required.  Since E-LSPs and
   L-LSPs are specified in this document for support of Differentiated
   Services, the required forwarding treatment (scheduling and drop
   policy) is defined by the appropriate Diff-Serv PHB.  This forwarding
   treatment MUST be applied by the LSR at the granularity of the BA and
   MUST be compliant with the relevant PHB specification.

Top      ToC       Page 9 
   When bandwidth requirements are signaled at the establishment of an
   L-LSP, the signaled bandwidth is obviously associated with the L-
   LSP's PSC.  Thus, LSRs which use the signaled bandwidth to perform
   admission control may perform admission control over Diff-Serv
   resources, which are dedicated to the PSC (e.g., over the bandwidth
   guaranteed to the PSC through its scheduling weight).

   When bandwidth requirements are signaled at the establishment of an
   E-LSP, the signaled bandwidth is associated collectively with the
   whole LSP and therefore with the set of transported PSCs.  Thus, LSRs
   which use the signaled bandwidth to perform admission control may
   perform admission control over global resources, which are shared by
   the set of PSCs (e.g., over the total bandwidth of the link).

   Examples of scenarios where bandwidth reservation is not used and
   scenarios where bandwidth reservation is used are provided for
   information in APPENDIX B.

2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models

2.1 Label Forwarding Model for Diff-Serv LSRs

   Since different Ordered Aggregates of a given FEC may be transported
   over different LSPs, the label swapping decision of a Diff-Serv LSR
   clearly depends on the forwarded packet's Behavior Aggregate.  Also,
   since the IP DS field of a forwarded packet may not be directly
   visible to an LSR, the way to determine the PHB to be applied to a
   received packet and to encode the PHB into a transmitted packet, is
   different than a non-MPLS Diff-Serv Router.

   Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we
   model the LSR Diff-Serv label switching behavior, comprised of four
   stages:

   -  Incoming PHB Determination (A)

   -  Outgoing PHB Determination with Optional Traffic Conditioning(B)

   -  Label Forwarding (C)

   -  Encoding of Diff-Serv information into Encapsulation Layer (EXP,
      CLP, DE, User_Priority)  (D)

   Each stage is described in more detail in the following sections.

   Obviously, to enforce the Diff-Serv service differentiation the LSR
   MUST also apply the forwarding treatment corresponding to the
   Outgoing PHB.

Top      ToC       Page 10 
   This model is illustrated below:

   --Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)-->
     \                                       I   I \
      \---->I===I                            I C I  \-->I===I--Encaps->
            I A I           I===I--Outg_PHB->I===I      I D I   (&)
   -Encaps->I===I--Inc_PHB->I B I         \          /->I===I
      (*)                   I===I          \--------+
                                                     \----Forwarding-->
                                                           Treatment
                                                             (PHB)

   "Encaps" designates the Diff-Serv related information encoded in the
   MPLS Encapsulation layer (e.g., EXP field, ATM CLP, Frame Relay DE,
   802.1 User_Priority)

   (*) when the LSR behaves as an MPLS ingress node, the incoming packet
   may be received unlabelled.

   (&) when the LSR behaves as an MPLS egress node, the outgoing packet
   may be transmitted unlabelled.

   This model is presented here to describe the functional operations of
   Diff-Serv LSRs and does not constrain actual implementation.

2.2 Incoming PHB Determination

   This stage determines which Behavior Aggregate the received packet
   belongs to.

2.2.1 Incoming PHB Determination Considering a Label Stack Entry

   Sections 3.3 and 4.3 provide the details on how to perform incoming
   PHB Determination considering a given received label stack entry
   and/or received incoming MPLS encapsulation information depending on
   the incoming LSP type and depending on the incoming MPLS
   encapsulation.

   Section 2.6 provides the details of which label stack entry to
   consider for the Incoming PHB Determination depending on the
   supported Diff-Serv tunneling mode.

2.2.2 Incoming PHB Determination Considering IP Header

   Section 2.6 provides the details of when the IP Header is to be
   considered for incoming PHB determination, depending on the supported
   Diff-Serv tunneling model.  In those cases where the IP header is to

Top      ToC       Page 11 
   be used, this stage operates exactly as with a non-MPLS IP Diff-Serv
   Router and uses the DS field to determine the incoming PHB.

2.3 Outgoing PHB Determination With Optional Traffic Conditioning

   The traffic conditioning stage is optional and may be used on an LSR
   to perform traffic conditioning including Behavior Aggregate demotion
   or promotion.  It is outside the scope of this specification.  For
   the purpose of specifying Diff-Serv over MPLS forwarding, we simply
   note that the PHB to be actually enforced and conveyed to downstream
   LSRs by an LSR (referred to as "outgoing PHB"), may be different to
   the PHB which had been associated with the packet by the previous LSR
   (referred to as "incoming PHB").

   When the traffic conditioning stage is not present, the "outgoing
   PHB" is simply identical to the "incoming PHB".

2.4 Label Forwarding

   [MPLS_ARCH] describes how label swapping is performed by LSRs on
   incoming labeled packets using an Incoming Label Map (ILM), where
   each incoming label is mapped to one or multiple NHLFEs.  [MPLS_ARCH]
   also describes how label imposition is performed by LSRs on incoming
   unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each
   incoming FEC is mapped to one or multiple NHLFEs.

   A Diff-Serv Context for a label is comprised of:

   -  `LSP type (i.e., E-LSP or L-LSP)'

   -  `supported PHBs'

   -  `Encaps-->PHB mapping' for an incoming label

   -  `Set of PHB-->Encaps mappings' for an outgoing label

   The present specification defines that a Diff-Serv Context is stored
   in the ILM for each incoming label.

   [MPLS_ARCH] states that the `NHLFE may also contain any other
   information needed in order to properly dispose of the packet'.  In
   accordance with this, the present specification defines that a Diff-
   Serv Context is stored in the NHLFE for each outgoing label that is
   swapped or pushed.

   This Diff-Serv Context information is populated into the ILM and the
   FTN at label establishment time.

Top      ToC       Page 12 
   If the label corresponds to an E-LSP for which no `EXP<-->PHB
   mapping' has been explicitly signaled at LSP setup, the `supported
   PHBs' is populated with the set of PHBs of the preconfigured
   `EXP<-->PHB mapping', which is discussed below in section 3.2.1.

   If the label corresponds to an E-LSP for which an `EXP<-->PHB
   mapping' has been explicitly signaled at LSP setup, the `supported
   PHBs' is populated with the set of PHBs of the signaled `EXP<-->PHB
   mapping'.

   If the label corresponds to an L-LSP, the `supported PHBs' is
   populated with the set of PHBs forming the PSC that is signaled at
   LSP set-up.

   The details of how the `Encaps-->PHB mapping' or `Set of PHB-->Encaps
   mappings' are populated are defined below in sections 3 and 4.

   [MPLS_ARCH] also states that:

   "If the ILM [respectively, FTN] maps a particular label to a set of
   NHLFEs that contain more than one element, exactly one element of the
   set must be chosen before the packet is forwarded.  The procedures
   for choosing an element from the set are beyond the scope of this
   document.  Having the ILM [respectively, FTN] map a label
   [respectively, a FEC] to a set containing more than one NHLFE may be
   useful if, e.g., it is desired to do load balancing over multiple
   equal-cost paths."

   In accordance with this, the present specification allows that an
   incoming label [respectively FEC] may be mapped, for Diff-Serv
   purposes, to multiple NHLFEs (for instance where different NHLFEs
   correspond to egress labels supporting different sets of PHBs).  When
   a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR
   MUST choose one of the NHLFEs whose Diff-Serv Context indicates that
   it supports the Outgoing PHB of the forwarded packet.

   When a label [respectively FEC] maps to multiple NHLFEs which support
   the Outgoing PHB, the procedure for choosing one among those is
   outside the scope of this document.  This situation may be
   encountered where it is desired to do load balancing of a Behavior
   Aggregate over multiple LSPs.  In such situations, in order to
   respect ordering constraints, all packets of a given microflow MUST
   be transported over the same LSP.

Top      ToC       Page 13 
2.5 Encoding Diff-Serv Information Into Encapsulation Layer

   This stage determines how to encode the fields which convey Diff-Serv
   information in the transmitted packet (e.g., MPLS Shim EXP, ATM CLP,
   Frame Relay DE, 802.1 User_Priority).

2.5.1 Encoding Diff-Serv Information Into Transmitted Label Entry

   Sections 3.5 and 4.5 provide the details on how to perform Diff-Serv
   information encoding into a given transmitted label stack entry
   and/or transmitted MPLS encapsulation information depending on the
   corresponding outgoing LSP type and depending on the MPLS
   encapsulation.

   Section 2.6 provides the details in which label stack entry to
   perform Diff-Serv information encoding into depending on the
   supported Diff-Serv tunneling mode.

2.5.2 Encoding Diff-Serv Information Into Transmitted IP Header

   To perform Diff-Serv Information Encoding into the transmitted packet
   IP header, this stage operates exactly as with a non-MPLS IP Diff-
   Serv Router and encodes the DSCP of the Outgoing PHB into the DS
   field.

   Section 2.6 provides the details of when Diff-Serv Information
   Encoding is to be performed into transmitted IP header depending on
   the supported Diff-Serv tunneling mode.

2.6 Diff-Serv Tunneling Models over MPLS

2.6.1 Diff-Serv Tunneling Models

   [DIFF_TUNNEL] considers the interaction of Differentiated Services
   with IP tunnels of various forms.  MPLS LSPs are not a form of "IP
   tunnels" since the MPLS encapsulating header does not contain an IP
   header and thus MPLS LSPs are not considered in [DIFF_TUNNEL].
   However, although not a form of "IP tunnel", MPLS LSPs are a form of
   "tunnel".

   From the Diff-Serv standpoint, LSPs share a number of common
   characteristics with IP Tunnels:

   -  Intermediate nodes (i.e., Nodes somewhere along the LSP span) only
      see and operate on the "outer" Diff-Serv information.

   -  LSPs are unidirectional.

Top      ToC       Page 14 
   -  The "outer" Diff-Serv information can be modified at any of the
      intermediate nodes.

   However, from the Diff-Serv standpoint, LSPs also have a distinctive
   property compared to IP Tunnels:

   -  There is generally no behavior analogous to Penultimate Hop
      Popping (PHP) used with IP Tunnels.  Furthermore, PHP results in
      the "outer" Diff-Serv information associated with the LSP not
      being visible to the LSP egress.  In situations where this
      information is not meaningful at the LSP Egress, this is obviously
      not an issue at all.  In situations where this information is
      meaningful at the LSP Egress, then it must somehow be carried in
      some other means.

   The two conceptual models for Diff-Serv tunneling over IP Tunnels
   defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over
   MPLS but their respective detailed operations is somewhat different
   over MPLS.  These two models are the Pipe Model and the Uniform
   Model.  Their operations over MPLS are specified in the following
   sections.  Discussion and definition of alternative tunneling models
   are outside the scope of this specification.

2.6.2 Pipe Model

   With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide the
   intermediate MPLS nodes between LSP Ingress and Egress from the
   Diff-Serv perspective.

   In this model, tunneled packets must convey two meaningful pieces of
   Diff-Serv information:

   -  the Diff-Serv information which is meaningful to intermediate
      nodes along the LSP span including the LSP Egress (which we refer
      to as the "LSP Diff-Serv Information").  This LSP Diff-Serv
      Information is not meaningful beyond the LSP Egress: Whether
      Traffic Conditioning at intermediate nodes on the LSP span affects
      the LSP Diff-Serv information or not, this updated Diff-Serv
      information is not considered meaningful beyond the LSP Egress and
      is ignored.

   -  the Diff-Serv information which is meaningful beyond the LSP
      Egress (which we refer to as the "Tunneled Diff-Serv
      Information").  This information is to be conveyed by the LSP
      Ingress to the LSP Egress.  This Diff-Serv information is not
      meaningful to the intermediate nodes on the LSP span.

Top      ToC       Page 15 
   Operation of the Pipe Model without PHP is illustrated below:

            ========== LSP =============================>

                ---Swap--(M)--...--Swap--(M)--Swap----
               /        (outer header)                \
             (M)                                      (M)
             /                                          \
   >--(m)-Push.................(m).....................Pop--(m)-->
            I             (inner header)                E   (M*)

   (M) represents the "LSP Diff-Serv information"
   (m) represents the "Tunneled Diff-Serv information"
   (*) The LSP Egress considers the LSP Diff-Serv information received
       in the outer header (i.e., before the pop) in order to apply its
       Diff-Serv forwarding treatment (i.e., actual PHB)
    I  represents the LSP ingress node
    E  represents the LSP egress node

   With the Pipe Model, the "LSP Diff-Serv Information" needs to be
   conveyed to the LSP Egress so that it applies its forwarding
   treatment based on it.  The "Tunneled Diff-Serv information" also
   needs to be conveyed to the LSP Egress so it can be conveyed further
   downstream.

   Since both require that Diff-Serv information be conveyed to the LSP
   Egress, the Pipe Model operates only without PHP.

   The Pipe Model is particularly appropriate for environments in which:

   -  the cloud upstream of the incoming interface of the LSP Ingress
      and the cloud downstream of the outgoing interface of the LSP
      Egress are in Diff-Serv domains which use a common set of Diff-
      Serv service provisioning policies and PHB definitions, while the
      LSP spans one (or more) Diff-Serv domain(s) which use(s) a
      different set of Diff-Serv service provisioning policies and PHB
      definitions

   -  the outgoing interface of the LSP Egress is in the (last) Diff-
      Serv domain spanned by the LSP.

   As an example, consider the case where a service provider is offering
   an MPLS VPN service (see [MPLS_VPN] for an example of MPLS VPN
   architecture) including Diff-Serv differentiation.  Say that a
   collection of sites is interconnected via such an MPLS VPN service.
   Now say that this collection of sites is managed under a common
   administration and is also supporting Diff-Serv service
   differentiation.  If the VPN site administration and the Service

Top      ToC       Page 16 
   Provider are not sharing the exact same Diff-Serv policy (for
   instance not supporting the same number of PHBs), then operation of
   Diff-Serv in the Pipe Model over the MPLS VPN service would allow the
   VPN Sites Diff-Serv policy to operate consistently throughout the
   ingress VPN Site and Egress VPN Site and transparently over the
   Service Provider Diff-Serv domain.  It may be useful to view such
   LSPs as linking the Diff-Serv domains at their endpoints into a
   single Diff-Serv region by making these endpoints virtually
   contiguous even though they may be physically separated by
   intermediate network nodes.

   The Pipe Model MUST be supported.

   For support of the Pipe Model over a given LSP without PHP, an LSR
   performs the Incoming PHB Determination and the Diff-Serv information
   Encoding in the following manner:

   -  when receiving an unlabelled packet, the LSR performs Incoming PHB
      Determination considering the received IP Header.

   -  when receiving a labeled packet, the LSR performs Incoming PHB
      Determination considering the outer label entry in the received
      label stack.  In particular, when a pop operation is to be
      performed for the considered LSP, the LSR performs Incoming PHB
      Determination BEFORE the pop.

   -  when performing a push operation for the considered LSP, the LSR:

      o  encodes Diff-Serv Information corresponding to the OUTGOING PHB
         in the transmitted label entry corresponding to the pushed
         label.

      o  encodes Diff-Serv Information corresponding to the INCOMING PHB
         in the encapsulated header (swapped label entry or IP header).

   -  when performing a swap-only operation for the considered LSP, the
      LSR encodes Diff-Serv Information in the transmitted label entry
      that contains the swapped label

   -  when performing a pop operation for the considered LSP, the LSR
      does not perform Encoding of Diff-Serv Information into the header
      exposed by the pop operation (i.e., the LSR leaves the exposed
      header "as is").

2.6.2.1 Short Pipe Model

   The Short Pipe Model is an optional variation of the Pipe Model
   described above.  The only difference is that, with the Short Pipe

Top      ToC       Page 17 
   Model, the Diff-Serv forwarding treatment at the LSP Egress is
   applied based on the "Tunneled Diff-Serv Information" (i.e., Diff-
   Serv information conveyed in the encapsulated header) rather than on
   the "LSP Diff-Serv information" (i.e., Diff-Serv information conveyed
   in the encapsulating header).

   Operation of the Short Pipe Model without PHP is illustrated below:

            ========== LSP =============================>

                ---Swap--(M)--...--Swap--(M)--Swap----
               /        (outer header)                \
             (M)                                      (M)
             /                                          \
   >--(m)-Push.................(m).....................Pop--(m)-->
            I             (inner header)                E

   (M) represents the "LSP Diff-Serv information"
   (m) represents the "Tunneled Diff-Serv information"
    I  represents the LSP ingress node
    E  represents the LSP egress node

   Since the LSP Egress applies its forwarding treatment based on the
   "Tunneled Diff-Serv Information", the "LSP Diff-Serv information"
   does not need to be conveyed by the penultimate node to the LSP
   Egress.  Thus the Short Pipe Model can also operate with PHP.

   Operation of the Short Pipe Model with PHP is illustrated below:

           =========== LSP ============================>

                ---Swap--(M)--...--Swap------
               /       (outer header)        \
             (M)                             (M)
             /                                 \
   >--(m)-Push.................(m).............Pop-(m)--E--(m)-->
           I           (inner header)           P (M*)

   (M) represents the "LSP Diff-Serv information"
   (m) represents the "Tunneled Diff-Serv information"
   (*) The Penultimate LSR considers the LSP Diff-Serv information
       received in the outer header (i.e., before the pop) in order to
       apply its Diff-Serv forwarding treatment (i.e., actual PHB)
    I  represents the LSP ingress node
    P  represents the LSP penultimate node
    E  represents the LSP egress node

Top      ToC       Page 18 
   The Short Pipe Model is particularly appropriate for environments in
   which:

   -  the cloud upstream of the incoming interface of the LSP Ingress
      and the cloud downstream of the outgoing interface of the LSP
      Egress are in Diff-Serv domains which use a common set of Diff-
      Serv service provisioning policies and PHB definitions, while the
      LSP spans one (or more) Diff-Serv domain(s) which use(s) a
      different set of Diff-Serv service provisioning policies and PHB
      definitions

   -  the outgoing interface of the LSP Egress is in the same Diff-Serv
      domain as the cloud downstream of it.

   Since each outgoing interface of the LSP Egress is in the same Diff-
   Serv domain as the cloud downstream of it, each outgoing interface
   may potentially be in a different Diff-Serv domain, and the LSP
   Egress needs to be configured with awareness of every corresponding
   Diff-Serv policy.  This operational overhead is justified in some
   situations where the respective downstream Diff-Serv policies are
   better suited to offering service differentiation over each egress
   interface than the common Diff-Serv policy used on the LSP span.  An
   example of such a situation is where a Service Provider offers an
   MPLS VPN service and where some VPN users request that their own VPN
   Diff-Serv policy be applied to control service differentiation on the
   dedicated link from the LSP Egress to the destination VPN site,
   rather than the Service Provider's Diff-Serv policy.

   The Short Pipe Model MAY be supported.

   For support of the Short Pipe Model over a given LSP without PHP, an
   LSR performs the Incoming PHB Determination and the Diff-Serv
   information Encoding in the same manner as with the Pipe Model with
   the following exception:

   -  when receiving a labeled packet, the LSR performs Incoming PHB
      Determination considering the header (label entry or IP header)
      which is used to do the actual forwarding.  In particular, when a
      pop operation is to be performed for the considered LSP, the LSR
      performs Incoming PHB Determination AFTER the pop.

   For support of the Short Pipe Model over a given LSP with PHP, an LSR
   performs Incoming PHB Determination and Diff-Serv information
   Encoding in the same manner as without PHP with the following
   exceptions:

Top      ToC       Page 19 
   -  the Penultimate LSR performs Incoming PHB Determination
      considering the outer label entry in the received label stack.  In
      other words, when a pop operation is to be performed for the
      considered LSP, the Penultimate LSR performs Incoming PHB
      Determination BEFORE the pop.

   Note that the behavior of the Penultimate LSR in the Short Pipe Mode
   with PHP, is identical to the behavior of the LSP Egress in the Pipe
   Mode (necessarily without PHP).

2.6.3 Uniform Model

   With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as
   artifacts of the end-to-end path from the Diff-Serv standpoint.  MPLS
   Tunnels may be used for forwarding purposes but have no significant
   impact on Diff-Serv.  In this model, any packet contains exactly one
   piece of Diff-Serv information which is meaningful and is always
   encoded in the outer most label entry (or in the IP DSCP where the IP
   packet is transmitted unlabelled for instance at the egress of the
   LSP).  Any Diff-Serv information encoded somewhere else (e.g., in
   deeper label entries) is of no significance to intermediate nodes or
   to the tunnel egress and is ignored.  If Traffic Conditioning at
   intermediate nodes on the LSP span affects the "outer" Diff-Serv
   information, the updated Diff-Serv information is the one considered
   meaningful at the egress of the LSP.

   Operation of the Uniform Model without PHP is illustrated below:

             ========== LSP =============================>

                 ---Swap--(M)--...-Swap--(M)--Swap----
                /         (outer header)              \
              (M)                                     (M)
              /                                         \
   >--(M)--Push...............(x).......................Pop--(M)->
            I            (inner header)                  E

   (M) represents the Meaningful Diff-Serv information encoded in the
       corresponding header.
   (x) represents non-meaningful Diff-Serv information.
    I  represents the LSP ingress node
    E  represents the LSP egress node

Top      ToC       Page 20 
   Operation of the Uniform Model with PHP is illustrated below:

             ========== LSP =========================>

                 ---Swap-(M)-...-Swap------
                /        (outer header)    \
              (M)                          (M)
              /                              \
   >--(M)--Push..............(x)............Pop-(M)--E--(M)->
             I          (inner header)       P

   (M) represents the Meaningful Diff-Serv information encoded in the
       corresponding header.
   (x) represents non-meaningful Diff-Serv information.
    I  represents the LSP ingress node
    P  represents the LSP penultimate node
    E  represents the LSP egress node

   The Uniform Model for Diff-Serv over MPLS is such that, from the
   Diff-Serv perspective, operations are exactly identical to the
   operations if MPLS was not used.  In other words, MPLS is entirely
   transparent to the Diff-Serv operations.

   Use of the Uniform Model allows LSPs to span Diff-Serv domain
   boundaries without any other measure in place than an inter-domain
   Traffic Conditioning Agreement at the physical boundary between the
   Diff-Serv domains and operating exclusively on the "outer" header,
   since the meaningful Diff-Serv information is always visible and
   modifiable in the outmost label entry.

   The Uniform Model MAY be supported.

   For support of the Uniform Model over a given LSP, an LSR performs
   Incoming PHB Determination and Diff-Serv information Encoding in the
   following manner:

   -  when receiving an unlabelled packet, the LSR performs Incoming PHB
      Determination considering the received IP Header.

   -  when receiving a labeled packet, the LSR performs Incoming PHB
      Determination considering the outer label entry in the received
      label stack.  In particular, when a pop operation is to be
      performed for the considered LSP, the LSR performs Incoming PHB
      Determination BEFORE the pop.

Top      ToC       Page 21 
   -  when performing a push operation for the considered LSP, the LSR
      encodes Diff-Serv Information in the transmitted label entry
      corresponding to the pushed label.  The Diff-Serv Information
      encoded in the encapsulated header (swapped label entry or IP
      Header) is of no importance.

   -  when performing a swap-only operation for the considered LSP, the
      LSR encodes Diff-Serv Information in the transmitted label entry
      that contains the swapped label.

   -  when PHP is used, the Penultimate LSR needs to be aware of the
      "Set of PHB-->Encaps mappings" for the label corresponding to the
      exposed header (or the `PHB-->DSCP mapping') in order to perform
      Diff-Serv Information Encoding.  Methods for providing this
      mapping awareness are outside the scope of this specification.  As
      an example, the "PHB-->DSCP mapping" may be locally configured.
      As another example, in some environments, it may be appropriate
      for the Penultimate LSR to assume that the "Set of PHB-->Encaps
      mappings" to be used for the outgoing label in the exposed header
      is the "Set of PHB-->Encaps mappings" that would be used by the
      LSR if the LSR was not doing PHP.  Note also that this
      specification assumes that the Penultimate LSR does not perform
      label swapping over the label entry exposed by the pop operation
      (and in fact that it does not even look at the exposed label).
      Consequently, restrictions may apply to the Diff-Serv Information
      Encoding that can be performed by the Penultimate LSR.  For
      example, this specification does not allow situations where the
      Penultimate LSR pops a label corresponding to an E-LSP supporting
      two PSCs, while the header exposed by the pop contains label
      values for two L-LSPs each supporting one PSC, since the Diff-Serv
      Information Encoding would require selecting one label or the
      other.

   Note that LSR behaviors for the Pipe, the Short Pipe and the Uniform
   Model only differ when doing a push or a pop.  Thus, Intermediate
   LSRs which perform swap only operations for an LSP, behave in exactly
   the same way, regardless of whether they are behaving in the Pipe,
   Short Pipe or the Uniform model.  With a Diff-Serv implementation
   supporting multiple Tunneling Models, only LSRs behaving as LSP
   Ingress, Penultimate LSR or LSP Egress need to be configured to
   operate in a particular Model.  Signaling to associate a Diff-Serv
   tunneling model on a per-LSP basis is not within the scope of this
   specification.

Top      ToC       Page 22 
2.6.4 Hierarchy

   Through the label stack mechanism, MPLS allows LSP tunneling to nest
   to any depth.  We observe that with such nesting, the push of level
   N+1 takes place on a subsequent (or the same) LSR to the LSR doing
   the push for level N, while the pop of level N+1 takes place on a
   previous (or the same) LSR to the LSR doing the pop of level N.  For
   a given level N LSP, the Ingress LSR doing the push and the LSR doing
   the pop (Penultimate LSR or LSP Egress) must operate in the same
   Tunneling Model (i.e., Pipe, Short Pipe or Uniform).  However, there
   is no requirement for consistent tunneling models across levels so
   that LSPs at different levels may be operating in different Tunneling
   Models.

   Hierarchical operations are illustrated below in the case of two
   levels of tunnels:

               +--------Swap--...---+
              /    (outmost header)  \
             /                        \
           Push(2).................(2)Pop
           / (outer header)             \
          /                              \
   >>---Push(1)........................(1)Pop-->>
             (inner header)

   (1) Tunneling Model 1
   (2) Tunneling Model 2

   Tunneling Model 2 may be the same as or may be different from
   Tunneling Model 1.

   For a given LSP of level N, the LSR must perform the Incoming PHB
   Determination and the Diff-Serv information Encoding as specified in
   section 2.6.2, 2.6.2.1 and 2.6.3 according to the Tunneling Model of
   this level N LSP and independently of the Tunneling Model of other
   level LSPs.



(page 22 continued on part 2)

Next RFC Part