Network Working Group                                                                Liwen Wu
Internet Draft
                                                            Alcatel, USA
Expiration Date: September 1999
                                                         Pierrick Cheval
                                                            Alcatel, USA
                                                           Pasi Vaananen
                                                                   Nokia
                                                    Francois le Faucheur
                                                     Cisco Systems, Inc.
                                                             Bruce Davie
                                                     Cisco Systems, Inc.

                                                           March
Internet Draft
Expires: December, 1999
Document: draft-ietf-mpls-diff-ext-01.txt               June, 1999

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

                     draft-ietf-mpls-diff-ext-00.txt

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
   Working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-
   Drafts. Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work _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 updates to the current MPLS LDP and MPLS RSVP
   messages a solution for LSP establishment in order MPLS to support Differentiated
   Services (Diff-Serv) over ATM LSRs and Frame Relay LSRs.

   In brief, we propose that:

      - a set of PHBs that requires no misordering of packets in a
      microflow (even if the microflow contains packets for more than
      one PHB) be defined as a PHB forwarding class (PFC);

      - packets that belong It proposes
   corresponding updates to the same PFC current MPLS LDP and the same forwarding
      equivalence class (FEC) should be transported over the same ATM
      LSP or FR LSP;

      - MPLS RSVP messages
   for a given FEC, a separate ATM LSP or FR LSP should be
      established for each PFC, so that multiple ATM or FR establishment.

   In brief, we propose to use LSPs are
      established in parallel for support of Diff-Serv;

      - among where the set of PHBs transported over Behavior Aggregate's
   scheduling treatment is inferred by the same ATM LSP or FR
      LSP, LSR from the different PHBs' packet's label
   value (VCI/DLCI) while the Behavior Aggregate's drop precedences be mapped into, and
      enforced via, precedence is
   indicated in the layer 2 specific ATM/FR selective discard mechanism
      (CLP bit with ATM, DE bit with FR).

1. CLP/DE field.

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 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. At the ingress node the
   packets are classified and marked with a Diff-Serv Code Point (DSCP)
   which corresponds to their Behavior Aggregate. Aggregate [DIFF_HEADER]. 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 treatment and, in some cases, drop
   probability for each packet.

   This document proposes a solution for support of supporting the Behavior
   Aggregates, whose corresponding PHBs are currently defined Diff Serv PHBs (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.
   Support of Diff Serv on other link types is for further study.

1.1.

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

   [DIFF_AF] states that "a DS node does not reorder IP packets of the
   same microflow if they belong to the same AF class" (even if
   different packets of the microflow contain multiple different AF codepoints within
   of the same AF class).

   For the sake of generality, we define a set of PHBs Behavior Aggregates
   which
   impose share such an ordering constraint to be constitute a "PHB Forwarding Class" or
   PFC. "Scheduling
   Aggregate" (SA). The mechanisms described in this draft aim aim, in
   particular, to preserve the correct ordering relationships for
   packets that belong to a single
   PFC.

1.2. LSP Establishment for Diff-Serv over ATM/FR MPLS

   Recognizing that:

      - given SA.

   We refer to the set of one or more PHBs applied to the set of
   Behavior Aggregates forming a given SA, as a "Per Hop Scheduling"
   (PHS).

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

1.1.1 DF PHS

Wu et. al                                                            2

                 MPLS Support of DiffServ over ATM/FR          June 99

   The Default PHB is a single PHB specified in [DIFF_Header]. Thus,
   the corresponding PHS comprises a single PHB and thus coincides with
   the DF PHB.

1.1.2 CSn PHS

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

1.1.3 AFCn PHS

   As described in [DIFF_AF], the Assured Forwarding (AF) PHB group
   provides forwarding of IP packets in 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
   i and has drop precedence j is marked with the AF codepoint AFij,
   where 1 <= i <= N and 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
   same microflow if they belong to the same AF class" (even if
   different packets of the microflow contain different AF codepoints
   of the same AF class). As noted above, each AF class in the AF PHB
   group is the primary example of a PHS. Each PHS comprises 3 PHBs and
   coincides with the AF Class. Those PHSs are thus referred to as
   AFCn, where 1 <= n <= 4.

1.1.4 EF PHS

   [DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic
   requiring forwarding with low loss, low latency, low jitter.
   [DIFF_EF] defines a single PHB. Thus, the corresponding PHS
   comprises a single PHB and thus coincides with the DF PHB.

1.1.5 Summary list of PHS

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

1.2 LSP Establishment for Diff-Serv over ATM/FR MPLS

   Recognizing that

Wu et. al                                                            3

                 MPLS Support of DiffServ over ATM/FR          June 99

        - the MPLS Header of MPLS switched packets is generally not
   visible to ATM and Frame Relay MPLS LSRs since it is encapsulated
   "inside" the ATM or FR LSP "connection";

        - MPLS Diff-Serv assumes a similar architecture to non-MPLS
   Diff-Serv whereby the appropriate forwarding/prioritisation is to be
   performed at every hop (ie every MPLS LSR, including ATM LSR and FR
   LSR) 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 is generally not
   capable of selecting different scheduling behaviors for cells/frames
   belonging to the same ATM/Frame Relay connection;

        - ATM and Frame Relay switching hardware is capable of
   maintaining the order of all packets or cells sent on a single
   connection;

        - ATM and 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 and Discard Eligible - DE- for Frame
   Relay);

   we propose that

        - all packets belonging to a single SA and the same Forwarding
   Equivalence Class (FEC) be sent down a single LSP;

        - one LSP be established per <FEC, SA> pair (rather than 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 from multiple BAs of a given SA be granted a
   different drop precedence through mapping 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 and FR MPLS.

   For the purpose 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 et. al                                                            4

                 MPLS Support of DiffServ over ATM/FR          June 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 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 is described in [ECN] and is
   proposed as an Experimental extension to the IP protocol. Because
   ECN is still at the Experimental stage and its impact and
   interactions with Diff-Serv have not yet been specified, this
   Internet-Draft does not discuss ECN operations. Support for
   simultaneous Diff-Serv and ECN over MPLS is left for further study.

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

   In order to describe Label Forwarding by Diff-Serv LSRs, we propose
   to model a 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 LSR SHALL apply the scheduling/dropping behavior
   corresponding to the "Outgoing PHB" in compliance with the
   corresponding Diff-Serv PHB specification.

   With such a model, we expect that "Diff-Serv over MPLS" label
   forwarding can be specified (from the Diff-Serv viewpoint)
   separately for each method (eg. Diff-Serv over MPLS over ATM/FR,
   Diff-Serv over MPLS over PPP using L-LSPs [MPLS_DIFF_PPP], Diff-Serv
   over MPLS over PPP using E-LSPs [MPLS_DIFF_PPP]) by specifying -A-
   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 Diff-Serv support over MPLS.

1.5 Relationship with [MPLS_DIFF_PPP]

   The procedures described in this Internet Draft to establish and use
   L-LSPs to achieve support of Diff-Serv over MPLS over ATM and FR,
   are identical to the procedures described in [MPLS_DIFF_PPP] for L-
   LSPs as one method to achieve support of Diff-Serv over MPLS Header over
   PPP.

   Note that a single method (based on L-LSPs) is proposed in this
   Internet Draft for support of Diff-Serv over MPLS switched over ATM/FR while

Wu et. al                                                            5

                 MPLS Support of DiffServ over ATM/FR          June 99

   [MPLS_DIFF_PPP] defines two methods for support of Diff-Serv over
   MPLS over PPP. The other method described in [MPLS_DIFF_PPP] to
   achieve support of Diff-Serv over MPLS over PPP relies on E-LSPs. E-
   LSPs require that different packets of the same LSP be given
   different scheduling treatment by the LSR which is generally not
      visible to ATM
   incompatible with existing ATM/FR hardware capabilities.

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

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

   When receiving an ATM/FR call/frame containing a labeled packet over
   an L-LSP of an MPLS LSRs since it ATM ingress interface:

   If the LSR is encapsulated
      "inside" a Frame LSR (ie Egress Edge of the ATM or FR LSP "connection"; ATM/FR MPLS cloud),
   the LSR:
        - ATM and Frame Relay switching hardware is generally capable determines the FEC based on the incoming label
        - determines the PHS from the incoming label among the set of
      selecting different scheduling queues
   LSPs established for cells/frames belonging
      to different connections but that FEC
        - determines the incoming PHB from the PHS and the EXP field 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 is generally not capable an ATM/FR LSR (ie ATM/FR LSR in the middle of selecting
      different scheduling queues for cells/frames belonging to the same
      ATM/Frame Relay connection;
   ATM/FR MPLS cloud), the LSR:
        - ATM and Frame Relay switching hardware must be capable determines the FEC based on the incoming VCI/DLCI
        - determines the PHS from the incoming VCI/DLCI among the set
   of
      maintaining LSPs established for that FEC
        - determines the "incoming" drop precedence to be applied on
   the packet based on the order CLP/DE field.

2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning

   This stage of all packets or cells sent on a single
      connection;

      - ATM and Frame Relay Diff-Serv label 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 optional and Discard Eligible - DE- for may be used
   on a Frame
      Relay);

   we propose that:

      - all packets belonging LSR to a single PFC and perform Behavior Aggregate demotion or promotion
   inside an MPLS Diff-Serv domain. For the same forwarding
      equivalence class (FEC) should be sent down purpose of specifying a single LSP;

      - one LSP should be established per <PFC, FEC> pair (rather than
   Diff-Serv over MPLS method, we simply one LSP per FEC as in a network note that does not support
      Diff-Serv);

      - multiple PHBs belonging to the same PFC PHB to be
   actually enforced by an LSR (referred to as "outgoing PHB") may be granted
   different
      drop precedences through mapping into to the layer 2 specific
      selective discard indicator (CLP bit with ATM, DE bit PHB which had been associated with FR).

   MPLS specifies how LSPs can be established via multiple signalling
   protocols. Those include the Label Distribution Protocol (LDP), RSVP,
   BGP and PIM. This Internet-Draft proposes below packet at
   the required
   extensions to LDP and RSVP previous LSR (referred to allow establishment as "incoming PHB").

   This stage of one LSP per
   <PFC, FEC> pair over ATM Diff-Serv label switching is optional and FR MPLS. may be used
   on Frame LSRs with ATM/FR interfaces.

   In the event that case of ATM/FR LSRs, it is desired to signal bandwidth or other resource
   requirements for an LSP expected that will carry this optional stage
   of Diff-Serv traffic (e.g. for
   traffic engineering purposes), label switching, if supported, would be limited to
   CLP/DE remarking (ie remarking the mechanisms available "incoming CLP/DE" to a different
   value in the LSP
   setup protocol (RSVP or LDP) may be used.

1.3. Label Forwarding for Diff-Serv "outgoing CLP/DE")

Wu et. al                                                            6

                 MPLS Support of DiffServ over ATM/FR MPLS

   At          June 99

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

   If the edge LSR is a Frame LSR (ie Ingress Edge of the ATM or FR Diff-Serv ATM/FR MPLS cloud,
   cloud):
   Once the Edge-LSR looks
   at outgoing PHB has been determined by the DSCP LSR as a function
   of the incoming packet PHB and based on 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 in section 3.
        - determines the egress L-LSP label from the packet's FEC and PFC to
   which
   PHS
        - encodes the packet belongs, EXP field of the Edge-LSR selects top level label entry shim
   header of the LSP among label stack (which is encapsulated in the set ATM /FR LSP)
   in accordance with the PHB --> PHS/EXP Mapping defined in section
   2.4 of LSPs established for each <FEC, PFC> pair. The ATM/FR Edge LSR
   also sets [MPLS_DIFF_PPP].
        - determines the value to be written in the CLP/DE bit field of the forwarded cells/frames according to
   outgoing cell/frame by performing the outgoing PHB--> PHS/CLP-DE
   mapping defined below between PHBs and in section 3.
        - applies a scheduling/dropping behavior corresponding to the
   "outgoing" PHB in compliance with the corresponding Diff-Serv PHB
   specification.

   If the LSR is an ATM/FR selective discard
   mechanism.

   In LSR (ie ATM/FR LSR in the middle of the ATM or FR Diff-Serv
   ATM/FR MPLS cloud, cloud):
   Once the "outgoing" drop precedence (CLP/DE) has been determined by
   the LSR as a function of the "incoming" drop precedence (CLP/DE) and
   of the optional Local Policy and Traffic Conditioning, the LSR:
        - determines the outgoing interface, the outgoing VCI/DLCI and
   the output scheduling queue from the incoming VCI/DLCI
        - applies a scheduling treatment corresponding to the
   VCI/DLCI/label's PHS in compliance with the corresponding Diff-Serv
   PHB specification
        - writes the "outgoing" CLP/DE value into the outgoing
   cell/frame
        - applies the drop precedence corresponding to the "outgoing"
   CLP/DE.

2.2.4 Simplified Forwarding on an ATM/FR LSR

   When Local Policy and Traffic Conditioning are not to be performed
   by the LSR, the
   Intermediate-LSR Forwarding operation of an ATM/FR LSR is "reduced"
   to traditional ATM/FR switching since:
        - the LSR only looks at the incoming VCI/DLCI of an incoming
   ATM cell/FR Frame to determine the output interface, the outgoing
   VCI/DLCI and the output scheduling queue. The Intermediate-LSR also queue,
        - the LSR only looks at the incoming CLP/DE bit field to determine
   the drop precedence to be applied on the cell/frame,
        - the MPLS Shim Header encapsulated in the ATM/FR connection
   does not need to be looked at nor modified.

Wu et. al                                                            7

                 MPLS Support of DiffServ over ATM/FR          June 99

2.2.5 Number of Drop Precedence Levels

   Because the incoming cell/Frame to enforce the
   appropriate drop priority.

2. PHB Mapping into PHB-group Forwarding Classes underlying standardized ATM and Frame Relay Selective
   Discard
   Mechanisms

2.1. Assured Forwarding PHB Group

   As described in [DIFF_AF], the Assured Forwarding (AF) PHB group
   provides forwarding mechanisms (CLP/DE) only support two levels of IP packets in N independent AF classes.
   Within each AF class, an IP packet Drop
   Precedence, the proposed solution is assigned one of M different limited to two levels of drop precedence. An IP packet that belongs to Drop
   Precedence per PHS in an AF class i
   and has drop precedence j ATM MPLS or FR MPLS cloud.

   However, the label stack encapsulated in the ATM LSP or FR LSP is marked with
   expected to include a shim header for the AF codepoint AFij, where
   1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4) top label entry with three a
   meaningful EXP field, which can thus be used to encode all levels of drop precedence
   Drop Precedence within a PHS as defined in each class (M=3) [MPLS_DIFF_PPP].
   Consequently, even if only two levels of Drop Precedence are defined for general
   use.

2.1.1. AF PHB-group Forwarding Class

   As noted above, an AF class
   achieved in the AF PHB group is ATM/FR MPLS cloud, all Drop Precedence levels (eg
   the primary
   example three levels of a PHB forwarding class. To meet the ordering constraints
   for an AF class, packets of the same AF class that belong to the same
   FEC must Class) can be sent on the same LSP, a sufficient condition to meet the
   ordering requirements defined for AF. supported in PPP MPLS clouds
   surrounding an ATM/FR MPLS cloud.

3. PHB Mapping into PHS and Selective Discard Mechanism

   3.1 PHB-->PHS/CLP Mapping

   The mapping from AF PHBs to PFC is as follows:

   PHB           PFC

   AF1x  ----->  AFC1
   AF2x  ----->  AFC2
   AF3x  ----->  AFC3
   AF4x  ----->  AFC4

2.1.2. AF drop precedences mapping into ATM CLP

   Within an AF PFC, the 3 drop precedences get mapped into L-LSP PHS and the layer 2
   technology specific selective discard indicator. Mapping from AF PHBs
   to ATM Cell Loss Priority
   (CLP) field of the ATM header is as follows:

      PHB               CLP bit

   AFx1    ------->        PHS

      DF     ----->     0          DF
      CSn    ----->     0
   AFx2    ------->          CSn
      AFn1   ----->     0          AFCn
      AFn2   ----->     1
   AFx3    ------->          AFCn
      AFn3   ----->     1

2.1.3. AF drop precedences mapping into FR DE          AFCn
      EF     ----->     0          EF

   3.2 PHB-->PHS/DE Mapping

   The mapping from AF PHBs to Frame Relay into the L-LSP PHS and the Discard Eligible
   (DE) field of the Frame Relay header is as follows:

      PHB               DE bit

   AFx1    ------->         PHS

      DF     ----->     0          DF
      CSn    ----->     0          CSn
      AFn1   ----->     0
   AFx2    ------->          AFCn
      AFn2   ----->     1
   AFx3    -------->          AFCn
      AFn3   ----->     1

2.2. Expedited Forwarding PHB

   [DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic
   requiring forwarding with low loss, low latency, low jitter.

2.2.1.          AFCn
      EF PHB-group Forwarding     ----->     0          EF

   3.3 Signaled PHS for Class

   [DIFF_EF] defines a single PHB. Thus, we propose that one PHB-group
   Forwarding Selector

   As described in [DIFF_HEADER], "the Class be Selector PHB Group
   identifies 8 PHBs defined for via the EF PHB.

   Mapping from EF relative probability of timely

Wu et. al                                                            8

                 MPLS Support of DiffServ over ATM/FR          June 99

   forwarding that they respectively offer to PFC is as follows:

   PHB          PFC

   EF  ------>  EFC

2.2.2. EF drop precedences mapping into ATM CLP

   A single PHB is defined in packets. For backwards
   compatibility purposes, the EF-group and Class Selector PHB Requirements are
   specified as the all EF packets should
   receive minimum requirements compatible with most of the same (high) drop  precedence (i.e., low drop
   probability). Thus
   deployed forwarding treatments selected by the mapping IP Precedence field".

   Quoting again from EF DSCP [DIFF_HEADER]:
   "In addition, we give a set of codepoints that MUST map to ATM Cell Loss Priority
   (CLP) is as follows: PHBs
   meeting these minimum requirements. The PHBs mapped to by these
   codepoints MAY have a more detailed list of specifications in
   addition to the required ones stated here".

   Considering that:

        - this document defines how ATM/FR LSRs support some
   "specific/restrictive" PHB           CLP bit

   EF    ------->      0

2.2.3. groups using their existing hardware
   capabilities (including AF PHB Group and EF drop precedences mapping into FR DE

   A single PHB).

        - ATM/FR LSRs do not have some legacy PHBs complying with Class
   Selector PHB is requirements as defined in [DIFF_HEADER] paragraph
   4.2.2.2 which are "less specific/restrictive" than the EF-group and the all EF packets should
   receive the same (high) drop  precedence (i.e., low drop
   probability). Thus PHBs
   addressed in this document.

        - as specified in [DIFF_HEADER], Class Selector Codepoints can
   be supported by "more specific PHBs" such as the mapping from EF DSCP other ones
   addressed in this document

   we propose that:
        - a Behavior Aggregate corresponding to Frame Relay Discard
   Eligible bit (DE) is as follows: a Class Selector
   Codepoint CSn may be mapped onto a CSn specific L-LSP with its CSn
   PHS signaled at label set-up,  OR
        - a Behavior Aggregate corresponding to a Class Selector
   Codepoint CSn may be mapped onto an L-LSP whose signaled PHS
   corresponds to a "more specific/restrictive" PHB            DE bit

   EF    ------->      0

3. than CSn (eg AFn,
   EF).

4. LSP Establishment and Message Format

3.1. Signalling

4.1. Signaling extension during LSP L-LSP establishment

   To support Diff-Serv in MPLS over ATM and Frame Relay, the PFC PHS must
   be signalled signaled in the MPLS label request messages and MPLS label
   binding messages. The detailed format of the corresponding message
   extension is described below when the signalling signaling protocol used is LDP
   or RSVP. The MPLS control application on each ATM LSR or Frame Relay
   LSR along the LSP L-LSP will process the new PFC PHS attribute and install
   the corresponding scheduling behavior for that L-LSP (eg. map the
   LSP and its associated into an output queue.

3.2. queue associated with the PHS).

4.2. Merging

Wu et. al                                                            9

                 MPLS Support of DiffServ over ATM/FR          June 99

   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 over ATM and
   Frame Relay is compatible with LSP Merging under the following
   condition:

   LSPs which carry Differentiated Service traffic

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

   Note that, when LSPs L-LSPs merge, the bandwidth that is available for
   the
   PFC PHS 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.

3.3.

4.3 New RSVP Object Format

   This section defines a new RSVP object necessary class and a new RSVP object
   within that class for support of Diff-Serv in MPLS over ATM and Frame Relay ATM/FR when LSPs
   L-LSPs are established via RSVP [MPLS_RSVP].

   The new object Class is defined as the "Class Of Service" Class (COS
   Class). Its Class-Num is [TBD].

   The new RSVP DIFFSERV_PFC DIFFSERV_PHS object is defined within the COS Class to
   carry the PHB-group
   Forwarding Class (PFC) PHS of the traffic to be transported on the corresponding
   LSP.

   As described in [MPLS_RSVP], bandwidth information may also be
   signalled at LSP establishment time, for the purpose of Traffic
   Engineering, using the SENDER_TSPEC Object (in the Path message) and
   the FLOWSPEC Object (in the Resv message).

      DIFFSERV_PFC object: 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               |   PFC              PHS              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PFC is an assigned number describing

   We propose that the Diff Serv PHB-group
   Forwarding Class 16-bit PHS be encoded as specified in section 2
   of the traffic [PHBID]. In particular, we propose that will the encoding for a PHS be forwarded onto
   the smallest numerical value of the encodings for the various PHBs
   in the PHS. In turn, the encoding of a single PHB defined by
   standards action is the recommended DSCP value for this
   LSP. Possible PFC values are:

                EFC    0x00
                AFC1   0x01
                AFC2   0x02
                AFC3   0x03
                AFC4   0x04

   Other values may be assigned PHB, left-
   justified in the event 16 bit field, with bits 6 through 15 set to zero.

   For instance, the encoding of new Diff-Serv PHBs
   being defined. the AFC1 PHS is the encoding of the
   AF11 PHB.

   This object may be carried in a PATH message that contains the
   LABEL_REQUEST object to indicate the PFC PHS for which a label is
   required. The object may also be carried in a RESV message that

Wu et. al                                                           10

                 MPLS Support of DiffServ over ATM/FR          June 99

   contains a LABEL object indicating the PFC for which PHS for which the label is to
   be used.

   As described in [MPLS_RSVP], bandwidth information may also be
   signaled at LSP establishment time, for the purpose of Traffic
   Engineering, using the SENDER_TSPEC Object (in the Path message) and
   the label is to
   be used.

3.4. FLOWSPEC Object (in the Resv message).

4.4. New LDP TLV

   This section defines a new LDP TLV necessary for support of Diff-Serv Diff-
   Serv in MPLS over ATM and Frame Relay ATM/FR when LSPs L-LSPs are established via LDP
   [MPLS_LDP].
   [MPLS_LDP] or CR-LDP [MPLS CR-LDP]. We define a new PFC PHS TLV to
   signal the PHB forwarding
   class for PHS in 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| Type = PFC PHS                |      Length = 1 2               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  PFC Value         PHS                   |
      +-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type of the TLV is [TBD].  As an alternative to defining a new
   TLV, it

   Encoding of the PHS field is possible the same as encoding of the PHS in
   RSVP, as specified in 4.3.

   We propose that the currently specifified COS TLV could which was specified in [LDP_03] (and
   removed in later version of the LDP specifications) be
   reincorporated into LDP and used for this purpose. Alternatively, to encode the PHS TLV specified here could be
   carried as part of a nested
   TLV (ie encode the PHS TLV in the COS value field of the COS TLV.

   The PFC Value field is 1 octet with TLV).
   Encoding the following possible values:

                EFC    0x00
                AFC1   0x01
                AFC2   0x02
                AFC3   0x03
                AFC4   0x04

   Other values may PHS TLV as a nested TLV of the COS TLV is proposed for
   flexibility so that if additional TLVs need to be assigned defined in the event
   future for support of new Diff-Serv PHBs
   being defined. over MPLS, those TLVs could be
   logically grouped inside the COS TLV.

   Alternatively, the PHS TLV could be included in the LDP messages as
   an independent TLV (ie not nested in the COS TLV).

   As described in [MPLS_CR_LDP], [MPLS_CR-LDP], bandwidth information may also be
   signalled
   signaled at LSP establishment time, for the purpose of Traffic
   Engineering, using the Traffic Parameters TLV.

4.

5. Security Considerations

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

5.

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.

6.

7. References

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

   [DIFF_ARCH] Blake et al, al., "An Architecture architecture for Differentiated
   Services", work in progress, (draft-ietf-diffserv-arch-02.txt),
   October, 1998 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, al., "Assured Forwarding PHB Group", work in
   progress, (draft-ietf-diffserv-af-04.txt), January 1999 RFC-2597,
   June 1999.

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

   [DIFF_HEADER] Nichols et al., "Definition of the Differentiated
   Services Field (DS Field) in
   progress, (draft-ietf-diffserv-phb-ef-02.txt), March 1999

   [MPLS_LDP] 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 of Label Switching on Frame Relay
   Networks", draft-ietf-mpls-fr-03.txt, November 1999.

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

   [LDP_03] Andersson et al, al., "LDP Specification", work in progress,
   (draft-ietf-mpls-ldp-03.txt), draft-ietf-mpls-ldp-
   03.txt, January 1999 99

   [LDP_04] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-
   04.txt, April 99

   [MPLS_RSVP] Awduche et al, "Extensions to RSVP for LSP Tunnels", work
   in progress, (draft-ietf-mpls-rsvp-lsp-tunnel-01.txt),
   draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999.

   [MPLS_CR_LDP] Andersson 1999

   [MPLS CR-LDP] Jamoussi et al, al., "Constraint-Based LSP Setup using
   LDP", work in progress, (draft-ietf-mpls-cr-ldp-00.txt),  January
   1999.

7. draft-ietf-mpls-cr-ldp-01.txt, February 1999

   [PHBID] Brim and Carpenter, "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 99

8. Author's Addresses

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

   E-mail:

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

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

   E-mail:

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

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

   E-mail:

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

   Francois le Faucheur
   Cisco Systems, Inc.
   16 av du Quebec,
   Villebon-BP 706,
   91961
   Les Ulis Lucioles - 291, rue Albert Caquot
   06560 Valbonne
   France

   E-mail:

   E-mail flefauch@cisco.com

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

   E-mail:

   E-mail bsd@cisco.com

Wu et. al                                                           13