Liwen Wu
                                                            Alcatel, USA
                                                         Pierrick Cheval
                                                            Alcatel, USA
                                                           Pasi Vaananen
                                                                   Nokia                                                    Francois le Le Faucheur
                                                     Cisco Systems, Inc.
                                                                Liwen Wu
                                                             Bruce Davie
                                                           Cisco Systems, Systems

                                                          Shahram Davari
                                                         PMC-Sierra Inc.

                                                           Pasi Vaananen
                                                                   Nokia

                                                            Ram Krishnan
                                                        Nexabit Networks

                                                         Pierrick Cheval
                                                                 Alcatel

IETF Internet Draft
Expires: December, 1999 April, 2000
Document: draft-ietf-mpls-diff-ext-01.txt               June, draft-ietf-mpls-diff-ext-02.txt              October, 1999

                MPLS Support of Differentiated Services by ATM LSRs
                          and Frame Relay LSRs

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 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 "work in progress._ 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.

Abstract

   This document proposes defines a flexible solution for MPLS to support of
   Differentiated Services (Diff-Serv) over ATM LSRs and Frame Relay LSRs. It proposes
   corresponding updates Multi-Protocol Label
   Switching (MPLS) networks.

   This solution allows the MPLS network administrator to flexibly
   define how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label
   Switched Paths so that he/she can best match the current Diff-Serv, Traffic

Le Faucheur, et. al                                                  1

                      MPLS LDP Support of Diff-Serv             October 99

   Engineering and MPLS RSVP messages
   for LSP establishment.

   In brief, we propose Fast Restoration 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 where both the Behavior Aggregate's scheduling treatment
   and its drop precedence are conveyed to the LSR in the EXP field of
   the MPLS Shim Header.
        - LSPs where the Behavior Aggregate's scheduling treatment is
   inferred by the LSR from the packet's label value (VCI/DLCI) while the Behavior
   Aggregate's drop precedence is indicated in the ATM/FR EXP field of the
   MPLS Shim Header or in the encapsulating link layer specific
   selective discard CLP/DE field.

1 drop mechanism (ATM, Frame Relay, 802.1).

1. Introduction

Wu,  et. al                                                          1

                 MPLS Support of DiffServ over ATM/FR          June 99

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

   [MPLS_ATM] and [MPLS_FR] provides detailed description of how ATM
   and FR Switches can be used as MPLS LSRs and how LSPs are
   established and used by those ATM LSRS and FR LSRs.

   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. 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 [DIFF_HEADER]. Aggregate. At each transit node, the destination address is used to decide the next hop
   while the DSCP is used to select
   the Per Hop Behavior (PHB) that determines the queuing scheduling treatment
   and, in some cases, drop probability for each packet.

   This document proposes specifies a solution for supporting the Diff-Serv
   Behavior
   Aggregates, Aggregates whose corresponding PHBs are currently defined
   (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS ATM or MPLS Frame
   Relay network, i.e., an MPLS network implemented using ATM of Frame
   Relay switches.

1.1 Ordering Constraints, "Scheduling Aggregate (SA)" and "Per Hop
Scheduling (PHS)"

   [DIFF_AF] states that "a DS node does network.

   As mentioned in [DIFF_HEADER], "Service providers are not reorder IP packets of required
   to use the same microflow if they belong node mechanisms or configurations to enable service
   differentiation within their networks, and are free to configure the same AF class" (even if
   different packets of
   node parameters in whatever way that is appropriate for their
   service offerings and traffic engineering objectives". Thus, the microflow contain different AF codepoints
   solution defined in this document gives Service Providers
   flexibility in selecting how Diff-Serv classes of service are Routed
   or Traffic Engineered within their domain (eg. separate classes of
   services supported via separate LSPs and Routed separately, all
   classes of service supported on the same AF class).

   For LSP and Routed or Traffic
   Engineered together). Similarly, the sake solution gives Service
   Providers flexibility in how Diff-Serv classes of generality, we define service can be
   protected via MPLS Fast Restoration (eg. some classes of service
   supported via LSPs which are protected via MPLS Fast Restoration

 Le Faucheur et. al                                                  2

                      MPLS Support of Diff-Serv             October 99

   while some other classes of service are supported via LSPs which are
   not protected).

   Beside, 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 mandating set-up of multiple LSPs
   for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when
   useful or required.

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

   The Diff-Serv model defines [APPENDIX A] the set of Behavior
   Aggregates which share such an ordering constraint to constitute a "Scheduling
   Aggregate" (SA). The mechanisms described in this draft aim, in
   particular, to preserve the correct ordering relationships for
   packets that belong to a given SA.

   We refer to an
   "Ordered Aggregate (OA)". It also defines the set of one or more
   PHBs applied to the set of Behavior Aggregates forming a given SA, OA,
   as a "Per Hop Scheduling"
   (PHS).

   The PHBs currently specified are Default PHB (DF), "PHB Scheduling Class Selector
   PHB group (CSx), Assured Forwarding PHB group (AFxy), Expedited
   Forwarding PHB (EF).

1.1.1 DF PHS

Wu et. al (PSC)".

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

   Section 2

                 MPLS Support of DiffServ over ATM/FR          June 99

   The Default PHB is below specifies how a single PHB specified in [DIFF_Header]. Thus, LSP can be used to support up
   to eight BAs, regardless of how many OAs these BAs span. With such
   LSPs, the corresponding PHS comprises a single PHB packet DSCP value gets entirely mapped into the EXP field
   of the MPLS Shim Header [MPLS_ENCAPS] at the Edge of the MPLS Diff-
   Serv Cloud (thus encoding both drop precedence and thus coincides with PSC/scheduling
   information). In other words, both PSC and Drop Precedence are
   conveyed in each labeled packet using the DF PHB.

1.1.2 CSn PHS

   [DIFF_HEADER] defines up to 8 CS Codepoints referred EXP field of the MPLS Shim
   Header [MPLS_ENCAPS].

   We refer to such LSPs as CSn,
   where 1 <= n <= 8. [DIFF_HEADER] states that "... PHBs selected "EXP-inferred-PSC LSPs" (E-LSP). Detailed
   operations of E-LSPs are specified in section 2 below.

   E-LSPs have the following benefits:
        - label space is conserved by
   distinct Class Selector Codepoints SHOULD be independently
   forwarded; that is, packets marked with different Class Selector
   Codepoints MAY be re-ordered". Thus, allowing "packing" of up to eight
   BAs per label (eg. when there are fewer than eight BAs in the
   network, this method maintains the same label space as in a non
   Diff-Serv capable MPLS network).
        - label establishment signaling is one PHS corresponding
   to each CSn PHB. Each CSn PHS comprises then reduced since a single PHB and thus
   coincides with this CSn PHB.

1.1.3 AFCn PHS

   As described
   LSP is established for up to eight BAs (eg. when there are fewer
   than eight BAs in [DIFF_AF], the Assured Forwarding (AF) PHB group
   provides forwarding network, this method maintains the same level
   of IP packets signaling as in N independent AF classes.
   Within each AF class, an IP packet a non-Diff-Serv capable MPLS network)
        - the amount of forwarding state is assigned one also reduced, as a single
   forwarding entry can support up to 8 BAs.
        - operation of M different
   levels Diff-Serv MPLS over E-LSPs is analogous to
   operations of drop precedence. An IP packet Diff-Serv in non-MPLS networks in the sense that belongs to an AF class
   i and has drop precedence j the
   Diff-Serv PHB is triggered exclusively by a field explicitly encoded
   in every packet based on locally configured PHB mapping. This is
   expected to facilitate migration from non-MPLS Diff-Serv to MPLS
   Diff-Serv operations in some networks.
        - some early implementations of E-LSPs exist today and
   experiments have confirmed proper operations and usefulness.

   E-LSPs only allow support of eight BAs or less.

 Le Faucheur et. al                                                  3

                      MPLS Support of Diff-Serv             October 99

1.3 Label-Inferred-PSC LSPs (L-LSP)

   Section 3 below specifies how a separate LSP can be established for
   each <FEC, OA> pair between two LSR neighbors.

   With such LSPs, the PSC is explicitly signaled at label
   establishment time so that, after label establishment, the LSR can
   infer from the label value the PSC to be applied to a labeled
   packet. When the Shim Header is used, the Drop Precedence to be
   applied by the LSR to the labeled packet is conveyed inside the
   labeled packet MPLS Shim Header using the EXP field [MPLS_ENCAPS].
   When the Shim Header is not used (eg. MPLS Over ATM), the Drop
   Precedence to be applied by the LSR to the labeled packet is
   conveyed inside the link layer header encapsulating the labeled
   packet using link layer specific drop precedence (eg. Cell Loss
   Priority).

   We refer to such LSPs as "Label-Inferred-PSC LSPs" (L-LSP). Detailed
   operations of L-LSPs are specified in section 3 below.

   L-LSPs allow support of any number of Behavior Aggregates.

   L-LSPs have the following drawbacks:
        - they require the use of a separate label for support of each
   PSC,   and
        - they require more signaling operations to set up the
   corresponding L-LSPs.

1.4 Overall Operations

   For a given FEC, and unless media specific restrictions apply as
   identified in the corresponding sections below (eg. `MPLS Support of
   Diff-Serv by ATM LSRs'), this specification allows any one of the
   following set of 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 from the
   set of allowed combinations in order to best match his/her
   environment and objectives in terms of Diff-Serv support, Traffic
   Engineering and Fast Restoration.

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

1.5 Label Forwarding Model for Diff-Serv LSRs

   In order to describe Label Forwarding by Diff-Serv LSRs, we model
   the LSR Diff-Serv label switching behavior as comprising three
   stages:
        -A- incoming PHB and FEC determination

 Le Faucheur et. al                                                  4

                      MPLS Support of Diff-Serv             October 99

        -B- Optional outgoing PHB determination via Local Policy and
   Traffic Conditioning
        -C- Outgoing EXP(and possibly CLP/DE) and label determination,
   enforcement of outgoing PHB's forwarding behavior

   This model is used below for specifying LSR Label Forwarding using
   L-LSPs and E-LSPs for Diff-Serv support over MPLS.

1.6 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 E-LSP transported Behavior Aggregates (BAs). Where
   all the MPLS supported BAs are transported over E-LSPs, the label
   then represents the complete FEC.
        - With L-LSPs, the label represents the combination of a FEC
   and an Ordered Aggregate (OA).

2. Detailed Operations of E-LSPs

2.1 E-LSP Establishment

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

      - the Diff-Serv Code Point field (DSCP) is 6-bit long
   [DIFF_HEADER] but when 8 (or less) BAs are used, the DSCP values can
   be mapped entirely into the 3-bit long EXP field of the MPLS label
   stack entry;

      We define that:

      - one LSP established for a given Forwarding Equivalent Class
   (FEC) may be used for transport of up to eight BAs of that FEC;

      - such an LSP is referred to as an "EXP-inferred-PSC" LSP or
   "E-LSP" because the PSC to be applied to a labeled packet by the LSR
   is inferred from the EXP field of the MPLS Shim Header;

 Le Faucheur et. al                                                  5

                      MPLS Support of Diff-Serv             October 99

      - the set of transported BAs can span one or multiple OAs;

      - packets belonging to this given (FEC) and from the
   corresponding set of BAs are sent down this E-LSP.

      - multiple BAs belonging to the same FEC and transported over the
   same E-LSP are granted different scheduling treatment and different
   drop precedence by the MPLS LSR based on the EXP field which is
   appropriately encoded to reflect both the PSC and the drop
   precedence of the PHB corresponding to the packet's BA.

   MPLS specifies how LSPs can be established via multiple signaling
   protocols. Those include the Label Distribution Protocol (LDP),
   RSVP, BGP and PIM. This document specifies below, respectively in
   section 4 and section 5, how RSVP and LDP are to be used for
   establishment of E-LSPs.

2.2 Label Forwarding

2.2.1 Incoming PHB and FEC Determination On Ingress E-LSP

   When receiving a labeled packet over a E-LSP of an MPLS ingress
   interface, the LSR:
        - determines the FEC based on the incoming label
        - determines the incoming PHB by looking at the EXP field of
   the top level label entry and then by looking up the PHB<-->EXP
   mapping defined below in section 2.3.

   If the EXP field value of a packet received on an E-LSP is not
   listed in the mapping defined in section 2.3, this EXP value should
   be considered invalid. LSR behavior in such situation is a local
   matter and is outside the scope of this document.

2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning

   This stage of Diff-Serv label switching is optional and may be used
   on an LSR to perform Behavior Aggregate demotion or promotion inside
   an MPLS Diff-Serv domain. 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").

2.2.3   Outgoing EXP Field And Label Determination On Egress E-LSP

   Once the outgoing PHB has been determined by the LSR as a function
   of the incoming PHB and of the optional Local Policy and Traffic
   Conditioning, the LSR:

 Le Faucheur et. al                                                  6

                      MPLS Support of Diff-Serv             October 99

        - determines via local configuration that the outgoing PHB is
   one of the PHBs supported by the E-LSP and determines the egress E-
   LSP label for the packet's FEC
        - determines the value to be written in the EXP field of the
   top level label entry (and possibly of other level label entries in
   the case of a hierarchical tunnel entry) by looking up the
   PHB<-->EXP mapping defined below in section 2.3 for the outgoing
   PHB.
        - SHALL apply the scheduling/dropping behavior corresponding to
   the Outgoing PHB in compliance with the corresponding Diff-Serv PHB
   specification.

2.2.4 Simplified Forwarding

   When Local Policy and Traffic Conditioning are not to be performed
   by the LSR and the labeled packet is received on a E-LSP and is
   forwarded onto an E-LSP, the Forwarding operation is simplified
   since:
        - the EXP field does not need to be modified
        - the outgoing label determination depends exclusively on the
   incoming label (ie does not depend on Local Policy and Traffic
   Conditioning). The outgoing label is determined from the Incoming
   Label Map (ILM) using the same procedures as with non Diff-Serv LSPs
   (ie the incoming label is used as the index into the ILM to identify
   the NHLFE independently of the Diff-Serv operations)
        - the scheduling/dropping behavior to be applied is determined
   exclusively from the unmodified EXP field value.

2.3 PHB<-->EXP field mapping

   Like the mapping between PHBs and DSCPs in a Diff-Serv network, the
   mapping between PHB and EXP field is a local matter to be defined by
   the Service Provider and configured on every LSR.

   LSRs supporting E-LSPs must allow configuration of PHB<-->EXP
   mapping. This mapping applies to all the E-LSPs established on this
   LSR (over interfaces belonging to a given MPLS Diff-Serv domain).

   The PHB<-->EXP mapping must be consistent at every LSP hop
   throughout the MPLS Diff-Serv domain spanned by the LSP. This is
   achieved via consistent configuration by the network operator within
   the MPLS Diff-Serv domain.

   Clearly, if different Behavior Aggregates transported over an E-LSP
   are to be treated differently in the MPLS Diff-Serv cloud, different
   values of the EXP field are to configured in the PHB<-->EXP mapping
   for the corresponding PHBs.

2.4 E-LSP Merging

 Le Faucheur et. al                                                  7

                      MPLS Support of Diff-Serv             October 99

   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 LSP if they support the exact
   same set of BAs.

   Since the BAs/PHBs supported over an E-LSP is not signalled at
   establishment time, an LSR can not rely on signaling information to
   enforce the above merge condition (ie that merged LSPs do support
   the exact same set of BAs). However all E-LSPs are to use the same
   PHB<-->EXP mapping, and transport the same set of Behavior
   Aggregates, within a given MPLS Diff-Serv domain. Thus, E-LSP
   merging is allowed within a given MPLS Diff-Serv domain.

   E-LSP Merging at a boundary between two MPLS Diff-Serv domains is
   for further study.

3.  Detailed Operation of L-LSPs

3.1 L-LSP Establishment

      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 Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER]. So
   that 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 in case of
   ATM/Frame Relay), the DS field can not be mapped entirely into the
   appropriate field of MPLS encapsulation header (i.e., EXP field in
   case of Shim Header and CLP/DE field in case of ATM/Frame Relay);

        - Some Service Providers have a requirement for fine grain
   Traffic Engineering (such as per OA Traffic Engineering)

      We propose that:

      - All packets belonging to a single OA and the same Forwarding
   Equivalent Class (FEC) be sent down a single LSP;

      - One LSP be established per <FEC, OA> pair (rather than simply
   one LSP per FEC as in an MPLS network that does not support Diff-
   Serv). Such an LSP is referred to as a "Label-inferred-PSC" LSP or
   "L-LSP";

      - Multiple BAs belonging to the same OA be granted different Drop
   Precedence (DP) values through appropriate coding of the relevant

 Le Faucheur et. al                                                  8

                      MPLS Support of Diff-Serv             October 99

   field of MPLS encapsulation header (EXP field of the top label entry
   for the shim header, CLP/DE bit in case of ATM/Frame Relay).

   MPLS specifies how LSPs can be established via multiple signaling
   protocols. Those include the Label Distribution Protocol (LDP),
   RSVP, BGP and PIM. This document specifies, respectively in section
   4 and section 5, how RSVP and LDP are to be used for establishment
   of L-LSPs.

3.2 Label Forwarding

3.2.1 Incoming PHB and FEC Determination On Ingress L-LSP

   When receiving a labeled packet over an L-LSP of an MPLS ingress
   interface, the LSR:
        - determines the FEC based on the incoming label
        - determines the PSC from the incoming label among the set of
   LSPs established for that FEC
        - determines the incoming PHB from the PSC and the EXP/CLP/DLE
   field of the top level label entry in accordance with the
   PSC/EXP(resp PSC/CLP, PSC/DE) -->PHB mappings defined below in
   sections 6.3 (resp 7.2 and 8.2).

3.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning

   This stage of Diff-Serv label switching is independent of the
   ingress/egress interface media type and method used for MPLS Diff-
   Serv support. It is optional and may be used on an LSR to perform
   Behavior Aggregate demotion or promotion inside an MPLS Diff-Serv
   domain. For the purpose of specifying a Diff-Serv over MPLS method,
   we simply note that the PHB to be actually enforced by an LSR
   (referred to as "outgoing PHB") may be different to the PHB which
   had been associated with the packet at the previous LSR (referred to
   as "incoming PHB").

3.2.3   Outgoing EXP/CLP/DE Field and Label Determination on Egress L-
LSP

   Once the outgoing PHB has been determined by the LSR as a function
   of the incoming PHB and of the optional Local Policy and Traffic
   Conditioning, the LSR:
        - determines via local configuration that the outgoing PHB is
   one of the PHBs supported by a L-LSP and determines the egress
   L-LSP label for the packet's FEC
        - determines the value to be written in the EXP/CLP/DLE field
   of the top level label entry (and possibly of other level label
   entries in the case of a hierarchical tunnel entry) by performing
   the outgoing PHB-->EXP/PSC (resp CLP/PSC, DE/PSC) mapping defined in
   sections 6.4 (resp 7.3 and 8.3).

 Le Faucheur et. al                                                  9

                      MPLS Support of Diff-Serv             October 99

        - SHALL apply the scheduling/dropping behavior corresponding to
   the "Outgoing PHB" in compliance with the corresponding Diff-Serv
   PHB specification.

3.2.4 Simplified Forwarding

   When Local Policy and Traffic Conditioning are not to be performed
   by the LSR, and when the labeled packet is received on a L-LSP on
   the ingress interface and is going out onto a L-LSP on an egress
   interface of the same type, the Forwarding operation is simplified
   since:
        - the EXP/CLP/DE field does not need to be modified
        - the outgoing label determination depends exclusively on the
   incoming label (ie does not depend on Local Policy and Traffic
   Conditioning). The outgoing label is determined from the Incoming
   Label Map (ILM) using the same procedures as with non Diff-Serv LSPs
   (ie the incoming label is used as the index into the ILM to identify
   the NHLFE independently of the Diff-Serv operations)
        - the scheduling behavior to be applied is  determined
   exclusively from the Diff-Serv information stored in the NHLFE for
   the incoming label
        - the dropping behavior to be applied is determined exclusively
   from the Diff-Serv information stored in the NHLFE for the incoming
   label and from the incoming EXP/CLP/DE field
   More information is provided below in the sections titled `RSVP
   extensions for Diff-Serv Support' and `LDP extensions for Diff-Serv
   Support' on what is the Diff-Serv information stored in NHLFEs.

3.3 Merging

   In an MPLS domain, two or more LSPs can be merged into one LSP at
   one LSR. The proposed support of Diff-Serv in MPLS is compatible
   with LSP Merging under the following condition:

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

   Note that when L-LSPs merge, the bandwidth that is available for the
   PSC downstream of the merge point must be sufficient to carry the
   sum of the merged traffic. This is particularly important in the
   case of EF traffic. This can be ensured in multiple ways (for
   instance via provisioning or via bandwidth signaling and explicit
   admission control).

4. RSVP Extension for Diff-Serv Support

   The MPLS architecture does not assume a single label distribution
   protocol. [RSVP_MPLS_TE] defines the extension to RSVP for
   establishing label switched paths (LSPs) in MPLS networks. This
   section specifies the extensions to RSVP, beyond those defined in

 Le Faucheur et. al                                                 10

                      MPLS Support of Diff-Serv             October 99

   [RSVP_MPLS_TE], to establish label switched path (LSPs) supporting
   Differentiated Services in MPLS networks.

4.1 Diff-Serv related RSVP Messages Format

   One new RSVP Object is defined in this document: the DIFFSERV_PSC
   Object. Detailed description of this Object is provided below. This
   new Object is applicable to Path messages. This specification only
   defines the use of the DIFFSERV_PSC 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 [RSVP_MPLS_TE] for support of establishment
   of LSP Tunnels via RSVP are also applicable to 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_PSC object is optional with respect to RSVP so
   that general RSVP implementations not concerned with MPLS LSP set up
   do not have to support this object.

   The DIFFSERV_PSC Object is optional for support of LSP Tunnels as
   defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs
   in compliance with this specification MAY support the DIFFSERV_PSC
   Object. A Diff-Serv capable LSR supporting L-LSPs in compliance with
   this specification MUST support the DIFFSERV_PSC Object.

4.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_PSC> ]
                                  [ <POLICY_DATA> ... ]
                                  [ <sender descriptor> ]

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

4.2 DIFFSERV_PSC Object

   As stated earlier, the PHB Scheduling Class associated with an L-LSP
   is to be specified through a new DIFFSERV_PSC object in RSVP Path
   messages. The DIFFSERV_PSC object has the following format :

 Le Faucheur et. al                                                 11

                      MPLS Support of Diff-Serv             October 99

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Length                |   Class-Num   |    C-Type     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved     | T |PSCnb|              PSC              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Length

      This is set to 4.

     Class-Num

      The Class-Num for a DIFFSERV_PSC object is [TBD] and identifies
      a new object Class called the "Class Of Service" Class (COS
      Class). (The Class-Num is to be allocated by IANA with the form
      0bbbbbbb)

     C-Type

      The C-Type for a DIFFSERV_PSC object is 1.

     Reserved

      This field is set to all zeros

     T

      This indicates the `LSP Type'. The following values are
      specified:

           T Value      LSP type
           00           E-LSP
           01           L-LSP

     PSCnb

      Indicates the number of PSC values included in the PSC object.
      This is set to 001.

     PSC

      The PSC indicates the PHB Scheduling Class to be supported by the
      L-LSP. The 16-bit 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.

 Le Faucheur et. al                                                 12

                      MPLS Support of Diff-Serv             October 99

        - 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  2  3  4  5  6  7  8  9 10 11 12 13 14 15
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      | 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  2  3  4  5  6  7  8  9 10 11 12 13 14 15
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      | 0  0  1  0  1  0| 0  0  0  0  0  0  0  0  1  0|
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

4.3 Handling Diff-Serv_PSC Object

   To establish an 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 using E-LSPs, to establish an
   E-LSP tunnel with RSVP, the sender creates a Path message with a
   session type of LSP_Tunnel_IPv4, with the LABEL_REQUEST object and
   without the DIFFSERV_PSC object.

   Optionally, to establish an E-LSP over which a single Ordered
   Aggregate is going to be transported, the sender MAY create a Path
   message which contains a session type of LSP_Tunnel_IPv4, contains
   the LABEL_REQUEST object and contains the DIFFSERV_PSC object with
   its LSP-Type field set to `E-LSP' and its PSC field set to the value
   of the PSC to be supported on the E-LSP.

   The destination node of an E-LSP responds to the Path message
   containing the LABEL_REQUEST object by sending a Resv message
   containing the LABEL object and no DIFFSERV_PSC object.

   When receiving a Resv message containing a LABEL object and
   associated with a Path message which contained a LABEL_REQUEST
   object and no DIFFSERV_PSC object (or which contained the
   DIFFSERV_PSC object with its LSP-Type set to E-LSP), assuming the
   reservation can be accepted and a label can be associated with the
   reservation, a Diff-Serv E-LSP capable LSR must:
        - update its Incoming Label Map (ILM) [MPLS_ARCH] to store the
   necessary Diff-Serv information. This includes the fact that the
   Next Hop Label Forwarding Entry (NHLFE) corresponds to an E-LSP.
   This is in accordance with [MPLS_ARCH] which states that the `NHLFE

 Le Faucheur et. al                                                 13

                      MPLS Support of Diff-Serv             October 99

   may also contain any other information needed in order to properly
   dispose of the packet'.
        - install the required scheduling and dropping behavior for
   this NHLFE in order to support Diff-Serv label forwarding as
   specified for E-LSPs in section 2.2.

   Where the sender supports Diff-Serv using L-LSPs, to establish an
   L-LSP tunnel with RSVP, the sender creates a Path message with a
   session type of LSP_Tunnel_IPv4, with the LABEL_REQUEST object and
   with the DIFFSERV_PSC object. The DIFFSERV_PSC object has its LSP-
   Type set to L-LSP and its the PSC value indicating the PHB
   Scheduling Class to be supported by the L-LSP.

   An RSVP router that does recognizes the DIFFSERV_PSC object and that
   receives a path message which contains the DIFFSERV_PSC 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
   sender with the error code `Diff-Serv Error' and an error value of
   `Unexpected DIFFSERV_PSC object'. Those are defined below in the
   section titled `Diff-Serv Errors'.

   A node receiving a Path message with the DIFFSERV_PSC object, which
   recognizes the DIFFSERV_PSC 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 Value'. Those are defined below in the section
   titled `Diff-Serv Errors'.

   If a path message contains multiple DIFFSERV_PSC objects, only the
   first one is meaningful; subsequent DIFFSERV_PSC object(s) must be
   ignored and not forwarded.

   Each node along the path records the DIFFSERV_PSC object, when
   present, in its path state block.

   The destination node of an L-LSP responds to the Path message
   containing the LABEL_REQUEST object and the DIFFSERV_PSC object by
   sending a Resv message containing the LABEL object and no
   DIFFSERV_PSC object.

   When receiving a Resv message containing a LABEL object and
   associated with a Path message which contained a LABEL_REQUEST
   object and the DIFFSERV_PSC object with its LSP-Type set to L-LSP,
   assuming the reservation can be accepted and a label can be
   associated with the reservation, a Diff-Serv L-LSP capable LSR must:
        - update its ILM to store the necessary Diff-Serv information.
   This includes the fact that the NHLFE corresponds to an L-LSP and
   its PSC.
        - install the required scheduling and dropping behavior for
   this NHLFE to support Diff-Serv label forwarding as specified for L-
   LSPs in section 3.2.

 Le Faucheur et. al                                                 14

                      MPLS Support of Diff-Serv             October 99

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

   [RSVP_MPLS_TE] identifies the conditions where LSPs can be merged to
   constitute a multipoint-to-point LSP. When the LSPs to be merged are
   L-LSPs, those can only be merged if an additional condition is met:
   the DIFFSERV_PSC object in their respective path messages must all
   be strictly identical.

4.4 Non-support of the Diff-Serv_PSC Object

   An RSVP router that does not recognize the COS Class's Class-Num
   sends a PathErr with the error code "Unknown object class" toward
   the sender. An RSVP router that recognizes the COS Class's Class-Num
   but does not recognize the DIFFSERV_PSC object C-Type, sends a
   PathErr with the error code "Unknown object C-Type" toward the
   sender. 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_PSC object (eg. attempt use of E-LSPs as a back-up
   strategy).

4.5 Error Codes For 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).

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

       Value    Error

       1       Unsupported PSC value
       2       Unexpected DIFFSERV_PSC object

4.6 Use 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 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.

 Le Faucheur et. al                                                 15

                      MPLS Support of Diff-Serv             October 99

   A Path message containing a COS SENDER_TSPEC and not containing a
   DIFFSERV_PSC object indicates to a Diff-Serv capable LSR that the
   LSP to be established in an E-LSP without any bandwidth reservation.

   A Path message containing a COS SENDER_TSPEC and containing a
   DIFFSERV_PSC object with its LSP-Type set to E-LSP indicates to a
   Diff-Serv capable LSR that the LSP to be established in an E-LSP
   without any bandwidth reservation.

   A Path message containing a COS SENDER_TSPEC and containing a
   DIFFSERV_PSC object with its LSP-Type set to L-LSP indicates to a
   Diff-Serv capable LSR that the LSP to be established in an L-LSP
   without any bandwidth reservation.

   The above is summarized in the following table:

           Path Message            LSP type
     Service   DIFFSERV_PSC  LSP
                 Object      Type

     GS/CL         No               E-LSP with bandwidth reservation
     GS/CL         Yes       E-LSP  E-LSP with bandwidth reservation
     GS/CL         Yes       L-LSP  L-LSP with bandwidth reservation
     COS           No               E-LSP without bandwidth reservation
     COS           Yes       E-LSP  E-LSP without bandwidth reservation
     COS           Yes       L-LSP  L-LSP without bandwidth 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).

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

   Two new LDP TLVs are defined in this document:
        - the `DIFF-SERV_PSC' TLV
        - the `Release Status' TLV
   Detailed descriptions of these TLV are provided below.

 Le Faucheur et. al                                                 16

                      MPLS Support of Diff-Serv             October 99

   As described in [LDP], there are two modes for label distribution:
   Downstream Unsolicited and Downstream on Demand.

   When an E-LSP is established using Downstream on Demand mode, the
   Label Request message and the Label Mapping message usually do not
   include the new Diff-Serv_PSC. In the case where, a single Ordered
   Aggregate is to be transported over the E-LSP, the Label Request
   message and the Label Mapping message may optionally include the new
   Diff-Serv_PSC (with its LSP-type defined below set to `E-LSP').

   When an E-LSP is established using Downstream Unsolicited mode, the
   new Diff-Serv_PSC MUST not be carried in the Label Request message
   nor in the Label Mapping message.

   When an L-LSP is established using Downstream on Demand mode, the
   new DIFF-SERV_PSC TLV MUST be carried in the Label Request Message
   to indicate the PHB Scheduling Class (PSC) of the LSP and may
   optionaly be carried in the Label Mapping message.

   When an L-LSP is established using Downstream Unsolicited mode, the
   new DIFF-SERV_PSC TLV MUST be carried in the Label Mapping Message
   to indicate the PHB Scheduling Class (PSC) of the LSP.

   The Release Status TLV is to be used to include diagnostic
   information in Label Release messages when handling Diff-Serv
   related errors.

   The new Diff-Serv_PSC and Release Status TLVs are optional with
   respect to LDP. A Diff-Serv capable LSR supporting E-LSPs in
   compliance with this specification MAY support the Diff-Serv_PSC TLV
   and the Release Status TLV. A Diff-Serv capable LSR supporting
   L-LSPs in compliance with this specification MUST support the Diff-
   Serv_PSC TLV and the Release Status TLV.

5.1 Diff-Serv related TLVs

5.1.1 Diff-Serv_PSC TLV

   As stated earlier, the PHB Scheduling Class associated with an L-LSP
   is to be specified through a new Diff-Serv_PSC TLV in LDP messages.
   The Diff-Serv_PSC TLV 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| Type = PSC (0x901)        |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Reserved     | T |PSCnb|              PSC              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U BIT =0

 Le Faucheur et. al                                                 17

                      MPLS Support of Diff-Serv             October 99

     If this new TLV is unknown to the LSR, the LSR must reject the
     whole message and return a notification

   F BIT = 0

     If this TLV is unknown to a LSR, this new TLV is NOT forwarded.

   Type

     The Type of the PSC TLV is: 0x901.

   Length

     This is set to 4.

   Reserved

     This field is set to all zeros

   T

      This indicates the `LSP Type'. The following values are
      specified:

           T Value      LSP type
           00           E-LSP
           01           L-LSP

   PSCnb

     Indicates the number of PSC values included in the TSC TLV. This
     is set to 001

   PSC Value

     Encoding of the PSC field is as specified in section 4.2.

5.1.2 Release Status TLV

   As stated earlier, error codes are to specified through a new
   Release Status TLV in LDP Label Release messages when E-LSP or L-LSP
   set-up fails. The Release Status TLV 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| Type = PSC (0x304)        |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Status Code                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Le Faucheur et. al                                                 18

                      MPLS Support of Diff-Serv             October 99

   U BIT =0

     If this new TLV is unknown to the LSR, the LSR must reject the
     whole message and return a notification

   F BIT = 0

     If this TLV is unknown to a LSR, this new TLV is NOT forwarded.

   Type

     The Type of the PSC TLV is: 0x304.

   Status Code

     Indicates the reason why the label was released. This field uses
     the same encoding and values as the `Status Code' word defined for
     the Notification message. Additional values are defined below, in
     the section titled `Status Code Values', for this Status Code
     field in addition to the values currently defined in [LDP].

5.1.3 Status Code Values

   The following values are defined for the Status Code field which is
   used in Notification message and may be used in Label Release
   messages:

        Status Code             E   Status Data

        Unsupported PSC value   0   0x00000016
        Unexpected PSC value    0   0x00000017
        Unexpected PSC TLV      0   0x00000018
        Unexpected LSP-Type     0   0x00000019

5.2 Diff-Serv Related LDP Messages

5.2.1 Label Request Message

   In Downstream on Demand mode, the Diff-Serv capable LSR requesting a
   label for an L-LSP includes the new Diff-Serv_PSC TLV in the Label
   Request message to signal that the LSP is an L-LSP and to indicate
   the PSC associated with the LSP.

   The format of the Label Request message for an L-LSP in Downstream
   on Demand mode, is as follows:

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

 Le Faucheur et. al                                                 19

                      MPLS Support of Diff-Serv             October 99

   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     PSC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.2 Label Mapping Message

   In Downstream Unsolicited mode, the Diff-Serv capable LSR allocating
   a label for an L-LSP includes the Diff-Serv_PSC TLV in the Label
   Mapping message to signal that the LSP is an L-LSP and to indicate
   the PSC associated with the LSP.

   The format of the Label Mapping message for an L-LSP in Downstream
   Unsolicited mode, is as follows:

    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                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     PSC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In Downstream on Demand mode, the Diff-Serv capable LSR allocating a
   label for an L-LSP in response to a Label Request message containing
   the Diff-Serv_PSC TLV, may optionally include the same Diff-Serv_PSC
   TLV in the Label Mapping message to confirm the PSC associated with
   the LSP.

   The format of the Label Mapping message for an L-LSP in Downstream
   Unsolicited mode, is as follows:

    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                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV                                 |

 Le Faucheur et. al                                                 20

                      MPLS Support of Diff-Serv             October 99

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     PSC TLV (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.3 Label Release Message

   [LDP] specifies that `an LSR sends a Label Release message to an LDP
   peer to signal the peer that the LSR no longer needs specific FEC-
   label mappings previously requested of and/or advertised by the
   peer.'

   This specification extends the use of the Label Release message so
   that, when an LSR cannot accept a label mapping for an E-LSP or an
   L-LSP, the LSR should send a Label Release message to the LDP Peer
   to signal the peer that the LSR cannot accept the label mapping.

   This specification also extends the encoding of the Label Release
   message so that the new Release Status TLV can optionally be
   included in the message. Thus the encoding of the Label Release
   message is:

       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)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Release Status TLV (optional)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.4 Notification Message

   This specification allows inclusion of the Diff-Serv_PSC TLV in the
   Notification. Thus the encoding of the Notification message is:

    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                       |

 Le Faucheur et. al                                                 21

                      MPLS Support of Diff-Serv             October 99

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Diff-Serv_PSC TLV (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3 Handling of the Diff-Serv_PSC TLV

5.3.1 Handling of the Diff-Serv_PSC TLV in Downstream Unsolicited Mode

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

   When allocating a label for an E-LSP, a Diff-Serv capable LSR issues
   a Label Mapping message without the Diff-Serv_PSC TLV.

   A Diff-Serv capable LSR receiving a Label Mapping message without
   the Diff-Serv_PSC TLV, must:
        - update its Incoming Label Map (ILM) [MPLS_ARCH] to store the
   necessary Diff-Serv information. This includes the fact that the
   Next Hop Label Forwarding Entry (NHLFE) corresponds to an E-LSP.
        - install the required scheduling and dropping behavior for
   this NHLFE to support Diff-Serv forwarding as specified for E-LSPs
   in section 2.2.

   When allocating a label for an L-LSP, a Diff-Serv capable LSR issues
   a Label Mapping message which contains the Diff-Serv_PSC TLV with
   its PSC field indicating the PSC of the L-LSP.

   A Diff-Serv capable LSR receiving a Label Mapping message containing
   the Diff-Serv_PSC TLV, must:
        - update its ILM to store the necessary Diff-Serv information.
   This includes the fact that the NHLFE corresponds to an L-LSP and
   its PSC.
        - install the required scheduling and dropping behavior for
   this LSP to support Diff-Serv forwarding as specified for L-LSPs in
   section 3.2.

   A Diff-Serv capable LSR receiving a Label Mapping message with the
   Diff-Serv_PSC TLV 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 Release Status TLV with a Status Code
   of `Unsupported PSC Value'.

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

5.3.2 Handling of the Diff-Serv_PSC TLV in Downstream on Demand Mode

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

 Le Faucheur et. al                                                 22

                      MPLS Support of Diff-Serv             October 99

   When requesting a label for an E-LSP, a Diff-Serv capable LSR sends
   a Label Request message without the Diff-Serv_PSC TLV.

   Optionally, when requesting a lebel for an E-LSP over which a single
   Ordered Aggregate is to going to be transported, the Diff-Serv
   capable LSR may send a Label Request message containing the Diff-
   Serv_PSC TLV with its LSP type set to E-LSP and its PSC field set to
   the value of the PSC to be supported on the E-LSP.

   A Diff-Serv capable LSR sending a Label Mapping message in response
   to a Label Request message which did not contain the Diff-Serv_PSC
   TLV, must not include Diff-Serv_PSC TLV in this Label Mapping
   message.

   A Diff-Serv capable LSR sending a Label Mapping message in response
   to a Label Request message which contained the Diff-Serv_PSC TLV
   with its E-LSP type set to E-LSP, may send this Label Mapping
   message without the Diff-Serv_PSC TLV. Optionally, the LSR may send
   this Label Mapping message with the Diff-Serv_PSC TLV with its LSP-
   Type set to E-LSP and its PSC field set to the same value as the one
   received in the Label Request message.

   A Diff-Serv capable LSR receiving a Label Mapping message without
   the Diff-Serv_PSC TLV in response to its Label Request message for
   an E-LSP, must:
        - update its ILM to store the necessary Diff-Serv information.
   This includes the fact that the NHLFE corresponds to an E-LSP.
        - install the required scheduling and dropping behavior for
   this NHLFE to support Diff-Serv forwarding as specified for E-LSPs
   in section 2.2.

   A Diff-Serv capable LSR receiving a Label Mapping message containing
   the Diff-Serv_PSC TLV in response to its Label Request message for
   an E-LSP which did not contain the Diff-Serv_PSC TLV, must reject
   the label mapping by sending a Label Release message which includes
   the Label TLV and the Release Status TLV with a Status Code of
   `Unexpected PSC TLV'.

   A Diff-Serv capable LSR receiving a Label Mapping message containing
   the Diff-Serv_PSC TLV in response to its Label Request message for
   an E-LSP which contained the Diff-Serv_PSC TLV, must compare the
   received and sent Diff-Serv_PSC TLVs.

   If those are equal, the LSR must:
        - update its ILM to store the necessary Diff-Serv information.
   This includes the fact that the NHLFE corresponds to an E-LSP.
        - install the required scheduling and dropping behavior for
   this NHLFE to support Diff-Serv forwarding as specified for E-LSPs
   in section 2.2.

 Le Faucheur et. al                                                 23

                      MPLS Support of Diff-Serv             October 99

   If those are not equal because they have a different LSP-Type, the
   LSR must reject the Label Mapping by sending a Label Release message
   which includes the Label TLV and the Release Status TLV with a
   Status Code of `Unexpected LSP-Type'.

   If those are not equal because they have a different PSC value, the
   LSR must reject the Label Mapping by sending a Label Release message
   which includes the Label TLV and the Release Status TLV with a
   Status Code of `Unexpected PSC Value'.

   When requesting a label for an L-LSP, a Diff-Serv capable LSR sends
   a Label Request message with the Diff-Serv_PSC TLV which indicates
   the PSC of the L-LSP.

   A Diff-Serv capable LSR receiving a Label Request message with the
   Diff-Serv_PSC TLV containing a PSC value which is not supported or
   for which no EXP/PSC<-->PHB mapping is configured, must send a
   Notification message with a Status Code of `Unsupported PSC Value'.

   A Diff-Serv capable LSR that recognizes the Diff-Serv_PSC 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' Status
   Code). This Notification message must include the requested
   Diff-Serv_PSC TLV.

   A Diff-Serv capable LSR sending a Label Mapping message in response
   to a Label Request message which contained the Diff-Serv_PSC TLV,
   may optionally include the exact same Diff-Serv_PSC TLV in this
   Label Mapping message.

   A Diff-Serv capable LSR receiving a Label Mapping message without
   the Diff-Serv_PSC TLV in response to its Label Request message for
   an L-LSP, must:
        - update its ILM to store the necessary Diff-Serv information.
   This includes the fact that the NHLFE corresponds to an L-LSP and
   its PSC.
        - install the required scheduling and dropping behavior for
   this NHLFE to support Diff-Serv forwarding as specified for L-LSPs
   in section 3.2.

   A Diff-Serv capable LSR receiving a Label Mapping message with the
   Diff-Serv_PSC TLV in response to its Label Request message for an L-
   LSP, must verify that the Diff-Serv_PSC TLV received in the Label
   Mapping message is equal to the Diff-Serv_PSC TLV sent in the Label
   Request message.

   If those are equal, the LSR must:
        - update its ILM to store the necessary Diff-Serv information.
   This includes the fact that the NHLFE corresponds to an L-LSP and
   its PSC

 Le Faucheur et. al                                                 24

                      MPLS Support of Diff-Serv             October 99

        - install the required scheduling and dropping behavior for
   this NHLFE to support Diff-Serv forwarding as specified for L-LSPs
   in section 3.2.

   If those are not equal because they have a different LSP-Type, the
   LSR must reject the Label Mapping by sending a Label Release message
   which includes the Label TLV and the Release Status TLV with a
   Status Code of `Unexpected LSP-Type'.

   If those are not equal because they have a different PSC value, the
   LSR must reject the Label Mapping by sending a Label Release message
   which includes the Label TLV and the Release Status TLV with a
   Status Code of `Unexpected PSC Value'.

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

5.4 Non-Handling of the Diff-Serv_PSC TLV

   An LSR that does not recognize the Diff-Serv_PSC TLV Type, on
   receipt of a Label Request message or a Label Mapping message
   containing the Diff-Serv_PSC TLV, must ignore the message and return
   a Notification message with _Unknown TLV_ Status.

5.5 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 TLV as described in
   [MPLS CR LDP].

6. MPLS Support of Diff-Serv over PPP

   The general operations for MPLS support of Diff-Serv, including
   label forwarding and LSP setup operations was specified in the
   previous sections. This section describes the specific operations
   required for MPLS support of Diff-Serv over PPP links. While
   sections 7, 8 and 9 focus on other media specific operations, namely
   ATM, Frame Relay and LAN respectively.

   This document allows the following set of LSP setup combinations per
   FEC within an MPLS PPP Diff-Serv domain:

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

6.1. E-LSP Operations over PPP

 Le Faucheur et. al                                                 25

                      MPLS Support of Diff-Serv             October 99

   Since MPLS uses the Shim Header for encapuslation over PPP, E-LSPs
   are supported over PPP. The E-LSP setup, label forwarding and
   merging operations over PPP follows exactly the procedures defined
   in section 2. No additional PPP specific procedures are defined for
   E-LSPs.

6.2  L-LSP Operations over PPP

   L-LSPs are also supported over PPP. The L-LSP operations over PPP
   follows the general procedures of section 3. However, the following
   PPP specific procedures are also defined for L-LSP operations over
   PPP :

        - An MPLS PPP ingress interface determines the incoming PHB
   from the PSC and the EXP field of the top level label entry in
   accordance with the PSC/EXP -->PHB mappings defined below in section
   6.3.

        - If the EXP field value of a packet received on an L-LSP is
   such that the PSC/EXP combination is not listed in the mapping of
   section 6.3, this PSC/EXP combination should be considered invalid.
   LSR behavior in such situation is a local matter and is outside the
   scope of this document.

        - An MPLS PPP egress interface determines the value to be
   written in the EXP field of the top level label entry (and possibly
   of other level label entries in the case of a hierarchical tunnel
   entry) by performing the outgoing PHB-->EXP/PSC mapping defined
   below in section 6.4.

6.3 PSC/EXP --> PHB mapping

   The mapping from the L-LSP PSC and the EXP field of the shim header
   into PHBs is as follows:

      EXP Field      PSC             PHB

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

6.4 PHB --> PSC/EXP mapping

   The mapping from PHBs into the L-LSP PSC and the EXP field of the
   shim header is as follows:

      PHB              EXP Field     PSC

      DF     ----->     000          DF

 Le Faucheur et. al                                                 26

                      MPLS Support of Diff-Serv             October 99

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

6.5 LSR implementation with PPP interfaces

   For an LSR implementation with PPP interfaces, support of E-LSPs
   over the PPP interfaces is mandatory with respect to this
   specification. A Diff-Serv capable LSR with PPP interfaces MUST
   support E-LSPs over these PPP interfaces in compliance with this
   specification.

   Support of L-LSPs over PPP interfaces by an LSR implementation is
   optional. A Diff-Serv capable LSR MAY support L-LSPs over PPP
   interfaces. However, if a Diff-Serv LSR does support L-LSPs over PPP
   interfaces, then it MUST do so in compliance with all the material
   from this specification pertaining to L-LSPs.

   An LSR running MPLS over PPP over a traditional ATM connection (ie
   where the ATM switches do not participate in MPLS and where the ATM
   connection VPI/VCI values have not been established via any label
   distribution protocol) is to be considered as an LSR with PPP
   interfaces from the point of view of compliance to this
   specification.

   Similarly, an LSR running MPLS over PPP over a traditional Frame
   Relay connection (ie where the Frame Realy switches do not
   participate in MPLS and where the Frame Relay connection DLCI values
   have not been established via any label distribution protocol) is to
   be considered as an LSR with PPP interfaces from the point of view
   of compliance to this specification.

7. MPLS Support of Diff-Serv by ATM LSRs

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

   This document allows the following set of LSP setup combinations per
   FEC within an MPLS ATM Diff-Serv domain:

        - any number of L-LSPs.

7.1 L-LSP Operations over ATM

   The L-LSP operations over ATM follows the general procedures of
   section 3. However, the following ATM specific procedures are also
   defined for L-LSP operations over ATM links :

 Le Faucheur et. al                                                 27

                      MPLS Support of Diff-Serv             October 99

        - An MPLS ATM ingress interface determines the incoming PHB
        from the PSC and the ATM Cell Loss Probability (CLP) bit in
        accordance with the incoming PSC/CLP-->PHB mapping defined
        below in section 7.2;

       - If the CLP value of a packet received on an L-LSP is such that
       the PSC/CLP combination is not listed in the mapping of section
       7.2, this PSC/CLP combination should be considered invalid. LSR
       behavior in such situation is a local matter and is outside the
       scope of this document.

        - An MPLS ATM egress interface determines the value to be
        written in the ATM Cell Loss Probability (CLP) bit by
        performing the outgoing PHB-->PSC/CLP mapping defined below in
        section 7.3. This is performed by an LSR on the Edge of the ATM
        Diff-Serv MPLS Cloud and is performed by an ATM LSR in the
        middle of the ATM Diff-Serv MPLS cloud when doing optional
        Local Policy and Traffic Conditioning. When not doing optional
        Local Policy and Traffic Conditioning, an LSR in the middle of
        the ATM Diff-Serv MPLS cloud may simply leave the CLP bit
        untouched;

        - when packet is segmented to cells on edge LSR, all cells of
        the packet SHOULD be encoded with the same CLP bit value.

7.2 PSC/CLP --> PHB mapping

   The mapping from L-LSP PSC and CLP bit of the ATM cell header into
   PHBs is as follows:

      CLP Bit      PSC             PHB

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

   Since there is marked with only one bit for encoding the AF codepoint AFij,
   where 1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4)
   with three levels of PHB drop precedence in each class (M=3)
   value over ATM links, only two different drop precedence levels are
   defined
   supported in ATM LSRs. The behaviour for general use. AF MUST comply to
   procedures described in [DIFF_AF] states that "a DS node does not reorder IP packets of for the
   same microflow if they belong to case when only two drop
   precedence levels are supported.

7.3 PHB --> PSC/CLP mapping

   The mapping from PHBs into the same AF class" (even if
   different packets of L-LSP PSC and the microflow contain different AF codepoints CLP bit of the same AF class). As noted above, each AF class in the AF ATM
   cell header is as follows:

      PHB
   group             CLP Bit     PSC

 Le Faucheur et. al                                                 28

                      MPLS Support of Diff-Serv             October 99

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

7.4 Merging

   The use of merging is the primary example optional. In case that merging of a PHS. Each PHS comprises 3 PHBs and
   coincides ATM LSPs is
   used, procedures described in section 3.5. of this specification
   apply. Additionally, to avoid cell interleaving problems with AAL-5
   merging, procedures specified in [MPLS ATM] MUST be followed.

7.5 Use of ATM Traffic Classes and Traffic Management mechanisms

   The use of the AF Class. Those PHSs are thus referred to ATM traffic classes as
   AFCn, where 1 <= n <= 4.

1.1.4 EF PHS

   [DIFF_EF] defines specified by ITU-T and ATM-
   Forum or of vendor specific ATM traffic classes is outside of the Expedited Forwarding (EF) PHB
   scope of this specification. The only requirement for traffic
   requiring compliant
   implementation is that the forwarding with low loss, low latency, low jitter.
   [DIFF_EF] defines behaviour experienced by a single PHB. Thus,
   Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be
   compliant with the corresponding PHS
   comprises a single Diff-Serv PHB and thus coincides specifications.

   To avoid discarding parts of 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.

7.6 LSR Implementation With ATM Interfaces

   For an LSR implementation with ATM interfaces running native ATM
   MPLS, support of L-LSPs over the DF PHB.

1.1.5 Summary list ATM interfaces is mandatory with
   respect to this specification. A Diff-Serv capable LSR with ATM
   interfaces MUST support L-LSPs over these ATM interfaces in
   compliance with this specification. Additionally, procedures
   specified in [MPLS ATM] MUST be followed by compliant
   implementation.

   Support of E-LSPs over ATM interfaces running native ATM MPLS by an
   LSR implementation is not allowed.

8. MPLS Support of PHS Diff-Serv by Frame Relay LSRs

   The following PHSs have thus been identified:
        - DF
        - CSn , 1 <= i <= 8
        - AFCn, 1 <= i <= 4
        - EF

1.2 general operations for MPLS support of Diff-Serv, including
   label forwarding and LSP Establishment setup operations was specified in the
   previous sections. This section describes the specific operations
   required for MPLS support of Diff-Serv over ATM/FR Frame Relay links.

   This document allows the following set of LSP setup combinations per
   FEC within an MPLS

   Recognizing that

Wu Frame Relay Diff-Serv domain:

        - any number of L-LSPs.

 Le Faucheur et. al                                                            3                                                 29

                      MPLS Support of DiffServ over ATM/FR          June Diff-Serv             October 99

        -

8.1 L-LSP Operations over Frame Relay

   The L-LSP operations over Frame Relay follows the general procedures
   of section 3. However, the following Frame Relay specific procedures
   are also defined for L-LSP operations over Frame Relay links :

        - An MPLS Header Frame Relay ingress interface determines the incoming
        PHB from the PSC and the Frame Relay Discard Eligible(DE) bit
        in accordance with the incoming PSC/CLP-->PHB mapping defined
        below in section 8.2;

       - If the DE value of MPLS switched packets a packet received on an L-LSP is such that
       the PSC/DE combination is generally not
   visible to ATM listed in the mapping of section
       8.2, this PSC/DE combination should be considered invalid. LSR
       behavior in such situation is a local matter and Frame Relay MPLS LSRs since it is encapsulated
   "inside" outside the ATM or FR LSP "connection";
       scope of this document.

        - An MPLS Diff-Serv assumes a similar architecture to non-MPLS
   Diff-Serv whereby Frame Relay egress interface determines the appropriate forwarding/prioritisation is value to
        be
   performed at every hop (ie every MPLS LSR, including ATM LSR and FR
   LSR) written in accordance to the packet's Behavior Aggregate.

        - ATM and Frame Relay switching hardware is generally capable
   of selecting different scheduling behaviors (eg. Queues) for
   cells/frames belonging to different connections but Discard Eligible (DE) bit by
        performing the outgoing PHB-->PSC/DE mapping defined below in
        section 8.3. This is generally not
   capable performed by an LSR on the Edge of selecting different scheduling behaviors for cells/frames
   belonging to the same ATM/Frame
        Frame Relay connection;

        - ATM Diff-Serv MPLS Cloud and is performed by an Frame
        Relay switching hardware is capable of
   maintaining LSR in the order middle of all packets or cells sent on a single
   connection;

        - ATM and the Frame Relay switching hardware is generally capable
   of enforcing different drop priorities within a single connection
   via standardized technology-specific selective drop mechanisms (Cell
   Loss Priority - CLP- for ATM Diff-Serv MPLS cloud
        when doing optional Local Policy and Discard Eligible - DE- for Frame
   Relay);

   we propose that

        - all packets belonging to a single SA Traffic Conditioning. When
        not doing optional Local Policy and Traffic Conditioning, an
        LSR in the same Forwarding
   Equivalence Class (FEC) be sent down a single LSP;

        - one LSP be established per <FEC, SA> pair (rather than middle of the Frame Relay Diff-Serv MPLS cloud may
        simply
   one LSP per FEC as in a network that does not support Diff-Serv).
   Such an LSP is referred to as a "Label-inferred-PHS" LSP or "L-LSP";

        - packets leave the DE bit untouched;

8.2 PSC/DE --> PHB mapping

   The mapping from multiple BAs L-LSP PSC and DE bit of a given SA be granted a the Frame Relay header into
   PHBs is as follows:

      DE Bit       PSC             PHB

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

   Since there is only one bit for encoding the PHB drop precedence
   value over Frame Relay links, only two different drop precedence through
   levels are supported in Frame Relay LSRs. The behaviour for AF MUST
   comply to procedures described in [DIFF_AF] for the case when only
   two drop precedence levels are supported.

8.3 PHB --> PSC/DE mapping

   The mapping from PHBs into the layer 2 specific
   selective discard indicator (CLP bit with ATM, DE bit with FR).

   MPLS specifies how LSPs can be established via multiple signaling
   protocols. Those include the Label Distribution Protocol (LDP),
   RSVP, BGP and PIM. This Internet-Draft proposes below the required
   extensions to LDP and RSVP to allow establishment of one L-LSP per
   <FEC,SA> pair over ATM MPLS PSC and FR MPLS.

   For the purpose DE bit of meeting some specific Traffic Engineering goals,
   we note that:
        - SAs supported by separate L-LSPs may be Traffic Engineered
   separately. A path is selected independently for each SA (eg by
   Constraint Based Routing or by explicit configuration) and the

Wu Frame
   Relay header is as follows:

 Le Faucheur et. al                                                            4                                                 30

                      MPLS Support of DiffServ over ATM/FR          June Diff-Serv             October 99

   corresponding L-LSPs are then established independently via RSVP or
   CR-LDP signaling;
        - SAs supported by separate L-LSPs may be Traffic Engineered
   jointly. A path is selected for the aggregate

      PHB               DE Bit     PSC

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

8.4 Merging

   The use of merging is optional. In case that merging of all the considered
   SAs and the L-LSPs are then established independently along the same
   common path via RSVP or CR-LDP signaling;

1.3 Explicit Congestion Notification

   Explicit Congestion Notification Frame Relay
   LSPs is used, procedures described in [ECN] and is
   proposed section 3.5. of this
   specification apply as an Experimental extension to well as procedures in [MPLS FR].

8.5 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms

   The use of the IP protocol. Because
   ECN Frame Relay traffic parameters as specified by ITU-T
   and Frame Relay-Forum or of vendor specific Frame Relay traffic
   management mechanisms is still at outside of the Experimental stage and its impact and
   interactions with Diff-Serv have not yet been specified, scope of this
   Internet-Draft does not discuss ECN operations. Support specification.
   The only requirement for
   simultaneous Diff-Serv and ECN over MPLS compliant implementation is left for further study.

1.4 Label Forwarding for Diff-Serv over ATM/FR MPLS

   In order to describe Label Forwarding that the
   forwarding behavior experienced by Diff-Serv LSRs, we propose
   to model a Behavior Aggregate forwarded
   over an L-LSP by the Frame Relay LSR MUST be compliant with the
   corresponding Diff-Serv label switching behavior as comprising three
   stages:
        -A- incoming PHB and FEC determination
        -B- Optional outgoing PHB determination via Local Policy and
   Traffic Conditioning
        -C- Outgoing EXP field and label determination

   The Diff-Serv specifications.

8.6 LSR SHALL apply Implementation With Frame Relay Interfaces

   For an LSR implementation with Frame Relay interfaces running native
   Frame Relay MPLS, support of L-LSPs over the scheduling/dropping behavior
   corresponding Frame Relay interfaces
   is mandatory with respect to the "Outgoing PHB" this specification. A Diff-Serv capable
   LSR with Frame Relay interfaces MUST support L-LSPs over these Frame
   Relay interfaces in compliance with the
   corresponding Diff-Serv PHB this specification.

   With such a model, we expect that "Diff-Serv

   Support of E-LSPs over Frame Relay interfaces running native Frame
   Relay MPLS by an LSR implementation is not allowed.

9. MPLS Support of Diff-Serv over MPLS" LAN Media

   The general operations for MPLS support of Diff-Serv, including
   label forwarding can be and LSP setup operations was specified (from in the Diff-Serv viewpoint)
   separately
   previous sections. This section describes the specific operations
   required for each method (eg. Diff-Serv over MPLS over ATM/FR, support of Diff-Serv over MPLS over PPP using L-LSPs [MPLS_DIFF_PPP], Diff-Serv LAN.

   This document allows the following set of LSP setup combinations per
   FEC over an MPLS over PPP using E-LSPs [MPLS_DIFF_PPP]) by specifying -A- link:

        - Zero or any number of E-LSP, and -C- for the considered method without having to specify the
   complete label switching behavior (A+B+C) for every possible
   incoming/outgoing combination.

   This model is used below for specifying LSR Label Forwarding over
   ATM/FR using L-LSPs for
        - Zero or any number of L-LSPs.

 Le Faucheur et. al                                                 31

                      MPLS Support of Diff-Serv support             October 99

9.1. E-LSP Operations over MPLS.

1.5 Relationship with [MPLS_DIFF_PPP]

   The procedures described in this Internet Draft PPP

   Text to establish and be written (in particular regarding use
   L-LSPs to achieve support of Diff-Serv over MPLS 802.1 COS field).

9.2  L-LSP Operations over ATM and FR,
   are identical to the procedures described in [MPLS_DIFF_PPP] for L-
   LSPs as one method PPP

   Text to achieve be written (in particular regarding use of 802.1 COS field).

9.3 LSR Implementation With LAN Interfaces

   For an LSR implementation with LAN interfaces, support of Diff-Serv over MPLS E-LSPs
   over
   PPP.

   Note that a single method (based on L-LSPs) the LAN interfaces is proposed in mandatory with respect to this
   Internet Draft for support of
   specification. A Diff-Serv capable LSR with LAN interfaces MUST
   support E-LSPs over MPLS over ATM/FR while

Wu et. al                                                            5

                 MPLS these LAN interfaces in compliance with this
   specification.

   Support of DiffServ L-LSPs over ATM/FR          June 99

   [MPLS_DIFF_PPP] defines two methods for LAN interfaces by an LSR implementation is
   optional. A Diff-Serv capable LSR MAY support of L-LSPs over LAN
   interfaces. However, 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.

10. Operations at MPLS over PPP. The other method Diff-Serv Boundaries

10.1 Operations at E-LSP/L-LSP Boundary Within Single MPLS Diff-Serv
Domain

   Text to be added

10.2 Operations At Boundary across Diff-Serv domains

   Text to be added

11. Explicit Congestion Notification

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

   [MPLS_ECN] discusses deployment of Diff-Serv over ECN in an MPLS over PPP relies on E-LSPs. E-
   LSPs require that different packets of network using the same LSP be given
   different scheduling treatment by
   Shim Header as the LSR which is generally
   incompatible with existing ATM/FR hardware capabilities.

2. Label Forwarding for Diff-Serv over ATM/FR MPLS

2.2.1 Incoming PHB and FEC Determination On Ingress ATM/FR L-LSP

   When receiving an ATM/FR call/frame containing encapsulation. It demonstrates that,
   provided a labeled packet over
   an L-LSP of 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 supported in an MPLS ATM ingress interface:

   If domain where the LSR Shim
   Header is a Frame LSR (ie Egress Edge of used as the ATM/FR MPLS cloud),
   the LSR:
        - determines the FEC based on the incoming label
        - determines encapsulation via a single bit of the PHS from EXP
   field.

   The details of how a given LSP is to be identified as ECN-capable or
   non-ECN-capable (whether via extensions to the incoming label among LSP establishment
   signaling and procedures, via configuration or via other means) are
   outside the set scope of this specification.

 Le Faucheur et. al                                                 32

                      MPLS Support of Diff-Serv             October 99

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

        - determines the incoming PHB Support of ECN does not require that any bit(s) from the PHS and the EXP
   field 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
   the top level label entry of the encapsulated label stack in
   accordance with the PHS/EXP-->PHB mapping defined in section 2.3 of
   [MPLS_DIFF_PPP]

   If the LSR whether this is an ATM/FR LSR (ie ATM/FR LSR in the middle of the
   ATM/FR MPLS cloud), the LSR:
        - determines the FEC based because at least one LSR on
   the incoming VCI/DLCI
        - determines the PHS from the incoming VCI/DLCI among the set
   of LSPs established for that FEC
        - determines LSP does not support ECN operations or whether this is because
   the "incoming" drop precedence network administrator does not wish to be applied on
   the packet based use ECN on the CLP/DE field.

2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning

   This stage this LSP) can
   make use of the full 3-bit EXP field for Diff-Serv label switching is optional purposes. Thus,
   non-ECN-capable E-LSPs and may non-ECN-capable L-LSPs can operate as
   defined earlier in this document without any restriction imposed by
   the fact that the MPLS domain is ECN-capable. In particular, up to 8
   BAs can still be used
   on transported over a Frame LSR to perform Behavior Aggregate demotion or promotion
   inside non-ECN-capable E-LSP within an
   ECN-capable MPLS Diff-Serv domain. For Similarly, non-ECN-capable L-LSPs within an
   ECN-capable MPLS domain can support all the purpose drop precedence levels
   of specifying currently defined PSCs. Should a
   Diff-Serv over future PSC involve more than 4
   drop precedence levels, non-ECN-capable L-LSPs within an ECN-capable
   MPLS method, we simply note that domain could still use the PHB full 3-bit field EXP.

        - Because a single bit is required to encode the ECN
   information inside the ECN-capable MPLS domain, LSPs identified as
   ECN-capable can make use of two bits of the EXP field value. In
   particular, up to 4 BAs can be
   actually enforced by transported over an LSR (referred ECN-capable E-
   LSP. Similarly, up to as "outgoing PHB") may 4 drop precedence levels can be
   different to supported over
   an ECN-capable L-LSP; since all the PHB which had been associated with 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 by standards action or corresponding to local use or
   experimental PHBs, involve more than 4 drop precedence levels, then
   ECN support over the packet at corresponding LSP would constrain the previous LSR (referred PSC to as "incoming PHB").

   This stage 4
   drop precedence levels; relative benefits of Diff-Serv label switching is optional and may additional precedence
   levels beyond 4, would then be used
   on Frame LSRs with ATM/FR interfaces.

   In weighted by the case network administrator
   over the benefits of ATM/FR LSRs, ECN, to determine whether it is expected that this optional stage
   of Diff-Serv label switching, if supported, would be limited to
   CLP/DE remarking (ie remarking the "incoming CLP/DE" preferable to a different
   value in the "outgoing CLP/DE")

Wu et. al                                                            6

                 MPLS Support of DiffServ
   support this PSC over ATM/FR          June 99

2.2.3   Outgoing CLP/DE Field and Label Determination on Egress ATM/FR
L-LSP

   If the LSR is a Frame LSR (ie Ingress Edge of the ATM/FR an ECN-capable or non-ECN-capable LSP.

11.1 MPLS
   cloud):
   Once the outgoing PHB has been determined by ECN bit with Shim Header

   Where the LSR Shim Header is used as a function
   of the incoming PHB and of the optional Local Policy and Traffic
   Conditioning, the LSR:
        - determines the "outgoing" PHS by performing the "outgoing"
   PHB--> PHS/CLP-DE mapping defined below MPLS encapsulation, ECN
   information is to be encoded on ECN-capable LSPs in section 3.
        - determines the egress L-LSP label from the packet's FEC and
   PHS
        - encodes first bit of
   the 3-bit EXP field of the top level label entry shim
   header of the label stack (which is encapsulated in the ATM /FR LSP) in accordance with the PHB following way:

     EXP field          MPLS ECN Meaning

     0xx        --> PHS/EXP Mapping defined in section
   2.4     `ECT, not CE'
     1xx        -->     `not ECT, or ECT+CE'

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

 Le Faucheur et. al                                                 33

                      MPLS Support of [MPLS_DIFF_PPP].
        - determines the value to be written in the CLP/DE field Diff-Serv             October 99

   Detailed specification for usage of this MPLS ECN bit is outside the
   outgoing cell/frame by performing the outgoing PHB--> PHS/CLP-DE
   mapping defined below in section 3.
        - applies a scheduling/dropping behavior corresponding to the
   "outgoing" PHB
   scope of this specification.

   For ECN-capable E-LSPs, the PHB<-->EXP mapping defined above in compliance with the corresponding Diff-Serv PHB
   specification.

   If
   section titled `PHB<-->EXP Field Mapping' and configured on the LSR
   is an ATM/FR LSR (ie ATM/FR LSR in only operating over the middle last 2 bits of the
   ATM/FR MPLS cloud):
   Once the "outgoing" drop precedence (CLP/DE) 3-bit EXP field. Thus
   it has been determined by the LSR as following format:

      EXP Field                 PHB

        e00     <----->         a function of given PHB
        e01     <----->         a given PHB
        e10     <----->         a given PHB
        e11     <----->         a given PHB

   where `e' is the "incoming" drop precedence (CLP/DE) MPLS ECN bit and
   of can take the optional Local Policy and Traffic Conditioning, value zero or one
   depending on ECN operations.

   For ECN-capable L-LSPs, the LSR:
        - determines PSC/EXP-->PHB mapping defined above in
   the outgoing interface, section titled `PSC/EXP-->PHB is only operating over the outgoing VCI/DLCI last 2
   bits of the 3-bit EXP field and is the output scheduling queue from following:

      EXP Field      PSC             PHB

        e00          DF    ----->    DF
        e00          CSn   ----->    CSn
        e00          AFCn  ----->    AFn1
        e01          AFCn  ----->    AFn2
        e10          AFCn  ----->    AFn3
        e00          EF    ----->    EF

   where `e' is the incoming VCI/DLCI
        - applies a scheduling treatment corresponding to MPLS ECN bit and can take the value zero or one
   depending on ECN operations.

   For ECN-capable L-LSPs, the
   VCI/DLCI/label's PHS PHB--> PSC/EXP mapping defined above in compliance with
   the corresponding Diff-Serv
   PHB specification
        - writes section titled `PHB--> PSC/EXP Mapping' is only operating over
   the "outgoing" CLP/DE value into last 2 bits of the outgoing
   cell/frame
        - applies 3-bit EXP field and is the drop precedence corresponding to following:

        PHB              EXP Field     PSC

        DF     ----->     e00          DF
        CSn    ----->     e00          CSn
        AFn1   ----->     e00          AFCn
        AFn2   ----->     e01          AFCn
        AFn3   ----->     e10          AFCn
        EF     ----->     e00          EF

   where `e' is the "outgoing"
   CLP/DE.

2.2.4 Simplified Forwarding MPLS ECN bit and can take the value zero or one
   depending on an ATM/FR LSR

   When Local Policy ECN operations.

 Le Faucheur et. al                                                 34

                      MPLS Support of Diff-Serv             October 99

   For non-ECN-capable LSPs, the first bit of the 3-bit EXP field is
   NOT reserved for ECN and Traffic Conditioning are not to can be performed
   by used to encode any Diff-Serv
   information. In particular, for non-ECN-capable E-LSPs, the LSR,
   PHB<-->EXP mapping defined in the Forwarding operation of an ATM/FR LSR is "reduced"
   to traditional ATM/FR switching since:
        - section titled `PHB<-->EXP Field
   Mapping' and configured on the LSR only looks at is operating over the incoming VCI/DLCI 3 bits of an incoming
   ATM cell/FR Frame to determine
   the output interface, EXP field.

12. Security Considerations

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

13. Acknowledgments

   This document has benefited from discussions with K. K.
   Ramakrishnan, Eric Rosen, Angela Chiu and Carol Iturralde.

APPENDIX A. Ordered Aggregate (OA) and PHB Scheduling Class (PSC)

   This Appendix contains the output scheduling queue, definition of two Diff-Serv concepts:
        - the LSR only looks at Ordered Aggregate (OA)
        - the incoming CLP/DE field to determine PHB Scheduling Class (PSC)
   In the drop precedence to future, it is expected that these definitions will be applied on the cell/frame,
        - the MPLS Shim Header encapsulated
   incorporated in new versions of the ATM/FR connection Diff-Serv specifications.

A.1 Ordered Aggregate (OA)

   [DIFF_AF] states that "a DS node does not need to be looked at nor modified.

Wu et. al                                                            7

                 MPLS Support reorder IP packets of DiffServ over ATM/FR          June 99

2.2.5 Number the
   same microflow if they belong to the same AF class" (even if
   different packets of Drop Precedence Levels

   Because the underlying standardized ATM and Frame Relay Selective
   Discard mechanisms (CLP/DE) only support two levels microflow contain different AF codepoints
   of Drop
   Precedence, the proposed solution is limited to two levels same AF class).

   For the sake of Drop
   Precedence per PHS in generality, we define a set of Behavior Aggregates
   which share such an ATM MPLS ordering constraint to constitute a "Ordered
   Aggregate" (OA).

A.2 PHB Scheduling Class (PSC)

   We refer to the set of one or FR more PHBs applied to the set of
   Behavior Aggregates forming a given OA, as a "PHB Scheduling Class"
   (PSC).

   The PHBs currently specified are Default PHB (DF), Class Selector
   PHB group (CSx), Assured Forwarding PHB group (AFxy), Expedited
   Forwarding PHB (EF).

 Le Faucheur et. al                                                 35

                      MPLS cloud.

   However, the label stack encapsulated in the ATM LSP or FR LSP Support of Diff-Serv             October 99

A.2.1 DF PSC

   The Default PHB is
   expected to include a shim header for single PHB specified in [DIFF_Header]. Thus,
   the top label entry with corresponding PSC comprises a
   meaningful EXP field, which can single PHB and thus coincides with
   the DF PHB.

A.2.2 CSn PSC

   [DIFF_HEADER] defines up to 8 CS Codepoints referred to as CSn,
   where 1 <= i <= 8. [DIFF_HEADER] states that "... PHBs selected by
   distinct Class Selector Codepoints SHOULD be used independently
   forwarded; that is, packets marked with different Class Selector
   Codepoints MAY be re-ordered". Thus, there is one PSC corresponding
   to encode all levels of
   Drop Precedence within each CSn PHB. Each CSn PSC comprises a PHS as defined single PHB and thus
   coincides with this CSn PHB.

A.2.3 AFn PSC

   As described in [MPLS_DIFF_PPP].
   Consequently, even if only two levels [DIFF_AF], the Assured Forwarding (AF) PHB group
   provides forwarding of Drop Precedence are
   achieved IP packets in the ATM/FR MPLS cloud, all Drop Precedence levels (eg
   the three N independent AF classes.
   Within each AF class, an IP packet is assigned one of M different
   levels of drop precedence. An IP packet that belongs to an AF Class) can be supported in PPP MPLS clouds
   surrounding an ATM/FR MPLS cloud.

3. PHB Mapping into PHS class
   i and Selective Discard Mechanism

   3.1 PHB-->PHS/CLP Mapping

   The mapping from PHBs into has drop precedence j is marked with the L-LSP PHS AF codepoint AFij,
   where 1 <= i <= N and the Cell Loss Priority
   (CLP) field 1 <= j <= M. Currently, four classes (N=4)
   with three levels of drop precedence in each class (M=3) are
   defined for general use.

   [DIFF_AF] states that "a DS node does not reorder IP packets of the ATM header is as follows:

      PHB               CLP        PHS

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

   3.2 PHB-->PHS/DE Mapping

   The mapping from PHBs into
   same microflow if they belong to the L-LSP PHS and same AF class" (even if
   different packets of the Discard Eligible
   (DE) field microflow contain different AF codepoints
   of the Frame Relay header is as follows:

      PHB               DE         PHS

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

   3.3 Signaled PHS for Class Selector same AF class). As described noted above, each AF class in [DIFF_HEADER], "the Class Selector the AF PHB Group
   identifies 8 PHBs defined via
   group is the relative probability of timely

Wu et. al                                                            8

                 MPLS Support primary example of DiffServ over ATM/FR          June 99

   forwarding that they respectively offer to packets. For backwards
   compatibility purposes, a PSC. Each PSC comprises 3 PHBs and
   coincides with the Class Selector PHB Requirements AF Class. Those PSCs are
   specified thus referred to as AFn,
   where 1 <= n <= 4.

A.2.4 EF PSC

   [DIFF_EF] defines the minimum requirements compatible with most of the
   deployed Expedited Forwarding (EF) PHB for traffic
   requiring forwarding treatments selected by with low loss, low latency, low jitter.
   [DIFF_EF] defines a single PHB. Thus, the IP Precedence field".

   Quoting again from [DIFF_HEADER]:
   "In addition, we give corresponding PSC
   comprises a set single PHB and thus coincides with the DF PHB.

A.2.5 Summary list of codepoints that MUST map to PHBs
   meeting these minimum requirements. PSC

   The PHBs mapped to by these
   codepoints MAY following PSCs have a more detailed list thus been identified:
        - DF
        - CSn , 1 <= i <= 8
        - AFn, 1 <= i <= 4
        - EF

APPENDIX B. Example Deployment Scenarios

 Le Faucheur et. al                                                 36

                      MPLS Support of specifications in
   addition Diff-Serv             October 99

   This section does not provide additional specification and is only
   here to the required ones stated here".

   Considering that:

        - this document defines provide examples of how ATM/FR LSRs this flexible approach for Diff-Serv
   support some
   "specific/restrictive" PHB groups using their existing hardware
   capabilities (including AF PHB Group over MPLS may be deployed. Pros and EF PHB).

        - ATM/FR LSRs do not have some legacy PHBs complying with Class
   Selector PHB requirements as defined in [DIFF_HEADER] paragraph
   4.2.2.2 which cons of various
   deployment options for particular environments are "less specific/restrictive" than beyond the PHBs
   addressed in scope
   of this document.

        - as specified

B.1 Scenario 1: 8 BAs, no Traffic Engineering, no Fast Reroute

   A Service Provider running 8 (or less) BAs over MPLS, not performing
   Traffic engineering, not performing protection via Fast Reroute and
   using MPLS Shim Header encapsulation in [DIFF_HEADER], Class Selector Codepoints his/her network, may elect
   to run Diff-Serv over MPLS using a single E-LSP per FEC established
   via LDP.

   Operations can be supported by "more specific PHBs" such summarized as the other ones
   addressed in this document

   we propose that: follows:
        - the Service Provider configures at every LSR the bi-
   directional mapping between each PHB and a Behavior Aggregate corresponding to a Class Selector
   Codepoint CSn may be mapped onto a CSn specific L-LSP with its CSn
   PHS signaled value of the EXP field
   (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13)
        - the Service Provider configures at label set-up,  OR every LSR, and for every
   interface, the scheduling behavior for each PSC (eg bandwdith
   allocated to AF1) and the dropping behavior for each PHB (eg drop
   profile for AF11, AF12, AF13)
        - LSRs signal establishment of a Behavior Aggregate corresponding single E-LSP per FEC using LDP
   in accordance with the specification above (ie no Diff-Serv_PSC TLV
   in LDP Label Request/Label Mapping messages to a Class Selector
   Codepoint CSn may be mapped onto implicitly indicate
   that the LSP is an L-LSP whose signaled PHS
   corresponds E-LSP)

B.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no Fast
Reroute

   A Service Provider running more than 8 BAs over MPLS, not performing
   Traffic Engineering and not performing protection via Fast Reroute
   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 to support a "more specific/restrictive" PHB than CSn (eg AFn,
   EF).

4. LSP Establishment and Message Format

4.1. Signaling extension during set of 8 (or less)
   BAs,
        AND
        - one L-LSP establishment

   To per <FEC,OA> established via LDP for support Diff-Serv in MPLS over ATM and Frame Relay, of the PHS must
   other BAs.

   Operations can be signaled in summarized as follows:
        - the MPLS label request messages Service Provider configures at every LSR the bi-
   directional mapping between each PHB and MPLS label
   binding messages. The detailed format a value of the corresponding message
   extension is described below when EXP field
   for the signaling protocol used is LDP
   or RSVP. The MPLS control application on each ATM LSR or Frame Relay
   LSR along BAs transported over the L-LSP will process E-LSP
        - the new PHS attribute Service Provider configures at every LSR, and for every
   interface, the scheduling behavior for each PSC supported over the
   E-LSP and install the dropping behavior for each corresponding PHB
        - the Service Provider configures at every LSR, and for every
   interface, the scheduling behavior for that L-LSP (eg. map each PSC supported over the
   LSP into an output queue associated with
   L-LSPs and the PHS).

4.2. Merging

Wu dropping behavior for each corresponding PHB

 Le Faucheur et. al                                                            9                                                 37

                      MPLS Support of DiffServ over ATM/FR          June Diff-Serv             October 99

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

        - LSRs signal establishment of Diff-Serv in MPLS over ATM and
   Frame Relay is compatible with LSP Merging under the following
   condition:

   L-LSPs can only be merged into one LSP if they are associated with
   the same PHS.

   Note that, when L-LSPs merge, the bandwidth that is available a single E-LSP per FEC for the PHS downstream
   set of the merge point must be sufficient E-LSP transported BAs using LDP as specified above (ie no
   Diff-Serv_PSC TLV in LDP Label Request/Label Mapping messages to carry
   implicitly indicate that the sum LSP is an E-LSP)
   - LSRs signal establishment of one L-LSP per <FEC,OA> for the merged traffic. This is particularly important other
   BAs using LDP as specified above (ie Diff-Serv_PSC TLV in LDP Label
   Request/Label Mapping messages to indicate the
   case of EF traffic.

4.3 New RSVP Object Format

   This section defines a new RSVP object class and L-LSP's PSC).

B.3 Scenario 3: 8 BAs, Aggregate Traffic Engineering, Aggregate Fast
Reroute

   A Service Provider running 8 (or less) BAs over MPLS, performing
   aggregate Traffic Engineering (ie performing a new RSVP object
   within that class single common path
   selection for support of Diff-Serv in all BAs), performing aggregate protection via Fast
   Reroute (ie performing Fast Reroute for all PSCs jointly) and using
   MPLS Shim Header encapsulation in his/her network, may elect to run
   Diff-Serv over ATM/FR when
   L-LSPs are MPLS using a single E-LSP per FEC established via
   RSVP [MPLS_RSVP].

   The new object Class is defined [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE].

   Operations can be summarized as follows:
        - the "Class Of Service" Class (COS
   Class). Its Class-Num is [TBD].

   The new RSVP DIFFSERV_PHS object is defined within the COS Class to
   carry Service Provider configures at every LSR the PHS
   bidirectional mapping between each PHB and a value of the traffic EXP field
   (eg. 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 be transported on AF1) and the corresponding
   LSP. Its C-Type is 1.

    DIFFSERV_PHS object Class = [TBD], C-Type = 1

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Length = 4            |   Class-Num   |    C-Type     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved               |              PHS              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   We propose that dropping behavior for each PHB (eg drop
   profile for AF11, AF12, AF13)
        - LSRs signal establishment of a single E-LSP per FEC:
            * using the 16-bit PHS be encoded RSVP protocol as specified above (ie no
   DIFFSERV_PSC RSVP Object in section 2
   of [PHBID]. In particular, we propose that the encoding for a PHS be the smallest numerical value of PATH message containing the encodings for
   LABEL_REQUEST Object), OR
            * using the various PHBs CR-LDP protocol as specified above (ie no Diff-
   Serv_PSC TLV in the PHS. In turn, the encoding LDP Label Request/Label Mapping messages).

B.4 Scenario 4: per-OA Traffic Engineering/Fast Reroute

   A Service Provider running any number of BAs over MPLS, performing
   per-OA Traffic Engineering (ie performing a single PHB defined by
   standards action is the recommended DSCP value separate path selection
   for this PHB, left-
   justified in the 16 bit field, each OA) and performing per-OA protection via Fast Reroute (ie
   performing protection with bits 6 through 15 set different Fast Reroute policies for the
   different OAs) in his/her network, may elect to zero.

   For instance, 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 encoding of Service Provider configures at every LSR, and for every
   interface, the AFC1 PHS is scheduling behavior for each PSC (eg bandwidth
   allocated to AF1) and the encoding dropping behavior for each PHB (eg drop
   profile for AF11, AF12, AF13)
        - LSRs signal establishment of one L-LSP per <FEC,OA>:

 Le Faucheur et. al                                                 38

                      MPLS Support of Diff-Serv             October 99

                * using the
   AF11 PHB.

   This object may be carried RSVP as specified above to signal the
   L-LSP's PSC (ie DIFFSERV_PSC RSVP Object in a the PATH message that contains
   containing the
   LABEL_REQUEST object LABEL_REQUEST), OR
                * using the CR-LDP protocol as specified above to indicate
   signal the PHS for which a label is
   required. The object may also be carried L-LSP PSC (ie Diff-Serv_PSC TLV in a RESV message that

Wu et. al                                                           10

                 MPLS Support of DiffServ LDP Label
   Request/Label Mapping messages).

B.5 Scenario 5: less than 8 BAs, per-OA Traffic Engineering/Fast
Reroute

   A Service Provider running less than 8 BAs over ATM/FR          June 99

   contains MPLS, performing
   per-OA Traffic Engineering (ie performing a LABEL object indicating the PHS separate path selection
   for each OA) and performing per-OA protection via Fast Reroute (ie
   performing protection with different Fast Reroute policies for which the label is to
   be used.

   As described
   different OAs) in [MPLS_RSVP], bandwidth information his/her network, may also elect to run Diff-Serv over
   MPLS using one E-LSP per <FEC,OA> pair established via RSVP or
   CR-LDP.

   Operations can be
   signaled summarized as follows:
        - the Service Provider configures at LSP establishment time, for every LSR the purpose
   bidirectional mapping between each PHB and a value of Traffic
   Engineering, using the SENDER_TSPEC Object (in EXP field
   (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13)
        - the Path message) Service Provider configures at every LSR, and for every
   interface, the FLOWSPEC Object (in scheduling behavior for each PSC (eg bandwidth
   allocated to AF1) and the Resv message).

4.4. New LDP TLV

   This section defines a new LDP TLV necessary dropping behavior for support each PHB (eg drop
   profile for AF11, AF12, AF13)
        - LSRs signal establishment of Diff-
   Serv one L-LSP per <FEC,OA>:
                * using the RSVP protocol as specified above to signal
   that the LSP is an E-LSP (ie no DIFFSERV_PSC RSVP Object in MPLS over ATM/FR when L-LSPs are established via LDP
   [MPLS_LDP] or the PATH
   message containing the LABEL_REQUEST), OR
                * using the CR-LDP [MPLS CR-LDP]. We define a new PHS TLV protocol as specified above to
   signal that the PHS LSP is an E-LSP (ie no Diff-Serv_PSC 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 label request or label binding as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 filtering/forwarding criteria so that packets
   belonging to a given OA are forwarded on the E-LSP established for
   the corresponding FEC and corresponding OA.

B.6 Scenario 6: no Traffic Engineering/Fast Reroute on 8 9 0 1 2 3 4 5 6 7 BAs, per-OA
Traffic Engineering/Fast Reroute on other BAs.

   A Service Provider not performing Traffic Engineering/Fast Reroute
   on 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| Type = PHS                |      Length = 2               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         PHS                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type of the TLV is [TBD].

   Encoding of (or less) BAs, performing per-OA Traffic Engineering/Fast
   Reroute on the PHS field is other BAs (ie performing a separate path selection
   for each OA corresponding to the same as encoding other BAs and performing protection
   with a different policy for each of these OA) and using the PHS in
   RSVP, as specified MPLS
   Shim encapsulation in 4.3.

   We propose that his/her network may elect to run Diff-Serv
   over MPLS, using for each FEC:
        - one E-LSP established via LDP to support the COS TLV which was specified in [LDP_03] (and
   removed in later version set of 8 (or
   less) non-traffic-engineered/non-fast-rerouted BAs,
        AND

 Le Faucheur et. al                                                 39

                      MPLS Support of Diff-Serv             October 99

        - one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP
   for support of the LDP specifications) other BAs.

   Operations can be
   reincorporated into LDP and used to encode the PHS TLV summarized as a nested
   TLV (ie encode follows:
        - the PHS TLV in Service Provider configures at every LSR the COS bi-
   directional mapping between each PHB and a value of the COS TLV).
   Encoding EXP field
   for the PHS TLV as a nested TLV of BAs supported over the COS TLV is proposed E-LSP
        - the Service Provider configures at every LSR, and for
   flexibility so that if additional TLVs need to be defined in every
   interface, the
   future scheduling behavior for support of Diff-Serv each PSC supported over MPLS, those TLVs could be
   logically grouped inside the COS TLV.

   Alternatively,
   E-LSP and the PHS TLV could be included in 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 messages as
   an independent TLV specified above (ie not nested in the COS TLV).

   As described no Diff-
   Serv_PSC TLV in [MPLS_CR-LDP], bandwidth information may also be
   signaled at LSP LDP Label Request/Label Mapping messages)
        - LSRs signal establishment time, of one L-LSP per <FEC,OA> for the purpose of Traffic
   Engineering,
   other BAs:
                * using the RSVP protocol as specified above to signal
   the L-LSP PSC (ie DIFFSERV_PSC RSVP Object in the PATH message
   containing the LABEL_REQUEST Object), OR
                * using the Traffic Parameters TLV.

5. Security Considerations

   This document does not introduce any new security issues beyond
   those inherent in Diff-Serv, MPLS and RSVP, and may use CR-LDP protocol as specified above to
   signal the same
   mechanisms proposed for those technologies.

6. Acknowledgments

Wu et. al                                                           11

                 MPLS Support of DiffServ over ATM/FR          June 99

   This document has benefited from discussions with Dan Tappan, Yakov
   Rekhter, George Swallow, Eric Rosen, and Emmanuel Desmet.

7. L-LSP PSC (ie Diff-Serv_PSC TLV in LDP Label
   Request/Label Mapping messages).

References

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

   [MPLS ATM] Davie et al., _MPLS using LDP and ATM VC Switching_, work
   in progress, (draft-ietf-mpls-atm-02.txt), April 1999

   [MPLS FR] Conta et al., _Use of Label Switching on Frame Relay
   Networks Specification_, (draft-ietf-mpls-fr-03.txt), November 1998

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

   [MPLS_DIFF_PPP] Le Faucheur et al, "MPLS Support of Differentiated
   Services over PPP links", draft-lefaucheur-mpls-diff-ppp-00.txt,
   June 99.

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

   [MPLS_ATM] Davie et al., "MPLS using LDP and ATM VC Switching",
   draft-ietf-mpls-atm-02.txt, April 1999.

   [MPLS_FR] Conta et al., "Use

 Le Faucheur et. al                                                 40

                      MPLS Support of Label Switching on Frame Relay
   Networks", draft-ietf-mpls-fr-03.txt, November 1999. Diff-Serv             October 99

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

   [LDP_03] Andersson

   [MPLS_ECN] Ramakrishnan et al., "LDP Specification", draft-ietf-mpls-ldp-
   03.txt, January 99

   [LDP_04] "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-
   04.txt, April
   05.txt, June 99

   [MPLS_RSVP]

   [RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels",
   draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March
   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt, September 1999

   [MPLS CR-LDP]

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

   [PHBID] Brim and Carpenter, et al., "Per Hop Behavior Identification Codes",
   draft-brim-diffserv-phbid-00.txt, April 99

Wu et. al                                                           12

                 MPLS Support of DiffServ over ATM/FR          June Codes
   draft-ietf-diffserv-phbid-00.txt, October 99

8.

Author's Addresses

   Liwen Wu
   Alcatel USA
   44983 Knoll Square
   Ashburn, VA 20147
   USA

   E-mail liwen.wu@adn.alcatel.com

   Pierrick Cheval
   Alcatel USA
   44983 Knoll Square
   Ashburn, VA 20147
   USA

   E-mail pierrick.cheval@adn.alcatel.com

   Pasi Vaananen
   Nokia
   3 Burlington Woods Drive, Suite 250
   Burlington, MA 01803
   USA

   E-mail pasi.vaananen@ntc.nokia.com Addresses:

   Francois le Le Faucheur
   Cisco Systems, Inc. Systems
   Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne -
   France

   E-mail
   Phone: +33 4 92 96 75 64
   Email: flefauch@cisco.com

   Liwen Wu
   Cisco Systems
   250 Apollo Drive, Chelmsford, MA 01824, USA
   Phone: (978)-244-3087
   Email:

          liwwu@cisco.com

   Bruce Davie
   Cisco Systems, Inc. Systems
   250 Apollo Drive Drive, Chelmsford, MA, MA 01824
   USA

   E-mail
   Phone: (978)-244-8000
   Email: bsd@cisco.com

Wu

   Shahram Davari
   PMC-Sierra Inc.
   105-8555 Baxter Place
   Burnaby, BC V5A 4V7
   Canada
   E-mail: Shahram_Davari@pmc-sierra.com

   Pasi Vaananen
   Nokia
   3 Burlington Woods Drive, Suit 250
   Burlington, MA 01803

 Le Faucheur et. al                                                           13                                                 41

                      MPLS Support of Diff-Serv             October 99

   USA
   Phone +1 (781) 238-4981
   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

 Le Faucheur et. al                                                 42