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