Francois Le Faucheur
                                                                Liwen Wu
                                                             Bruce Davie
                                                           Cisco Systems

                                                          Shahram Davari
                                                         PMC-Sierra Inc.

                                                           Pasi Vaananen
                                                                   Nokia

                                                            Ram Krishnan
                                                        Nexabit Networks

                                                         Pierrick Cheval
                                                                 Alcatel

                                                           Juha Heinanen
                                                           Telia Finland

IETF Internet Draft
Expires: December, 2000 January, 2001
Document: draft-ietf-mpls-diff-ext-05.txt              June, draft-ietf-mpls-diff-ext-06.txt              July, 2000

                MPLS Support of Differentiated Services

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are Working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Le Faucheur, et. al                                                  1
                      MPLS Support of Diff-Serv              July 2000

Abstract

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

Le Faucheur, et. al                                                  1
                      MPLS Support of Diff-Serv              June 2000

   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 Fast Restoration 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.

   This solution relies on 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).
     - 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).

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.

   As mentioned in [DIFF_HEADER], "Service providers are not required

 Le Faucheur et. al                                                  2
                      MPLS Support of Diff-Serv              July 2000

   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

 Le Faucheur et. al                                                  2
                      MPLS Support of Diff-Serv              June 2000
   or Traffic Engineered within their domain (eg. (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).
   Similarly,

   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 how the level of protection provided to
   different Diff-Serv classes of service can be protected via MPLS Fast
   Restoration (eg. (e.g. some classes of service
   can be supported via by LSPs which are protected via MPLS Fast Restoration while some other
   classes of service are supported via 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.

1.1  Ordered Aggregate (OA) and PHB Scheduling Class (PSC)

   The Diff-Serv model defines [DIFF_NEW] solution described in this document does not preclude the set
   signaled or configured use of Behavior
   Aggregates which share an ordering constraint the EXP bits to constitute support Explicit
   Congestion Notification [ECN] simultaneously with Diff-Serv over
   MPLS. However, techniques for supporting ECN in an
   "Ordered Aggregate (OA)". It also defines MPLS environment
   are outside the set scope of one or more
   PHBs that are applied to this set of Behavior Aggregates document.

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
   constitute a "PHB Scheduling Class (PSC)".

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

   A single LSP can be used to support up interpreted as described in RFC 2119.

   The reader is assumed to eight BAs of a given FEC,
   regardless be familiar with the terminology of how many OAs these BAs
   [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM] and [MPLS_FR] including the
   following:

     EXP        EXPerimental (bits)

 Le Faucheur et. al                                                  3
                      MPLS Support of Diff-Serv              July 2000

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

   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

 Le Faucheur et. al                                                  4
                      MPLS Support of Diff-Serv              July 2000

     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 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 [MPLS_ENCAPS] 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 EXP field to PHB (ie 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.

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 label
   establishment time so that, after label establishment, the LSR can
   infer exclusively from the label value the PSC to be applied to a

 Le Faucheur et. al                                                  3
                      MPLS Support of Diff-Serv              June 2000
   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 [MPLS_ENCAPS]. field. When the Shim
   Header is not used (eg. (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 (eg. (e.g. ATM Cell Loss Priority). 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 (eg. (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, 9 8 and 10 9 below, this specification

 Le Faucheur et. al                                                  5
                      MPLS Support of Diff-Serv              July 2000

   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 Fast Restoration. MPLS Protection.
   Criteria for selecting such a combination are outside the scope of
   this specification; However in order to respect ordering
   constraints, all packets of 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) PHBs BAs of a given PSC.
   OA.

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

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 Behavior Aggregates (BAs) BAs transported over the E-

 Le Faucheur et. al                                                  4
                      MPLS Support of Diff-Serv              June 2000

       LSP). 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 Ordered Aggregate (OA). 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 without bandwidth reservation or with
   bandwidth reservation.

   Establishing an E-LSP or L-LSP with bandwidth reservation means that
   bandwidth requirements for the LSP are signaled at LSP establishment

 Le Faucheur et. al                                                  6
                      MPLS Support of Diff-Serv              July 2000

   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 COPS) 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 necessarily 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.

   When bandwidth requirements are signaled at 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 establishment of an
   E-LSP, the signaled bandwidth is associated collectively to the
   whole LSP and therefore to 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.

 Le Faucheur et. al                                                  5
                      MPLS Support of Diff-Serv              June 2000

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 to 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 as comprising four
   stages:
     - Incoming PHB Determination (A)

 Le Faucheur et. al                                                  7
                      MPLS Support of Diff-Serv              July 2000

     - Optional Outgoing PHB Determination via Local Policy and with Optional Traffic
       Conditioning (B) Conditioning(B)
     - Label Swapping (C)
     - Encoding of Diff-Serv information into Encapsulation Layer (EXP,
       CLP, DE, User_Priority)  (D)

   Each stage is described in more details 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.

   This model is illustrated below:

   --Inc_label(*)--------------------------->I===I---Outg_label (**)-->
     \                                       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 (eg EXP field, ATM CLP, Frame Relay DE,
   802.1 User_Priority)

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

   (**) when the LSR performs label disposition, behaves as an MPLS egress node, the outgoing
   packet is may be transmitted unlabelled.

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

 Le Faucheur et. al                                                  6
                      MPLS Support of Diff-Serv              June 2000

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 corresponding to the considered stack entry 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.

 Le Faucheur et. al                                                  8
                      MPLS Support of Diff-Serv              July 2000

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 mode. model. In those cases where the IP header is to
   be used, this stage operates exactly as with a non-MPLS IP Diff-Serv
   Router and uses the DS field to determine incoming PHB.

2.3 Optional Outgoing PHB Determination Via Local Policy And With Optional Traffic Conditioning

   This

   The traffic conditioning stage of Diff-Serv label switching 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 this the traffic conditioning stage is not present, the "outgoing
   PHB" is simply identical to the "incoming PHB".

2.4 Label Swapping

   [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 defined as comprising:
     - `LSP type (ie E-LSP or L-LSP)'
     - `supported PHBs'

 Le Faucheur et. al                                                  7
                      MPLS Support of Diff-Serv              June 2000
     - `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 which is
   swapped or pushed.

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

   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

 Le Faucheur et. al                                                  9
                      MPLS Support of Diff-Serv              July 2000

   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 contains 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
   supports the Outgoing PHB, the procedure for choosing one among

 Le Faucheur et. al                                                  8
                      MPLS Support of Diff-Serv              June 2000
   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.

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 (eg. (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

 Le Faucheur et. al                                                 10
                      MPLS Support of Diff-Serv              July 2000

   corresponding outgoing LSP type and depending on the MPLS
   encapsulation.

   Section 2.6 provides the details of 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

   This paragraph defines how to perform Diff-Serv Information Encoding
   into the transmitted packet 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 Terminology

   As per [MPLS_ARCH],
   "we can speak of the level m LSP for Packet P as Diff-Serv Tunneling Models

   [DIFF_TUNNEL] considers the sequence interaction of
   routers:

     1. which begins Differentiated Services
   with an LSR (an "LSP Ingress") that pushes on a
       level m label,
     2. all of whose intermediate LSRs make their forwarding decision
       by label Switching on a level m label,
     3. which ends (at an "LSP Egress") when a forwarding decision is
       made by label Switching on a level m-k label, where k>0, or when

 Le Faucheur et. al                                                  9
                      MPLS Support of Diff-Serv              June 2000

       a forwarding decision is made by "ordinary", non-MPLS forwarding
       procedures."

   We note that if Penultimate Hop Popping (PHP) is used on the LSP,
   the label pop for the LSP is not performed by the LSP Egress but
   instead is performed by the Penultimate LSR. If PHP is not used,
   then the label pop for the LSP is performed by the LSP Egress.

   In all the figures below, (I) indicates "LSP Ingress", (P) indicates
   "LSP Penultimate Hop" and (E) indicates "LSP Egress".

2.6.2 Diff-Serv Tunneling Models

   [DIFF_TUNNEL] considers the interaction of Differentiated Services
   with IP tunnels 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 thus clearly out of the scope of 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 lot of characteristics
   with IP Tunnels:
     - intermediate Intermediate nodes (ie. (i.e. Nodes somewhere along the LSP span)
       only see and operate on the "outer" Diff-Serv information.
     - LSPs are unidirectional unidirectional.
     - the The "outer" Diff-Serv information can be modified at any
       intermediate nodes.

   However, from the Diff-Serv standpoint, LSPs also have a number of
   distinctive properties property compared to IP Tunnels:
     - There is generally no behavior analogous to Penultimate Hop
       Popping (PHP)
       for 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.
     - Two-level hierarchical LSPs with the two nested LSPs starting on
       the same Ingress LSR and finishing on the same Egress LSR, are
       expected to be commonplace in MPLS networks for applications
       such as MPLS VPNs [MPLS_VPN].

   Based on these considerations, it is clear that the

   The two important conceptual models for Diff-Serv tunneling over IP Tunnels
   defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over
   MPLS and
   that but their respective detailed operations is somewhat different
   over MPLS. These two models are the Uniform Model and the Pipe Model and
   their operations over MPLS is described in the following sections.

2.6.3 Uniform Model

 Le Faucheur et. al                                                 10                                                 11
                      MPLS Support of Diff-Serv              June              July 2000

   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 Uniform Pipe Model, MPLS tunnels (aka LSPs) are viewed as
   artifacts of used to hide the end-to-end path
   intermediate MPLS nodes between LSP Ingress and Egress from the
   Diff-Serv standpoint. MPLS
   Tunnels may be used for forwarding purposes but have no significant
   impact on Diff-Serv. perspective. In this model, any packet contains exactly one
   piece of Diff-Serv the LSP Egress uses the Diff-
   Serv information which is meaningful and is always
   encoded in conveyed from the outer most label entry (or in LSP Ingress inside the
   encapsulated header (be it an IP DSCP where Header or an MPLS Header) and
   ignores the
   IP packet is transmitted unlabelled for instance at Diff-Serv information conveyed in the egress encapsulating
   header.

   In this model, tunneled packets must convey two meaningful pieces of
   Diff-Serv information:
     - the LSP). Any Diff-Serv information encoded somewhere else (eg. in
   deeper label entries) which is of no significance meaningful to intermediate
       nodes or along the LSP span (which we refer to as the tunnel egress and "LSP Diff-
       Serv Information"). This LSP Diff-Serv Information is ignored. If not
       meaningful at the LSP Egress: Whether Traffic Conditioning at
       intermediate nodes on the LSP span affects the "outer" LSP Diff-Serv
   information, the
       information or not, this updated Diff-Serv information is the one not
       considered meaningful at the egress of the LSP.

   With this Uniform Model:
     - the LSP Ingress, when performing the push operation, encodes the
       meaningful Diff-Serv information in the label entry
       corresponding to the pushed label.
     - Intermediate LSRs only consider Egress and operate on is ignored.
     - the LSP Diff-Serv
       Information encoded in the "outer" label entry (ie label entry
       on information which they perform is meaningful at the label swap).
     - Penultimate Hop Popping (PHP) can be used. In that case, LSP Egress
       (which we refer to as the
       meaningful "Tunneled Diff-Serv Information").
       This information is to be conveyed by the Penultimate
       LSR LSP Ingress to the LSP Egress in the header that
       Egress. This Diff-Serv information is exposed by the pop
       operation (ie. in not meaningful to the header that will be used for actual
       forwarding by
       intermediate nodes on the LSP Egress).
       Note that to do so, the Penultimate LSR needs to be aware span.

   Operation of the
       "Set of PHB-->Encaps mappings" for 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 label corresponding to "LSP Diff-Serv information
   (m) represents the exposed header (or "Tunneled Diff-Serv information"
    I represents the PHB-->DSCP mapping). Methods for
       providing this mapping awareness are outside LSP ingress node
    E represents the scope LSP egress node

   Operation 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 Pipe Model with PHP is illustrated below:

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

                 ---Swap--(M)--...--Swap------

 Le Faucheur et. al                                                 12
                      MPLS Support of Diff-Serv              July 2000

                /       (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 to assume that the
       "Set of PHB-->Encaps mappings" to be used for considers the outgoing label LSP Diff-Serv information
      received in the exposed outer header is (i.e. before the "Set of PHB-->Encaps mappings" that
       would be used by pop) in order to
      apply its Diff-Serv forwarding treatment (ie actual PHB)
    I represents the LSR if LSP ingress node
    P represents the LSR was not doing PHP.
       Note also that this specification assumes that LSP penultimate node
    E represents the Penultimate
       LSR does not perform label swapping over LSP egress node

   The Pipe Model is particularly appropriate to environments in which
   the label entry exposed
       by incoming interface of the pop operation (and in fact that it does not even look at LSP Ingress and the exposed label). Consequently, restrictions may apply to outgoing interface
   of the LSP Egress are in Diff-Serv Information Encoding that can be performed by domains which use a common set of
   Diff-Serv service provisioning policies and PHB definitions, while
   the
       Penultimate LSR. For LSP spans one (or more) Diff-Serv domain(s) which use(s) a
   different set of Diff-Serv service provisioning policies and PHB
   definitions.

   As an example, this specification does not allow
       situations where consider the Penultimate LSR pops case where a label corresponding
       to service provider is
   offering an E-LSP supporting two PSCs, while the header exposed by the
       pop contains label values MPLS VPN service (see [MPLS_VPN] for two L-LSPs each an example of MPLS
   VPN architecture) including Diff-Serv differentiation. Say that a
   collection of sites are interconnected via such an MPLS VPN service.
   Now say that this collection of sites are managed under a common
   administration and are also supporting one
       PSC, since the Diff-Serv Information Encoding would require
       selecting one label or service
   differentiation. If the other.
     - It is also possible to VPN site administration and the Service
   Provider are not use PHP. In that case, sharing the meaningful exact same Diff-Serv information is conveyed by the Penultimate LSR to policy (for
   instance not supporting the
       LSP Egress same number of PHBs), then operation of
   Diff-Serv in the "outer" label entry (which corresponds to Pipe Model over the
       LSP label).

 Le Faucheur et. al                                                 11 MPLS Support of VPN service would allow
   the VPN Sites Diff-Serv              June 2000

     - When policy to operate consistently throughout
   the pop operation is performed (ie. Penultimate hop with
       PHP, LSP ingress VPN Site and Egress without PHP), VPN Site and transparently over the incoming
   Service Provider Diff-Serv information
       contained in the outmost label entry before the pop is
       considered as the meaningful information.

   Operation of the Uniform Model with PHP is illustrated below :

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

                 +--Swap-(M)-...-Swap-(M)--+
                /        (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.

   Operation of the Uniform Model without PHP is illustrated below:

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

                 +--Swap--(M)-...-Swap-(M)-swap--(M)--+
                /        (outer header)     (P)        \
              (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.

   Use of the Uniform Model allows LSPs domain. It may be useful to span Diff-Serv domain
   boundaries without any other measure in place than an inter-domain
   Traffic Conditioning Agreement at the physical boundary between view such
   LSPs as linking the Diff-Serv domains and operating exclusively on the "outer" header,
   since the meaningful at their endpoints into a
   single Diff-Serv information is always visible and
   modifiable in the outmost label entry. region by making these endpoints virtually
   contiguous even though they may be physically separated by
   intermediate network nodes.

   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. For this reason, the

 Le Faucheur et. al                                                 12
                      MPLS Support of Diff-Serv              June 2000

   Uniform Pipe Model has been selected in this specification as the base
   mandatory mode of operations and thus MUST be supported.

   For support of the Uniform Pipe Model over an a given LSP (with and without PHP), 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 header (label entry in or IP header)
       which is used to do the received
       label stack. actual forwarding. In particular, when a pop operation is to be
       performed for

 Le Faucheur et. al                                                 13
                      MPLS Support of Diff-Serv              July 2000

       pop operation is to be performed for the considered LSP, the LSR
       performs Incoming PHB Determination BEFORE AFTER the pop.
     - when performing a swap-only operation for an the considered LSP,
       the LSR encodes Diff-Serv Information in the transmitted label
       entry corresponding to the swapped label
     - when performing a push operation for an the considered LSP, the LSR
       LSR:
           o encodes Diff-Serv Information corresponding to the
             OUTGOING PHB in the transmitted label entry corresponding
             to the pushed label. The
           o encodes Diff-Serv Information
       encoded corresponding to the
             INCOMING PHB in the encapsulated header (swapped label
             entry or IP
       Header) is header).

   For support of no importance.

2.6.4 the Pipe Model

   With over a given LSP with PHP, an LSR
   performs Incoming PHB Determination and Diff-Serv information
   Encoding in the Pipe Model, MPLS tunnels (aka LSPs) are used same manner as without PHP with the following
   exceptions:
     - 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 hide be performed for the
   intermediate MPLS nodes between LSP Ingress and Egress from
       considered LSP, the Penultimate LSR performs Incoming PHB
       Determination BEFORE the pop.
     - the Penultimate LSR does not perform Encoding of Diff-Serv perspective. In this model,
       Information into the LSP Egress uses header exposed by the Diff-
   Serv information conveyed from pop operation (i.e.
       the LSP Ingress inside LSR leaves the
   encapsulated exposed header (be it an IP Header or an "as is").

2.6.3 Uniform Model

   With the Uniform Model, MPLS Header) and
   ignores tunnels (aka LSPs) are viewed as
   artifacts of the Diff-Serv information conveyed in end-to-end path from the encapsulating
   header. Diff-Serv standpoint. MPLS
   Tunnels may be used for forwarding purposes but have no significant
   impact on Diff-Serv. In this model, tunneled packets must convey two meaningful pieces any packet contains exactly one
   piece of Diff-Serv information:
     - the Diff-Serv information which is meaningful to intermediate
       nodes along the LSP span (which we refer to as and is always
   encoded in the "LSP Diff-
       Serv Information"). This LSP Diff-Serv Information outer most label entry (or in the IP DSCP where the
   IP packet is not
       meaningful transmitted unlabelled for instance at the LSP Egress: Whether 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 LSP "outer" Diff-Serv
       information or not, this
   information, the updated Diff-Serv information is not
       considered meaningful at the LSP Egress and is ignored.
     - the Diff-Serv information which is one considered
   meaningful at the LSP Egress
       (which we refer to as the "Tunneled Diff-Serv Information").
       This information is to be conveyed by egress of the LSP Ingress to LSP.

   Operation of the LSP
       Egress. This Diff-Serv information Uniform Model without PHP is not meaningful to the
       intermediate nodes on the LSP span.

   With this Pipe Model:
     - the LSP Ingress, when performing the push operation, encodes the illustrated below:

             ========== LSP Diff-Serv information in the label entry that is pushed
       ("outer label entry") and encodes the Tunneled Diff-Serv =============================>

                 ---Swap--(M)--...-Swap--(M)--Swap----
                /         (outer header)              \
              (M)                                     (M)
              /                                         \

 Le Faucheur et. al                                                 13                                                 14
                      MPLS Support of Diff-Serv              June              July 2000

       Information in the encapsulated header (IP header or swapped
       label entry).
     - Intermediate LSRs only consider and operate on

   >--(M)--Push...............(x).......................Pop--(M)->
            I            (inner header)                  E

   (M) represents the LSP Meaningful Diff-Serv
       Information information encoded in the "outer" label entry (ie label entry
       on which they perform the label swap).
     - Penultimate Hop Popping (PHP) can be used. In that case, the LSP
   corresponding header.
   (x) represents non-meaningful Diff-Serv Information is simply not conveyed by the Penultimate
       LSR to information.
    I represents the LSP Egress. The Penultimate LSR conveys to ingress node
    E represents the LSP
       Egress the Tunneled Diff-Serv Information in egress node

   Operation of the header that Uniform Model with PHP is
       exposed by the pop operation (ie. in the header that will be
       used for actual forwarding by the illustrated below :

             ========== LSP Egress). However, since =========================>

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

   (M) represents the LSP Meaningful Diff-Serv Information is information encoded in the meaningful one over
   corresponding header.
   (x) represents non-meaningful Diff-Serv information.
    I represents the
       whole LSP including from the Penultimate LSR to ingress node
    P represents the LSP Egress,
       the Penultimate LSR performs Diff-Serv forwarding treatment (ie
       PHB enforcement) based on penultimate node
    E represents the LSP egress node

   The Uniform Model for Diff-Serv Information (even if
       this information over MPLS is not actually conveyed in such that, from the packet
       transmitted
   Diff-Serv perspective, operations are exactly identical to the LSP Egress).
     - it is also possible to
   operations if MPLS was not use PHP. used. In that case, the LSP Diff-
       Serv Information other words, MPLS is conveyed by the Penultimate LSR entirely
   transparent to the LSP
       Egress in Diff-Serv operations.

   Use of the "outer" label entry (which corresponds Uniform Model allows LSPs to the LSP
       label) where it will simply be ignored.
     - When PHP is used, the LSP Egress directly uses the span Diff-Serv
       information received domain
   boundaries without any other measure in place than an inter-domain
   Traffic Conditioning Agreement at the outer header (IP header or outer
       label entry) since it carries physical boundary between the Tunneled
   Diff-Serv
       Information.
     - When PHP is not used, LSP Egress ignores domains and operating exclusively on the "outer" header,
   since the meaningful Diff-Serv information contained is always visible and
   modifiable in the outmost label entry to entry.

   The Uniform Model MAY be popped (since it
       contains the LSP Diff-Serv information) and considers supported.

   For support of the Diff-
       Serv Uniform Model over a given LSP, an LSR performs
   Incoming PHB Determination and Diff-Serv information conveyed Encoding in the header (IP header or MPLS
       header) which is used to do
   following manner:
     - when receiving an unlabelled packet, the actual forwarding (since it
       contains LSR performs Incoming
       PHB Determination considering the  Tunneled LSP Diff-Serv information). In other
       words, received IP Header.
     - when receiving a labeled packet, the LSP Egress considers LSR performs Incoming PHB
       Determination considering the Diff-Serv information
       conveyed outer label entry in the header after the received
       label stack. In particular, when a pop operation.

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

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

                 +--Swap--(M)-...-Swap--(M)--+
                /       (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" to be

 Le Faucheur et. al                                                 14                                                 15
                      MPLS Support of Diff-Serv              June              July 2000

   (*) The Penultimate

       performed for the considered LSP, the LSR considers performs Incoming PHB
       Determination BEFORE the LSP Diff-Serv information
   received in pop.
     - when performing a push operation for the outer header (ie. before considered LSP, the pop) LSR
       encodes Diff-Serv Information in order the transmitted label entry
       corresponding to apply
   its the pushed label. The Diff-Serv forwarding treatment (ie actual PHB)

   Operation of Information
       encoded in the Pipe Model without PHP encapsulated header (swapped label entry or IP
       Header) is illustrated below:

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

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

   (M) represents of no importance.
     - when performing a swap-only operation for the "LSP Diff-Serv information

   (m) represents considered LSP,
       the "Tunneled LSR encodes Diff-Serv information"

   The Pipe Model is particularly appropriate to environments Information in which
   the incoming interface of the LSP Ingress and transmitted label
       entry corresponding to the outgoing interface swapped label.
     - when PHP is used, the Penultimate LSR needs to be aware of the LSP Egress are in
       "Set of PHB-->Encaps mappings" for the same Diff-Serv domain while label corresponding to
       the LSP
   spans another (other) exposed header (or the PHB-->DSCP mapping) in order to
       perform Diff-Serv domain(s). Information Encoding. Methods for providing
       this mapping awareness are outside the scope of this
       specification. As an example, consider the case where a service provider is
   offering an MPLS VPN service including Diff-Serv differentiation.
   Say "PHB-->DSCP mapping" may be
       locally configured. As another example, in some environments, it
       may be appropriate for the Penultimate LSR to assume that a collection the
       "Set of sites are interconnected via such an MPLS
   VPN service. Now say that this collection PHB-->Encaps mappings" to be used for the outgoing label
       in the exposed header is the "Set of sites are managed under
   a common administration and are also supporting Diff-Serv service
   differentiation. If PHB-->Encaps mappings" that
       would be used by the VPN site administration and LSR if the Service
   Provider are LSR was not sharing doing PHP.
       Note also that this specification assumes that the exact same Diff-Serv policy (for
   instance Penultimate
       LSR does not supporting perform label swapping over the same number of PHBs), then label entry exposed
       by the pop operation of
   Diff-Serv (and in fact that it does not even look at
       the Pipe Model over the MPLS VPN service would allow
   the VPN Sites Diff-Serv domain policy exposed label). Consequently, restrictions may apply to operate consistently
   throughout the ingress VPN Site and Egress VPN Site and
   transparently over the Service Provider
       Diff-Serv domain.

   Support of Information Encoding that can be performed by the Pipe Model is defined in
       Penultimate LSR. For example, this specification as a
   recommended option and thus SHOULD be supported.

   For support of the Pipe Model over an 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, does not allow
       situations where the Penultimate LSR performs Incoming
       PHB Determination considering the received IP Header.
     - when receiving pops a labeled packet, the LSR performs Incoming PHB
       Determination considering label corresponding
       to an E-LSP supporting two PSCs, while the header (label entry or IP header)
       which is used to do exposed by the actual forwarding. In particular, when a
       pop operation is to be performed contains label values for two L-LSPs each supporting one
       PSC, since the considered LSP, the LSR
       performs Incoming PHB Determination AFTER the pop.

 Le Faucheur et. al                                                 15
                      MPLS Support of Diff-Serv              June 2000

     - when performing a swap-only operation for an LSP, Information Encoding would require
       selecting one label or the other.

   Note that LSR
       encodes Diff-Serv Information in behaviors for the transmitted label entry
       corresponding to Pipe Model and for the swapped label
     - Uniform Model
   only differ when performing doing a push operation or a pop. Thus, Intermediate LSRs
   which perform swap only operations for an LSP, the LSR:
           o encodes Diff-Serv Information corresponding to LSP , behave exactly in
   the
             OUTGOING PHB same way regardless of whether they are behaving in the transmitted label entry corresponding
             to Pipe
   Model or the pushed label.
           o encodes Uniform model. With a Diff-Serv Information corresponding to the
             INCOMING PHB in the encapsulated header (swapped label
             entry or IP header).

   For support of implementation
   supporting both the Pipe Model over an LSP with PHP, an LSR performs
   Incoming PHB Determination and Diff-Serv information Encoding in the
   same manner as without PHP with the following exception:
     - 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.
     - the Penultimate LSR does not perform Encoding of Diff-Serv
       Information into the header exposed by the pop operation.

   Note that LSR behaviors for the Uniform Model and for the Pipe Model
   only differ when doing a push or a pop. Thus, Intermediate LSRs
   which perform swap only operations for an LSP , behave exactly in
   the same way regardless of whether they are behaving in the Uniform
   Model or the Pipe model. With a Diff-Serv implementation supporting
   both the Uniform Model and the Pipe Model, only LSRs
   behaving as LSP Ingress, Penultimate LSR or LSP Egress need to be
   configured to operate in a particular Model.

2.6.5 Other Models

   Other Signaling to associate
   a Diff-Serv tunneling models are conceivable over MPLS for
   support of more complex scenarios. For instance, the egress of an
   LSP could conceivably make some complex Diff-Serv decision based model on
   both the Diff-Serv information conveyed in the encapsulating header
   and in the encapsulated header. Models beyond the Uniform Model and
   the Pipe Model are outside a per-LSP basis is out of the scope
   of this specification and MAY
   be supported as an option.

2.6.6 specification.

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

 Le Faucheur et. al                                                 16
                      MPLS Support of Diff-Serv              July 2000

   doing the pop (Penultimate LSR or LSP Egress) are expected to must operate in the
   same Tunneling Model (ie Uniform (i.e. Pipe or Pipe). LSRs at

 Le Faucheur et. al                                                 16
                      MPLS Support of Diff-Serv              June 2000

   different Uniform). However, there is no
   requirement for consistent tunneling models across levels of so that
   LSPs are expected to operate in the same or at different levels may be operating in different Tunneling
   Models.

 Le Faucheur et. al                                                 17
                      MPLS Support of Diff-Serv              June 2000

   Hierarchical operations is 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 (either Uniform or Pipe)
   (2) Tunneling Model 2 (same as
   Tunneling Model 1 2 may be the same as or may be different Model) to
   Tunneling Model 1.

   For support of M levels of push in the Pipe Model:
     - when performing multiple push operations, the LSR:
           o encodes Diff-Serv Information corresponding to the
             Outgoing PHB in the transmitted label entry corresponding
             to the LAST pushed label (i.e. the label pushed in the
             outer label entry).
           o encodes Diff-Serv Information corresponding to the
             Incoming PHB in the encapsulated header (swapped label
             entry or IP header) as well as in the label entries for
             all the pushed labels (except the last pushed label).

   For support of M levels of pop in the Pipe Model:
     - when performing multiple pop operations for an LSP, the LSR
       performs Incoming PHB Determination considering the header
       (label entry or IP header) which is used to do the actual
       forwarding. In other words, when a pop operation is to be
       performed for the considered LSP, the LSR performs Incoming PHB
       Determination AFTER ALL the pop operations.

   For support of M levels of push in the Uniform Model:
     - when performing multiple push operations, the LSR encodes Diff-
       Serv Information in the transmitted label entry corresponding to
       the LAST pushed label (ie (i.e. the label pushed in the outer label
       entry). The Diff-Serv Information encoded in the encapsulated
       header (swapped label entry or IP Header) as well as the Diff-
       Serv Information encoded in label entries for other pushed
       labels are of no importance.

 Le Faucheur et. al                                                 17
                      MPLS Support of Diff-Serv              July 2000

   For support of M levels of pop in the Uniform Model:
     - when performing multiple pop operations for an LSP, the LSR
       performs Incoming PHB Determination considering the outmost
       label entry in the received label stack. In other words, when
       multiple pop operations are to be performed, the LSR performs
       Incoming PHB Determination BEFORE ANY pop operations.
     - when the multiple pop operations are performed by the
       Penultimate LSR, note that to perform Encoding

3. Detailed Operations of E-LSPs

3.1 E-LSP Definition

   E-LSPs are defined in section 1.2.

   Within a given MPLS Diff-Serv
       Information, domain, all the Penultimate LSR needs to be aware of the "Set
       of PHB-->Encaps mappings" for the label corresponding to the
       exposed header after all the pop operations (or E-LSPs relying on the PHB-->DSCP
       mapping). Methods for providing this
   pre-configured mapping awareness are
       outside capable of transporting the scope same common
   set of 8, or fewer, BAs. Each of those E-LSPs may actually transport
   this specification.
     - when the multiple pop operations are performed by full set of BAs or any arbitrary subset of it.

   For a given FEC, two given E-LSPs using signaled EXP<-->PHB mapping
   can support the
       Penultimate LSR, note also that this specification assumes that same or different sets of Ordered Aggregates.

3.2 Populating the Penultimate LSR does not perform label swapping over `Encaps-->PHB mapping' for an incoming E-LSP

   This section defines how the
       label entry exposed after all `Encaps-->PHB mapping' of the pop operations (and Diff-Serv
   Context is populated for an incoming E-LSP in fact
       that it does not even look at the header exposed after the last
       pop operations). Consequently, restrictions may apply order to the
       Diff-Serv Information Encoding that can be performed by the
       Penultimate LSR.

   For support of M levels allow
   Incoming PHB determination.

   The `Encaps-->PHB mapping' for an E-LSP is always of push in the Pipe Model:
     - when performing multiple push operations, form
   `EXP-->PHB mapping'.

   If the LSR:
           o encodes Diff-Serv Information corresponding label corresponds to an E-LSP for which no EXP<-->PHB mapping
   has been explicitly signaled at LSP setup, the
             Outgoing PHB `EXP-->PHB mapping'
   is populated based on the Preconfigured EXP<-->PHB Mapping which is
   discussed below in section 3.2.1.

   If the transmitted label entry corresponding

 Le Faucheur et. al                                                 18
                      MPLS Support of Diff-Serv              June 2000

             to the LAST pushed label (ie the label pushed in the outer
             label entry).
           o encodes Diff-Serv Information corresponding corresponds to an E-LSP for which an EXP<-->PHB mapping
   has been explicitly signaled at LSP setup, the
             Incoming PHB in the encapsulated header (swapped label
             entry or IP header) as well `EXP-->PHB mapping'
   is populated as in the label entries for
             all per the pushed labels (except signaled EXP<-->PHB mapping.

3.2.1 Preconfigured EXP<-->PHB mapping

   LSRs supporting E-LSPs which use the last pushed label).

   For support of M levels preconfigured EXP<-->PHB
   mapping must allow local configuration of pop in this EXP<-->PHB mapping.
   This mapping applies to all the Pipe Model E-LSPs established on this LSR
   without PHP:
     - when performing multiple pop operations for an LSP, a mapping explicitly signaled at set-up time.

   The preconfigured EXP<-->PHB mapping must either be consistent at
   every E-LSP hop throughout the LSR
       performs Incoming PHB Determination considering MPLS Diff-Serv domain spanned by the header
       (label entry
   LSP or IP header) which is used to do appropriate remarking of the actual
       forwarding. In other words, when a pop operation is to EXP field must be performed for the considered LSP, by
   the LSR performs Incoming PHB
       Determination AFTER ALL whenever a different preconfigured mapping is used on the pop operations.

   For support of M levels
   ingress and egress interfaces.

 Le Faucheur et. al                                                 18
                      MPLS Support of pop in Diff-Serv              July 2000

   In case, the Pipe Model with PHP, preconfigured EXP<-->PHB mapping has not actually been
   configured by the
   Penultimate LSR:
     - performs Network Administrator, the LSR should use a
   default preconfigured EXP<-->PHB mapping which maps all EXP values
   to the Default PHB.

3.3 Incoming PHB Determination considering the outmost On Incoming E-LSP

   This section defines how Incoming PHB Determination is carried out
   when the considered label entry in the received label stack. In other words, when
       multiple pop operations are stack
   corresponds to be performed for the considered
       LSP, an E-LSP. This requires that the LSR performs `Encaps-->PHB
   mapping' is populated as defined in section 3.2.

   When considering a label entry corresponding to an incoming E-LSP
   for Incoming PHB Determination BEFORE ANY pop
       operations. Determination, the LSR:
     - does not perform Encoding determines the EXP-->PHB mapping by looking up the
       `Encaps-->PHB mapping' of the Diff-Serv Information into Context associated in
       the
       header that is exposed after all ILM with the pop operations

3. Detailed Operations of E-LSPs

3.1 considered incoming E-LSP Definition

    Recognizing that:
     - Certain MPLS encapsulations (such as PPP and LAN) make use of a
       Shim Header which consists of a label stack with one or more
       entries [MPLS_ENCAPS] each with a 3-bit EXP field; label.
     - determines the Differentiated-Service (DS) field is 6-bit long
       [DIFF_HEADER] potentially allowing support of incoming PHB by looking up to 64 Behavior
       Aggregates
     - any subset of 8 (or less) DSCP values can be mapped entirely
       into the 3-bit long EXP field of the MPLS
       considered label stack entry;

    We define that:
     - an LSP established for a given Forwarding Equivalent Class (FEC)
       may be used for transport of up to eight BAs of that FEC;
     - entry in the set EXP-->PHB mapping table.

3.4 Populating the `Set of transported BAs can span multiple OAs;
     - PHB-->Encaps mappings' for a given OA transported over an outgoing E-LSP

   This section defines how the LSP, all supported BAs `Set of PHB-->Encaps mappings' of
       this OA are transported over the LSP;
     - such an LSP
   Diff-Serv Context is referred to as populated at label setup for an "EXP-inferred-PSC" LSP or
       "E-LSP" because the PSC to be applied outgoing E-LSP
   in order to a labeled packet by the
       LSR depends on the EXP field value allow Encoding of Diff-Serv information in the MPLS Shim Header;
     - packets belonging to this given FEC and from
   Encapsulation Layer.

3.4.1 `PHB-->EXP mapping'

   An outgoing E-LSP must always have a `PHB-->EXP mapping' as part of
   the corresponding
       set `Set of BAs are sent down this E-LSP.

 Le Faucheur et. al                                                 19
                      MPLS Support PHB-->Encaps mappings' of its Diff-Serv              June 2000

     - multiple BAs belonging to the same FEC and transported over Context.

   If the
       same label corresponds to an E-LSP are granted different scheduling treatment and
       different drop precedence by the LSR for which no EXP<-->PHB mapping
   has been explicitly signaled at LSP setup, this `PHB-->EXP mapping'
   is populated based on the EXP field Preconfigured EXP<-->PHB Mapping which is appropriately encoded to reflect both the PSC and the
       drop precedence of
   discussed above in section 3.2.1.

   If the PHB corresponding label corresponds to an E-LSP for which an EXP<-->PHB mapping
   has been explicitly signaled at LSP setup, the packet's BA.
     - `PHB-->EXP mapping'
   is populated as per the mapping between EXP field and PHB signaled EXP<-->PHB mapping.

3.4.2 `PHB-->CLP mapping'

   If the LSP is egressing over an ATM interface which is not label
   switching controlled, then one `PHB-->CLP mapping' is added to be applied by the LSR
   `Set of PHB-->Encaps mappings' for a given E-LSP this outgoing LSP. This
   `PHB-->CLP mapping' is populated in the following way:
     - it is either explicitly signaled at label set-up
       or relies on a preconfigured mapping.

   Within a given MPLS Diff-Serv domain, all function of the E-LSPs relying PHBs supported on this LSP, and may use
       the
   pre-configured relevant mapping are capable of transporting the same common
   set of 8, or fewer, BAs. Each of those E-LSPs may actually transport
   this full set of BAs or any arbitrary subset of it.

   For a given FEC, two given E-LSPs using signaled EXP<-->PHB mapping
   can support entries for these PHBs from the same or different sets of Ordered Aggregates.

   For a given FEC, there may be more
       Default PHB-->CLP Mapping defined in section 3.4.2.1. Other
       mappings than one E-LSP carrying the same
   OA, for example for purposes of load balancing of the OA. In that
   case, one defined in order to respect ordering constraints, all packets of a
   given microflow must section 3.4.2.1 may be transported over the same LSP. used. In

 Le Faucheur et. al                                                 19
                      MPLS specifies how LSPs can be established via multiple signaling
   protocols. Those include the Label Distribution Protocol (LDP),
   RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP
   are to be used for establishment of E-LSPs.

3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP

   This section defines how the `Encaps-->PHB mapping' Support of the Diff-Serv
   Context              July 2000

       particular, if a mapping from PHBs to CLP is populated for an incoming E-LSP standardized in order to allow
   Incoming PHB determination.

   The `Encaps-->PHB mapping' the
       future for an E-LSP is always operations of Diff-Serv over ATM, such standardized
       mapping may then be used.

   For example if the form
   `EXP-->PHB mapping'.

   If the outgoing label corresponds to an E-LSP for which no EXP<-->PHB mapping
   has been explicitly signaled at LSP setup, supporting
   the `EXP-->PHB AF1 PSC , then the `PHB-->CLP mapping'
   is may be populated based on the Preconfigured EXP<-->PHB Mapping which is
   discussed below in section 3.2.1. with:

        PHB                CLP Field

        AF11       ---->      0
        AF12       ---->      1
        AF13       ---->      1
        EF         ---->      0

   Notice that in this case the `Set of PHB-->Encaps mappings' contains
   both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'.

3.4.2.1 Default PHB-->CLP Mapping

        PHB                CLP Bit

        DF         ---->      0
        CSn        ---->      0
        AFn1       ---->      0
        AFn2       ---->      1
        AFn3       ---->      1
        EF         ---->      0

3.4.3 `PHB-->DE mapping'

   If the LSP is egressing over a Frame Relay interface which is not
   label corresponds switching controlled, one `PHB-->DE mapping' is added to an E-LSP the
   `Set of PHB-->Encaps mappings' for which an EXP<-->PHB mapping
   has been explicitly signaled at this outgoing LSP setup, the `EXP-->PHB mapping' and is
   populated as per in the signaled EXP<-->PHB mapping.

3.2.1 Preconfigured EXP<-->PHB mapping

   LSRs supporting E-LSPs which following way:
     - it is a function of the PHBs supported on this LSP, and may use
       the preconfigured EXP<-->PHB relevant mapping must allow local configuration of this EXP<-->PHB mapping.
   This entries for these PHBs from the Default
       PHB-->DE Mapping defined in section 3.4.3.1. Other mappings than
       the one defined in section 3.4.3.1 may be used. In particular,
       if a mapping applies from PHBs to all DE is standardized in the E-LSPs established on future for
       operations of Diff-Serv over Frame Relay, such standardized
       mapping may then be used.

   Notice that in this LSR
   without case the `Set of PHB-->Encaps mappings' contains
   both a mapping explicitly signaled at set-up time. `PHB-->EXP mapping' and a `PHB-->DE mapping'.

3.4.3.1 Default PHB-->DE Mapping

        PHB                 DE Bit

         DF       ---->       0
         CSn      ---->       0
         AFn1     ---->       0

 Le Faucheur et. al                                                 20
                      MPLS Support of Diff-Serv              June              July 2000

   The preconfigured EXP<-->PHB mapping must either be consistent at
   every E-LSP hop throughout the MPLS Diff-Serv domain spanned by

         AFn2     ---->       1
         AFn3     ---->       1
         EF       ---->       0

3.4.4 `PHB-->802.1 mapping'

   If the LSP or appropriate remarking is egressing over a LAN interface on which multiple 802.1
   Traffic Classes are supported as per [IEEE_802.1], then one
   `PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings'
   for this outgoing LSP. This `PHB-->802.1 mapping' is populated in
   the EXP field must be performed by following way:
     - it is a function of the PHBs supported on this LSP, an uses the
       relevant mapping entries for these PHBs from the Preconfigured
       PHB-->802.1 Mapping defined in section 3.4.4.1.

   Notice that the `Set of PHB-->Encaps mappings' then contains both a
   `PHB-->EXP mapping' and a `PHB-->802.1 mapping'.

3.4.4.1 Preconfigured `PHB-->802.1 Mapping'

   At the time of producing this specification, there are no
   standardized mapping from PHBs to 802.1 Traffic Classes.
   Consequently, an LSR whenever supporting multiple 802.1 Traffic Classes over
   LAN interfaces must allow local configuration of a different preconfigured `PHB-->802.1
   Mapping'. This mapping is used on applies to all the
   ingress and egress outgoing LSPs established
   by the LSR on such LAN interfaces.

3.3 Incoming PHB Determination

3.5 Encoding Diff-Serv information into Encapsulation Layer On Incoming Outgoing
E-LSP

   This section defines how Incoming PHB Determination is carried out
   when to encode Diff-Serv information into the considered
   MPLS encapsulation Layer for a given transmitted label entry in the received label stack
   corresponds
   corresponding to an outgoing E-LSP. This requires that the `Encaps-->PHB
   mapping' `Set of
   PHB-->Encaps mappings' is populated as defined above in section 3.2.

   When considering a label entry corresponding to an incoming E-LSP
   for Incoming PHB Determination, the LSR:
     - 3.4.

   The LSR first determines the EXP-->PHB mapping by looking up the
       `Encaps-->PHB mapping' `Set of the PHB-->Encaps mappings' of the
   Diff-Serv Context associated with the corresponding label in the ILM with
   NHLFE.

3.5.1 `PHB-->EXP mapping'

   If the considered incoming E-LSP label. `Set of PHB-->Encaps mappings' contains a mapping of the form
   `PHB-->EXP mapping', then the LSR:
      - determines the incoming PHB by looking up value to be written in the EXP field of the
       considered
       corresponding level label entry in by looking up the EXP-->PHB "outgoing PHB"
       in this PHB-->EXP mapping table.

3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP

   This section defines how

3.5.2 `PHB-->CLP mapping'

   If the `Set of PHB-->Encaps mappings' contains a mapping of the
   Diff-Serv Context is populated for an outgoing E-LSP in order to
   allow Encoding form
   `PHB-->CLP mapping', then the LSR:

 Le Faucheur et. al                                                 21
                      MPLS Support of Diff-Serv information              July 2000

     - determines the value to be written in the Encapsulation Layer.

3.4.1 `PHB-->EXP mapping'

   An outgoing E-LSP must always have a `PHB-->EXP mapping' as part CLP field of the ATM
       encapsulation header, by looking up the "outgoing PHB" in this
       PHB-->CLP mapping table.

3.5.3 `PHB-->DE mapping'

   If the `Set of PHB-->Encaps mappings' contains a mapping of its Diff-Serv Context.

   If the label corresponds to an E-LSP for which no EXP<-->PHB mapping
   has been explicitly signaled at LSP setup, this `PHB-->EXP mapping'
   is populated based on form
   `PHB-->DE mapping', then the Preconfigured EXP<-->PHB Mapping which is
   discussed above in section 3.2.1.

   If LSR:
     - determines the label corresponds value to an E-LSP for which an EXP<-->PHB mapping
   has been explicitly signaled at LSP setup, be written in the `PHB-->EXP mapping'
   is populated as per DE field of the signaled EXP<-->PHB mapping.

3.4.2 `PHB-->CLP Frame
       Relay encapsulation header, by looking up the "outgoing PHB" in
       this PHB-->DE mapping table.

3.5.4 `PHB-->802.1 mapping'

   If the E-LSP is egressing over an ATM interface which is not label
   switching controlled, then one `PHB-->CLP mapping' is added at label
   setup to the `Set of PHB-->Encaps mappings' in contains a mapping of the Diff-Serv Context
   for this outgoing E-LSP. This `PHB-->CLP mapping' is populated in form
   `PHB-->802.1 mapping', then the following way: LSR:
     - it is a function determines the value to be written in the User_Priority field of
       the PHBs supported on this LSP, and may use Tag Control Information of the relevant mapping entries for these PHBs from 802.1 encapsulation header
       [IEEE_802.1], by looking up the
       Default PHB-->CLP Mapping defined "outgoing PHB" in section 3.4.2.1. Other
       mappings than this
       PHB-->802.1 mapping table.

3.6 E-LSP Merging

   In an MPLS domain, two or more LSPs can be merged into one LSP at
   one LSR. E-LSPs are compatible with LSP Merging under the following
   condition:

        E-LSPs can only be merged into one defined in section 3.4.2.1 may LSP if they support the
        exact same set of BAs.

   For E-LSPs using signaled EXP<-->PHB mapping, the above merge
   condition MUST be used. In

 Le Faucheur et. al                                                 21
                      MPLS Support enforced by LSRs through explicit checking at
   label setup that the exact same set of Diff-Serv              June 2000

       particular, if a mapping from PHBs to CLP is standardized in supported on the
       future for operations of Diff-Serv over ATM, such standardized
       mapping may then be used.
   merged LSPs.

   For example if E-LSPs using the outgoing label corresponds to preconfigured EXP<-->PHB mapping, since the
   PHBs supported over an E-LSP supporting is not signaled at establishment time,
   an LSR can not rely on signaling information to enforce the AF1 PSC and above
   merge. However all E-LSPs using the EF PHB and egressing over an ATM interface, then
   the `PHB-->CLP mapping' may be populated with:

        PHB                CLP Field

        AF11       ---->      0
        AF12       ---->      1
        AF13       ---->      1
        EF         ---->      0

   Notice that if the E-LSP is egressing over an ATM interface, then preconfigured EXP<-->PHB mapping
   are required to support the `Set same set of PHB-->Encaps mappings' contains both a `PHB-->EXP
   mapping' and Behavior Aggregates within a `PHB-->CLP mapping'.

3.4.2.1 Default PHB-->CLP Mapping

        PHB                CLP Bit

        DF         ---->      0
        CSn        ---->      0
        AFn1       ---->      0
        AFn2       ---->      1
        AFn3       ---->      1
        EF         ---->      0

3.4.3 `PHB-->DE mapping'

   If
   given MPLS Diff-Serv domain. Thus, merging of E-LSPs using the E-LSP
   preconfigured EXP<-->PHB mapping is egressing over allowed within a Frame Relay interface which is not
   label switching controlled, one `PHB-->DE given MPLS
   Diff-Serv domain.

4.  Detailed Operation of L-LSPs

4.1 L-LSP Definition

   L-LSPs are defined in section 1.3.

4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP

 Le Faucheur et. al                                                 22
                      MPLS Support of Diff-Serv              July 2000

   This section defines how the `Encaps-->PHB mapping' of the Diff-Serv
   Context is added populated at label setup for an incoming L-LSP in order
   to allow Incoming PHB determination.

4.2.1 `EXP-->PHB mapping'

   If the `Set of PHB-->Encaps mappings' in LSR terminates the Diff-Serv Context
   for MPLS Shim Layer over this outgoing E-LSP incoming L-LSP
   and the L-LSP ingresses on an interface which is not ATM nor Frame
   Relay, then the `Encaps-->PHB mapping' is populated in the following
   way:
     - it is actually a `EXP-->PHB mapping'
     - this mapping is a function of the PHBs supported PSC which is carried on this
       LSP, and may must use the relevant mapping entries for these PHBs this PSC from
       the Default
       PHB-->DE Mandatory EXP/PSC-->PHB Mapping defined in section 3.4.3.1. Other mappings than Section 4.2.1.1.

   For example if the one defined in section 3.4.3.1 may be used. In particular,
       if a mapping from PHBs incoming label corresponds to DE is standardized in the future for
       operations of Diff-Serv over Frame Relay, such standardized
       mapping may then be used.

   Notice that if an L-LSP supporting
   the E-LSP is egressing over a Frame Relay interface, AF1 PSC, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP `Encaps-->PHB mapping' and a `PHB-->DE mapping'.

3.4.3.1 Default PHB-->DE Mapping will be populated with:

      EXP Field              PHB                 DE Bit

 Le Faucheur et. al                                                 22
                      MPLS Support of Diff-Serv              June 2000

         DF       ---->       0
         CSn      ---->       0
         AFn1     ---->       0
         AFn2

        000        ---->       1
         AFn3    AF11
        001        ---->       1
         EF    AF12
        010        ---->       0

3.4.4 `PHB-->802.1 mapping'

   If the E-LSP is egressing    AF13

   An LSR supporting L-LSPs over a PPP interfaces and LAN interface on interfaces is
   an example of LSR terminating the Shim layer over ingress interfaces
   which multiple
   802.1 Traffic Classes are supported as per [IEEE_802.1], then one
   `PHB-->802.1 mapping' is added at label setup to not ATM nor Frame Relay.

   If the `Set of
   PHB-->Encaps mappings' of LSR terminates the Diff-Serv Context for MPLS Shim Layer over this outgoing
   E-LSP. This `PHB-->802.1 incoming L-LSP
   and the L-LSP ingresses on an ATM or Frame Relay interface, then the
   `Encaps-->PHB mapping' is populated in the following way:
     - it is should actually be a function `EXP-->PHB mapping'. Alternative
       optional ways of populating the PHBs supported on this LSP, an uses the
       relevant mapping entries for these PHBs from the Preconfigured
       PHB-->802.1 Mapping `Encaps-->PHB mapping' might be
       defined in section 3.4.4.1.

   Notice that the `Set of PHB-->Encaps mappings' then contains both future (e.g., using a
   `PHB-->EXP 'CLP/EXP--> PHB mapping' and or
       a `PHB-->802.1 mapping'.

3.4.4.1 Preconfigured `PHB-->802.1 Mapping'

   At 'DE/EXP-->PHB mapping') but are outside the time scope of producing this specification, there are no
   standardized mapping from PHBs to 802.1 Traffic Classes.
   Consequently, an LSR supporting multiple 802.1 Traffic Classes over
   LAN interfaces must allow local configuration of a `PHB-->802.1
   Mapping'. This mapping applies to all the outgoing LSPs established
   by the LSR on such LAN interfaces.

3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing
E-LSP

   This section defines how to encode Diff-Serv information into
       document.
     - when the
   MPLS encapsulation Layer for a given transmitted label entry
   corresponding to `Encaps-->PHB mapping' is an outgoing E-LSP. This requires that the `Set of
   PHB-->Encaps mappings' `EXP-->PHB mapping', this
       `EXP-->PHB mapping' mapping is populated as defined above in section 3.4.

   The LSR first determines the `Set of PHB-->Encaps mappings' a function of the
   Diff-Serv Context associated with the corresponding label in PSC which is
       carried on the
   NHLFE.

3.5.1 `PHB-->EXP mapping'

   The LSR:
     - determines L-LSP, and must use the PHB-->EXP relevant mapping by looking up entries
       for this PSC from the
       `Set Mandatory EXP/PSC-->PHB Mapping defined in
       Section 4.2.1.1.

   An Edge-LSR of PHB-->Encaps mapping' an ATM-MPLS domain or of the Diff-Serv Context
       associated with the corresponding label in the NHLFE.
     - determines the value to be written in the EXP field a FR-MPLS domain is an
   example of LSR terminating the
       corresponding level label entry by looking up the "outgoing PHB"
       in this PHB-->EXP shim layer over an ingress ATM/FR
   interface.

4.2.1.1 Mandatory EXP/PSC --> PHB mapping table.

      EXP Field      PSC             PHB

        000          DF    ---->    DF

 Le Faucheur et. al                                                 23
                      MPLS Support of Diff-Serv              June              July 2000

3.5.2 `PHB-->CLP mapping'

   If the `Set of PHB-->Encaps mappings' contains a mapping of the form
   `PHB-->CLP mapping', then the LSR:
     - determines the value to be written in the CLP field of

        000          CSn   ---->    CSn
        000          AFn   ---->    AFn1
        001          AFn   ---->    AFn2
        010          AFn   ---->    AFn3
        000          EF    ---->    EF

4.2.2 `CLP-->PHB mapping'

   If the LSR does not terminate an MPLS Shim Layer over this incoming
   label and uses ATM encapsulation header, by looking up (i.e. it is an ATM-LSR), then the "outgoing PHB" in this
       PHB-->CLP mapping table.

3.5.3 `PHB-->DE
   `Encaps-->PHB mapping'

   If for this incoming L-LSP is populated in the `Set of PHB-->Encaps mappings' contains
   following way:
     - it is actually a `CLP-->PHB mapping'
     - the mapping is a function of the form
   `PHB-->DE mapping', then PSC which is carried on this
       LSP, and should use the LSR:
     - determines relevant mapping entries for this PSC
       from the value to be written Default CLP/PSC-->PHB Mapping defined in Section
       4.2.2.1.

   For example if the DE field of incoming label corresponds to an L-LSP supporting
   the Frame
       Relay encapsulation header, by looking up AF1 PSC, then the "outgoing PHB" in
       this PHB-->DE mapping table.

3.5.4 `PHB-->802.1 `Encaps-->PHB mapping' should be populated
   with:

      CLP Field              PHB

        0          ---->    AF11
        1          ---->    AF12

4.2.2.1 Default CLP/PSC --> PHB Mapping

      CLP Bit      PSC             PHB

         0          DF    ---->    DF
         0          CSn   ---->    CSn
         0          AFn   ---->    AFn1
         1          AFn   ---->    AFn2
         0          EF    ---->    EF

4.2.3 `DE-->PHB mapping'

   If the `Set of PHB-->Encaps mappings' contains LSR does not terminate an MPLS Shim Layer over this incoming
   label and uses Frame Relay encapsulation (i.e. it is a mapping of the form
   `PHB-->802.1 mapping', FR-LSR), then
   the LSR:
     - determines the value to be written in the User_Priority field of
       the Tag Control Information of the 802.1 encapsulation header
       [IEEE_802.1], by looking up the "outgoing PHB" in `Encaps-->PHB mapping' for this
       PHB-->802.1 mapping table.

3.6 E-LSP Merging

   In an MPLS domain, two or more LSPs can be merged into one LSP at
   one LSR. E-LSPs are compatible with LSP Merging under incoming L-LSP is populated in
   the following
   condition:

        E-LSPs can only be merged into one LSP if they support the
        exact same set of BAs.

   For E-LSPs using signaled EXP<-->PHB mapping, the above merge
   condition MUST be enforced by LSRs through explicit checking at
   label setup that the exact same set of PHBs way:
     - it is supported on the
   merged LSPs.

   For E-LSPs using actually a `DE-->PHB mapping'
     - the preconfigured EXP<-->PHB mapping, since mapping is a function of the
   PHBs supported over an E-LSP PSC which is not signaled at establishment time,
   an LSR can not rely carried on signaling information to enforce the above
   merge. However all E-LSPs using this
       LSP, and should use the preconfigured EXP<-->PHB relevant mapping
   are required to support the same set of Behavior Aggregates within a
   given MPLS Diff-Serv domain. Thus, merging of E-LSPs using entries for this PSC
       from the
   preconfigured EXP<-->PHB mapping is allowed within a given MPLS
   Diff-Serv domain.

4.  Detailed Operation of L-LSPs

4.1 L-LSP Definition Default DE/PSC-->PHB Mapping defined in Section
       4.2.3.1.

4.2.3.1 Default DE/PSC --> PHB Mapping

      DE Bit      PSC             PHB

 Le Faucheur et. al                                                 24
                      MPLS Support of Diff-Serv              June              July 2000

    Recognizing that:

     - All currently defined MPLS encapsulation methods have a field of
       3 bits or less for Diff-Serv encoding (i.e., 3-bit EXP field in
       case of Shim Header and 1-bit CLP/DE bit in case of ATM/Frame
       Relay).
     - The Differentiated-Services (DS) field

         0          DF    ---->    DF
         0          CSn   ---->    CSn
         0          AFn   ---->    AFn1
         1          AFn   ---->    AFn2
         0          EF    ---->    EF

4.3 Incoming PHB Determination On Incoming L-LSP

   This section defines how Incoming PHB determination is 6-bit long
       [DIFF_HEADER] potentially allowing support of up to 64 Behavior
       Aggregates. So that carried out
   when more than a certain number of BAs are
       used (i.e., more than 8 BAs in case of Shim Header and more than
       2 BAs the considered label entry in case of ATM/Frame Relay), the DS field can not be
       mapped entirely into received label stack
   corresponds to an L-LSP. This requires that the appropriate field of MPLS encapsulation
       header (i.e., EXP field in case of Shim Header and CLP/DE field `Encaps-->PHB
   mapping' is populated as defined in case of ATM/Frame Relay);

    We define that:

     - an LSP established for section 4.2.

   When considering a given Forwarding Equivalent Class (FEC)
       may be used label entry corresponding to an incoming L-LSP
   for transport of Incoming PHB Determination, the BAs comprised in one Ordered
       Aggregate (OA) for that FEC;
     - all BAs LSR first determines the
   `Encaps-->PHB mapping' associated with -corresponding label.

4.3.1 `EXP-->PHB mapping'

   If the `Encaps-->PHB mapping' is of this OA can be transported over the LSP;
     - BAs from other OAs can not be transported over form `EXP-->PHB mapping',
   then the LSP; LSR:
     - BAs from determines the OA transported over incoming PHB by looking at the LSP are given EXP field of the
       appropriate scheduling treatment based on
       considered label entry and by using the PSC which EXP-->PHB mapping.

4.3.2 `CLP-->PHB mapping'

   If the `Encaps-->PHB mapping' is
       explicitly signaled at label set-up time. of the form `CLP-->PHB mapping',
   then the LSR:
     - Such an LSP is referred to as a "Label-Only-inferred-PSC" LSP or
       "L-LSP";
     - Multiple BAs from the OA transported over determines the LSP are granted
       different drop precedence incoming PHB by looking at the LSR based on the  appropriately
       encoded relevant CLP field of MPLS the
       ATM Layer encapsulation header (EXP field
       of and by using the top label entry for CLP-->PHB mapping.

4.3.3 `DE-->PHB mapping'

   If the shim header, CLP/DE bit in case `Encaps-->PHB mapping' is of ATM/Frame Relay); The mapping between the relevant form `DE-->PHB mapping',
   then the LSR:
     - determines the incoming PHB by looking at the DE field of the MPLS
       Frame Relay encapsulation and by using the drop precedence is a well-known DE-->PHB mapping.

   For a given FEC, there may be more than one L-LSP carrying the same
   OA, for example for purposes of load balancing of the OA. In that
   case, in order to respect ordering constraints, all packets of a
   given microflow must be transported over the same LSP.

   MPLS specifies how LSPs can be established via multiple signaling
   protocols. Those include the Label Distribution Protocol (LDP),
   RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP
   are to be used for establishment of L-LSPs.

4.2

4.4 Populating the `Encaps-->PHB mapping' `Set of PHB-->Encaps mappings' for an incoming outgoing L-LSP

   This section defines how the `Encaps-->PHB mapping' `Set of PHB-->Encaps mappings' of the
   Diff-Serv Context is populated at label setup for an incoming outgoing L-LSP
   in order to allow
   Incoming PHB determination.

 Le Faucheur et. al                                                 25
                      MPLS Support Encoding of Diff-Serv              June 2000

4.2.1 `EXP-->PHB Information.

4.4.1 `PHB-->EXP mapping'

   If the LSR terminates the uses an MPLS Shim Layer over this incoming L-LSP
   and the L-LSP ingresses on an interface which is not ATM nor Frame
   Relay, outgoing L-LSP, then
   one `PHB-->EXP mapping' is added to the `Encaps-->PHB `Set of
   PHB-->Encaps mappings' for this outgoing
   L-LSP. This `PHB-->EXP mapping' is populated at label setup in the following way:

 Le Faucheur et. al                                                 25
                      MPLS Support of Diff-Serv              July 2000

     - it must actually be a `EXP-->PHB mapping'
     - this mapping it is a function of the PSC which is carried supported on this LSP, and must use
       the relevant mapping entries relevant for this PSC from the Mandatory EXP/PSC-->PHB
       PHB-->EXP Mapping defined in Section 4.2.1.1. section 4.4.1.1.

   For example if the incoming outgoing label corresponds to an L-LSP supporting
   the AF1 PSC, then the `Encaps-->PHB following `PHB-->EXP mapping' will be populated with: is added into
   the `Set of PHB-->Encaps mappings':

        PHB                EXP Field

        AF11       ---->      000
        AF12       ---->      001
        AF13       ---->      010

4.4.1.1 Mandatory PHB-->EXP Mapping

        PHB                EXP Field

        DF         ---->      000
        CSn        ---->      000
        AFn1       ---->      000
        AFn2       ---->    AF11      001
        AFn3       ---->    AF12      010
        EF         ---->    AF13

   An LSR supporting L-LSPs over PPP interfaces and LAN interfaces      000

4.4.2 `PHB-->CLP mapping'

   If the L-LSP is egressing on an ATM interface (i.e. it is an example of ATM-LSR
   or it is a frame-based LSR terminating the Shim layer over ingress interfaces sending packets on an LC-ATM interface or
   on an ATM interface which are is not ATM nor Frame Relay.

   If the LSR terminates label switching controlled), then
   one `PHB-->CLP mapping' is added to the MPLS Shim Layer over `Set of PHB-->Encaps
   mappings' for this incoming L-LSP
   and outgoing L-LSP.

   If the L-LSP ingresses on is egressing over an ATM or Frame Relay interface which is not label-
   controlled, the `PHB-->CLP mapping' is populated as per section
   3.4.2.

   If the L-LSP is egressing over an LC-ATM interface, then the
   `Encaps-->PHB `PHB-->CLP
   mapping' is populated at label setup in the following way:
     - it should actually be a `EXP-->PHB mapping'. Alternative
       optional ways of populating the `Encaps-->PHB mapping' might be
       defined in the future (e.g., using a 'CLP/EXP--> PHB mapping' or
       a 'DE/EXP-->PHB mapping') but are outside the scope of this
       document.
     - when the `Encaps-->PHB mapping' is an `EXP-->PHB mapping', this
       `EXP-->PHB mapping' mapping is a function of the PSC which is
       carried supported on the L-LSP, and must this LSP, and should
       use the relevant mapping entries for this PSC from the Mandatory EXP/PSC-->PHB Default
       PHB-->CLP Mapping defined in
       Section 4.2.1.1.

   An Edge-LSR of section 3.4.2.1.

   Notice that if the LSR is a frame-based LSR supporting an ATM-MPLS domain or L-LSP
   egressing over an ATM interface, then the `Set of PHB-->Encaps
   mappings' contains both a FR-MPLS domain `PHB-->EXP mapping' and a `PHB-->CLP
   mapping'. If the LSR is an
   example of LSR terminating the shim layer over ATM-LSR supporting an ingress ATM/FR
   interface.

4.2.1.1 Mandatory EXP/PSC --> PHB mapping

      EXP Field      PSC             PHB

        000          DF    ---->    DF
        000          CSn   ---->    CSn
        000          AFn   ---->    AFn1
        001          AFn   ---->    AFn2
        010          AFn   ---->    AFn3 L-LSP, then the
   `Set of PHB-->Encaps mappings' only contains a `PHB-->CLP mapping'.

4.4.3 `PHB-->DE mapping'

 Le Faucheur et. al                                                 26
                      MPLS Support of Diff-Serv              June              July 2000

        000          EF    ---->    EF

4.2.2 `CLP-->PHB mapping'

   If the LSR does not terminate an MPLS Shim Layer L-LSP is egressing over this incoming
   label and uses ATM encapsulation a Frame Relay interface (i.e. it is
   an ATM-LSR), then the
   `Encaps-->PHB LSR sending packets on an LC-FR interface or on a Frame Relay
   interface which is not label switching controlled), one `PHB-->DE
   mapping' of is added to the Diff-Serv Context `Set of PHB-->Encaps mappings' for this incoming
   outgoing L-LSP.

   If the L-LSP is populated at egressing over a FR interface which is not label setup
   switching controlled, the `PHB-->DE mapping' is populated as per
   section 3.4.3.

   If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE
   mapping' is populated in the following way:
     - it is actually a `CLP-->PHB mapping'
     - the mapping is a function of the PSC which is carried supported on this LSP, and should
       use the relevant mapping entries for this PSC from the Default CLP/PSC-->PHB
       PHB-->DE Mapping defined in Section
       4.2.2.1.

   For example section 3.4.3.1.

   Notice that if the incoming label corresponds to LSR is an L-LSP Edge-LSR supporting
   the AF1 PSC, an L-LSP egressing
   over a LC-FR interface, then the `Encaps-->PHB mapping' should be populated
   with:

      CLP Field              PHB

        0          ---->    AF11
        1          ---->    AF12

4.2.2.1 Default CLP/PSC --> PHB Mapping

      CLP Bit      PSC             PHB

         0          DF    ---->    DF
         0          CSn   ---->    CSn
         0          AFn   ---->    AFn1
         1          AFn   ---->    AFn2
         0          EF    ---->    EF

4.2.3 `DE-->PHB `Set of PHB-->Encaps mappings'
   contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. If the
   LSR does not terminate an MPLS Shim Layer over this incoming
   label and uses Frame Relay encapsulation (i.e. it is a FR-LSR), FR-LSR supporting an L-LSP, then the `Encaps-->PHB mapping' `Set of the Diff-Serv Context for this
   incoming L-LSP is populated at label setup in the following way:
     - it is actually PHB-->Encaps
   mappings' only contains a `DE-->PHB `PHB-->DE mapping'.

4.4.4 `PHB-->802.1 mapping'
     -

   If the mapping LSP is egressing over a function of the PSC which is carried LAN interface on this
       LSP, and should use the relevant mapping entries for this PSC
       from the Default DE/PSC-->PHB Mapping which multiple 802.1
   Traffic Classes are supported as defined in Section
       4.2.3.1.

4.2.3.1 Default DE/PSC --> PHB Mapping

      DE Bit      PSC             PHB

         0          DF    ---->    DF
         0          CSn   ---->    CSn
         0          AFn   ---->    AFn1

 Le Faucheur et. al                                                 27
                      MPLS Support of [IEEE_802.1], then one
   `PHB-->802.1 mapping' is added as per section 3.4.4.

4.5 Encoding Diff-Serv              June 2000

         1          AFn   ---->    AFn2
         0          EF    ---->    EF

4.3 Incoming PHB Determination On Incoming Information into Encapsulation Layer on Outgoing
L-LSP

   This section defines how Incoming PHB determination is carried out
   when to encode Diff-Serv information into the considered
   MPLS encapsulation Layer for a transmitted label entry in the received label stack
   corresponds corresponding
   to an outgoing L-LSP. This requires that the `Encaps-->PHB
   mapping' `Set of PHB-->Encaps
   mappings' is populated as defined above in section 4.2.

   When considering a label entry corresponding to an incoming L-LSP
   for Incoming PHB Determination, the 4.4.

   The LSR first determines the
   `Encaps-->PHB mapping' `Set of PHB-->Encaps mappings' of the
   Diff-Serv Context associated with the incoming top level label.

4.3.1 `EXP-->PHB mapping'

   If the `Encaps-->PHB mapping' is of corresponding label in the form `EXP-->PHB mapping',
   NHLFE and then the LSR:
     - determines the incoming PHB by looking at the EXP field of the
       considered label entry performs corresponding encoding as specified in
   sections 3.5.1, 3.5.2, 3.5.3 and by using 3.5.4.

4.6 L-LSP Merging

   In an MPLS domain, two or more LSPs can be merged into one LSP at
   one LSR. L-LSPs are compatible with LSP Merging under the EXP-->PHB mapping.

4.3.2 `CLP-->PHB mapping'

   If following
   condition:

        L-LSPs can only be merged into one L-LSP if they support the `Encaps-->PHB mapping' is
        same PSC.

 Le Faucheur et. al                                                 27
                      MPLS Support of the form `CLP-->PHB mapping',
   then the LSR:
     - determines the incoming PHB Diff-Serv              July 2000

   The above merge condition MUST be enforced by looking LSRs through explicit
   checking at label setup that the CLP field of the
       ATM Layer encapsulation and by using the CLP-->PHB mapping.

4.3.3 `DE-->PHB mapping'

   If the `Encaps-->PHB mapping' same PSC is of the form `DE-->PHB mapping',
   then supported on the LSR:
     - determines merged
   LSPs.

   Note that when L-LSPs merge, the incoming PHB by looking at bandwidth that is available for the DE field
   PSC downstream of the
       Frame Relay encapsulation and by using the DE-->PHB mapping.

4.4 Populating merge point must be sufficient to carry the `Set
   sum of PHB-->Encaps mappings' for an outgoing L-LSP the merged traffic. This section defines how is particularly important in the `Set of PHB-->Encaps mappings'
   case of the
   Diff-Serv Context is populated for an outgoing L-LSP EF traffic. This can be ensured in order to
   allow Encoding of multiple ways (for
   instance via provisioning, or via bandwidth signaling and explicit
   admission control).

5. RSVP Extension for Diff-Serv Information.

4.4.1 `PHB-->EXP mapping'

   If the LSR uses an Support

   The MPLS Shim Layer over this outgoing L-LSP, then
   one `PHB-->EXP mapping' is added at architecture does not assume a single label setup to distribution
   protocol. [RSVP_MPLS_TE] defines the `Set of
   PHB-->Encaps mappings' extension to RSVP for
   establishing label switched paths (LSPs) in MPLS networks. This
   section specifies the extensions to RSVP, beyond those defined in
   [RSVP_MPLS_TE], to establish label switched path (LSPs) supporting
   Differentiated Services in MPLS networks.

5.1 Diff-Serv Context for this outgoing
   L-LSP. This `PHB-->EXP mapping' related RSVP Messages Format

   One new RSVP Object is populated defined in this document: the following way:
     - it is a function DIFFSERV
   Object. Detailed description of the PSC supported on this LSP, and must use Object is provided below. This
   new Object is applicable to Path messages. This specification only
   defines the mapping entries relevant for this PSC from use of the Mandatory
       PHB-->EXP Mapping DIFFSERV Object in Path messages used to
   establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus
   containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4
   and containing a LABEL_REQUEST object.

   Restrictions defined in section 4.4.1.1.

 Le Faucheur et. al                                                 28
                      MPLS Support [RSVP_MPLS_TE] for support of Diff-Serv              June 2000

   For example if the outgoing label corresponds establishment
   of LSP Tunnels via RSVP are also applicable to an L-LSP supporting
   the AF1 PSC, then the following `PHB-->EXP mapping' is added into
   the `Set establishment of PHB-->Encaps mappings':

        PHB                EXP Field

        AF11       ---->      000
        AF12       ---->      001
        AF13       ---->      010

4.4.1.1 Mandatory PHB-->EXP Mapping

        PHB                EXP Field

        DF         ---->      000
        CSn        ---->      000
        AFn1       ---->      000
        AFn2       ---->      001
        AFn3       ---->      010
        EF         ---->      000

4.4.2 `PHB-->CLP mapping'

   If the L-LSP is egressing on an ATM interface (i.e. it is an ATM-LSR
   or it is a frame-based LSR sending packets on an LC-ATM interface or
   on an ATM interface which
   LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs
   are supported and Multicast LSPs are for further study.

   This new DIFFSERV object is optional with respect to RSVP so that
   general RSVP implementations not label switching controlled), then
   one `PHB-->CLP mapping' is added at label setup concerned with MPLS LSP set up do
   not have to the `Set support this object.

   The DIFFSERV Object is optional for support of
   PHB-->Encaps mappings' LSP Tunnels as
   defined in the [RSVP_MPLS_TE]. A Diff-Serv Context for this outgoing
   L-LSP.

   If the L-LSP is egressing over an LC-ATM interface, capable LSR supporting E-LSPs
   using the `PHB-->CLP
   mapping' is populated preconfigured EXP<-->PHB mapping in the following way:
     - it is a function of the PSC supported on compliance with this LSP, and should
       use
   specification MAY support the relevant DIFFSERV Object. A Diff-Serv capable
   LSR supporting E-LSPs using a signaled EXP<-->PHB mapping entries for this PSC from the Default
       PHB-->CLP Mapping defined in section 3.4.2.1.

   For example if
   compliance with this specification MUST support the outgoing label corresponds to an L-LSP DIFFSERV Object.
   A Diff-Serv capable LSR supporting L-LSPs in compliance with this
   specification MUST support the AF1 PSC, then the `PHB-->CLP mapping' should be populated with:

        PHB                CLP Field

        AF11       ---->      0
        AF12       ---->      1
        AF13       ---->      1

   If the L-LSP is egressing over an ATM interface which is not label
   switching controlled, the `PHB-->CLP mapping' is populated in the
   following way:
     - it is a function DIFFSERV Object.

5.1.1 Path Message Format

   The format of the PSC supported on this LSP, and may use
       the relevant mapping entries for this PSC from the Default
       PHB-->CLP Mapping defined in section 3.4.2.1. Other mappings
       than the one defined in section 3.4.2.1 may be used. In Path message is as follows:

 Le Faucheur et. al                                                 29                                                 28
                      MPLS Support of Diff-Serv              June              July 2000

       particular, if a mapping from PHBs to CLP

         <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                                  <SESSION> <RSVP_HOP>
                                  <TIME_VALUES>
                                  [ <EXPLICIT_ROUTE> ]
                                  <LABEL_REQUEST>
                                  [ <SESSION_ATTRIBUTE> ]
                                  [ <DIFFSERV> ]
                                  [ <POLICY_DATA> ... ]
                                  [ <sender descriptor> ]

         <sender descriptor> ::=  <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
                                  [ <ADSPEC> ]
                                  [ <RECORD_ROUTE> ]

5.2 DIFFSERV Object

   The DIFFSERV object formats are shown below. Currently there are two
   possible C_Types. Type 1 is standardized in the
       future a DIFFSERV object for operations of Diff-Serv over ATM, such standardized
       mapping may then be used.

   Notice that if the LSR an E-LSP. Type 2
   is a frame-based LSR supporting an L-LSP
   egressing over DIFFSERV object for an ATM interface, then the `Set of PHB-->Encaps
   mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP
   mapping'. If the LSR is L-LSP.

5.2.1. DIFFSERV object for an ATM-LSR supporting E-LSP:

   class = TBD, C_Type = 1  (need to get an L-LSP, then official class num from the
   `Set of PHB-->Encaps mappings' only contains a `PHB-->CLP mapping'.

4.4.3 `PHB-->DE mapping'

   If
   IANA with the L-LSP is egressing over a Frame Relay interface (i.e. it is
   an LSR sending packets on an LC-FR interface or on a Frame Relay
   interface which is not label switching controlled), one `PHB-->DE
   mapping' form 0bbbbbbb)

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved                                       | MAPnb |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (1)                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                               ...                            //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (MAPnb)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 28 bits
       This field is added at label setup reserved. It must be set to the `Set of PHB-->Encaps
   mappings' in the Diff-Serv Context for this outgoing L-LSP.

   If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE
   mapping' is populated in the following way:
     - it is a function of the PSC supported zero on this LSP, transmission
       and should
       use must be ignored on receipt.

     MAPnb : 4 bits
       Indicates the relevant mapping number of MAP entries for this PSC from the Default
       PHB-->DE Mapping defined included in section 3.4.3.1.

   If the L-LSP is egressing over a FR interface which is not label
   switching controlled, DIFFSERV
       Object. This can be set to any value from 1 to 8.

     MAP : 32 bits
       Each MAP entry defines the `PHB-->DE mapping' is populated in mapping between one EXP field value
       and one PHB. The MAP entry has the following way:
     - it is a function of the PSC supported format:

 Le Faucheur et. al                                                 29
                      MPLS Support of Diff-Serv              July 2000

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved     | EXP |             PHBID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Reserved : 13 bits
               This field is reserved. It must be set to zero on this LSP,
               transmission and may use must be ignored on receipt.

           EXP : 3 bits
               This field contains the relevant mapping entries value of the EXP field for this PSC from the Default
       PHB-->DE Mapping
               EXP<-->PHB mapping defined in section 3.4.3.1. Other mappings than this MAP entry.

           PHBID : 16 bits
               This field contains the one PHBID of the PHB for the
               EXP<-->PHB mapping defined in section 3.4.3.1 may be used. In particular,
       if a mapping from PHBs to DE this MAP entry. The PHBID
               is standardized encoded as specified in the future for
       operations section 2 of Diff-Serv over Frame Relay, such standardized
       mapping may then be used.

   Notice that if the LSR is an Edge-LSR supporting [PHBID].

5.2.2 DIFFSERV object for an L-LSP egressing
   over a LC-FR interface, then the `Set of PHB-->Encaps mappings'
   contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. If the
   LSR L-LSP:

   class = TBD, C_Type = 2  (class num is a FR-LSR supporting an L-LSP, then the `Set of PHB-->Encaps
   mappings' only contains a `PHB-->DE mapping'.

4.4.4 `PHB-->802.1 mapping'

   If the L-LSP is egressing over a LAN interface on which multiple
   802.1 Traffic Classes are supported same as defined in [IEEE_802.1], then
   one `PHB-->802.1 mapping' DIFFSERV object
   for E-LSP))

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved               |             PSC               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 16 bits
       This field is added at label setup reserved. It must be set to zero on transmission
       and must be ignored on receipt.

     PSC : 16 bits
        The PSC indicates a PHB Scheduling Class to be supported by the `Set of
   PHB-->Encaps mappings'
        LSP. The PSC is encoded as specified in section 2 of [PHBID]:
            - Where the Diff-Serv Context PSC comprises a single PHB defined by standards
        action, the encoding for the PSC is the encoding for this outgoing
   L-LSP. This `PHB-->802.1 mapping'
        single PHB. It is populated the recommended DSCP value for that PHB,
        left-justified in the following way: 16-bit field, with bits 6 through 15 set
        to zero.
           - it is a function of Where the PSC supported on this LSP, and uses comprises multiple PHBs defined by standards
        action, the
       relevant mapping entries for this PSC from encoding is the Preconfigured
       `PHB-->802.1 mapping' defined above in section 3.4.4.1.

 Le Faucheur et. al                                                 30
                      MPLS Support encoding for this set of Diff-Serv              June 2000

   Notice that if the LSR PHB.
        It is supporting an L-LSP egressing over a LAN
   interface supporting multiple 802.1 Traffic Classes, then the `Set smallest numerical value of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' the recommended DSCP for
        the various PHBs in the PSC, left-justified in the 16 bit
        field, with bits 6 through 13 and a
   `PHB-->802.1 mapping'.

4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing
L-LSP

   This section defines how bit 15 set to encode Diff-Serv information into the
   MPLS encapsulation Layer for a transmitted label entry corresponding zero and with
        bit 14 set to an outgoing L-LSP. This requires that one.

       For instance, the `Set encoding of PHB-->Encaps
   mappings' is populated as defined above in section 4.4.

   The LSR first determines the `Set of PHB-->Encaps mappings' EF PSC is :
              0                   1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

 Le Faucheur et. al                                                 30
                      MPLS Support of the Diff-Serv Context associated with the corresponding label in the
   NHLFE.

4.5.1 `PHB-->EXP mapping'

   If              July 2000

             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0|
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       For instance, the `Set of PHB-->Encaps mappings' encoding of the transmitted label
   contains AF1 PSC is :
              0                   1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0|
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3 Handling DIFFSERV Object

   To establish an LSP tunnel with RSVP, the sender creates a mapping Path
   message with a session type of LSP_Tunnel_IPv4 and with a
   LABEL_REQUEST object as per [RSVP_MPLS_TE].

   To establish with RSVP an E-LSP tunnel which uses the form `PHB-->EXP mapping', then Preconfigured
   EXP<-->PHB mapping, the LSR: sender creates a Path message:
     - determines the value to be written in the EXP field with a session type of LSP_Tunnel_IPv4,
     - with the
       corresponding level label entry by looking up the "outgoing PHB"
       in this PHB-->EXP mapping table.

4.5.2 `PHB-->CLP mapping'

   If LABEL_REQUEST object, and
     - without the `Set of PHB-->Encaps mappings' of DIFFSERV object.

   To establish with RSVP an E-LSP tunnel which uses a signaled EXP<--
   >PHB mapping, the transmitted label
   contains sender creates a mapping Path message :
     - with a session type of LSP_Tunnel_IPv4,
     - with the form `PHB-->CLP mapping', then the LSR: LABEL_REQUEST object,
     - determines with the DIFFSERV object for an E-LSP containing one MAP entry
       for each EXP value to be written in the CLP field of the ATM
       Layer encapsulation by looking up the "outgoing PHB" in supported on this
       PHB-->CLP mapping table.

4.5.3 `PHB-->DE mapping'

   If the `Set of PHB-->Encaps mappings' of E-LSP.

   To establish with RSVP an L-LSP tunnel, the transmitted label
   contains sender creates a mapping Path
   message:
     - with a session type of the form `PHB-->DE mapping', then the LSR: LSP_Tunnel_IPv4,
     - determines the value to be written in with the DE field of LABEL_REQUEST object,
     - with the Frame
       Relay encapsulation by looking up DIFFSERV object for an L-LSP containing the "outgoing PHB" in PHB
       Scheduling Class (PSC) supported on this
       PHB-->DE mapping table.

4.5.4 `PHB-->802.1 mapping' L-LSP.

   If the `Set of PHB-->Encaps mappings' of the transmitted label
   contains a mapping  of path message contains multiple DIFFSERV objects, only the form `PHB-->802.1 mapping', then first
   one is meaningful; subsequent DIFFSERV object(s) must be ignored and
   not forwarded.

   Each LSR along the LSR:
     - determines path records the value to be written DIFFSERV object, when present,
   in the User_Priority field its path state block.

   The destination LSR of an E-LSP or L-LSP responds to the Tag Control Information of Path
   message containing the 802.1 encapsulation header
       [IEEE_802.1] LABEL_REQUEST object by looking up sending a Resv
   message:
     - with the "outgoing PHB" in this
       PHB-->802.1 mapping table.

4.6 L-LSP Merging LABEL object
     - without a DIFFSERV object.

   Assuming the label request is accepted and a label is allocated, the
   Diff-Serv LSRs (sender, destination, intermediate nodes) must:

 Le Faucheur et. al                                                 31
                      MPLS Support of Diff-Serv              June              July 2000

   In an MPLS domain, two or more LSPs can be merged into one LSP at
   one LSR. The proposed support of

     - update the Diff-Serv in MPLS is compatible Context associated with LSP Merging under the following condition:

        L-LSPs can only be merged into one L-LSP if they support the
        same PSC.

   The above merge condition MUST be enforced by LSRs through explicit
   checking at label setup that the same PSC is supported on established
       LSPs in their ILM/FTN as specified in previous sections
       (incoming and outgoing label),
     - install the merged
   LSPs.

   Note required Diff-Serv forwarding treatment (scheduling
       and dropping behavior) for this NHLFE (outgoing label).

   An LSR that when L-LSPs merge, recognizes the bandwidth DIFFSERV object and that is available for receives a path
   message which contains the
   PSC downstream DIFFSERV object but which does not
   contain a LABEL_REQUEST object or which does not have a session type
   of LSP_Tunnel_IPv4, sends a PathErr towards the merge point must be sufficient to carry sender with the
   sum
   error code `Diff-Serv Error' and an error value of the merged traffic. This is particularly important `Unexpected
   DIFFSERV object'. Those are defined below in section 5.5.

   An LSR receiving a Path message with the
   case of EF traffic. This can be ensured DIFFSERV object for E-LSP,
   which recognizes the DIFFSERV object but does not support the
   particular PHB encoded in multiple ways (for
   instance via provisioning, one, or via bandwidth signaling and explicit
   admission control).

5. RSVP Extension for Diff-Serv Support

   The MPLS architecture does not assume more, of the MAP entries, sends a single label distribution
   protocol. [RSVP_MPLS_TE] defines
   PathErr towards the extension to RSVP for
   establishing label switched paths (LSPs) in MPLS networks. This
   section specifies sender with the extensions to RSVP, beyond those error code `Diff-Serv Error' and
   an error value of `Unsupported PHB'. Those are defined below in
   [RSVP_MPLS_TE], to establish label switched path (LSPs) supporting
   Differentiated Services in MPLS networks.

5.1 Diff-Serv related RSVP Messages Format

   One new RSVP Object
   section 5.5.

   An LSR receiving a Path message with the DIFFSERV object for E-LSP,
   which recognizes the DIFFSERV object but determines that the
   signaled EXP<-->PHB mapping is invalid, sends a PathErr towards the
   sender with the error code `Diff-Serv Error' and an error value of
   `Invalid EXP<-->PHB mapping'. Those are defined below in section
   5.5. The EXP<-->PHB mapping signaled in this document: the DIFFSERV
   Object. Detailed description of this Object for an
   E-LSP is provided below. This
   new Object invalid when:
     - the MAPnb field is applicable not within the range 1 to 8 or
     - a given EXP value appears in more than one MAP entry, or
     - the PHBID encoding is invalid.

   An LSR receiving a Path messages. This specification only
   defines message with the use of DIFFSERV object for L-LSP,
   which recognizes the DIFFSERV Object in Path messages used to
   establish LSP Tunnels object but does not support the
   particular PSC encoded in accordance with [RSVP_MPLS_TE] and thus
   containing the PSC field, sends a Session Object PathErr towards the
   sender with a C-Type equal to LSP_TUNNEL_IPv4 the error code `Diff-Serv Error' and containing a LABEL_REQUEST object.

   Restrictions defined in [RSVP_MPLS_TE] for support of establishment an error value of LSP Tunnels via RSVP
   `Unsupported PSC'. Those are also applicable to defined below in section 5.5.

   An LSR receiving a Path message with the DIFFSERV object, which
   recognizes the establishment of
   LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs
   are supported and Multicast LSPs are for further study.

   This new DIFFSERV object but that is optional with respect unable to RSVP so that
   general RSVP implementations not concerned allocate the
   required per-LSP Diff-Serv context sends a PathErr with MPLS LSP set up do
   not have to support this object.

   The DIFFSERV Object is optional for support of LSP Tunnels as the error
   code "Diff-Serv Error" and the error value "Per-LSP context
   allocation failure". Those are defined below in [RSVP_MPLS_TE]. section 5.5.

   A Diff-Serv capable LSR supporting E-LSPs
   using MUST handle the preconfigured EXP<-->PHB mapping situations where the label request
   can not be accepted for other reasons than those already discussed
   in compliance with this
   specification MAY support section, in accordance with [RSVP_MPLS_TE] (e.g. reservation
   rejected by admission control, a label can not be associated).

5.4 Non-support of the DIFFSERV Object. A Diff-Serv capable Object

   An LSR supporting E-LSPs using a signaled EXP<-->PHB mapping that does not recognize the DIFFSERV object Class-Num must
   behave in accordance with the procedures specified in [RSVP] for an

 Le Faucheur et. al                                                 32
                      MPLS Support of Diff-Serv              June              July 2000

   compliance

   unknown Class-Num whose format is 0bbbbbbb i.e. it must send a
   PathErr with this specification MUST support the DIFFSERV Object.
   A Diff-Serv capable error code `Unknown object class' toward the
   sender.

   An LSR supporting L-LSPs in compliance with this
   specification MUST support that recognize the DIFFSERV Object.

5.1.1 Path Message Format

   The format of the Path message is as follows:

         <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                                  <SESSION> <RSVP_HOP>
                                  <TIME_VALUES>
                                  [ <EXPLICIT_ROUTE> ]
                                  <LABEL_REQUEST>
                                  [ <SESSION_ATTRIBUTE> ]
                                  [ <DIFFSERV> ]
                                  [ <POLICY_DATA> ... ]
                                  [ <sender descriptor> ]

         <sender descriptor> ::=  <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
                                  [ <ADSPEC> ]
                                  [ <RECORD_ROUTE> ]

5.2 DIFFSERV Object

   The DIFFSERV object formats are shown below. Currently there are two
   possible C_Types. Type 1 is a Class-Num but does not
   recognize the DIFFSERV object C-Type, must behave in accordance with
   the procedures specified in [RSVP] for an E-LSP. Type 2
   is unknown C-type i.e. It
   must send a DIFFSERV PathErr with the error code `Unknown object for an L-LSP.

5.2.1. C-Type'
   toward the sender.

   In both situations, this causes the path set-up to fail. The sender
   should notify management that a L-LSP cannot be established and
   possibly take action to retry LSP establishment without the DIFFSERV
   object for an E-LSP:

   class = TBD, C_Type = 1  (need (e.g. attempt to get an official class num from the
   IANA use E-LSPs with Preconfigured EXP<-->PHB
   mapping as a fall-back strategy).

5.5 Error Codes For Diff-Serv

   In the form 0bbbbbbb)

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 procedures described above, certain errors must be reported
   as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error
   code is TBD (number to be allocated by IANA)).

   The following defines error values for the Diff-Serv Error:

       Value    Error

        1       Unexpected DIFFSERV object
        2       Unsupported PHB
        3       Invalid EXP<-->PHB mapping
        4       Unsupported PSC
        5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved                                       | MAPnb |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (1)                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                               ...                            //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (MAPnb)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 28 bits
       This field is reserved. It must be set to zero on transmission       Per-LSP context allocation failure

5.6 Use of COS Service with E-LSPs and must L-LSPs

   Both E-LSPs and L-LSPs can be ignored on receipt.

     MAPnb : 4 bits established with bandwidth reservation
   or without bandwidth reservation.

   To establish an E-LSP or an L-LSP with bandwidth reservation, Int-
   Serv's Controlled Load service (or possibly Guaranteed Service) is
   used and the bandwidth is signaled in the SENDER_TSPEC (respectively
   FLOWSPEC) of the path (respectively Resv) message.

   To establish an E-LSP or an L-LSP without bandwidth reservation, the
   Class of Service service defined in [RSVP_MPLS_TE] is used.

   Note that this specification defines usage of E-LSPs and L-LSPs
   for support of the Diff-Serv service only. Regardless of whether the
   signaling messages actually indicate an Int-Serv service of COS, GS
   or CL and regardless of whether the signaling messages contain a
   signaled bandwidth reservation or not, E-LSPs and L-LSPs are defined
   here for support of Diff-Serv services. Support of Int-Serv services

 Le Faucheur et. al                                                 33
                      MPLS Support of Diff-Serv              June              July 2000

       Indicates

   over an MPLS Diff-Serv backbone is outside the number scope of MAP entries included in the this
   specification.

   A Path message containing a COS SENDER_TSPEC and not containing a
   DIFFSERV
       Object. This can be set object indicates to any value from 1 a Diff-Serv capable LSR that the LSP to 8.

     MAP : 32 bits
       Each MAP entry defines
   be established is an E-LSP using the Preconfigured mapping between one EXP field value and one PHB. The MAP entry has the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved     | EXP |             PHBID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Reserved : 13 bits
               This field is reserved. It must be set to zero on
               transmission
   without any bandwidth reservation.

   A Path message containing a COS SENDER_TSPEC and must be ignored on receipt.

           EXP : 3 bits
               This field contains the value of the EXP field for the
               EXP<-->PHB mapping defined in this MAP entry.

           PHBID : 16 bits
               This field contains the PHBID of the PHB containing a
   DIFFSERV object for E-LSP indicates to a Diff-Serv capable LSR that
   the
               EXP<-->PHB mapping defined in this MAP entry. The PHBID LSP to be established is encoded as specified in section 2 of [PHBID].

5.2.2 an E-LSP using a signaled mapping and
   without any bandwidth reservation.

   A Path message containing a COS SENDER_TSPEC and containing a
   DIFFSERV object for L-LSP indicates to a Diff-Serv capable LSR that
   the LSP to be established is an L-LSP:

   class = TBD, C_Type = 2  (class num L-LSP without any bandwidth
   reservation.

   The above is summarized in the same as following table:

           Path Message  LSP type
    Service  DIFFSERV object
   for E-LSP))

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved               |             PSC               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 16 bits
       This field is reserved. It must be set to zero on transmission
       and must be ignored on receipt.

     PSC : 16 bits
        The PSC indicates a PHB Scheduling Class to be supported by the
        LSP. The PSC is encoded as specified in section 2 of [PHBID]:
              Object

     GS/CL     No        E-LSP + preconf mapping + bandw reservation
     GS/CL   Yes/E-LSP   E-LSP + signaled mapping + bandw reservation
     GS/CL   Yes/L-LSP   L-LSP + bandw reservation
     COS       No        E-LSP + preconf mapping + no bandw reservation
     COS     Yes/E-LSP   E-LSP + signaled mapping + no band reservation
     COS     Yes/L-LSP   L-LSP + no bandw reservation

   Where:
        - Where the PSC comprises GS stands for Guaranteed Service
        - CL stands for Controlled Load
        - COS stands for COS service

   When processing a single PHB defined by standards
        action, the encoding path (respectively Resv) message for an E-LSP or
   an L-LSP using the PSC is COS service, a Diff-Serv capable LSR must ignore
   the encoding value of the COS field within a COS SENDER_TSPEC (respectively a
   COS FLOWSPEC).

6. LDP Extensions for this Diff-Serv Support

   The MPLS architecture does not assume a single PHB. It is label distribution
   protocol. [LDP] defines the recommended DSCP value Label Distribution Protocol and its
   usage for that PHB,
        left-justified establishment of label switched paths (LSPs) in MPLS
   networks. This section specifies the 16-bit field, with bits 6 through 15 set extensions to zero.
           - Where the PSC comprises multiple PHBs LDP to establish
   label switched path (LSPs) supporting Differentiated Services in
   MPLS networks.

   One new LDP TLV is defined by standards
        action, the PSC encoding is the encoding for in this set of PHB.
        It is the smallest numerical value of the recommended DSCP for document:

 Le Faucheur et. al                                                 34
                      MPLS Support of Diff-Serv              June              July 2000

        - the various PHBs in Diff-Serv TLV
   Detailed description of this TLV is provided below.

   The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv
   capable LSR supporting E-LSPs which uses the PSC, left-justified Preconfigured
   EXP<-->PHB mapping in compliance with this specification MAY support
   the 16 bit
        field, Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which
   uses the signaled EXP<-->PHB mapping in compliance with bits 6 through 13 and bit 15 set to zero and this
   specification MUST support the Diff-Serv TLV. A Diff-Serv capable
   LSR supporting L-LSPs in compliance with
        bit 14 set to one.

       For instance, this specification MUST
   support the encoding of Diff-Serv TLV.

6.1 Diff-Serv TLV

   The Diff-Serv TLV has the EF PSC is : following formats:
   Diff-Serv TLV for an E-LSP:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0|
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       For instance, the encoding of the AF1 PSC is :
              0                   1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |0 0 1 0 1 0|0 0 0 0 0 0 0 6 7 8 9 0 1 0|
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3 Handling
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F|  Diff-Serv Object

   To establish an (0x901)        |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|        Reserved                                     | MAPnb |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            MAP (1)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            MAP (MAPnb)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     T:1 bit
       LSP tunnel with RSVP, the sender creates a Path
   message with a session type of LSP_Tunnel_IPv4 and with a
   LABEL_REQUEST object as per [RSVP_MPLS_TE].
   Where the sender supports Diff-Serv, Type. This is set to establish with RSVP 0 for an E-LSP
   tunnel which uses the Preconfigured EXP<-->PHB mapping,

     Reserved : 27 bits
       This field is reserved. It must be set to zero on transmission
       and must be ignored on receipt.

     MAPnb : 4 bits
       Indicates the sender
   creates a Path message:
     - with a session type number of LSP_Tunnel_IPv4,
     - with the LABEL_REQUEST object, and
     - without MAP entries included in the DIFFSERV object.

   Where the sender supports Diff-Serv,
       Object. This can be set to establish with RSVP an E-LSP
   tunnel which uses a signaled EXP<-->PHB mapping, the sender creates
   a Path message any value from 1 to 8.

     MAP :
     - with a session type of LSP_Tunnel_IPv4,
     - with the LABEL_REQUEST object,
     - with 32 bits
       Each MAP entry defines the DIFFSERV object for an E-LSP containing mapping between one EXP field value
       and one PHB. The MAP entry
       for each has the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved     | EXP value |             PHBID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Le Faucheur et. al                                                 35
                      MPLS Support of Diff-Serv              July 2000

           Reserved : 13 bits
               This field is reserved. It must be set to zero on
               transmission and must be supported ignored on this E-LSP.

   Where receipt.

           EXP : 3 bits
               This field contains the sender supports Diff-Serv, to establish with RSVP an L-LSP
   tunnel, value of the sender creates a Path message:
     - with a session type of LSP_Tunnel_IPv4,
     - with the LABEL_REQUEST object,
     - with the DIFFSERV object EXP field for an L-LSP containing the PHB
       Scheduling Class (PSC) supported on
               EXP<-->PHB mapping defined in this L-LSP.

   If a path message MAP entry.

           PHBID : 16 bits
               This field contains multiple DIFFSERV objects, only the first
   one is meaningful; subsequent DIFFSERV object(s) must be ignored and
   not forwarded.

   Each node along PHBID of the path records PHB for the DIFFSERV object, when present,
               EXP<-->PHB mapping defined in its path state block.

 Le Faucheur et. al                                                 35
                      MPLS Support of Diff-Serv              June 2000 this MAP entry. The destination node PHBID
               is encoded as specified in section 2 of [PHBID].

   Diff-Serv TLV for an L-LSP:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| Type = PSC (0x901)        |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|        Reserved             |              PSC              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     T:1 bit
       LSP Type. This is set to 1 for an E-LSP or L-LSP responds

     Reserved : 15 bits
       This field is reserved. It must be set to the Path
   message containing the LABEL_REQUEST object by sending zero on transmission
       and must be ignored on receipt.

     PSC : 16 bits
        The PSC indicates a Resv
   message:
     - with PHB Scheduling Class to be supported by the LABEL object
        LSP. The PSC is encoded as specified in section 2 of [PHBID]:
            - without Where the PSC comprises a DIFFSERV object.

   Assuming single PHB defined by standards
        action, the reservation encoding for the PSC is accepted and a label the encoding for this
        single PHB. It is associated with the reservation, recommended DSCP value for that PHB,
        left-justified in the Diff-Serv LSRs (sender, destination,
   intermediate nodes) must: 16-bit field, with bits 6 through 15 set
        to zero.
           - update Where the Diff-Serv Context associated with PSC comprises multiple PHBs defined by standards
        action, the established
       LSPs in their ILM/FTN as specified in previous sections
       (incoming and outgoing label),
     - install PSC encoding is the required Diff-Serv forwarding treatment (scheduling
       and dropping behavior) encoding for this NHLFE (outgoing label).

   An RSVP router that does recognizes the DIFFSERV object and that
   receives a path message which contains the DIFFSERV object but which
   does not contain a LABEL_REQUEST object or which does not have a
   session type set of LSP_Tunnel_IPv4, sends a PathErr towards the sender
   with PHB.
        It is the error code `Diff-Serv Error' and an error smallest numerical value of
   `Unexpected DIFFSERV object'. Those are defined below in section
   5.5.

   A node receiving a Path message with the DIFFSERV object recommended DSCP for E-LSP,
   which recognizes the DIFFSERV object but does not support
        the
   particular PHB encoded various PHBs in one, or more, of the MAP entries, sends a
   PathErr towards PSC, left-justified in the sender 16 bit
        field, with the error code `Diff-Serv Error' bits 6 through 13 and bit 15 set to zero and
   an error value of `Unsupported PHB'. Those are defined below in
   section 5.5.

   A node receiving a Path message with
        bit 14 set to one.

       For instance, the DIFFSERV object for E-LSP,
   which recognizes the DIFFSERV object but determines that encoding of the
   signaled EXP<-->PHB mapping EF PSC is invalid, sends a PathErr towards the
   sender with the error code `Diff-Serv Error' and an error value of
   `Invalid EXP<-->PHB mapping'. Those are defined below in section
   5.5. The EXP<-->PHB mapping signaled in the DIFFSERV Object for an
   E-LSP is invalid when:
     - the MAPnb field is not within the range :
              0                   1 to
              0 1 2 3 4 5 6 7 8 or
     - a given EXP value appears in more than one MAP entry, or
     - the PHBID encoding is invalid.

   A node receiving a Path message with the DIFFSERV object for L-LSP,
   which recognizes the DIFFSERV object but does not support the
   particular PSC encoded in the PSC field, sends a PathErr towards the
   sender with the error code `Diff-Serv Error' and an error value of
   `Unsupported PSC'. Those are defined below in section 5.5.

   A Diff-Serv LSR MUST handle the situations where the reservation can
   not be accepted for other reasons than those already discussed in
   this section, in accordance with [RSVP_MPLS_TE] (eg. reservation
   rejected by admission control, a label can not be associated). 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0|

 Le Faucheur et. al                                                 36
                      MPLS Support of Diff-Serv              June              July 2000

5.4 Non-support of the Diff-Serv Object

   An RSVP router that does not recognize

             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       For instance, the DIFFSERV object Class-Num
   must behave in accordance with encoding of the procedures specified in [RSVP]
   for an unknown Class-Num whose format AF1 PSC is 0bbbbbbb ie. it must send a
   PathErr with the error code `Unknown object class' toward the
   sender.

   An RSVP router that recognizes the DIFFSERV object Class-Num but
   does not recognize the DIFFSERV object C-Type, must behave in
   accordance with the procedures specified in [RSVP] for an unknown C-
   type ie. It must send a PathErr with the error code `Unknown object
   C-Type' toward the sender.

   In both situations, this causes the path set-up to fail. The sender
   should notify management that a L-LSP cannot be established and
   possibly take action to retry reservation establishment without the
   DIFFSERV object (eg. attempt to use E-LSPs with Preconfigured
   EXP<-->PHB mapping as a fall-back strategy).

5.5 Error Codes For :
              0                   1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0|
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.2 Diff-Serv

   In the procedures described above, certain errors must be reported
   as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error
   code is 26 (TBD). Status Code Values

   The following defines error values are defined for the Diff-Serv Error:

       Value    Error

        1 Status Code field of the
   Status TLV:

        Status Code                             E   Status Data

        Unexpected DIFFSERV object
        2 Diff-Serv TLV                0   0x01000001
        Unsupported PHB
        3                         0   0x01000002
        Invalid EXP<-->PHB mapping
        4              0   0x01000003
        Unsupported PSC

5.6 Use                         0   0x01000004
        Per-LSP context allocation failure      0   0x01000005

6.3 Diff-Serv Related LDP Messages

6.3.1 Label Request Message

   The format of COS Service with E-LSPs and L-LSPs

   Both E-LSPs and L-LSPs can be established with bandwidth reservation
   or without bandwidth reservation.

   To establish an E-LSP or an L-LSP with bandwidth reservation, Int-
   Serv's Controlled Load service (or possibly Guaranteed Service) is
   used and the bandwidth Label Request message is signaled in the SENDER_TSPEC (respectively
   FLOWSPEC) of the path (respectively Resv) message.

   To establish an E-LSP or an L-LSP without bandwidth reservation, the
   Class of Service service defined in [RSVP_MPLS_TE] is used.

   Note that this specification defines usage of E-LSPs and L-LSPs
   for support of extended as follows, to
   optionally include the Diff-Serv service only. Regardless TLV:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Request (0x0401)    |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Diff-Serv TLV (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.2 Label Mapping Message

   The format of whether the
   signaling messages actually indicate an Int-Serv service of COS, GS
   or CL and regardless of whether Label Mapping message is extended as follows, to
   optionally include the signaling messages contain a Diff-Serv TLV:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Mapping (0x0400)    |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |

 Le Faucheur et. al                                                 37
                      MPLS Support of Diff-Serv              June              July 2000

   signaled bandwidth reservation or not, E-LSPs and L-LSPs are defined
   here for support of

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Diff-Serv services. Support TLV (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.3 Label Release Message

   The format of Int-Serv services
   over an MPLS Diff-Serv backbone is outside the scope of this
   specification.

   A Path Label Release message containing a COS SENDER_TSPEC and not containing a
   DIFFSERV object indicates to a Diff-Serv capable LSR that the LSP to
   be established is an E-LSP using the Preconfigured mapping and
   without any bandwidth reservation.

   A Path message containing a COS SENDER_TSPEC and containing a
   DIFFSERV object for E-LSP indicates to a Diff-Serv capable LSR that
   the LSP to be established is an E-LSP using a signaled mapping and
   without any bandwidth reservation.

   A Path message containing a COS SENDER_TSPEC and containing a
   DIFFSERV object for L-LSP indicates to a Diff-Serv capable LSR that
   the LSP to be established is an L-LSP without any bandwidth
   reservation.

   The above is summarized in the following table:

           Path Message  LSP type
    Service  DIFFSERV
              Object

     GS/CL     No        E-LSP + preconf mapping + bandw reservation
     GS/CL   Yes/E-LSP   E-LSP + signaled mapping + bandw reservation
     GS/CL   Yes/L-LSP   L-LSP + bandw reservation
     COS       No        E-LSP + preconf mapping + no bandw reservation
     COS     Yes/E-LSP   E-LSP + signaled mapping + no band reservation
     COS     Yes/L-LSP   L-LSP + no bandw reservation

   Where:
        - GS stands for Guaranteed Service
        - CL stands for Controlled Load
        - COS stands for COS service

   When processing a path (respectively Resv) message for an E-LSP or
   an L-LSP using the COS service, a Diff-Serv capable LSR must ignore
   the value of the COS field within a COS SENDER_TSPEC (respectively a
   COS FLOWSPEC).

6. LDP Extensions for Diff-Serv Support

   The MPLS architecture does not assume a single label distribution
   protocol. [LDP] defines the Label Distribution Protocol and its
   usage for establishment of label switched paths (LSPs) in MPLS
   networks. This section specifies the extensions to LDP to establish
   label switched path (LSPs) supporting Differentiated Services in
   MPLS networks.

 Le Faucheur et. al                                                 38
                      MPLS Support of Diff-Serv              June 2000

   One new LDP TLV is defined in this document:
        - the Diff-Serv TLV
   Detailed description of this TLV is provided below.

   The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv
   capable LSR supporting E-LSPs which uses the Preconfigured
   EXP<-->PHB mapping in compliance with this specification MAY support
   the Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which
   uses the signaled EXP<-->PHB mapping in compliance with this
   specification MUST support the Diff-Serv TLV. A Diff-Serv capable
   LSR supporting L-LSPs in compliance with this specification MUST
   support the Diff-Serv TLV.

6.1 Diff-Serv TLV

   The Diff-Serv TLV has the following formats:
   Diff-Serv TLV for an E-LSP:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F|  Diff-Serv (0x901)        |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|        Reserved                                     | MAPnb |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            MAP (1)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            MAP (MAPnb)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     T:1 bit
       LSP Type. This is set to 0 for an E-LSP

     Reserved : 27 bits
       This field is reserved. It must be set to zero on transmission
       and must be ignored on receipt.

     MAPnb : 4 bits
       Indicates the number of MAP entries included in the DIFFSERV
       Object. This can be set to any value from 1 to 8.

     MAP : 32 bits
       Each MAP entry defines the mapping between one EXP field value
       and one PHB. The MAP entry has the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Le Faucheur et. al                                                 39
                      MPLS Support of Diff-Serv              June 2000

    |            Reserved     | EXP |             PHBID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Reserved : 13 bits
               This field is reserved. It must be set to zero on
               transmission and must be ignored on receipt.

           EXP : 3 bits
               This field contains the value of the EXP field for the
               EXP<-->PHB mapping defined in this MAP entry.

           PHBID : 16 bits
               This field contains the PHBID of the PHB for the
               EXP<-->PHB mapping defined in this MAP entry. The PHBID
               is encoded as specified in section 2 of [PHBID].

   Diff-Serv TLV for an L-LSP:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| Type = PSC (0x901)        |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|        Reserved             |              PSC              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     T:1 bit
       LSP Type. This is set to 1 for an L-LSP

     Reserved : 15 bits
       This field is reserved. It must be set to zero on transmission
       and must be ignored on receipt.

     PSC : 16 bits
        The PSC indicates a PHB Scheduling Class to be supported by the
        LSP. The PSC is encoded as specified in section 2 of [PHBID]:
            - Where the PSC comprises a single PHB defined by standards
        action, the encoding for the PSC is the encoding for this
        single PHB. It is the recommended DSCP value for that PHB,
        left-justified in the 16-bit field, with bits 6 through 15 set
        to zero.
           - Where the PSC comprises multiple PHBs defined by standards
        action, the PSC encoding is the encoding for this set of PHB.
        It is the smallest numerical value of the recommended DSCP for
        the various PHBs in the PSC, left-justified in the 16 bit
        field, with bits 6 through 13 and bit 15 set to zero and with
        bit 14 set to one.

       For instance, the encoding of the EF PSC is :
              0                   1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

 Le Faucheur et. al                                                 40
                      MPLS Support of Diff-Serv              June 2000

             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0|
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       For instance, the encoding of the AF1 PSC is :
              0                   1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0|
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.2 Diff-Serv Status Code Values

   The following values are defined for the Status Code field of the
   Status TLV:

        Status Code                     E   Status Data

        Unsupported PHB                 0   0x00000016
        Invalid EXP<-->PHB mapping      0   0x00000017
        Unsupported PSC                 0   0x00000018
        Unexpected Diff-Serv TLV        0   0x00000019

6.3 Diff-Serv Related LDP Messages

6.3.1 Label Request Message

   The format of the Label Request message is extended as follows, to
   optionally include the Diff-Serv TLV:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Request (0x0401)    |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Diff-Serv TLV (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.2 Label Mapping Message

   The format of the Label Mapping message is extended as follows, to
   optionally include the Diff-Serv TLV:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Mapping (0x0400)    |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Le Faucheur et. al                                                 41
                      MPLS Support of Diff-Serv              June 2000

   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Diff-Serv TLV (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.3 Label Release Message

   The format of the Label Release message is extended as follows, to
   optionally include the Status TLV:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Label Release (0x0403)   |      Message Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     FEC TLV                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Label TLV (optional)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Status TLV (optional)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.4 Notification Message

   The format of the Notification message is extended as follows, to
   optionally include the Diff-Serv TLV:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Status TLV                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Diff-Serv TLV (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.4 Handling of the Diff-Serv TLV

6.4.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode

 Le Faucheur et. al                                                 42
                      MPLS Support of Diff-Serv              June 2000

   This section describes operations when the Downstream Unsolicited
   Mode is used.

   When allocating a label for an E-LSP which is to use the
   preconfigured EXP<-->PHB mapping, a downstream Diff-Serv LSR issues
   a Label Mapping message without the Diff-Serv TLV.

   When allocating a label for an E-LSP which is to use a signaled
   EXP<-->PHB mapping, a downstream Diff-Serv LSR issues a Label
   Mapping message with the Diff-Serv TLV for an E-LSP which contains
   one MAP entry for each EXP value to be supported on this E-LSP.

   When allocating a label for an L-LSP, a downstream Diff-Serv LSR
   issues a Label Mapping message with the Diff-Serv TLV for an L-LSP
   which contains the PHB Scheduling Class (PSC) to be supported on
   this L-LSP.

   Assuming the label set-up is successful, the downstream and upstream
   LSRs must:
     - update the Diff-Serv Context associated with the established
       LSPs in their ILM/FTN as specified in previous sections
       (incoming and outgoing label),
     - install the required Diff-Serv forwarding treatment (scheduling
       and dropping behavior) for this NHLFE (outgoing label).

   An upstream Diff-Serv LSR receiving a Label Mapping message with
   multiple Diff-Serv TLVs only considers the first one as meaningful.
   The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
   An upstream Diff-Serv LSR which receives a Label Mapping message
   with the Diff-Serv TLV for an E-LSP and does not support the
   particular PHB encoded in one, or more, of the MAP entries, must
   reject the mapping by sending a Label Release message which includes
   the Label TLV and the Status TLV with a Status Code of `Unsupported
   PHB'.

   An upstream Diff-Serv LSR receiving a Label Mapping message with the
   Diff-Serv TLV for an E-LSP and determining that the signaled
   EXP<-->PHB mapping is invalid, must reject the mapping by sending a
   Label Release message which includes the Label TLV and the Status
   TLV with a Status Code of `Invalid EXP<-->PHB Mapping'. The
   EXP<-->PHB mapping signaled in the DIFFSERV Object for an E-LSP is
   invalid when:
     - the MAPnb field is not within the range 1 to 8, or
     - a given EXP value appears in more than one MAP entry, or
     - the PHBID encoding is invalid

   An upstream Diff-Serv LSR receiving a Label Mapping message with the
   Diff-Serv TLV for an L-LSP containing a PSC value which is not
   supported, must reject the mapping by sending a Label Release
   message which includes the Label TLV and the Status TLV with a
   Status Code of `Unsupported PSC'.

 Le Faucheur et. al                                                 43
                      MPLS Support of Diff-Serv              June 2000

6.4.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode

   This section describes operations when the Downstream on Demand Mode
   is used.

   When requesting a label for an E-LSP which is to use the
   preconfigured EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a
   Label Request message without the Diff-Serv TLV.

   When requesting a label for an E-LSP which is to use a signaled
   EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a Label Request
   message with the Diff-Serv TLV for an E-LSP which contains one MAP
   entry for each EXP value to be supported on this E-LSP.

   When requesting a label for an L-LSP, an upstream Diff-Serv LSR
   sends a Label Request message with the Diff-Serv TLV for an L-LSP
   which contains the PSC to be supported on this L-LSP.

   A downstream Diff-Serv LSR sending a Label Mapping message in
   response to a Label Request message for an E-LSP or an L-LSP must
   not include a Diff-Serv TLV in this Label Mapping message.
   Assuming the label set-up is successful, the downstream and upstream
   LSRs must:
     - update the Diff-Serv Context associated with the established
       LSPs in their ILM/FTN as specified in previous sections
       (incoming and outgoing label),
     - install the required Diff-Serv forwarding treatment (scheduling
       and dropping behavior) for this NHLFE (outgoing label).

   An upstream Diff-Serv LSR receiving a Label Mapping message
   containing a Diff-Serv TLV in response to its Label Request message,
   must reject the label mapping by sending a Label Release message
   which includes the Label TLV and the Status TLV with a Status Code
   of `Unexpected Diff-Serv TLV'.

   A downstream Diff-Serv LSR receiving a Label Request message with
   multiple Diff-Serv TLVs only considers the first one as meaningful.
   The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).

   A downstream Diff-Serv LSR which receives a Label Request message
   with the Diff-Serv TLV for an E-LSP and does not support the
   particular PHB encoded in one (or more) of the MAP entries, must
   reject the request by sending a Notification message which includes
   the Status TLV with a Status Code of `Unsupported PHB'.

   A downstream Diff-Serv LSR receiving a Label Request message with
   the Diff-Serv TLV for an E-LSP and determining that the signaled
   EXP<-->PHB mapping is invalid, must reject the request by sending a
   Notification message which includes extended as follows, to
   optionally include the Status TLV with a Status
   Code of `Invalid EXP<-->PHB Mapping'. The EXP<-->PHB mapping
   signaled in the DIFFSERV TLV for an E-LSP is invalid when:
     - the MAPnb field is not within the range TLV:

       0                   1 to 8, or

 Le Faucheur et. al                                                 44
                      MPLS Support of Diff-Serv              June 2000

     - a given EXP value appears in more than one MAP entry, or
     - the PHBID encoding is invalid

   A downstream Diff-Serv LSR receiving a                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Label Request message with
   the Diff-Serv TLV for an L-LSP containing a PSC value which is not
   supported, must reject the request by sending a Notification message
   which includes the Status TLV with a Status Code of `Unsupported
   PSC'.

   A downstream Diff-Serv LSR that recognizes the Diff-Serv Release (0x0403)   |      Message Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     FEC TLV Type in
   a Label Request message and supports the requested PSC but is not
   able to satisfy the label request for other reasons (eg. no label
   available), must send a Notification message in accordance with
   existing LDP procedures [LDP] (eg. with a `No                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Label Resource' TLV (optional)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Status
   Code). This TLV (optional)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.4 Notification message must include the requested
   Diff-Serv TLV.

6.5 Non-Handling Message

   The format of the Diff-Serv TLV

   An LSR that does not recognize the Diff-Serv TLV Type, on receipt of
   a Label Request message or a Label Mapping Notification message containing is extended as follows, to
   optionally include the Diff-Serv TLV, must behave in accordance with the procedures
   specified in [LDP] for an unknown TLV whose U Bit and F Bit are set
   to TLV:

    0 ie. it must ignore the message, return a                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification message
   with `Unknown TLV' Status.

6.6 Bandwidth Information

   Bandwidth information may also be signaled at establishment time of
   E-LSP and L-LSP, for instance for the purpose of Traffic
   Engineering, using the Traffic Parameters (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Status TLV as described in
   [MPLS CR LDP].

7. MPLS Support of Diff-Serv over PPP interfaces

   The general operations for MPLS support of Diff-Serv, including
   label forwarding and LSP setup operations are specified in the
   previous sections. This section describes the specific operations
   required for MPLS support of Diff-Serv over PPP links.

   This document allows any of the following LSP combinations per FEC
   within an MPLS PPP                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Diff-Serv domain:

     - Zero or any number of E-LSP, and
     - Zero or any number TLV (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.4 Handling of L-LSPs.

7.1 LSR implementation with PPP interfaces

   A the Diff-Serv capable LSR with PPP interfaces MUST support, over these
   PPP interfaces, E-LSPs which use TLV

6.4.1 Handling of the pre-configured EXP<-->PHB Diff-Serv TLV in Downstream Unsolicited Mode

   This section describes operations when the Downstream Unsolicited
   Mode is used.

 Le Faucheur et. al                                                 45                                                 38
                      MPLS Support of Diff-Serv              June              July 2000

   mapping, in compliance with all the material from this specification
   pertaining

   When allocating a label for an E-LSP which is to those types of LSPs.

   A use the
   preconfigured EXP<-->PHB mapping, a downstream Diff-Serv capable LSR with PPP interfaces MAY support, over these
   PPP interfaces, E-LSPs issues
   a Label Mapping message without the Diff-Serv TLV.

   When allocating a label for an E-LSP which is to use a signaled
   EXP<-->PHB mapping. If mapping, a downstream Diff-Serv LSR does support E-LSPs which use issues a signaled EXP<-->PHB
   mapping over PPP interfaces, then it MUST do so in compliance Label
   Mapping message with
   all the material from this specification pertaining to those types
   of LSPs.

   A Diff-Serv capable LSR with PPP interfaces MAY support L-LSPs over
   these PPP interfaces. If TLV for an E-LSP which contains
   one MAP entry for each EXP value to be supported on this E-LSP.

   When allocating a label for an L-LSP, a downstream Diff-Serv LSR does support L-LSPs over
   PPP interfaces, then it MUST do so in compliance
   issues a Label Mapping message with all the
   material from this specification pertaining to L-LSPs.

7.2 LSR implementation with non-LC ATM interfaces

   The E-LSP/L-LSP support requirements Diff-Serv TLV for an LSR running MPLS over a
   traditional ATM connection (ie. where L-LSP
   which contains the PHB Scheduling Class (PSC) to be supported on
   this L-LSP.

   Assuming the label set-up is successful, the downstream and upstream
   LSRs must:
     - update the interface is not label
   switching controlled) are Diff-Serv Context associated with the same established
       LSPs in their ILM/FTN as those specified in section 7.1 previous sections
       (incoming and outgoing label),
     - install the required Diff-Serv forwarding treatment (scheduling
       and dropping behavior) for an LSR with PPP interfaces.

7.3 this NHLFE (outgoing label).

   An upstream Diff-Serv LSR implementation receiving a Label Mapping message with non-LC FR interfaces
   multiple Diff-Serv TLVs only considers the first one as meaningful.
   The E-LSP/L-LSP support requirements for an LSR running MPLS over a
   traditional Frame Relay connection (ie. where the interface is must ignore and not
   label switching controlled) are forward the same as those specified in
   section 7.1 for an subsequent Diff-Serv TLV(s).
   An upstream Diff-Serv LSR which receives a Label Mapping message
   with PPP interfaces.

8. MPLS Support of the Diff-Serv over LC-ATM Interfaces

   The general operations TLV for MPLS support of Diff-Serv, including
   label forwarding an E-LSP and LSP setup operations was specified does not support the
   particular PHB encoded in one, or more, of the
   previous sections. This section describes MAP entries, must
   reject the specific operations
   required for MPLS support mapping by sending a Label Release message which includes
   the Label TLV and the Status TLV with a Status Code of `Unsupported
   PHB'.

   An upstream Diff-Serv over label switching
   controlled ATM (LC-ATM) interfaces.

   This document allows any number of L-LSPs per FEC within an MPLS ATM LSR receiving a Label Mapping message with the
   Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces.

8.1 Merging

   The use TLV for an E-LSP and determining that the signaled
   EXP<-->PHB mapping is invalid, must reject the mapping by sending a
   Label Release message which includes the Label TLV and the Status
   TLV with a Status Code of merging `Invalid EXP<-->PHB Mapping'. The
   EXP<-->PHB mapping signaled in the DIFFSERV Object for an E-LSP is optional. In case that merging of ATM LSPs
   invalid when:
     - the MAPnb field is
   used, procedures described in section 3.6 of this specification
   apply. Additionally, not within the range 1 to avoid cell interleaving problems with AAL-5
   merging, procedures specified 8, or
     - a given EXP value appears in [MPLS_ATM] MUST be followed.

8.2 Use of ATM Traffic Classes and Traffic Management mechanisms

   The use of more than one MAP entry, or
     - the ATM traffic classes as specified PHBID encoding is invalid

   An upstream Diff-Serv LSR receiving a Label Mapping message with the
   Diff-Serv TLV for an L-LSP containing a PSC value which is not
   supported, must reject the mapping by ITU-T sending a Label Release
   message which includes the Label TLV and ATM-
   Forum or the Status TLV with a
   Status Code of vendor specific ATM traffic classes is outside `Unsupported PSC'.

6.4.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode

 Le Faucheur et. al                                                 46                                                 39
                      MPLS Support of Diff-Serv              June              July 2000

   scope of this specification. The only requirement

   This section describes operations when the Downstream on Demand Mode
   is used.

   When requesting a label for compliant
   implementation an E-LSP which is that to use the forwarding behavior experienced by
   preconfigured EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a
   Label Request message without the Diff-Serv TLV.

   When requesting a label for an E-LSP which is to use a signaled
   EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a Label Request
   message with the Diff-Serv TLV for an E-LSP which contains one MAP
   entry for each EXP value to be supported on this E-LSP.

   When requesting a
   Behavior Aggregate forwarded over label for an L-LSP by the ATM L-LSP, an upstream Diff-Serv LSR MUST be
   compliant
   sends a Label Request message with the corresponding Diff-Serv PHB specifications.

   Since there is only one bit TLV for encoding an L-LSP
   which contains the PHB drop precedence
   value over ATM links, only two different drop precedence levels are PSC to be supported on this L-LSP.

   A downstream Diff-Serv LSR sending a Label Mapping message in ATM LSRs. The behavior for AF MUST comply
   response to procedures
   described in [DIFF_AF] a Label Request message for an E-LSP or an L-LSP must
   not include a Diff-Serv TLV in this Label Mapping message.
   Assuming the case when only two drop precedence
   levels are supported.

   To avoid discarding parts of label set-up is successful, the packets, frame discard mechanisms,
   such downstream and upstream
   LSRs must:
     - update the Diff-Serv Context associated with the established
       LSPs in their ILM/FTN as Early Packet Discard (EPD) SHOULD be enabled specified in previous sections
       (incoming and outgoing label),
     - install the ATM-LSRs required Diff-Serv forwarding treatment (scheduling
       and dropping behavior) for all PHBs described in this document.

8.3 NHLFE (outgoing label).

   An upstream Diff-Serv LSR Implementation With LC-ATM Interfaces receiving a Label Mapping message
   containing a Diff-Serv TLV in response to its Label Request message,
   must reject the label mapping by sending a Label Release message
   which includes the Label TLV and the Status TLV with a Status Code
   of `Unexpected Diff-Serv TLV'.

   A downstream Diff-Serv LSR receiving a Label Request message with
   multiple Diff-Serv TLVs only considers the first one as meaningful.
   The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).

   A downstream Diff-Serv capable LSR which receives a Label Request message
   with LC-ATM interfaces MUST the Diff-Serv TLV for an E-LSP and does not support L-LSPs
   over these ATM interfaces in compliance with all the material from
   this specification pertaining to those types of LSPs. Additionally,
   procedures specified
   particular PHB encoded in [MPLS_ATM] MUST be followed by compliant
   implementation.

   This specification assumes that Edge-LSRs one (or more) of the ATM-LSR domain use
   the "shim header" encapsulation method defined in [MPLS_ATM].
   Operations without MAP entries, must
   reject the "shim header" encapsulation is outside request by sending a Notification message which includes
   the
   scope of this specification.

9. MPLS Support Status TLV with a Status Code of `Unsupported PHB'.

   A downstream Diff-Serv over LC-FR Interfaces

   The general operations LSR receiving a Label Request message with
   the Diff-Serv TLV for MPLS support of Diff-Serv, including
   label forwarding an E-LSP and LSP setup operations was specified in determining that the
   previous sections. This section describes signaled
   EXP<-->PHB mapping is invalid, must reject the specific operations
   required for MPLS support of Diff-Serv over label switching
   controlled Frame Relay (LC-FR) interfaces.

   This document allows any number request by sending a
   Notification message which includes the Status TLV with a Status
   Code of L-LSPs per FEC within an MPLS
   Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR
   interfaces.

9.1 Merging `Invalid EXP<-->PHB Mapping'. The use of merging EXP<-->PHB mapping
   signaled in the DIFFSERV TLV for an E-LSP is optional. In case that merging of Frame Relay
   LSPs invalid when:
     - the MAPnb field is used, procedures described in section 3.6 of this
   specification apply as well as procedures not within the range 1 to 8, or
     - a given EXP value appears in [MPLS_FR].

9.2 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms more than one MAP entry, or
     - the PHBID encoding is invalid

 Le Faucheur et. al                                                 47                                                 40
                      MPLS Support of Diff-Serv              June              July 2000

   The use of the Frame Relay traffic parameters as specified by ITU-T
   and Frame Relay-Forum or of vendor specific Frame Relay traffic
   management mechanisms is outside of

   A downstream Diff-Serv LSR receiving a Label Request message with
   the scope of this specification.
   The only requirement Diff-Serv TLV for compliant implementation an L-LSP containing a PSC value which is that not
   supported, must reject the
   forwarding behavior experienced request by sending a Behavior Aggregate forwarded
   over an L-LSP by Notification message
   which includes the Frame Relay LSR MUST be compliant Status TLV with a Status Code of `Unsupported
   PSC'.

   A downstream Diff-Serv LSR that recognizes the
   corresponding Diff-Serv PHB specifications.

   Since there TLV Type in
   a Label Request message but is only one bit for encoding unable to allocate the PHB drop precedence
   value over Frame Relay links, only two different drop precedence
   levels are supported required
   per-LSP context information, must reject the request sending a
   Notification message which includes the Status TLV with a Status
   Code of `Per-LSP context allocation failure'.

   A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in Frame Relay LSRs. The behavior for AF MUST
   comply
   a Label Request message and supports the requested PSC but is not
   able to procedures described in [DIFF_AF] satisfy the label request for other reasons (e.g. no label
   available), must send a Notification message in accordance with
   existing LDP procedures [LDP] (e.g. with a `No Label Resource'
   Status Code). This Notification message must include the case when only
   two drop precedence levels are supported.

9.3 LSR Implementation With LC-FR Interfaces

   A requested
   Diff-Serv capable TLV.

6.5 Non-Handling of the Diff-Serv TLV

   An LSR with LC-FR interfaces MUST support
   L-LSPs over these Frame Relay interfaces that does not recognize the Diff-Serv TLV Type, on receipt of
   a Label Request message or a Label Mapping message containing the
   Diff-Serv TLV, must behave in compliance accordance with all the
   material from this specification pertaining to those types of LSPs.
   Additionally, procedures
   specified in [MPLS_FR] MUST [LDP] for an unknown TLV whose U Bit and F Bit are set
   to 0 i.e. it must ignore the message, return a Notification message
   with `Unknown TLV' Status.

6.6 Bandwidth Information

   Bandwidth information may also be followed by
   compliant implementation.

   This specification assumes that Edge-LSRs signaled at establishment time of
   E-LSP and L-LSP, for instance for the FR-LSR domain use purpose of Traffic
   Engineering, using the "generic encapsulation" method Traffic Parameters TLV as recommended described in [MPLS_FR].
   Operations without the "generic encapsulation" is outside the scope
   of this specification.

10.
   [MPLS CR LDP].

7. MPLS Support of Diff-Serv over LAN PPP, LAN, Non-LC-ATM and Non-LC-FR
Interfaces

   The general operations for MPLS support of Diff-Serv, including
   label forwarding and LSP setup operations was are specified in the
   previous sections. This section describes the specific operations
   required for MPLS support of Diff-Serv over PPP interfaces, LAN interfaces.

   This document
   interfaces, ATM Interfaces which are not label controlled and Frame
   Relay interfaces which are not label controlled.

   On these interfaces, this specification allows any of the following set of
   LSP setup combinations per
   FEC over a LAN interface: FEC:

     - Zero or any number of E-LSP, and
     - Zero or any number of L-LSPs.

10.1 LSR Implementation With LAN Interfaces

   A Diff-Serv capable LSR with LAN interfaces MUST support, over these
   LAN interfaces, E-LSPs which use the pre-configured EXP<-->PHB
   mapping, in compliance with all the material from this specification
   pertaining to those types

 Le Faucheur et. al                                                 41
                      MPLS Support of LSPs. Diff-Serv              July 2000

     - Zero or any number of L-LSPs.

   A Diff-Serv capable LSR with LAN interfaces MAY support, over these
   LAN interfaces, MUST support E-LSPs which use a signaled pre-configured
   EXP<-->PHB mapping. If a mapping over these interfaces.

   A Diff-Serv capable LSR does MAY support E-LSPs which use a signaled
   EXP<-->PHB mapping and L-LSPs over LAN interfaces, then it MUST do so in compliance with

 Le Faucheur et. al                                                 48 these interfaces.

8. MPLS Support of Diff-Serv              June 2000

   all over LC-ATM Interfaces

   This section describes the material from this specification pertaining to those types specific operations required for MPLS
   support of LSPs.

   A Diff-Serv capable LSR MAY support L-LSPs over LAN label switching controlled ATM (LC-ATM)
   interfaces. If a
   Diff-Serv LSR does support L-LSPs over LAN interfaces, then it MUST
   do so in compliance with all the material from this specification
   pertaining to L-LSPs.

11. Explicit Congestion Notification

   Explicit Congestion Notification is described in [ECN] and is
   proposed as an Experimental extension to the IP protocol.

   [MPLS_ECN] discusses deployment

   This document allows any number of ECN in L-LSPs per FEC within an MPLS network using the
   Shim Header as the MPLS encapsulation. It demonstrates that,
   provided a given LSP is identified as ECN-capable or as non-ECN-
   capable (and consistently recognized as such by all the involved
   LSRs), then ECN can be ATM
   Diff-Serv domain. E-LSPs are not supported in an MPLS domain where the Shim
   Header is used as the MPLS encapsulation via a single bit over LC-ATM interfaces.

8.1 Use of the EXP
   field. ATM Traffic Classes and Traffic Management mechanisms

   The details use of how a given LSP is to be identified as ECN-capable or
   non-ECN-capable (whether via extensions to the LSP establishment
   signaling ATM traffic classes as specified by ITU-T and procedures, via configuration ATM-
   Forum or via other means) are of vendor specific ATM traffic classes is outside of the
   scope of this specification.

   However, this specification recognizes that, within an ECN-capable
   MPLS domain where LSPs are identified as ECN-capable or not-ECN-
   capable:

     - Support of ECN does not require The only requirement for compliant
   implementation is that any bit(s) from the EXP
       field forwarding behavior experienced by a
   Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be reserved for ECN operations across all LSPs even when
       those LSPs are not ECN-capable. Consequently, LSPs identified as
       non-ECN-capable (regardless of whether this
   compliant with the corresponding Diff-Serv PHB specifications.

   Since there is because at least only one LSR on bit (CLP) for encoding the LSP does not support ECN operations or whether
       this is because PHB drop
   precedence value over ATM links, only two different drop precedence
   levels are supported in ATM LSRs. Sections 4.2.2 and 4.4.2 define
   how the network administrator does not wish to use
       ECN on this LSP) can make use three drop precedence levels of the full 3-bit EXP field for
       Diff-Serv purposes. Thus, non-ECN-capable E-LSPs and non-ECN-
       capable L-LSPs can operate as defined earlier AFn Ordered Aggregates
   are mapped to these two ATM drop precedence levels. This mapping is
   in this document
       without any restriction imposed by the fact that accordance with the MPLS domain
       is ECN-capable. In particular, up to 8 BAs can still be
       transported over a non-ECN-capable E-LSP within an ECN-capable
       MPLS domain. Similarly, non-ECN-capable L-LSPs within an ECN-
       capable MPLS domain can support all requirements specified in [DIFF_AF] for the
   case when only two drop precedence levels are supported.

   To avoid discarding parts of currently defined PSCs. Should a future PSC involve more than
       4 drop precedence levels, non-ECN-capable L-LSPs within an ECN- the packets, frame discard mechanisms,
   such as Early Packet Discard (EPD) SHOULD be enabled in the ATM-LSRs
   for all PHBs described in this document.

8.2 LSR Implementation With LC-ATM Interfaces

   A Diff-Serv capable MPLS LSR MUST support L-LSPs over LC-ATM interfaces.

   This specification assumes that Edge-LSRs of the ATM-LSR domain could still use
   the full 3-bit field EXP.

     - Because a single bit is required to encode "shim header" encapsulation method defined in [MPLS_ATM].
   Operations without the ECN information
       inside "shim header" encapsulation is outside the ECN-capable MPLS domain, LSPs identified as ECN-
       capable can make use
   scope of two bits this specification.

9. MPLS Support of the EXP field value for Diff-Serv over LC-FR Interfaces

 Le Faucheur et. al                                                 49                                                 42
                      MPLS Support of Diff-Serv              June              July 2000

   This section describes the specific operations required for MPLS
   support of Diff-Serv purposes. In particular, up to 4 BAs can be
       transported over label switching controlled Frame Relay
   (LC-FR) interfaces.

   This document allows any number of L-LSPs per FEC within an ECN-capable E-LSP. Similarly, up to 4 drop
       precedence levels can be MPLS
   Frame Relay Diff-Serv domain. E-LSPs are not supported over an ECN-capable L-LSP;
       since all LC-FR
   interfaces.

9.1 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms

   The use of the PSCs corresponding to PHBs currently defined
       through standards action involve less than 4 drop precedence
       levels, ECN support does not currently restrict Diff-Serv
       operations over L-LSPs. Should a PSC corresponding to future
       PHBs defined Frame Relay traffic parameters as specified by standards action ITU-T
   and Frame Relay-Forum or of vendor specific Frame Relay traffic
   management mechanisms is outside of the scope of this specification.
   The only requirement for compliant implementation is that the
   forwarding behavior experienced by a Behavior Aggregate forwarded
   over an L-LSP by the Frame Relay LSR MUST be compliant with the
   corresponding to local use
       or experimental PHBs, involve more than 4 Diff-Serv PHB specifications.

   Since there is only one bit (DE) for encoding the PHB drop
   precedence
       levels, then ECN support value over Frame Relay links, only two different drop
   precedence levels are supported in Frame Relay LSRs. Sections 4.2.3
   and 4.4.3 define how the corresponding LSP would
       constrain three drop precedence levels of the PSC AFn
   Ordered Aggregates are mapped to 4 these two Frame Relay drop
   precedence levels; relative benefits
       of additional levels. This mapping is in accordance with the
   requirements specified in [DIFF_AF] for the case when only two drop
   precedence levels beyond 4, would then be weighted
       by the network administrator are supported.

9.2 LSR Implementation With LC-FR Interfaces

   A Diff-Serv capable LSR MUST support L-LSPs over the benefits LC-Frame Relay
   interfaces.

   This specification assumes that Edge-LSRs of ECN, to
       determine whether it the FR-LSR domain use
   the "generic encapsulation" method as recommended in [MPLS_FR].
   Operations without the "generic encapsulation" is preferable to support outside the scope
   of this PSC over an
       ECN-capable or non-ECN-capable LSP.

11.1 MPLS ECN bit specification.

10. IANA Considerations.

   This document defines a number of objects with Shim Header

   Where implications for
   IANA.

   This document defines in section 5.2 a new RSVP object, the Shim Header is used as Diffserv
   object. This object requires a number to be assigned from the MPLS encapsulation, ECN
   information is space
   defined in [RSVP] for those objects which, if not understood, cause
   the entire RSVP message to be encoded on ECN-capable LSPs rejected with an error code of
   "Unknown Object Class". Such objects are identified by a zero in the first
   most significant bit of the 3-bit EXP field class number. Within that space, this
   object should be assigned a number from the "IETF Consensus" space.

 Le Faucheur et. al                                                 43
                      MPLS Support of Diff-Serv              July 2000

   This document defines in section 5.5 a new RSVP error code,
   "Diffserv Error". This error code should be assigned by IANA. This
   document defines values 1 through 5 of the following way:

     EXP value field          MPLS ECN Meaning

     0xx        -->     `ECT, not CE'
     1xx        -->     `not ECT, or ECT+CE'

   where ECT stands for `ECN Capable Transport' and `CE' stands for
   `Congestion experienced'.

   Detailed specification to be used
   within the ERROR_SPEC object for usage of this MPLS ECN bit is outside the
   scope error code. Future allocations
   of values in this document.

   For ECN-capable LSPs, the mappings between EXP and PHB (be it space should be handled by IANA using the
   E-LSP Preconfigured Mapping specified First
   Come First Served policy defined in [IANA].

   This document defines in section 3.2.1, 6.1 a new LDP TLV, the E-LSP
   Signaled Mapping, Diffserv
   TLV. The number for this TLV has been assigned by working group
   consensus according to the L-LSP Mappings policies defined in [LDP].

   This document defines in section 4.2.1.1 and
   4.4.1.1) are adjusted accordingly to only take into account the last
   2 bits of the 3-bit EXP field.

   Note that when the E-LSP signaled mapping is used on an ECN-capable
   E-LSP, the signaled mapping only needs to contain a single MAP entry 6.2 five new LDP Status Code values
   for a given PHBID, which includes an EXP value with its first bit
   set to zero.

   For non-ECN-capable LSPs, the first bit of the 3-bit EXP field is
   NOT reserved Diffserv-related error conditions. The values for ECN and can be used the Status
   Code have been assigned by working group consensus according to encode any Diff-Serv
   information.

12. the
   policies defined in [LDP].

11. Security Considerations

 Le Faucheur et. al                                                 50
                      MPLS Support of Diff-Serv              June 2000

   This document does not introduce any new security issues beyond
   those inherent in Diff-Serv, MPLS and RSVP, and may use the same
   mechanisms proposed for those technologies.

13.

12. Acknowledgments

   This document has benefited from discussions with K. K.
   Ramakrishnan, Eric Rosen, Angela
   Chiu and Carol Iturralde. It has also borrowed from the work done by
   D. Black regarding Diff-Serv and IP Tunnels interaction.

APPENDIX A. Example Deployment Scenarios

   This section does not provide additional specification and is only
   here to provide examples of how this flexible approach for Diff-Serv
   support over MPLS may be deployed. Pros and cons of various
   deployment options for particular environments are beyond the scope
   of this document.

A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no Fast
Reroute MPLS
Protection

   A Service Provider running 8 (or fewer) BAs over MPLS, not
   performing Traffic engineering, not performing using MPLS protection via Fast
   Reroute and using
   MPLS Shim Header encapsulation in his/her network, may elect to run
   Diff-Serv over MPLS using a single E-LSP per FEC established via
   LDP. Furthermore the Service Provider may elect to use the
   preconfigured EXP<-->PHB mapping.

   Operations can be summarized as follows:

 Le Faucheur et. al                                                 44
                      MPLS Support of Diff-Serv              July 2000

     - the Service Provider configures at every LSR the bi-directional
       mapping between each PHB and a value of the EXP field
       (eg.
       (e.g. 000<-->AF11, 001<-->AF12, 010<-->AF13)
     - the Service Provider configures at every LSR, and for every
       interface, the scheduling behavior for each PSC (eg bandwidth
       allocated to AF1) and the dropping behavior for each PHB (eg. (e.g.
       drop profile for AF11, AF12, AF13)
     - LSRs signal establishment of a single E-LSP per FEC using LDP in
       accordance with the specification above (ie (i.e. no Diff-Serv TLV
       in LDP Label Request/Label Mapping messages to implicitly
       indicate that the LSP is an E-LSP and that it uses the
       preconfigured mapping)

A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no Fast
Reroute MPLS
Protection

   A Service Provider running more than 8 BAs over MPLS, not performing
   Traffic Engineering and Engineering, not performing protection via Fast Reroute

 Le Faucheur et. al                                                 51 using MPLS Support of Diff-Serv              June 2000 protection and using MPLS Shim
   encapsulation in his/her network may elect to run Diff-Serv over
   MPLS using for each FEC:
     - one E-LSP established via LDP and using the preconfigured
       mapping to support a set of 8 (or less) BAs, AND
     - one L-LSP per <FEC,OA> established via LDP for support of the
       other BAs.

   Operations can be summarized as follows:
     - the Service Provider configures at every LSR the bi-directional
       mapping between each PHB and a value of the EXP field for the
       BAs transported over the E-LSP
     - the Service Provider configures at every LSR, and for every
       interface, the scheduling behavior for each PSC supported over
       the E-LSP and the dropping behavior for each corresponding PHB
     - the Service Provider configures at every LSR, and for every
       interface, the scheduling behavior for each PSC supported over
       the L-LSPs and the dropping behavior for each corresponding PHB
     - LSRs signal establishment of a single E-LSP per FEC for the set
       of E-LSP transported BAs using LDP as specified above (ie (i.e. no
       Diff-Serv TLV in LDP Label Request/Label Mapping messages to
       implicitly indicate that the LSP is an E-LSP and that it uses
       the preconfigured mapping)
     - LSRs signal establishment of one L-LSP per <FEC,OA> for the
       other BAs using LDP as specified above (ie (i.e. Diff-Serv TLV in
       LDP Label Request/Label Mapping messages to indicate the L-LSP's
       PSC).

A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering,
Aggregate Fast Reroute MPLS Protection

   A Service Provider running 8 (or fewer) BAs over MPLS, performing
   aggregate Traffic Engineering (ie (i.e. performing a single common path
   selection for all BAs), performing using aggregate MPLS protection via Fast
   Reroute (ie performing Fast Reroute for   (i.e.
   restoring service to all PSCs jointly) and using MPLS Shim Header Shim Header

 Le Faucheur et. al                                                 45
                      MPLS Support of Diff-Serv              July 2000

   encapsulation in his/her network, may elect to run Diff-Serv over
   MPLS using a single E-LSP per FEC established via RSVP
   [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the
   preconfigured mapping.

   Operations can be summarized as follows:
     - the Service Provider configures at every LSR the bi-directional
       mapping between each PHB and a value of the EXP field
       (eg.
       (e.g. 000<-->AF11, 001<-->AF12, 010<-->AF13)
     - the Service Provider configures at every LSR, and for every
       interface, the scheduling behavior for each PSC (eg bandwidth
       allocated to AF1) and the dropping behavior for each PHB (eg
       drop profile for AF11, AF12, AF13)
     - LSRs signal establishment of a single E-LSP per FEC which will
       use the preconfigured mapping:
           * using the RSVP protocol as specified above (ie (i.e. no
       DIFFSERV RSVP Object in the PATH message containing the
       LABEL_REQUEST Object), OR

 Le Faucheur et. al                                                 52
                      MPLS Support of Diff-Serv              June 2000
           * using the CR-LDP protocol as specified above (ie (i.e. no Diff-
       Serv
       Diff-Serv TLV in LDP Label Request/Label Mapping messages).
     - protection is activated on all the E-LSPs in order to achieve
       MPLS protection via mechanisms outside the scope of this
       document.

A.4 Scenario 4: per-OA Traffic Engineering/Fast Reroute Engineering/MPLS Protection

   A Service Provider running any number of BAs over MPLS, performing
   per-OA Traffic Engineering (ie (i.e. performing a separate path
   selection for each OA) and performing per-OA MPLS protection via Fast Reroute (ie (i.e.
   performing protection with potentially different Fast Reroute policies levels of
   protection for the different OAs) in his/her network, may elect to
   run Diff-Serv over MPLS using one L-LSP per <FEC,OA> pair
   established via RSVP or CR-LDP.

   Operations can be summarized as follows:
     - the Service Provider configures at every LSR, and for every
       interface, the scheduling behavior for each PSC (eg bandwidth
       allocated to AF1) and the dropping behavior for each PHB (eg
       drop profile for AF11, AF12, AF13)
     - LSRs signal establishment of one L-LSP per <FEC,OA>:
                * using the RSVP as specified above to signal the
       L-LSP's PSC (ie (i.e. DIFFSERV RSVP Object in the PATH message
       containing the LABEL_REQUEST), OR
                * using the CR-LDP protocol as specified above to
       signal the L-LSP PSC (ie (i.e. Diff-Serv TLV in LDP Label
       Request/Label Mapping messages).
     - the appropriate level of protection is activated on the
       different L-LSPs (potentially with a different level of
       protection for each PSC)_via mechanisms outside the scope of
       this document.

 Le Faucheur et. al                                                 46
                      MPLS Support of Diff-Serv              July 2000

A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/Fast
Reroute Engineering/MPLS
Protection

   A Service Provider running 8 (or fewer) 8 BAs over MPLS, performing
   per-OA Traffic Engineering (ie (i.e. performing a separate path
   selection for each OA) and performing per-OA MPLS protection via Fast Reroute (ie (i.e.
   performing protection with potentially different Fast Reroute policies levels of
   protection for the different OAs) in his/her network, may elect to
   run Diff-Serv over MPLS using one E-LSP per <FEC,OA> pair
   established via RSVP or CR-LDP. Furthermore, the Service Provider
   may elect to use the preconfigured mapping on all the E-LSPs.

   Operations can be summarized as follows:
     - the Service Provider configures at every LSR the bi-directional
       mapping between each PHB and a value of the EXP field
       (eg.
       (e.g. 000<-->AF11, 001<-->AF12, 010<-->AF13)
     - the Service Provider configures at every LSR, and for every
       interface, the scheduling behavior for each PSC (eg bandwidth
       allocated to AF1) and the dropping behavior for each PHB (eg
       drop profile for AF11, AF12, AF13)
     - LSRs signal establishment of one E-LSP per <FEC,OA>:
                * using the RSVP protocol as specified above to signal
       that the LSP is an E-LSP which uses the preconfigured mapping
       (ie
       (i.e. no DIFFSERV RSVP Object in the PATH message containing the
       LABEL_REQUEST), OR

 Le Faucheur et. al                                                 53
                      MPLS Support of Diff-Serv              June 2000
                * using the CR-LDP protocol as specified above to
       signal that the LSP is an E-LSP  which uses the preconfigured
       mapping (ie (i.e. no Diff-Serv TLV in LDP Label Request/Label
       Mapping messages)
     - the Service Provider configures, for each E-LSP, at the head-end
       of that E-LSP, a filtering/forwarding criteria so that only the
       packets belonging to a given OA are forwarded on the E-LSP
       established for the corresponding FEC and corresponding OA.
     - the appropriate level of protection is activated on the
       different E-LSPs (potentially with a different level of
       protection depending on the PSC actually transported over each
       E-LSP)_via mechanisms outside the scope of this document.

A.6 Scenario 6: no Traffic Engineering/Fast Reroute Engineering/MPLS Protection on 8 BAs, per-OA
Traffic Engineering/Fast Reroute Engineering/MPLS Protection on other BAs.

   A Service Provider not performing Traffic Engineering/Fast Reroute Engineering/MPLS
   Protection on 8 (or fewer) BAs, performing per-OA Traffic Engineering/Fast
   Reroute
   Engineering/MPLS Protection on the other BAs (ie (i.e. performing a
   separate path selection for each OA corresponding to the other BAs
   and performing protection MPLS Protection with a potentially different policy
   for each of these OA) and using the MPLS Shim encapsulation in
   his/her network may elect to run Diff-Serv over MPLS, using for each
   FEC:

 Le Faucheur et. al                                                 47
                      MPLS Support of Diff-Serv              July 2000

     - one E-LSP using the preconfigured mapping established via LDP to
       support the set of 8 (or fewer) non-traffic-engineered/non-fast-
       rerouted non-traffic-engineered/non-
       protected BAs, AND
     - one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for
       support of the other BAs.

   Operations can be summarized as follows:
     - the Service Provider configures at every LSR the bi-directional
       mapping between each PHB and a value of the EXP field for the
       BAs supported over the E-LSP
     - the Service Provider configures at every LSR, and for every
       interface, the scheduling behavior for each PSC supported over
       the E-LSP and the dropping behavior for each corresponding PHB
     - the Service Provider configures at every LSR, and for every
       interface, the scheduling behavior for each PSC supported over
       the L-LSPs and the dropping behavior for each corresponding PHB
     - LSRs signal establishment of a single E-LSP per FEC for the non-
       traffic engineered BAs using LDP as specified above (ie (i.e. no Diff-
       Serv
       Diff-Serv TLV in LDP Label Request/Label Mapping messages)
     - LSRs signal establishment of one L-LSP per <FEC,OA> for the
       other BAs:
                * using the RSVP protocol as specified above to signal
       the L-LSP PSC (ie (i.e. DIFFSERV RSVP Object in the PATH message
       containing the LABEL_REQUEST Object), OR
                * using the CR-LDP protocol as specified above to
       signal the L-LSP PSC (ie (i.e. Diff-Serv TLV in LDP Label
       Request/Label Mapping messages).
     - protection is not activated on the E-LSPs.
     - the appropriate level of protection is activated on the
       different L-LSPs (potentially with a different level of
       protection depending on the L-LSP's PSC)_via mechanisms outside
       the scope of this document.

A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no Fast
Reroute MPLS
Protection

   A Service Provider running more than 8 BAs over MPLS, not performing
   Traffic engineering, not performing MPLS protection via Fast Reroute and

 Le Faucheur et. al                                                 54
                      MPLS Support of Diff-Serv              June 2000 using MPLS
   Shim Header encapsulation in his/her network, may elect to run Diff-Serv Diff-
   Serv over MPLS using two E-LSPs per FEC established via LDP and
   using signaled EXP<-->PHB mapping.
   Operations can be summarized as follows:
     - the Service Provider configures at every LSR, and for every
       interface, the scheduling behavior for each PSC (eg bandwidth
       allocated to AF1) and the dropping behavior for each PHB (eg
       drop profile for AF11, AF12, AF13)
     - LSRs signal establishment of two E-LSPs per FEC using LDP in
       accordance with the specification above (ie (i.e. Diff-Serv TLV in
       LDP Label Request/Label Mapping messages to explicitly indicate
       that the LSP is an E-LSP and its EXP<--> mapping). The signaled
       mapping will indicate the subset of 8 (or less) BAs to be

 Le Faucheur et. al                                                 48
                      MPLS Support of Diff-Serv              July 2000

       transported on each E-LSP and what EXP values are mapped to each
       BA on each E-LSP.

APPENDIX B. Example Bandwidth Reservation Scenarios

B.1 Scenario 1: No Bandwidth Reservation

   Consider the case where a network administrator elects to:
     - have Diff-Serv resources entirely provisioned off-line (e.g. via
       Command Line Interface, via SNMP, via COPS,...)
     - have Shortest Path Routing used for all the Diff-Serv traffic.

   This is the closest model to provisioned Diff-Serv over non-MPLS IP.
   In that case, E-LSPs and/or L-LSPs would be established without
   signaled bandwidth.

B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control

   Consider the case where a network administrator elects to:
     - have Diff-Serv resources entirely provisioned off-line (e.g. via
       Command Line Interface, via SNMP, via COPS,...)
     - use L-LSPs
     - have Constraint Based Routing performed separately for each PSC,
       where one of the constraints is availability of bandwidth from
       the bandwidth allocated to the relevant PSC.

   In that case, L-LSPs would be established with signaled bandwidth.
   The bandwidth signaled at L-LSP establishment would be used by LSRs
   to perform admission control at every hop to ensure that the
   constraint on availability of bandwidth for the relevant PSC is met.

B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and
per-PSC Resource Adjustment

   Consider the case where a network administrator elects to:
     - use L-LSPs

 Le Faucheur et. al                                                 55
                      MPLS Support of Diff-Serv              June 2000
     - have Constraint Based Routing performed separately for each PSC,
       where one of the constraints is availability of bandwidth from
       the bandwidth allocated to the relevant PSC.
     - have Diff-Serv resources dynamically adjusted

   In that case, L-LSPs would be established with signaled bandwidth.
   The bandwidth signaled at L-LSP establishment would be used by LSRs
   to attempt to adjust the resources allocated to the relevant PSC
   (e.g. scheduling weight) and then perform admission control to
   ensure that the constraint on availability of bandwidth for the
   relevant PSC is met after the adjustment.

References

 Le Faucheur et. al                                                 49
                      MPLS Support of Diff-Serv              July 2000

   [MPLS_ARCH] Rosen et al., "Multiprotocol label switching
   Architecture", work in progress, (draft-ietf-mpls-arch-06.txt), draft-ietf-mpls-arch-06.txt, August
   1999.

   [MPLS_ENCAPS] Rosen et al., "MPLS Label Stack Encoding, work in
   progress, draft-ietf-mpls-label-encaps-07.txt, September 1999.

   [MPLS_ATM] Davie et al., "MPLS using LDP and ATM VC Switching", work
   in progress, (draft-ietf-mpls-atm-03.txt), May 2000 draft-ietf-mpls-atm-04.txt, June 2000.

   [MPLS_FR] Conta et al., "Use of Label Switching on Frame Relay
   Networks Specification", (draft-ietf-mpls-fr-04.txt), May 2000 work in progress, draft-ietf-mpls-fr-
   06.txt, June 2000.

   [DIFF_ARCH] Blake et al., "An architecture for Differentiated
   Services", RFC-2475, December 1998.

   [DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597,
   June 1999.

   [DIFF_EF] Jacobson et al., "An Expedited Forwarding PHB", RFC-2598,
   June 1999.

   [DIFF_HEADER] Nichols et al., "Definition of the Differentiated
   Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474,
   December 1998.

   [ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion
   Notification (ECN) to IP", RFC-2481, January 1999.

   [MPLS_ECN] Ramakrishnan et al., "A Proposal to Incorporate ECN in
   MPLS", draft-ietf-mpls-ecn-00.txt, June 1999.

   [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-
   06.txt, October 99 work in progress,
   draft-ietf-mpls-ldp-08.txt, June 2000

   [RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels",
   work in progress, draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, February
   2000

   [CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using
   LDP", work in progress, draft-ietf-mpls-cr-ldp-03.txt, October 1999

 Le Faucheur et. al                                                 56
                      MPLS Support of Diff-Serv              June 2000

   [PHBID] Brim et al., "Per Hop Behavior Identification Codes"
   RFC 2836, May 2000

   [DIFF_NEW] Grossman, "New Terminology for Diffserv", draft-ietf-
   diffserv-new-terms-02.txt, work in
   progress, draft-ietf-diffserv-new-terms-02.txt, November 99 1999

   [IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998
   Edition (Revision and redesignation of ISO/IEC 10038:98

   [ANSI/IEEE Std 802.1D, 1993 Edition], incorporating IEEE
   supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and
   P802.12e)

 Le Faucheur et. al                                                 50
                      MPLS Support of Diff-Serv              July 2000

   [DIFF_TUNNEL] Black, "Differentiated Services and Tunnels", draft-
   ietf-diffserv-tunnels-00-txt, February work in
   progress, draft-ietf-diffserv-tunnels-01-txt, June 2000.

   [MPLS_VPN] Rosen et al., "BGP/MPLS VPNs", draft-rosen-rfc2547bis-
   00.txt, March work in progress, draft-
   rosen-rfc2547bis-01.txt, May 2000.

Author's Addresses:

   [RSVP] Braden et al., "Resource ReSerVation Protocol (RSVP) -
   Version 1 Functional Specification", RFC-2205, September 1997.

   [IANA] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
   Considerations Section in RFCs", RFC 2434, October 1998.

Authors' Address:

   Francois Le Faucheur
   Cisco Systems
   Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne -
   France
   Phone: +33 4 92 96 75 64
   Email: flefauch@cisco.com

   Liwen Wu
   Cisco Systems
   250 Apollo Drive, Chelmsford, MA 01824,
   USA
   Phone: +1 (978) 244-3087
   Email: liwwu@cisco.com

   Bruce Davie
   Cisco Systems
   250 Apollo Drive, Chelmsford, MA 01824
   USA
   Phone: +1 (978) 244-8000
   Email: bsd@cisco.com

   Shahram Davari
   PMC-Sierra Inc.
   555 Legget drive,
   Suit 834, Tower B,
   Ottawa, ON K2K 2X3
   Canada
   Phone: +1 (613) 271-4018
   Email: shahram_davari@pmc-sierra.com

 Le Faucheur et. al                                                 57
                      MPLS Support of Diff-Serv              June 2000

   Pasi Vaananen
   Nokia
   3 Burlington Woods Drive, Suit 250
   Burlington, MA 01803
   USA
   Phone +1 (781) 238-4981

 Le Faucheur et. al                                                 51
                      MPLS Support of Diff-Serv              July 2000

   Email: pasi.vaananen@nokia.com

   Ram Krishnan
   Nexabit Networks
   200 Nickerson Road,
   Marlboro, MA 01752
   USA
   E-mail: ram@nexabit.com

   Pierrick Cheval
   Alcatel
   5 rue Noel-Pons
   92734 Nanterre Cedex
   France
   E-mail:pierrick.cheval@alcatel.fr

   Juha Heinanen
   Telia Finland
   E-mail: jh@lohi.eng.telia.fi

Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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."

 Le Faucheur et. al                                                 58                                                 52