Internet Draft
                                                                Liwen Wu 
                                                            Alcatel, USA
                                                         Pierrick Cheval
                                                            Alcatel, USA
                                                           Pasi Vaananen
                                                                   Nokia
                                                    Francois le Faucheur
                                                     Cisco Systems, Inc.
                                                             Bruce Davie
                                                     Cisco Systems, Inc.
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


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

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

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

Abstract

   This document proposes a solution for MPLS to support Differentiated
   Services (Diff-Serv) over ATM LSRs and Frame Relay LSRs. It proposes
   corresponding updates to the current MPLS LDP and MPLS RSVP messages
   for LSP establishment.

   In brief, we propose to use 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 selective discard 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 [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 supporting the Behavior
   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 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).

   For the sake of generality, we define a 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 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  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
    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 over
   PPP.

   Note that a single method (based on L-LSPs) is proposed in this
   Internet Draft for support of Diff-Serv over MPLS 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
   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 a labeled packet over
   an L-LSP of an MPLS ATM ingress interface:

   If the LSR is a Frame LSR (ie Egress Edge of the ATM/FR MPLS cloud),
   the LSR:
        - determines the FEC based on the incoming label
        - determines the PHS from the incoming label among the set of
   LSPs established for 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 an ATM/FR LSR (ie ATM/FR LSR in the middle of the
   ATM/FR MPLS cloud), the LSR:
        - determines the FEC based on the incoming VCI/DLCI
        - determines the PHS from the incoming VCI/DLCI among the set
   of LSPs established for that FEC
        - determines the "incoming" drop precedence to be applied on
   the packet based on the CLP/DE field.

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 a Frame 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").

   This stage of Diff-Serv label switching is optional and may be used
   on Frame LSRs with ATM/FR interfaces.

   In the case of ATM/FR LSRs, 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" to a different
   value in the "outgoing CLP/DE")



Wu et. al                                                            6


                 MPLS Support of DiffServ 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 MPLS
   cloud):
   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 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
   PHS
        - encodes the 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 --> PHS/EXP Mapping defined in section
   2.4 of [MPLS_DIFF_PPP].
        - determines the value to be written in the CLP/DE field of 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 in compliance with the corresponding Diff-Serv PHB
   specification.


   If the LSR is an ATM/FR LSR (ie ATM/FR LSR in the middle of the
   ATM/FR MPLS 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 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 LSR only looks at the incoming CLP/DE 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 underlying standardized ATM and Frame Relay Selective
   Discard mechanisms (CLP/DE) only support two levels of Drop
   Precedence, the proposed solution is limited to two levels of Drop
   Precedence per PHS in an ATM MPLS or FR MPLS cloud.

   However, the label stack encapsulated in the ATM LSP or FR LSP is
   expected to include a shim header for the top label entry with a
   meaningful EXP field, which can thus be used to encode all levels of
   Drop Precedence within a PHS as defined in [MPLS_DIFF_PPP].
   Consequently, even if only two levels of Drop Precedence are
   achieved in the ATM/FR MPLS cloud, all Drop Precedence levels (eg
   the three levels of an AF Class) can be 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 PHBs into the L-LSP PHS and the Cell Loss Priority
   (CLP) field 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 the L-LSP PHS and the Discard Eligible
   (DE) field 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

   As described in [DIFF_HEADER], "the Class Selector PHB Group
   identifies 8 PHBs defined via the relative probability of timely

Wu et. al                                                            8


                 MPLS Support of DiffServ over ATM/FR          June 99

   forwarding that they respectively offer to packets. For backwards
   compatibility purposes, the Class Selector PHB Requirements are
   specified as the minimum requirements compatible with most of the
   deployed forwarding treatments selected by the IP Precedence field".

   Quoting again from [DIFF_HEADER]:
   "In addition, we give a set of codepoints that MUST map to 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 groups using their existing hardware
   capabilities (including AF PHB Group 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 are "less specific/restrictive" than the PHBs
   addressed in this document.

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

   we propose that:
        - a Behavior Aggregate corresponding to 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 than CSn (eg AFn,
   EF).


4. LSP Establishment and Message Format

4.1. Signaling extension during L-LSP establishment

   To support Diff-Serv in MPLS over ATM and Frame Relay, the PHS must
   be 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 signaling protocol used is LDP
   or RSVP. The MPLS control application on each ATM LSR or Frame Relay
   LSR along the L-LSP will process the new PHS attribute and install
   the corresponding scheduling behavior for that L-LSP (eg. map the
   LSP into an output 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:

   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 for
   the 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.

4.3 New RSVP Object Format

   This section defines a new RSVP object class and a new RSVP object
   within that class for support of Diff-Serv in MPLS over ATM/FR when
   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_PHS object is defined within the COS Class to
   carry the PHS of the traffic to be transported on 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 the 16-bit PHS be encoded as specified in section 2
   of [PHBID]. In particular, we propose that the encoding for a PHS be
   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 PHB, left-
   justified in the 16 bit field, with bits 6 through 15 set to zero.

   For instance, the encoding of 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 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 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 FLOWSPEC Object (in the Resv message).

4.4. New LDP TLV

   This section defines a new LDP TLV necessary for support of Diff-
   Serv in MPLS over ATM/FR when L-LSPs are established via LDP
   [MPLS_LDP] or CR-LDP [MPLS CR-LDP]. We define a new PHS TLV to
   signal the 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 = PHS                |      Length = 2               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         PHS                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type of the TLV is [TBD].

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

   We propose that the COS TLV which was specified in [LDP_03] (and
   removed in later version of the LDP specifications) be
   reincorporated into LDP and used to encode the PHS TLV as a nested
   TLV (ie encode the PHS TLV in the COS value of the COS TLV).
   Encoding the PHS TLV as a nested TLV of the COS TLV is proposed for
   flexibility so that if additional TLVs need to be defined in the
   future for support of Diff-Serv 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], bandwidth information may also be
   signaled at LSP establishment time, for the purpose of Traffic
   Engineering, 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 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. References


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

   [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 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., "LDP Specification", draft-ietf-mpls-ldp-
   03.txt, January 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",
   draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999

   [MPLS CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using
   LDP", 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 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

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

   E-mail flefauch@cisco.com

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

   E-mail bsd@cisco.com










Wu et. al                                                           13