GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3270

Network Working Group F. Le Faucheur, Editor Request for Comments: 3270 L. Wu Category: Standards Track B. Davie

                                                         Cisco Systems
                                                             S. Davari
                                                       PMC-Sierra Inc.
                                                           P. Vaananen
                                                                 Nokia
                                                           R. Krishnan
                                                     Axiowave Networks
                                                             P. Cheval
                                                               Alcatel
                                                           J. Heinanen
                                                         Song Networks
                                                              May 2002
               Multi-Protocol Label Switching (MPLS)
                 Support of Differentiated Services

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

 This document defines a flexible solution for support of
 Differentiated Services (Diff-Serv) over Multi-Protocol Label
 Switching (MPLS) networks.
 This solution allows the MPLS network administrator to select how
 Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched
 Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic
 Engineering and protection objectives within his/her particular
 network.  For instance, this solution allows the network
 administrator to decide whether different sets of BAs are to be
 mapped onto the same LSP or mapped onto separate LSPs.

Le Faucheur, et. al. Standards Track [Page 1] RFC 3270 MPLS Support of Differentiated Services May 2002

Table of Contents

 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
 1.1  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
 1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6
 1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7
 1.4 Overall Operations. . . . . . . . . . . . . . . . . . . . . . . 7
 1.5 Relationship between Label and FEC. . . . . . . . . . . . . . . 8
 1.6 Bandwidth Reservation for E-LSPs and L-LSPs . . . . . . . . . . 8
 2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models . 9
 2.1 Label Forwarding Model for Diff-Serv LSRs . . . . . . . . . . . 9
 2.2 Incoming PHB Determination. . . . . . . . . . . . . . . . . . .10
 2.3 Outgoing PHB Determination With Optional Traffic Conditioning .11
 2.4 Label Forwarding. . . . . . . . . . . . . . . . . . . . . . . .11
 2.5 Encoding Diff-Serv Information Into Encapsulation Layer . . . .13
 2.6 Diff-Serv Tunneling Models over MPLS. . . . . . . . . . . . . .13
 3. Detailed Operations of E-LSPs. . . . . . . . . . . . . . . . . .22
 3.1 E-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .22
 3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP . .23
 3.3 Incoming PHB Determination On Incoming E-LSP. . . . . . . . . .23
 3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
     E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
 3.5 Encoding Diff-Serv information into Encapsulation Layer On
     Outgoing E-LSP. . . . . . . . . . . . . . . . . . . . . . . . .26
 3.6 E-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .27
 4.  Detailed Operation of L-LSPs. . . . . . . . . . . . . . . . . .28
 4.1 L-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .28
 4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP . .28
 4.3 Incoming PHB Determination On Incoming L-LSP. . . . . . . . . .30
 4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
     L-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
 4.5 Encoding Diff-Serv Information into Encapsulation Layer on
     Outgoing L-LSP. . . . . . . . . . . . . . . . . . . . . . . . .33
 4.6 L-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .34
 5. RSVP Extension for Diff-Serv Support . . . . . . . . . . . . . .34
 5.1 Diff-Serv related RSVP Messages Format. . . . . . . . . . . . .34
 5.2 DIFFSERV Object . . . . . . . . . . . . . . . . . . . . . . . .35
 5.3 Handling DIFFSERV Object. . . . . . . . . . . . . . . . . . . .37
 5.4 Non-support of the DIFFSERV Object. . . . . . . . . . . . . . .40
 5.5 Error Codes For Diff-Serv . . . . . . . . . . . . . . . . . . .40
 5.6 Intserv Service Type. . . . . . . . . . . . . . . . . . . . . .41
 6. LDP Extensions for Diff-Serv Support . . . . . . . . . . . . . .41
 6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . . .42
 6.2 Diff-Serv Status Code Values. . . . . . . . . . . . . . . . . .44
 6.3 Diff-Serv Related LDP Messages. . . . . . . . . . . . . . . . .44
 6.4 Handling of the Diff-Serv TLV . . . . . . . . . . . . . . . . .46
 6.5 Non-Handling of the Diff-Serv TLV . . . . . . . . . . . . . . .49
 6.6 Bandwidth Information . . . . . . . . . . . . . . . . . . . . .49

Le Faucheur, et. al. Standards Track [Page 2] RFC 3270 MPLS Support of Differentiated Services May 2002

 7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and
    Non-LC-FR Interfaces . . . . . . . . . . . . . . . . . . . . . .49
 8. MPLS Support of Diff-Serv over LC-ATM Interfaces . . . . . . . .50
 8.1 Use of ATM Traffic Classes and Traffic Management mechanisms. .50
 8.2 LSR Implementation With LC-ATM Interfaces . . . . . . . . . . .50
 9. MPLS Support of Diff-Serv over LC-FR Interfaces. . . . . . . . .51
 9.1 Use of Frame Relay Traffic parameters and Traffic Management
     mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . .51
 9.2 LSR Implementation With LC-FR Interfaces. . . . . . . . . . . .51
 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .52
 11. Security Considerations . . . . . . . . . . . . . . . . . . . .52
 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .52
 APPENDIX A. Example Deployment Scenarios. . . . . . . . . . . . . .53
 APPENDIX B. Example Bandwidth Reservation Scenarios . . . . . . . .58
 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .62
 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .64

1. Introduction

 In an MPLS domain [MPLS_ARCH], when a stream of data traverses a
 common path, a Label Switched Path (LSP) can be established using
 MPLS signaling protocols.  At the ingress Label Switch Router (LSR),
 each packet is assigned a label and is transmitted downstream.  At
 each LSR along the LSP, the label is used to forward the packet to
 the next hop.
 In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the IP
 packets crossing a link and requiring the same Diff-Serv behavior are
 said to constitute a Behavior Aggregate (BA).  At the ingress node of
 the Diff-Serv domain, the packets are classified and marked with a
 Diff-Serv Code Point (DSCP) which corresponds to their Behavior
 Aggregate.  At each transit node, the DSCP is used to select the Per
 Hop Behavior (PHB) that determines the scheduling treatment and, in
 some cases, drop probability for each packet.
 This document specifies a solution for supporting the Diff-Serv
 Behavior Aggregates whose corresponding PHBs are currently defined
 (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network.  This
 solution also offers flexibility for easy support of PHBs that may be
 defined in the future.
 This solution relies on the combined use of two types of LSPs:
  1. LSPs which can transport multiple Ordered Aggregates, so that the

EXP field of the MPLS Shim Header conveys to the LSR the PHB to be

    applied to the packet (covering both information about the
    packet's scheduling treatment and its drop precedence).

Le Faucheur, et. al. Standards Track [Page 3] RFC 3270 MPLS Support of Differentiated Services May 2002

  1. LSPs which only transport a single Ordered Aggregate, so that the

packet's scheduling treatment is inferred by the LSR exclusively

    from the packet's label value while the packet's drop precedence
    is conveyed in the EXP field of the MPLS Shim Header or in the
    encapsulating link layer specific selective drop mechanism (ATM,
    Frame Relay, 802.1).
 As mentioned in [DIFF_HEADER], "Service providers are not required to
 use the same node mechanisms or configurations to enable service
 differentiation within their networks, and are free to configure the
 node parameters in whatever way that is appropriate for their service
 offerings and traffic engineering objectives".  Thus, the solution
 defined in this document gives Service Providers flexibility in
 selecting how Diff-Serv classes of service are Routed or Traffic
 Engineered within their domain (e.g., separate classes of services
 supported via separate LSPs and Routed separately, all classes of
 service supported on the same LSP and Routed together).
 Because MPLS is path-oriented it can potentially provide faster and
 more predictable protection and restoration capabilities in the face
 of topology changes than conventional hop by hop routed IP systems.
 In this document we refer to such capabilities as "MPLS protection".
 Although such capabilities and associated mechanisms are outside the
 scope of this specification, we note that they may offer different
 levels of protection to different LSPs.  Since the solution presented
 here allow Service Providers to choose how Diff-Serv classes of
 services are mapped onto LSPs, the solution also gives Service
 Providers flexibility in the level of protection provided to
 different Diff-Serv classes of service (e.g., some classes of service
 can be supported by LSPs which are protected while some other classes
 of service are supported by LSPs which are not protected).
 Furthermore, the solution specified in this document achieves label
 space conservation and reduces the volume of label set-up/tear-down
 signaling where possible by only resorting to multiple LSPs for a
 given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or
 required.
 This specification allows support of Differentiated Services for both
 IPv4 and IPv6 traffic transported over an MPLS network.  This
 document only describes operations for unicast.  Multicast support is
 for future study.
 The solution described in this document does not preclude the
 signaled or configured use of the EXP bits to support Explicit
 Congestion Notification [ECN] simultaneously with Diff-Serv over
 MPLS.  However, techniques for supporting ECN in an MPLS environment
 are outside the scope of this document.

Le Faucheur, et. al. Standards Track [Page 4] RFC 3270 MPLS Support of Differentiated Services May 2002

1.1 Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119.
 The reader is assumed to be familiar with the terminology of
 [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR], including the
 following:
    FEC        Forwarding Equivalency Class
    FTN        FEC-To-NHLFE Map
    ILM        Incoming Label Map
    LC-ATM     Label Switching Controlled-ATM (interface)
    LC-FR      Label Switching Controlled-Frame Relay (interface)
    LSP        Label Switched Path
    LSR        Label Switch Router
    MPLS       Multi-Protocol Label Switching
    NHLFE      Next Hop Label Forwarding Entry
 The reader is assumed to be familiar with the terminology of
 [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF], including the
 following:
    AF         Assured Forwarding
    BA         Behavior Aggregate
    CS         Class Selector
    DF         Default Forwarding
    DSCP       Differentiated Services Code Point
    EF         Expedited Forwarding
    PHB        Per Hop Behavior

Le Faucheur, et. al. Standards Track [Page 5] RFC 3270 MPLS Support of Differentiated Services May 2002

 The reader is assumed to be familiar with the terminology of
 [DIFF_NEW], including the following:
    OA        Ordered Aggregate.  The set of Behavior Aggregates which
              share an ordering constraint.
    PSC       PHB Scheduling Class.  The set of one or more PHB(s)
              that are applied to the Behavior Aggregate(s) belonging
              to a given OA.  For example, AF1x is a PSC comprising
              the AF11, AF12 and AF13 PHBs.  EF is an example of PSC
              comprising a single PHB, the EF PHB.
 The following acronyms are also used:
    CLP        Cell Loss Priority
    DE         Discard Eligibility
    SNMP       Simple Network Management Protocol
 Finally, the following acronyms are defined in this specification:
    E-LSP      EXP-Inferred-PSC LSP
    L-LSP      Label-Only-Inferred-PSC LSP

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

 A single LSP can be used to support one or more OAs.  Such LSPs can
 support up to eight BAs of a given FEC, regardless of how many OAs
 these BAs span.  With such LSPs, the EXP field of the MPLS Shim
 Header is used by the LSR to determine the PHB to be applied to the
 packet.  This includes both the PSC and the drop preference.
 We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the
 PSC of a packet transported on this LSP depends on the EXP field
 value for that packet.
 The mapping from the EXP field to the PHB (i.e., to PSC and drop
 precedence) for a given such LSP, is either explicitly signaled at
 label set-up or relies on a pre-configured mapping.
 Detailed operations of E-LSPs are specified in section 3 below.

Le Faucheur, et. al. Standards Track [Page 6] RFC 3270 MPLS Support of Differentiated Services May 2002

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

 A separate LSP can be established for a single <FEC, OA> pair.  With
 such LSPs, the PSC is explicitly signaled at the time of label
 establishment, so that after label establishment, the LSR can infer
 exclusively from the label value the PSC to be applied to a labeled
 packet.  When the Shim Header is used, the Drop Precedence to be
 applied by the LSR to the labeled packet, is conveyed inside the
 labeled packet MPLS Shim Header using the EXP field.  When the Shim
 Header is not used (e.g., MPLS Over ATM), the Drop Precedence to be
 applied by the LSR to the labeled packet is conveyed inside the link
 layer header encapsulation using link layer specific drop precedence
 fields (e.g., ATM CLP).
 We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP) since
 the PSC can be fully inferred from the label without any other
 information (e.g., regardless of the EXP field value).  Detailed
 operations of L-LSPs are specified in section 4 below.

1.4 Overall Operations

 For a given FEC, and unless media specific restrictions apply as
 identified in the sections 7, 8 and 9 below, this specification
 allows any one of the following combinations within an MPLS Diff-Serv
 domain:
  1. zero or any number of E-LSPs, and
  1. zero or any number of L-LSPs.
 The network administrator selects the actual combination of LSPs from
 the set of allowed combinations and selects how the Behavior
 Aggregates are actually transported over this combination of LSPs, in
 order to best match his/her environment and objectives in terms of
 Diff-Serv support, Traffic Engineering and MPLS Protection.  Criteria
 for selecting such a combination are outside the scope of this
 specification.
 For a given FEC, there may be more than one LSP carrying the same OA,
 for example for purposes of load balancing of the OA; However in
 order to respect ordering constraints, all packets of a given
 microflow, possibly spanning multiple BAs of a given Ordered
 Aggregate, MUST be transported over the same LSP.  Conversely, each
 LSP MUST be capable of supporting all the (active) BAs of a given OA.
 Examples of deployment scenarios are provided for information in
 APPENDIX A.

Le Faucheur, et. al. Standards Track [Page 7] RFC 3270 MPLS Support of Differentiated Services May 2002

1.5 Relationship between Label and FEC

 [MPLS_ARCH] states in section `2.1. Overview' that:  `Some routers
 analyze a packet's network layer header not merely to choose the
 packet's next hop, but also to determine a packet's "precedence" or
 "class of service".  They may then apply different discard thresholds
 or scheduling disciplines to different packets.  MPLS allows (but
 does not require) the precedence or class of service to be fully or
 partially inferred from the label.  In this case, one may say that
 the label represents the combination of a FEC and a precedence or
 class of service.'
 In line with this, we observe that:
  1. With E-LSPs, the label represents the combination of a FEC and the

set of BAs transported over the E-LSP. Where all the supported

    BAs are transported over an E-LSP, the label then represents the
    complete FEC.
  1. With L-LSPs, the label represents the combination of a FEC and an

OA.

1.6 Bandwidth Reservation for E-LSPs and L-LSPs

 Regardless of which label binding protocol is used, E-LSPs and L-LSPs
 may be established with or without bandwidth reservation.
 Establishing an E-LSP or L-LSP with bandwidth reservation means that
 bandwidth requirements for the LSP are signaled at LSP establishment
 time.  Such signaled bandwidth requirements may be used by LSRs at
 establishment time to perform admission control of the signaled LSP
 over the Diff-Serv resources provisioned (e.g., via configuration,
 SNMP or policy protocols) for the relevant PSC(s).  Such signaled
 bandwidth requirements may also be used by LSRs at establishment time
 to perform adjustment to the Diff-Serv resources associated with the
 relevant PSC(s) (e.g., adjust PSC scheduling weight).
 Note that establishing an E-LSP or L-LSP with bandwidth reservation
 does not mean that per-LSP scheduling is required.  Since E-LSPs and
 L-LSPs are specified in this document for support of Differentiated
 Services, the required forwarding treatment (scheduling and drop
 policy) is defined by the appropriate Diff-Serv PHB.  This forwarding
 treatment MUST be applied by the LSR at the granularity of the BA and
 MUST be compliant with the relevant PHB specification.

Le Faucheur, et. al. Standards Track [Page 8] RFC 3270 MPLS Support of Differentiated Services May 2002

 When bandwidth requirements are signaled at the establishment of an
 L-LSP, the signaled bandwidth is obviously associated with the L-
 LSP's PSC.  Thus, LSRs which use the signaled bandwidth to perform
 admission control may perform admission control over Diff-Serv
 resources, which are dedicated to the PSC (e.g., over the bandwidth
 guaranteed to the PSC through its scheduling weight).
 When bandwidth requirements are signaled at the establishment of an
 E-LSP, the signaled bandwidth is associated collectively with the
 whole LSP and therefore with the set of transported PSCs.  Thus, LSRs
 which use the signaled bandwidth to perform admission control may
 perform admission control over global resources, which are shared by
 the set of PSCs (e.g., over the total bandwidth of the link).
 Examples of scenarios where bandwidth reservation is not used and
 scenarios where bandwidth reservation is used are provided for
 information in APPENDIX B.

2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models

2.1 Label Forwarding Model for Diff-Serv LSRs

 Since different Ordered Aggregates of a given FEC may be transported
 over different LSPs, the label swapping decision of a Diff-Serv LSR
 clearly depends on the forwarded packet's Behavior Aggregate.  Also,
 since the IP DS field of a forwarded packet may not be directly
 visible to an LSR, the way to determine the PHB to be applied to a
 received packet and to encode the PHB into a transmitted packet, is
 different than a non-MPLS Diff-Serv Router.
 Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we
 model the LSR Diff-Serv label switching behavior, comprised of four
 stages:
  1. Incoming PHB Determination (A)
  1. Outgoing PHB Determination with Optional Traffic Conditioning(B)
  1. Label Forwarding (C)
  1. Encoding of Diff-Serv information into Encapsulation Layer (EXP,

CLP, DE, User_Priority) (D)

 Each stage is described in more detail in the following sections.
 Obviously, to enforce the Diff-Serv service differentiation the LSR
 MUST also apply the forwarding treatment corresponding to the
 Outgoing PHB.

Le Faucheur, et. al. Standards Track [Page 9] RFC 3270 MPLS Support of Differentiated Services May 2002

 This model is illustrated below:
  1. -Inc_label(s)(*)————————>I===I–Outg_label(s)(&)–>

\ I I \

    \---->I===I                            I C I  \-->I===I--Encaps->
          I A I           I===I--Outg_PHB->I===I      I D I   (&)
 -Encaps->I===I--Inc_PHB->I B I         \          /->I===I
    (*)                   I===I          \--------+
                                                   \----Forwarding-->
                                                         Treatment
                                                           (PHB)
 "Encaps" designates the Diff-Serv related information encoded in the
 MPLS Encapsulation layer (e.g., EXP field, ATM CLP, Frame Relay DE,
 802.1 User_Priority)
 (*) when the LSR behaves as an MPLS ingress node, the incoming packet
 may be received unlabelled.
 (&) when the LSR behaves as an MPLS egress node, the outgoing packet
 may be transmitted unlabelled.
 This model is presented here to describe the functional operations of
 Diff-Serv LSRs and does not constrain actual implementation.

2.2 Incoming PHB Determination

 This stage determines which Behavior Aggregate the received packet
 belongs to.

2.2.1 Incoming PHB Determination Considering a Label Stack Entry

 Sections 3.3 and 4.3 provide the details on how to perform incoming
 PHB Determination considering a given received label stack entry
 and/or received incoming MPLS encapsulation information depending on
 the incoming LSP type and depending on the incoming MPLS
 encapsulation.
 Section 2.6 provides the details of which label stack entry to
 consider for the Incoming PHB Determination depending on the
 supported Diff-Serv tunneling mode.

2.2.2 Incoming PHB Determination Considering IP Header

 Section 2.6 provides the details of when the IP Header is to be
 considered for incoming PHB determination, depending on the supported
 Diff-Serv tunneling model.  In those cases where the IP header is to

Le Faucheur, et. al. Standards Track [Page 10] RFC 3270 MPLS Support of Differentiated Services May 2002

 be used, this stage operates exactly as with a non-MPLS IP Diff-Serv
 Router and uses the DS field to determine the incoming PHB.

2.3 Outgoing PHB Determination With Optional Traffic Conditioning

 The traffic conditioning stage is optional and may be used on an LSR
 to perform traffic conditioning including Behavior Aggregate demotion
 or promotion.  It is outside the scope of this specification.  For
 the purpose of specifying Diff-Serv over MPLS forwarding, we simply
 note that the PHB to be actually enforced and conveyed to downstream
 LSRs by an LSR (referred to as "outgoing PHB"), may be different to
 the PHB which had been associated with the packet by the previous LSR
 (referred to as "incoming PHB").
 When the traffic conditioning stage is not present, the "outgoing
 PHB" is simply identical to the "incoming PHB".

2.4 Label Forwarding

 [MPLS_ARCH] describes how label swapping is performed by LSRs on
 incoming labeled packets using an Incoming Label Map (ILM), where
 each incoming label is mapped to one or multiple NHLFEs.  [MPLS_ARCH]
 also describes how label imposition is performed by LSRs on incoming
 unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each
 incoming FEC is mapped to one or multiple NHLFEs.
 A Diff-Serv Context for a label is comprised of:
  1. `LSP type (i.e., E-LSP or L-LSP)'
  1. `supported PHBs'
  1. `Encaps–>PHB mapping' for an incoming label
  1. `Set of PHB–>Encaps mappings' for an outgoing label
 The present specification defines that a Diff-Serv Context is stored
 in the ILM for each incoming label.
 [MPLS_ARCH] states that the `NHLFE may also contain any other
 information needed in order to properly dispose of the packet'.  In
 accordance with this, the present specification defines that a Diff-
 Serv Context is stored in the NHLFE for each outgoing label that is
 swapped or pushed.
 This Diff-Serv Context information is populated into the ILM and the
 FTN at label establishment time.

Le Faucheur, et. al. Standards Track [Page 11] RFC 3270 MPLS Support of Differentiated Services May 2002

 If the label corresponds to an E-LSP for which no `EXP<-->PHB
 mapping' has been explicitly signaled at LSP setup, the `supported
 PHBs' is populated with the set of PHBs of the preconfigured
 `EXP<-->PHB mapping', which is discussed below in section 3.2.1.
 If the label corresponds to an E-LSP for which an `EXP<-->PHB
 mapping' has been explicitly signaled at LSP setup, the `supported
 PHBs' is populated with the set of PHBs of the signaled `EXP<-->PHB
 mapping'.
 If the label corresponds to an L-LSP, the `supported PHBs' is
 populated with the set of PHBs forming the PSC that is signaled at
 LSP set-up.
 The details of how the `Encaps-->PHB mapping' or `Set of PHB-->Encaps
 mappings' are populated are defined below in sections 3 and 4.
 [MPLS_ARCH] also states that:
 "If the ILM [respectively, FTN] maps a particular label to a set of
 NHLFEs that contain more than one element, exactly one element of the
 set must be chosen before the packet is forwarded.  The procedures
 for choosing an element from the set are beyond the scope of this
 document.  Having the ILM [respectively, FTN] map a label
 [respectively, a FEC] to a set containing more than one NHLFE may be
 useful if, e.g., it is desired to do load balancing over multiple
 equal-cost paths."
 In accordance with this, the present specification allows that an
 incoming label [respectively FEC] may be mapped, for Diff-Serv
 purposes, to multiple NHLFEs (for instance where different NHLFEs
 correspond to egress labels supporting different sets of PHBs).  When
 a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR
 MUST choose one of the NHLFEs whose Diff-Serv Context indicates that
 it supports the Outgoing PHB of the forwarded packet.
 When a label [respectively FEC] maps to multiple NHLFEs which support
 the Outgoing PHB, the procedure for choosing one among those is
 outside the scope of this document.  This situation may be
 encountered where it is desired to do load balancing of a Behavior
 Aggregate over multiple LSPs.  In such situations, in order to
 respect ordering constraints, all packets of a given microflow MUST
 be transported over the same LSP.

Le Faucheur, et. al. Standards Track [Page 12] RFC 3270 MPLS Support of Differentiated Services May 2002

2.5 Encoding Diff-Serv Information Into Encapsulation Layer

 This stage determines how to encode the fields which convey Diff-Serv
 information in the transmitted packet (e.g., MPLS Shim EXP, ATM CLP,
 Frame Relay DE, 802.1 User_Priority).

2.5.1 Encoding Diff-Serv Information Into Transmitted Label Entry

 Sections 3.5 and 4.5 provide the details on how to perform Diff-Serv
 information encoding into a given transmitted label stack entry
 and/or transmitted MPLS encapsulation information depending on the
 corresponding outgoing LSP type and depending on the MPLS
 encapsulation.
 Section 2.6 provides the details in which label stack entry to
 perform Diff-Serv information encoding into depending on the
 supported Diff-Serv tunneling mode.

2.5.2 Encoding Diff-Serv Information Into Transmitted IP Header

 To perform Diff-Serv Information Encoding into the transmitted packet
 IP header, this stage operates exactly as with a non-MPLS IP Diff-
 Serv Router and encodes the DSCP of the Outgoing PHB into the DS
 field.
 Section 2.6 provides the details of when Diff-Serv Information
 Encoding is to be performed into transmitted IP header depending on
 the supported Diff-Serv tunneling mode.

2.6 Diff-Serv Tunneling Models over MPLS

2.6.1 Diff-Serv Tunneling Models

 [DIFF_TUNNEL] considers the interaction of Differentiated Services
 with IP tunnels of various forms.  MPLS LSPs are not a form of "IP
 tunnels" since the MPLS encapsulating header does not contain an IP
 header and thus MPLS LSPs are not considered in [DIFF_TUNNEL].
 However, although not a form of "IP tunnel", MPLS LSPs are a form of
 "tunnel".
 From the Diff-Serv standpoint, LSPs share a number of common
 characteristics with IP Tunnels:
  1. Intermediate nodes (i.e., Nodes somewhere along the LSP span) only

see and operate on the "outer" Diff-Serv information.

  1. LSPs are unidirectional.

Le Faucheur, et. al. Standards Track [Page 13] RFC 3270 MPLS Support of Differentiated Services May 2002

  1. The "outer" Diff-Serv information can be modified at any of the

intermediate nodes.

 However, from the Diff-Serv standpoint, LSPs also have a distinctive
 property compared to IP Tunnels:
  1. There is generally no behavior analogous to Penultimate Hop

Popping (PHP) used with IP Tunnels. Furthermore, PHP results in

    the "outer" Diff-Serv information associated with the LSP not
    being visible to the LSP egress.  In situations where this
    information is not meaningful at the LSP Egress, this is obviously
    not an issue at all.  In situations where this information is
    meaningful at the LSP Egress, then it must somehow be carried in
    some other means.
 The two conceptual models for Diff-Serv tunneling over IP Tunnels
 defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over
 MPLS but their respective detailed operations is somewhat different
 over MPLS.  These two models are the Pipe Model and the Uniform
 Model.  Their operations over MPLS are specified in the following
 sections.  Discussion and definition of alternative tunneling models
 are outside the scope of this specification.

2.6.2 Pipe Model

 With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide the
 intermediate MPLS nodes between LSP Ingress and Egress from the
 Diff-Serv perspective.
 In this model, tunneled packets must convey two meaningful pieces of
 Diff-Serv information:
  1. the Diff-Serv information which is meaningful to intermediate

nodes along the LSP span including the LSP Egress (which we refer

    to as the "LSP Diff-Serv Information").  This LSP Diff-Serv
    Information is not meaningful beyond the LSP Egress: Whether
    Traffic Conditioning at intermediate nodes on the LSP span affects
    the LSP Diff-Serv information or not, this updated Diff-Serv
    information is not considered meaningful beyond the LSP Egress and
    is ignored.
  1. the Diff-Serv information which is meaningful beyond the LSP

Egress (which we refer to as the "Tunneled Diff-Serv

    Information").  This information is to be conveyed by the LSP
    Ingress to the LSP Egress.  This Diff-Serv information is not
    meaningful to the intermediate nodes on the LSP span.

Le Faucheur, et. al. Standards Track [Page 14] RFC 3270 MPLS Support of Differentiated Services May 2002

 Operation of the Pipe Model without PHP is illustrated below:
          ========== LSP =============================>
  1. –Swap–(M)–…–Swap–(M)–Swap—-

/ (outer header) \

           (M)                                      (M)
           /                                          \
 >--(m)-Push.................(m).....................Pop--(m)-->
          I             (inner header)                E   (M*)
 (M) represents the "LSP Diff-Serv information"
 (m) represents the "Tunneled Diff-Serv information"
 (*) The LSP Egress considers the LSP Diff-Serv information received
     in the outer header (i.e., before the pop) in order to apply its
     Diff-Serv forwarding treatment (i.e., actual PHB)
  I  represents the LSP ingress node
  E  represents the LSP egress node
 With the Pipe Model, the "LSP Diff-Serv Information" needs to be
 conveyed to the LSP Egress so that it applies its forwarding
 treatment based on it.  The "Tunneled Diff-Serv information" also
 needs to be conveyed to the LSP Egress so it can be conveyed further
 downstream.
 Since both require that Diff-Serv information be conveyed to the LSP
 Egress, the Pipe Model operates only without PHP.
 The Pipe Model is particularly appropriate for environments in which:
  1. the cloud upstream of the incoming interface of the LSP Ingress

and the cloud downstream of the outgoing interface of the LSP

    Egress are in Diff-Serv domains which use a common set of Diff-
    Serv service provisioning policies and PHB definitions, while the
    LSP spans one (or more) Diff-Serv domain(s) which use(s) a
    different set of Diff-Serv service provisioning policies and PHB
    definitions
  1. the outgoing interface of the LSP Egress is in the (last) Diff-

Serv domain spanned by the LSP.

 As an example, consider the case where a service provider is offering
 an MPLS VPN service (see [MPLS_VPN] for an example of MPLS VPN
 architecture) including Diff-Serv differentiation.  Say that a
 collection of sites is interconnected via such an MPLS VPN service.
 Now say that this collection of sites is managed under a common
 administration and is also supporting Diff-Serv service
 differentiation.  If the VPN site administration and the Service

Le Faucheur, et. al. Standards Track [Page 15] RFC 3270 MPLS Support of Differentiated Services May 2002

 Provider are not sharing the exact same Diff-Serv policy (for
 instance not supporting the same number of PHBs), then operation of
 Diff-Serv in the Pipe Model over the MPLS VPN service would allow the
 VPN Sites Diff-Serv policy to operate consistently throughout the
 ingress VPN Site and Egress VPN Site and transparently over the
 Service Provider Diff-Serv domain.  It may be useful to view such
 LSPs as linking the Diff-Serv domains at their endpoints into a
 single Diff-Serv region by making these endpoints virtually
 contiguous even though they may be physically separated by
 intermediate network nodes.
 The Pipe Model MUST be supported.
 For support of the Pipe Model over a given LSP without PHP, an LSR
 performs the Incoming PHB Determination and the Diff-Serv information
 Encoding in the following manner:
  1. when receiving an unlabelled packet, the LSR performs Incoming PHB

Determination considering the received IP Header.

  1. when receiving a labeled packet, the LSR performs Incoming PHB

Determination considering the outer label entry in the received

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

LSR encodes Diff-Serv Information in the transmitted label entry

    that contains the swapped label
  1. when performing a pop operation for the considered LSP, the LSR

does not perform Encoding of Diff-Serv Information into the header

    exposed by the pop operation (i.e., the LSR leaves the exposed
    header "as is").

2.6.2.1 Short Pipe Model

 The Short Pipe Model is an optional variation of the Pipe Model
 described above.  The only difference is that, with the Short Pipe

Le Faucheur, et. al. Standards Track [Page 16] RFC 3270 MPLS Support of Differentiated Services May 2002

 Model, the Diff-Serv forwarding treatment at the LSP Egress is
 applied based on the "Tunneled Diff-Serv Information" (i.e., Diff-
 Serv information conveyed in the encapsulated header) rather than on
 the "LSP Diff-Serv information" (i.e., Diff-Serv information conveyed
 in the encapsulating header).
 Operation of the Short Pipe Model without PHP is illustrated below:
          ========== LSP =============================>
  1. –Swap–(M)–…–Swap–(M)–Swap—-

/ (outer header) \

           (M)                                      (M)
           /                                          \
 >--(m)-Push.................(m).....................Pop--(m)-->
          I             (inner header)                E
 (M) represents the "LSP Diff-Serv information"
 (m) represents the "Tunneled Diff-Serv information"
  I  represents the LSP ingress node
  E  represents the LSP egress node
 Since the LSP Egress applies its forwarding treatment based on the
 "Tunneled Diff-Serv Information", the "LSP Diff-Serv information"
 does not need to be conveyed by the penultimate node to the LSP
 Egress.  Thus the Short Pipe Model can also operate with PHP.
 Operation of the Short Pipe Model with PHP is illustrated below:
         =========== LSP ============================>
  1. –Swap–(M)–…–Swap——

/ (outer header) \

           (M)                             (M)
           /                                 \
 >--(m)-Push.................(m).............Pop-(m)--E--(m)-->
         I           (inner header)           P (M*)
 (M) represents the "LSP Diff-Serv information"
 (m) represents the "Tunneled Diff-Serv information"
 (*) The Penultimate LSR considers the LSP Diff-Serv information
     received in the outer header (i.e., before the pop) in order to
     apply its Diff-Serv forwarding treatment (i.e., actual PHB)
  I  represents the LSP ingress node
  P  represents the LSP penultimate node
  E  represents the LSP egress node

Le Faucheur, et. al. Standards Track [Page 17] RFC 3270 MPLS Support of Differentiated Services May 2002

 The Short Pipe Model is particularly appropriate for environments in
 which:
  1. the cloud upstream of the incoming interface of the LSP Ingress

and the cloud downstream of the outgoing interface of the LSP

    Egress are in Diff-Serv domains which use a common set of Diff-
    Serv service provisioning policies and PHB definitions, while the
    LSP spans one (or more) Diff-Serv domain(s) which use(s) a
    different set of Diff-Serv service provisioning policies and PHB
    definitions
  1. the outgoing interface of the LSP Egress is in the same Diff-Serv

domain as the cloud downstream of it.

 Since each outgoing interface of the LSP Egress is in the same Diff-
 Serv domain as the cloud downstream of it, each outgoing interface
 may potentially be in a different Diff-Serv domain, and the LSP
 Egress needs to be configured with awareness of every corresponding
 Diff-Serv policy.  This operational overhead is justified in some
 situations where the respective downstream Diff-Serv policies are
 better suited to offering service differentiation over each egress
 interface than the common Diff-Serv policy used on the LSP span.  An
 example of such a situation is where a Service Provider offers an
 MPLS VPN service and where some VPN users request that their own VPN
 Diff-Serv policy be applied to control service differentiation on the
 dedicated link from the LSP Egress to the destination VPN site,
 rather than the Service Provider's Diff-Serv policy.
 The Short Pipe Model MAY be supported.
 For support of the Short Pipe Model over a given LSP without PHP, an
 LSR performs the Incoming PHB Determination and the Diff-Serv
 information Encoding in the same manner as with the Pipe Model with
 the following exception:
  1. when receiving a labeled packet, the LSR performs Incoming PHB

Determination considering the header (label entry or IP header)

    which is used to do the actual forwarding.  In particular, when a
    pop operation is to be performed for the considered LSP, the LSR
    performs Incoming PHB Determination AFTER the pop.
 For support of the Short Pipe Model over a given LSP with PHP, an LSR
 performs Incoming PHB Determination and Diff-Serv information
 Encoding in the same manner as without PHP with the following
 exceptions:

Le Faucheur, et. al. Standards Track [Page 18] RFC 3270 MPLS Support of Differentiated Services May 2002

  1. the Penultimate LSR performs Incoming PHB Determination

considering the outer label entry in the received label stack. In

    other words, when a pop operation is to be performed for the
    considered LSP, the Penultimate LSR performs Incoming PHB
    Determination BEFORE the pop.
 Note that the behavior of the Penultimate LSR in the Short Pipe Mode
 with PHP, is identical to the behavior of the LSP Egress in the Pipe
 Mode (necessarily without PHP).

2.6.3 Uniform Model

 With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as
 artifacts of the end-to-end path from the Diff-Serv standpoint.  MPLS
 Tunnels may be used for forwarding purposes but have no significant
 impact on Diff-Serv.  In this model, any packet contains exactly one
 piece of Diff-Serv information which is meaningful and is always
 encoded in the outer most label entry (or in the IP DSCP where the IP
 packet is transmitted unlabelled for instance at the egress of the
 LSP).  Any Diff-Serv information encoded somewhere else (e.g., in
 deeper label entries) is of no significance to intermediate nodes or
 to the tunnel egress and is ignored.  If Traffic Conditioning at
 intermediate nodes on the LSP span affects the "outer" Diff-Serv
 information, the updated Diff-Serv information is the one considered
 meaningful at the egress of the LSP.
 Operation of the Uniform Model without PHP is illustrated below:
           ========== LSP =============================>
  1. –Swap–(M)–…-Swap–(M)–Swap—-

/ (outer header) \

            (M)                                     (M)
            /                                         \
 >--(M)--Push...............(x).......................Pop--(M)->
          I            (inner header)                  E
 (M) represents the Meaningful Diff-Serv information encoded in the
     corresponding header.
 (x) represents non-meaningful Diff-Serv information.
  I  represents the LSP ingress node
  E  represents the LSP egress node

Le Faucheur, et. al. Standards Track [Page 19] RFC 3270 MPLS Support of Differentiated Services May 2002

 Operation of the Uniform Model with PHP is illustrated below:
           ========== LSP =========================>
  1. –Swap-(M)-…-Swap——

/ (outer header) \

            (M)                          (M)
            /                              \
 >--(M)--Push..............(x)............Pop-(M)--E--(M)->
           I          (inner header)       P
 (M) represents the Meaningful Diff-Serv information encoded in the
     corresponding header.
 (x) represents non-meaningful Diff-Serv information.
  I  represents the LSP ingress node
  P  represents the LSP penultimate node
  E  represents the LSP egress node
 The Uniform Model for Diff-Serv over MPLS is such that, from the
 Diff-Serv perspective, operations are exactly identical to the
 operations if MPLS was not used.  In other words, MPLS is entirely
 transparent to the Diff-Serv operations.
 Use of the Uniform Model allows LSPs to span Diff-Serv domain
 boundaries without any other measure in place than an inter-domain
 Traffic Conditioning Agreement at the physical boundary between the
 Diff-Serv domains and operating exclusively on the "outer" header,
 since the meaningful Diff-Serv information is always visible and
 modifiable in the outmost label entry.
 The Uniform Model MAY be supported.
 For support of the Uniform Model over a given LSP, an LSR performs
 Incoming PHB Determination and Diff-Serv information Encoding in the
 following manner:
  1. when receiving an unlabelled packet, the LSR performs Incoming PHB

Determination considering the received IP Header.

  1. when receiving a labeled packet, the LSR performs Incoming PHB

Determination considering the outer label entry in the received

    label stack.  In particular, when a pop operation is to be
    performed for the considered LSP, the LSR performs Incoming PHB
    Determination BEFORE the pop.

Le Faucheur, et. al. Standards Track [Page 20] RFC 3270 MPLS Support of Differentiated Services May 2002

  1. when performing a push operation for the considered LSP, the LSR

encodes Diff-Serv Information in the transmitted label entry

    corresponding to the pushed label.  The Diff-Serv Information
    encoded in the encapsulated header (swapped label entry or IP
    Header) is of no importance.
  1. when performing a swap-only operation for the considered LSP, the

LSR encodes Diff-Serv Information in the transmitted label entry

    that contains the swapped label.
  1. when PHP is used, the Penultimate LSR needs to be aware of the

"Set of PHB–>Encaps mappings" for the label corresponding to the

    exposed header (or the `PHB-->DSCP mapping') in order to perform
    Diff-Serv Information Encoding.  Methods for providing this
    mapping awareness are outside the scope of this specification.  As
    an example, the "PHB-->DSCP mapping" may be locally configured.
    As another example, in some environments, it may be appropriate
    for the Penultimate LSR to assume that the "Set of PHB-->Encaps
    mappings" to be used for the outgoing label in the exposed header
    is the "Set of PHB-->Encaps mappings" that would be used by the
    LSR if the LSR was not doing PHP.  Note also that this
    specification assumes that the Penultimate LSR does not perform
    label swapping over the label entry exposed by the pop operation
    (and in fact that it does not even look at the exposed label).
    Consequently, restrictions may apply to the Diff-Serv Information
    Encoding that can be performed by the Penultimate LSR.  For
    example, this specification does not allow situations where the
    Penultimate LSR pops a label corresponding to an E-LSP supporting
    two PSCs, while the header exposed by the pop contains label
    values for two L-LSPs each supporting one PSC, since the Diff-Serv
    Information Encoding would require selecting one label or the
    other.
 Note that LSR behaviors for the Pipe, the Short Pipe and the Uniform
 Model only differ when doing a push or a pop.  Thus, Intermediate
 LSRs which perform swap only operations for an LSP, behave in exactly
 the same way, regardless of whether they are behaving in the Pipe,
 Short Pipe or the Uniform model.  With a Diff-Serv implementation
 supporting multiple Tunneling Models, only LSRs behaving as LSP
 Ingress, Penultimate LSR or LSP Egress need to be configured to
 operate in a particular Model.  Signaling to associate a Diff-Serv
 tunneling model on a per-LSP basis is not within the scope of this
 specification.

Le Faucheur, et. al. Standards Track [Page 21] RFC 3270 MPLS Support of Differentiated Services May 2002

2.6.4 Hierarchy

 Through the label stack mechanism, MPLS allows LSP tunneling to nest
 to any depth.  We observe that with such nesting, the push of level
 N+1 takes place on a subsequent (or the same) LSR to the LSR doing
 the push for level N, while the pop of level N+1 takes place on a
 previous (or the same) LSR to the LSR doing the pop of level N.  For
 a given level N LSP, the Ingress LSR doing the push and the LSR doing
 the pop (Penultimate LSR or LSP Egress) must operate in the same
 Tunneling Model (i.e., Pipe, Short Pipe or Uniform).  However, there
 is no requirement for consistent tunneling models across levels so
 that LSPs at different levels may be operating in different Tunneling
 Models.
 Hierarchical operations are illustrated below in the case of two
 levels of tunnels:
             +--------Swap--...---+
            /    (outmost header)  \
           /                        \
         Push(2).................(2)Pop
         / (outer header)             \
        /                              \
 >>---Push(1)........................(1)Pop-->>
           (inner header)
 (1) Tunneling Model 1
 (2) Tunneling Model 2
 Tunneling Model 2 may be the same as or may be different from
 Tunneling Model 1.
 For a given LSP of level N, the LSR must perform the Incoming PHB
 Determination and the Diff-Serv information Encoding as specified in
 section 2.6.2, 2.6.2.1 and 2.6.3 according to the Tunneling Model of
 this level N LSP and independently of the Tunneling Model of other
 level LSPs.

3. Detailed Operations of E-LSPs

3.1 E-LSP Definition

 E-LSPs are defined in section 1.2.
 Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the
 pre-configured mapping are capable of transporting the same common
 set of 8, or fewer, BAs.  Each of those E-LSPs may actually transport
 this full set of BAs or any arbitrary subset of it.

Le Faucheur, et. al. Standards Track [Page 22] RFC 3270 MPLS Support of Differentiated Services May 2002

 For a given FEC, two given E-LSPs using a signaled `EXP<-->PHB
 mapping' can support the same or different sets of Ordered
 Aggregates.

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

 This section defines how the `Encaps-->PHB mapping' of the Diff-Serv
 Context is populated for an incoming E-LSP in order to allow Incoming
 PHB determination.
 The `Encaps-->PHB mapping' for an E-LSP is always of the form
 `EXP-->PHB mapping'.
 If the label corresponds to an E-LSP for which no `EXP<-->PHB
 mapping' has been explicitly signaled at LSP setup, the `EXP-->PHB
 mapping' is populated based on the Preconfigured `EXP<-->PHB mapping'
 which is discussed below in section 3.2.1.
 If the label corresponds to an E-LSP for which an `EXP<-->PHB
 mapping' has been explicitly signaled at LSP setup, the `EXP-->PHB
 mapping' is populated as per the signaled `EXP<-->PHB mapping'.

3.2.1 Preconfigured `EXP←→PHB mapping'

 LSRs supporting E-LSPs which use the preconfigured `EXP<-->PHB
 mapping' must allow local configuration of this `EXP<-->PHB mapping'.
 This mapping applies to all the E-LSPs established on this LSR
 without a mapping explicitly signaled at set-up time.
 The preconfigured `EXP<-->PHB mapping' must either be consistent at
 every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the
 LSP or appropriate remarking of the EXP field must be performed by
 the LSR whenever a different preconfigured mapping is used on the
 ingress and egress interfaces.
 In case, the preconfigured `EXP<-->PHB mapping' has not actually been
 configured by the Network Administrator, the LSR should use a default
 preconfigured `EXP<-->PHB mapping' which maps all EXP values to the
 Default PHB.

3.3 Incoming PHB Determination On Incoming E-LSP

 This section defines how Incoming PHB Determination is carried out
 when the considered label entry in the received label stack
 corresponds to an E-LSP.  This requires that the `Encaps-->PHB
 mapping' is populated as defined in section 3.2.

Le Faucheur, et. al. Standards Track [Page 23] RFC 3270 MPLS Support of Differentiated Services May 2002

 When considering a label entry corresponding to an incoming E-LSP for
 Incoming PHB Determination, the LSR:
  1. determines the `EXP–>PHB mapping' by looking up the `Encaps–>PHB

mapping' of the Diff-Serv Context associated in the ILM with the

    considered incoming E-LSP label.
  1. determines the incoming PHB by looking up the EXP field of the

considered label entry in the `EXP–>PHB mapping' table.

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

 This section defines how the `Set of PHB-->Encaps mappings' of the
 Diff-Serv Context is populated at label setup for an outgoing E-LSP
 in order to allow Encoding of Diff-Serv information in the
 Encapsulation Layer.

3.4.1 `PHB–>EXP mapping'

 An outgoing E-LSP must always have a `PHB-->EXP mapping' as part of
 the `Set of PHB-->Encaps mappings' of its Diff-Serv Context.
 If the label corresponds to an E-LSP for which no `EXP<-->PHB
 mapping' has been explicitly signaled at LSP setup, this `PHB-->EXP
 mapping' is populated based on the Preconfigured `EXP<-->PHB mapping'
 which is discussed above in section 3.2.1.
 If the label corresponds to an E-LSP for which an `EXP<-->PHB
 mapping' has been explicitly signaled at LSP setup, the `PHB-->EXP
 mapping' is populated as per the signaled `EXP<-->PHB mapping'.

3.4.2 `PHB–>CLP mapping'

 If the LSP is egressing over an ATM interface which is not label
 switching controlled, then one `PHB-->CLP mapping' is added to the
 `Set of PHB-->Encaps mappings' for this outgoing LSP.  This
 `PHB-->CLP mapping' is populated in the following way:
  1. it is a function of the PHBs supported on this LSP, and may use

the relevant mapping entries for these PHBs from the Default

    `PHB-->CLP mapping' defined in section 3.4.2.1.  Mappings other
    than the one defined in section 3.4.2.1 may be used.  In
    particular, if a mapping from PHBs to CLP is standardized in the
    future for operations of Diff-Serv over ATM, such a standardized
    mapping may then be used.

Le Faucheur, et. al. Standards Track [Page 24] RFC 3270 MPLS Support of Differentiated Services May 2002

 For example if the outgoing label corresponds to an LSP supporting
 the AF1 PSC, then the `PHB-->CLP mapping' may be populated with:
       PHB                CLP Field
       AF11       ---->      0
       AF12       ---->      1
       AF13       ---->      1
       EF         ---->      0
 Notice that in this case the `Set of PHB-->Encaps mappings' contains
 both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'.

3.4.2.1 Default `PHB–>CLP mapping'

       PHB                CLP Bit
       DF         ---->      0
       CSn        ---->      0
       AFn1       ---->      0
       AFn2       ---->      1
       AFn3       ---->      1
       EF         ---->      0

3.4.3 `PHB–>DE mapping'

 If the LSP is egressing over a Frame Relay interface which is not
 label switching controlled, one `PHB-->DE mapping' is added to the
 `Set of PHB-->Encaps mappings' for this outgoing LSP and is populated
 in the following way:
  1. it is a function of the PHBs supported on this LSP, and may use

the relevant mapping entries for these PHBs from the Default

    `PHB-->DE mapping' defined in section 3.4.3.1.  Mappings other
    than the one defined in section 3.4.3.1 may be used.  In
    particular, if a mapping from PHBs to DE is standardized in the
    future for operations of Diff-Serv over Frame Relay, such a
    standardized mapping may then be used.
 Notice that in this case the `Set of PHB-->Encaps mappings' contains
 both a `PHB-->EXP mapping' and a `PHB-->DE mapping'.

Le Faucheur, et. al. Standards Track [Page 25] RFC 3270 MPLS Support of Differentiated Services May 2002

3.4.3.1 `Default PHB–>DE mapping'

       PHB                 DE Bit
        DF       ---->       0
        CSn      ---->       0
        AFn1     ---->       0
        AFn2     ---->       1
        AFn3     ---->       1
        EF       ---->       0

3.4.4 `PHB–>802.1 mapping'

 If the LSP is egressing over a LAN interface on which multiple 802.1
 Traffic Classes are supported as per [IEEE_802.1], then one
 `PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings'
 for this outgoing LSP.  This `PHB-->802.1 mapping' is populated in
 the following way:
  1. it is a function of the PHBs supported on this LSP, and uses the

relevant mapping entries for these PHBs from the Preconfigured

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

3.4.4.1 Preconfigured `PHB–>802.1 Mapping'

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

3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing

  E-LSP
 This section defines how to encode Diff-Serv information into the
 MPLS encapsulation Layer for a given transmitted label entry
 corresponding to an outgoing E-LSP.  This requires that the `Set of
 PHB-->Encaps mappings' be populated as defined in section 3.4.
 The LSR first determines the `Set of PHB-->Encaps mappings' of the
 Diff-Serv Context associated with the corresponding label in the
 NHLFE.

Le Faucheur, et. al. Standards Track [Page 26] RFC 3270 MPLS Support of Differentiated Services May 2002

3.5.1 `PHB–>EXP mapping'

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

corresponding level label entry by looking up the "outgoing PHB"

    in this `PHB-->EXP mapping' table.

3.5.2 `PHB–>CLP mapping'

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

encapsulation header, by looking up the "outgoing PHB" in this

    `PHB-->CLP mapping' table.

3.5.3 `PHB–>DE mapping'

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

Relay encapsulation header, by looking up the "outgoing PHB" in

    this `PHB-->DE mapping' table.

3.5.4 `PHB–>802.1 mapping'

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

the Tag Control Information of the 802.1 encapsulation header

    [IEEE_802.1], by looking up the "outgoing PHB" in this 'PHB--
    >802.1 mapping' table.

3.6 E-LSP Merging

 In an MPLS domain, two or more LSPs can be merged into one LSP at one
 LSR.  E-LSPs are compatible with LSP Merging under the following
 condition:
    E-LSPs can only be merged into one LSP if they support the exact
    same set of BAs.

Le Faucheur, et. al. Standards Track [Page 27] RFC 3270 MPLS Support of Differentiated Services May 2002

 For E-LSPs using a signaled `EXP<-->PHB mapping', the above merge
 condition MUST be enforced by LSRs through explicit checking at label
 setup that the exact same set of PHBs is supported on the merged
 LSPs.
 For E-LSPs using the preconfigured `EXP<-->PHB mapping', since the
 PHBs supported over an E-LSP is not signaled at establishment time,
 an LSR can not rely on signaling information to enforce the above
 merge.  However all E-LSPs using the preconfigured `EXP<-->PHB
 mapping' are required to support the same set of Behavior Aggregates
 within a given MPLS Diff-Serv domain.  Thus, merging of E-LSPs using
 the preconfigured `EXP<-->PHB mapping' is allowed within a given MPLS
 Diff-Serv domain.

4. Detailed Operation of L-LSPs

4.1 L-LSP Definition

 L-LSPs are defined in section 1.3.

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

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

4.2.1 `EXP–>PHB mapping'

 If the LSR terminates the MPLS Shim Layer over this incoming L-LSP
 and the L-LSP ingresses on an interface which is not ATM nor Frame
 Relay, then the `Encaps-->PHB mapping' is populated in the following
 way:
  1. it is actually a `EXP–>PHB mapping'
  1. this mapping is a function of the PSC which is carried on this

LSP, and must use the relevant mapping entries for this PSC from

    the Mandatory `EXP/PSC-->PHB mapping' defined in Section 4.2.1.1.
 For example if the incoming label corresponds to an L-LSP supporting
 the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with:
    EXP Field              PHB
      001        ---->    AF11
      010        ---->    AF12
      011        ---->    AF13

Le Faucheur, et. al. Standards Track [Page 28] RFC 3270 MPLS Support of Differentiated Services May 2002

 An LSR, supporting L-LSPs over PPP interfaces and LAN interfaces, is
 an example of an LSR terminating the Shim layer over ingress
 interfaces which are not ATM nor Frame Relay.
 If the LSR terminates the MPLS Shim Layer over this incoming L-LSP
 and the L-LSP ingresses on an ATM or Frame Relay interface, then the
 `Encaps-->PHB mapping' is populated in the following way:
  1. it should actually be a `EXP–>PHB mapping'. Alternative optional

ways of populating the `Encaps–>PHB mapping' might be defined in

    the future (e.g., using a 'CLP/EXP--> PHB mapping' or a
    'DE/EXP-->PHB mapping') but are outside the scope of this
    document.
  1. when the `Encaps–>PHB mapping' is an `EXP–>PHB mapping', this

`EXP–>PHB mapping' mapping is a function of the PSC which is

    carried on the L-LSP, and must use the relevant mapping entries
    for this PSC from the Mandatory `EXP/PSC-->PHB mapping' defined in
    Section 4.2.1.1.
 An Edge-LSR of an ATM-MPLS domain or of a FR-MPLS domain is an
 example of an LSR terminating the shim layer over an ingress ATM/FR
 interface.

4.2.1.1 Mandatory `EXP/PSC –> PHB mapping'

    EXP Field      PSC             PHB
      000          DF    ---->    DF
      000          CSn   ---->    CSn
      001          AFn   ---->    AFn1
      010          AFn   ---->    AFn2
      011          AFn   ---->    AFn3
      000          EF    ---->    EF

4.2.2 `CLP–>PHB mapping'

 If the LSR does not terminate an MPLS Shim Layer over this incoming
 label and uses ATM encapsulation (i.e., it is an ATM-LSR), then the
 `Encaps-->PHB mapping' for this incoming L-LSP is populated in the
 following way:
  1. it is actually a `CLP–>PHB mapping'
  1. the mapping is a function of the PSC, which is carried on this

LSP, and should use the relevant mapping entries for this PSC from

    the Default `CLP/PSC-->PHB mapping' defined in Section 4.2.2.1.

Le Faucheur, et. al. Standards Track [Page 29] RFC 3270 MPLS Support of Differentiated Services May 2002

 For example if the incoming label corresponds to an L-LSP supporting
 the AF1 PSC, then the `Encaps-->PHB mapping' should be populated
 with:
    CLP Field              PHB
      0          ---->    AF11
      1          ---->    AF12

4.2.2.1 Default `CLP/PSC –> PHB mapping'

    CLP Bit      PSC             PHB
       0          DF    ---->    DF
       0          CSn   ---->    CSn
       0          AFn   ---->    AFn1
       1          AFn   ---->    AFn2
       0          EF    ---->    EF

4.2.3 `DE–>PHB mapping'

 If the LSR does not terminate an MPLS Shim Layer over this incoming
 label and uses Frame Relay encapsulation (i.e., it is a FR-LSR), then
 the `Encaps-->PHB mapping' for this incoming L-LSP is populated in
 the following way:
  1. it is actually a `DE–>PHB mapping'
  1. the mapping is a function of the PSC which is carried on this LSP,

and should use the relevant mapping entries for this PSC from the

    Default `DE/PSC-->PHB mapping' defined in Section 4.2.3.1.

4.2.3.1 Default `DE/PSC –> PHB mapping'

    DE Bit      PSC             PHB
       0          DF    ---->    DF
       0          CSn   ---->    CSn
       0          AFn   ---->    AFn1
       1          AFn   ---->    AFn2
       0          EF    ---->    EF

4.3 Incoming PHB Determination On Incoming L-LSP

 This section defines how Incoming PHB determination is carried out
 when the considered label entry in the received label stack
 corresponds to an L-LSP.  This requires that the `Encaps-->PHB
 mapping' is populated as defined in section 4.2.

Le Faucheur, et. al. Standards Track [Page 30] RFC 3270 MPLS Support of Differentiated Services May 2002

 When considering a label entry corresponding to an incoming L-LSP
 for Incoming PHB Determination, the LSR first determines the
 `Encaps-->PHB mapping' associated with the corresponding label.

4.3.1 `EXP–>PHB mapping'

 If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping',
 then the LSR:
  1. determines the incoming PHB by looking at the EXP field of the

considered label entry and using the `EXP–>PHB mapping'.

4.3.2 `CLP–>PHB mapping'

 If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping',
 then the LSR:
  1. determines the incoming PHB by looking at the CLP field of the

ATM Layer encapsulation and using the `CLP–>PHB mapping'.

4.3.3 `DE–>PHB mapping'

 If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping',
 then the LSR:
  1. determines the incoming PHB by looking at the DE field of the

Frame Relay encapsulation and by using the `DE–>PHB mapping'.

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

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

4.4.1 `PHB–>EXP mapping'

 If the LSR uses an MPLS Shim Layer over this outgoing L-LSP, then
 one `PHB-->EXP mapping' is added to the `Set of
 PHB-->Encaps mappings' for this outgoing
 L-LSP.  This `PHB-->EXP mapping' is populated in the following way:
  1. it is a function of the PSC supported on this LSP, and must use

the mapping entries relevant for this PSC from the Mandatory

    `PHB-->EXP mapping' defined in section 4.4.1.1.
 For example, if the outgoing label corresponds to an L-LSP supporting
 the AF1 PSC, then the following `PHB-->EXP mapping' is added into
 the `Set of PHB-->Encaps mappings':

Le Faucheur, et. al. Standards Track [Page 31] RFC 3270 MPLS Support of Differentiated Services May 2002

       PHB                EXP Field
       AF11       ---->      001
       AF12       ---->      010
       AF13       ---->      011

4.4.1.1 Mandatory `PHB–>EXP mapping'

       PHB                EXP Field
       DF         ---->      000
       CSn        ---->      000
       AFn1       ---->      001
       AFn2       ---->      010
       AFn3       ---->      011
       EF         ---->      000

4.4.2 `PHB–>CLP mapping'

 If the L-LSP is egressing on an ATM interface (i.e., it is an ATM-LSR
 or it is a frame-based LSR sending packets on an LC-ATM interface or
 on an ATM interface which is not label switching controlled), then
 one `PHB-->CLP mapping' is added to the `Set of PHB-->Encaps
 mappings' for this outgoing L-LSP.
 If the L-LSP is egressing over an ATM interface which is not label-
 controlled, the `PHB-->CLP mapping' is populated as per section
 3.4.2.
 If the L-LSP is egressing over an LC-ATM interface, the `PHB-->CLP
 mapping' is populated in the following way:
  1. it is a function of the PSC supported on this LSP, and should use

the relevant mapping entries for this PSC from the Default

    `PHB-->CLP mapping' defined in section 3.4.2.1.
 Notice that if the LSR is a frame-based LSR supporting an L-LSP
 egressing over an ATM interface, then the `Set of PHB-->Encaps
 mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP
 mapping'.  If the LSR is an ATM-LSR supporting an L-LSP, then the
 `Set of PHB-->Encaps mappings' only contains a `PHB-->CLP mapping'.

Le Faucheur, et. al. Standards Track [Page 32] RFC 3270 MPLS Support of Differentiated Services May 2002

4.4.3 `PHB–>DE mapping'

 If the L-LSP is egressing over a Frame Relay interface (i.e., it is
 an LSR sending packets on an LC-FR interface or on a Frame Relay
 interface which is not label switching controlled), one `PHB-->DE
 mapping' is added to the `Set of PHB-->Encaps mappings' for this
 outgoing L-LSP.
 If the L-LSP is egressing over a FR interface which is not label
 switching controlled, the `PHB-->DE mapping' is populated as per
 section 3.4.3.
 If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE
 mapping' is populated in the following way:
  1. it is a function of the PSC supported on this LSP, and should use

the relevant mapping entries for this PSC from the Default

    `PHB-->DE mapping' defined in section 3.4.3.1.
 Notice that if the LSR is an Edge-LSR supporting an L-LSP egressing
 over a LC-FR interface, then the `Set of PHB-->Encaps mappings'
 contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'.  If the
 LSR is a FR-LSR supporting an L-LSP, then the `Set of PHB-->Encaps
 mappings' only contains a `PHB-->DE mapping'.

4.4.4 `PHB–>802.1 mapping'

 If the LSP is egressing over a LAN interface on which multiple 802.1
 Traffic Classes are supported, as defined in [IEEE_802.1], then one
 `PHB-->802.1 mapping' is added as per section 3.4.4.

4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing

  L-LSP
 This section defines how to encode Diff-Serv information into the
 MPLS encapsulation Layer for a transmitted label entry corresponding
 to an outgoing L-LSP.  This requires that the `Set of PHB-->Encaps
 mappings' is populated as defined in section 4.4.
 The LSR first determines the `Set of PHB-->Encaps mappings' of the
 Diff-Serv Context associated with the corresponding label in the
 NHLFE and then performs corresponding encoding as specified in
 sections 3.5.1, 3.5.2, 3.5.3 and 3.5.4.

Le Faucheur, et. al. Standards Track [Page 33] RFC 3270 MPLS Support of Differentiated Services May 2002

4.6 L-LSP Merging

 In an MPLS domain, two or more LSPs can be merged into one LSP at one
 LSR.  L-LSPs are compatible with LSP Merging under the following
 condition:
    L-LSPs can only be merged into one L-LSP if they support the same
    PSC.
 The above merge condition MUST be enforced by LSRs, through explicit
 checking at label setup, that the same PSC is supported on the merged
 LSPs.
 Note that when L-LSPs merge, the bandwidth that is available for the
 PSC downstream of the merge point must be sufficient to carry the sum
 of the merged traffic.  This is particularly important in the case of
 EF traffic.  This can be ensured in multiple ways (for instance via
 provisioning, or via bandwidth signaling and explicit admission
 control).

5. RSVP Extension for Diff-Serv Support

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

5.1 Diff-Serv related RSVP Messages Format

 One new RSVP Object is defined in this document: the DIFFSERV Object.
 Detailed description of this Object is provided below.  This new
 Object is applicable to Path messages.  This specification only
 defines the use of the DIFFSERV Object in Path messages used to
 establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus
 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4
 and containing a LABEL_REQUEST object.
 Restrictions defined in [RSVP_MPLS_TE] for support of the
 establishment of LSP Tunnels via RSVP are also applicable to the
 establishment of LSP Tunnels supporting Diff-Serv: for instance, only
 unicast LSPs are supported and Multicast LSPs are for further study.
 This new DIFFSERV object is optional with respect to RSVP so that
 general RSVP implementations not concerned with MPLS LSP set up do
 not have to support this object.

Le Faucheur, et. al. Standards Track [Page 34] RFC 3270 MPLS Support of Differentiated Services May 2002

 The DIFFSERV Object is optional for support of LSP Tunnels as defined
 in [RSVP_MPLS_TE].  A Diff-Serv capable LSR supporting E-LSPs using
 the preconfigured `EXP<-->PHB mapping' in compliance with this
 specification MAY support the DIFFSERV Object.  A Diff-Serv capable
 LSR supporting E-LSPs using a signaled `EXP<-->PHB mapping' in
 compliance with this specification MUST support the DIFFSERV Object.
 A Diff-Serv capable LSR supporting L-LSPs in compliance with this
 specification MUST support the DIFFSERV Object.

5.1.1 Path Message Format

 The format of the Path message is as follows:
       <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                                <SESSION> <RSVP_HOP>
                                <TIME_VALUES>
                                [ <EXPLICIT_ROUTE> ]
                                <LABEL_REQUEST>
                                [ <SESSION_ATTRIBUTE> ]
                                [ <DIFFSERV> ]
                                [ <POLICY_DATA> ... ]
                                [ <sender descriptor> ]
       <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                                [ <ADSPEC> ]
                                [ <RECORD_ROUTE> ]

5.2 DIFFSERV Object

 The DIFFSERV object formats are shown below.  Currently there are two
 possible C_Types.  Type 1 is a DIFFSERV object for an E-LSP.  Type 2
 is a DIFFSERV object for an L-LSP.

Le Faucheur, et. al. Standards Track [Page 35] RFC 3270 MPLS Support of Differentiated Services May 2002

5.2.1. DIFFSERV object for an E-LSP:

 class = 65, 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved                                       | MAPnb |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (1)                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                               ...                            //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (MAPnb)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Reserved : 28 bits
       This field is reserved.  It must be set to zero on transmission
       and must be ignored on receipt.
    MAPnb : 4 bits
       Indicates the number of MAP entries included in the DIFFSERV
       Object.  This can be set to any value from 0 to 8.
    MAP : 32 bits
       Each MAP entry defines the mapping between one EXP field value
       and one PHB.  The MAP entry has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved     | EXP |             PHBID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Reserved : 13 bits
       This field is reserved.  It must be set to zero on transmission
       and must be ignored on receipt.
    EXP : 3 bits
       This field contains the value of the EXP field for the
       `EXP<-->PHB mapping' defined in this MAP entry.
    PHBID : 16 bits
       This field contains the PHBID of the PHB for the `EXP<-->PHB
       mapping' defined in this MAP entry.  The PHBID is encoded as
       specified in [PHBID].

Le Faucheur, et. al. Standards Track [Page 36] RFC 3270 MPLS Support of Differentiated Services May 2002

5.2.2 DIFFSERV object for an L-LSP:

 class = 65, C_Type = 2
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved               |             PSC               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Reserved : 16 bits
       This field is reserved.  It must be set to zero on transmission
       and must be ignored on receipt.
    PSC : 16 bits
       The PSC indicates a PHB Scheduling Class to be supported by the
       LSP.  The PSC is encoded as specified in [PHBID].

5.3 Handling DIFFSERV Object

 To establish an LSP tunnel with RSVP, the sender creates a Path
 message with a session type of LSP_Tunnel_IPv4 and with a
 LABEL_REQUEST object as per [RSVP_MPLS_TE].
 To establish an E-LSP tunnel with RSVP, which uses the Preconfigured
 `EXP<-->PHB mapping', the sender creates a Path message:
  1. with a session type of LSP_Tunnel_IPv4,
  1. with the LABEL_REQUEST object, and
  1. without the DIFFSERV object.
 To establish an E-LSP tunnel with RSVP, which uses the Preconfigured
 `EXP<-->PHB mapping', the sender MAY alternatively create a Path
 message:
  1. with a session type of LSP_Tunnel_IPv4,
  1. with the LABEL_REQUEST object, and
  1. with the DIFFSERV object for an E-LSP containing no MAP entries.
 To establish an E-LSP tunnel with RSVP, which uses a signaled
 `EXP<-->PHB mapping', the sender creates a Path message:
  1. with a session type of LSP_Tunnel_IPv4,

Le Faucheur, et. al. Standards Track [Page 37] RFC 3270 MPLS Support of Differentiated Services May 2002

  1. with the LABEL_REQUEST object,
  1. with the DIFFSERV object for an E-LSP containing one MAP entry for

each EXP value to be supported on this E-LSP.

 To establish with RSVP an L-LSP tunnel, the sender creates a Path
 message:
  1. with a session type of LSP_Tunnel_IPv4,
  1. with the LABEL_REQUEST object,
  1. with the DIFFSERV object for an L-LSP containing the PHB

Scheduling Class (PSC) supported on this L-LSP.

 If a path message contains multiple DIFFSERV objects, only the first
 one is meaningful; subsequent DIFFSERV object(s) must be ignored and
 not forwarded.
 Each LSR along the path records the DIFFSERV object, when present, in
 its path state block.
 If a DIFFSERV object is not present in the Path message, the LSR
 SHOULD interpret this as a request for an E-LSP using the
 Preconfigured `EXP<-->PHB mapping'.  However, for backward
 compatibility purposes, with other non-Diff-Serv Quality of Service
 options allowed by [RSVP_MPLS_TE] such as Integrated Services
 Controlled Load or Guaranteed Services, the LSR MAY support a
 configurable "override option".  When this "override option" is
 configured, the LSR interprets a path message without a Diff-Serv
 object as a request for an LSP with such non-Diff-Serv Quality of
 Service.
 If a DIFFSERV object for an E-LSP containing no MAP entry is present
 in the Path message, the LSR MUST interpret this as a request for an
 E-LSP using the Preconfigured `EXP<-->PHB mapping'.  In particular,
 this allows an LSR with the "override option" configured to support
 E-LSPs with Preconfigured `EXP<-->PHB mapping', simultaneously with
 LSPs with non-Diff-Serv Quality of Service.
 If a DIFFSERV object for an E-LSP containing at least one MAP entry
 is present in the Path message, the LSR MUST interpret this as a
 request for an E-LSP with signaled `EXP<-->PHB mapping'.
 If a DIFFSERV object for an L-LSP is present in the Path message, the
 LSR MUST interpret this as a request for an L-LSP.

Le Faucheur, et. al. Standards Track [Page 38] RFC 3270 MPLS Support of Differentiated Services May 2002

 The destination LSR of an E-LSP or L-LSP responds to the Path message
 containing the LABEL_REQUEST object by sending a Resv message:
  1. with the LABEL object
  1. without a DIFFSERV object.
 Assuming the label request is accepted and a label is allocated, the
 Diff-Serv LSRs (sender, destination, intermediate nodes) must:
  1. update the Diff-Serv Context associated with the established LSPs

in their ILM/FTN as specified in previous sections (incoming and

    outgoing label),
  1. install the required Diff-Serv forwarding treatment (scheduling

and dropping behavior) for this NHLFE (outgoing label).

 An LSR that recognizes the DIFFSERV object and that receives a path
 message which contains the DIFFSERV object but which does not contain
 a LABEL_REQUEST object or which does not have a session type of
 LSP_Tunnel_IPv4, sends a PathErr towards the sender with the error
 code `Diff-Serv Error' and an error value of `Unexpected DIFFSERV
 object'.  Those are defined below in section 5.5.
 An LSR receiving a Path message with the DIFFSERV object for E-LSP,
 which recognizes the DIFFSERV object but does not support the
 particular PHB encoded in one, or more, of the MAP entries, sends a
 PathErr towards the sender with the error code `Diff-Serv Error' and
 an error value of `Unsupported PHB'.  Those are defined below in
 section 5.5.
 An LSR receiving a Path message with the DIFFSERV object for E-LSP,
 which recognizes the DIFFSERV object but determines that the signaled
 `EXP<-->PHB mapping' is invalid, sends a PathErr towards the sender
 with the error code `Diff-Serv Error' and an error value of Invalid
 `EXP<-->PHB mapping'.  Those are defined below in section 5.5.  `The
 EXP<-->PHB mapping' signaled in the DIFFSERV Object for an E-LSP is
 invalid when:
  1. the MAPnb field is not within the range 0 to 8 or
  1. a given EXP value appears in more than one MAP entry, or
  1. the PHBID encoding is invalid.

Le Faucheur, et. al. Standards Track [Page 39] RFC 3270 MPLS Support of Differentiated Services May 2002

 An LSR receiving a Path message with the DIFFSERV object for L-LSP,
 which recognizes the DIFFSERV object but does not support the
 particular PSC encoded in the PSC field, sends a PathErr towards the
 sender with the error code `Diff-Serv Error' and an error value of
 `Unsupported PSC'.  Those are defined below in section 5.5.
 An LSR receiving a Path message with the DIFFSERV object, which
 recognizes the DIFFSERV object but that is unable to allocate the
 required per-LSP Diff-Serv context sends a PathErr with the error
 code "Diff-Serv Error" and the error value "Per-LSP context
 allocation failure".  Those are defined below in section 5.5.
 A Diff-Serv LSR MUST handle the situations where the label request
 can not be accepted for reasons other than those already discussed in
 this section, in accordance with [RSVP_MPLS_TE] (e.g., reservation
 rejected by admission control, a label can not be associated).

5.4 Non-support of the DIFFSERV Object

 An LSR that does not recognize the DIFFSERV object Class-Num MUST
 behave in accordance with the procedures specified in [RSVP] for an
 unknown Class-Num whose format is 0bbbbbbb i.e., it must send a
 PathErr with the error code `Unknown object class' toward the sender.
 An LSR that recognize the DIFFSERV object Class-Num but does not
 recognize the DIFFSERV object C-Type, must behave in accordance with
 the procedures specified in [RSVP] for an unknown C-type i.e., it
 must send a PathErr with the error code `Unknown object C-Type'
 toward the sender.
 In both situations, this causes the path set-up to fail.  The sender
 should notify management that a L-LSP cannot be established and
 should possibly take action to retry LSP establishment without the
 DIFFSERV object (e.g., attempt to use E-LSPs with Preconfigured
 `EXP<-->PHB mapping' as a fall-back strategy).

5.5 Error Codes For Diff-Serv

 In the procedures described above, certain errors must be reported as
 a `Diff-Serv Error'.  The value of the `Diff-Serv Error' error code
 is 27.

Le Faucheur, et. al. Standards Track [Page 40] RFC 3270 MPLS Support of Differentiated Services May 2002

 The following defines error values for the Diff-Serv Error:
    Value    Error
     1       Unexpected DIFFSERV object
     2       Unsupported PHB
     3       Invalid `EXP<-->PHB mapping'
     4       Unsupported PSC
     5       Per-LSP context allocation failure

5.6 Intserv Service Type

 Both E-LSPs and L-LSPs can be established with or without bandwidth
 reservation.
 As specified in [RSVP_MPLS_TE], to establish an E-LSP or an L-LSP
 with bandwidth reservation, Int-Serv's Controlled Load service (or
 possibly Guaranteed Service) is used and the bandwidth is signaled in
 the SENDER_TSPEC (respectively FLOWSPEC) of the path (respectively
 Resv) message.
 As specified in [RSVP_MPLS_TE],to establish an E-LSP or an L-LSP
 without bandwidth reservation, the Null Service specified in [NULL]
 is used.
 Note that this specification defines usage of E-LSPs and L-LSPs for
 support of the Diff-Serv service only.  Regardless of the Intserv
 service (Controlled Load, Null Service, Guaranteed Service,...) and
 regardless of whether the reservation is with or without bandwidth
 reservation, E-LSPs and L-LSPs are defined here for support of Diff-
 Serv services.  Support of Int-Serv services over an MPLS Diff-Serv
 backbone is outside the scope of this specification.
 Note also that this specification does not concern itself with the
 DCLASS object defined in [DCLASS], since this object conveys
 information on DSCP values, which are not relevant inside the MPLS
 network.

6. LDP Extensions for Diff-Serv Support

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

Le Faucheur, et. al. Standards Track [Page 41] RFC 3270 MPLS Support of Differentiated Services May 2002

 One new LDP TLV is defined in this document:
  1. the Diff-Serv TLV
 Detailed description of this TLV is provided below.
 The new Diff-Serv TLV is optional with respect to LDP.  A Diff-Serv
 capable LSR supporting E-LSPs which uses the Preconfigured `EXP<--
 >PHB mapping' in compliance with this specification MAY support the
 Diff-Serv TLV.  A Diff-Serv capable LSR supporting E-LSPs which uses
 the signaled `EXP<-->PHB mapping' in compliance with this
 specification MUST support the Diff-Serv TLV.  A Diff-Serv capable
 LSR supporting L-LSPs in compliance with this specification MUST
 support the Diff-Serv TLV.

6.1 Diff-Serv TLV

 The Diff-Serv TLV has the following formats:
 Diff-Serv TLV for an E-LSP:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |U|F|  Diff-Serv (0x0901)       |      Length                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |T|        Reserved                                     | MAPnb |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (1)                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (MAPnb)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    T:1 bit
       LSP Type.  This is set to 0 for an E-LSP
    Reserved : 27 bits
       This field is reserved.  It must be set to zero on transmission
       and must be ignored on receipt.
    MAPnb : 4 bits
       Indicates the number of MAP entries included in the DIFFSERV
       Object.  This can be set to any value from 1 to 8.

Le Faucheur, et. al. Standards Track [Page 42] RFC 3270 MPLS Support of Differentiated Services May 2002

    MAP : 32 bits
       Each MAP entry defines the mapping between one EXP field value
       and one PHB.  The MAP entry has the following format:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved     | EXP |             PHBID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Reserved : 13 bits
       This field is reserved.  It must be set to zero on transmission
       and must be ignored on receipt.
    EXP : 3 bits
       This field contains the value of the EXP field for the
       `EXP<-->PHB mapping' defined in this MAP entry.
    PHBID : 16 bits
       This field contains the PHBID of the PHB for the `EXP<-->PHB
       mapping' defined in this MAP entry.  The PHBID is encoded as
       specified in [PHBID].
 Diff-Serv TLV for an L-LSP:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |U|F| Type = PSC (0x0901)       |      Length                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |T|        Reserved             |              PSC              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    T:1 bit
       LSP Type.  This is set to 1 for an L-LSP
    Reserved : 15 bits
       This field is reserved.  It must be set to zero on transmission
       and must be ignored on receipt.
    PSC : 16 bits
       The PSC indicates a PHB Scheduling Class to be supported by the
       LSP.  The PSC is encoded as specified in [PHBID].

Le Faucheur, et. al. Standards Track [Page 43] RFC 3270 MPLS Support of Differentiated Services May 2002

6.2 Diff-Serv Status Code Values

 The following values are defined for the Status Code field of the
 Status TLV:
       Status Code                             E   Status Data
       Unexpected Diff-Serv TLV                0   0x01000001
       Unsupported PHB                         0   0x01000002
       Invalid `EXP<-->PHB mapping'            0   0x01000003
       Unsupported PSC                         0   0x01000004
       Per-LSP context allocation failure      0   0x01000005

6.3 Diff-Serv Related LDP Messages

6.3.1 Label Request Message

 The format of the Label Request message is extended as follows, to
 optionally include the Diff-Serv TLV:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0|   Label Request (0x0401)    |      Message Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Message ID                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     FEC TLV                                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Diff-Serv TLV (optional)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et. al. Standards Track [Page 44] RFC 3270 MPLS Support of Differentiated Services May 2002

6.3.2 Label Mapping Message

 The format of the Label Mapping message is extended as follows, to
 optionally include the Diff-Serv TLV:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0|   Label Mapping (0x0400)    |      Message Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Message ID                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     FEC TLV                                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Label TLV                                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Diff-Serv TLV (optional)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.3 Label Release Message

 The format of the Label Release message is extended as follows, to
 optionally include the Status TLV:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|   Label Release (0x0403)   |      Message Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Message ID                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     FEC TLV                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Label TLV (optional)                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Status TLV (optional)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et. al. Standards Track [Page 45] RFC 3270 MPLS Support of Differentiated Services May 2002

6.3.4 Notification Message

 The format of the Notification message is extended as follows, to
 optionally include the Diff-Serv TLV:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0|   Notification (0x0001)     |      Message Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Message ID                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Status TLV                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Optional Parameters                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Diff-Serv TLV (optional)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.4 Handling of the Diff-Serv TLV

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

 This section describes operations when the Downstream Unsolicited
 Mode is used.
 When allocating a label for an E-LSP which is to use the
 preconfigured `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues
 a Label Mapping message without the Diff-Serv TLV.
 When allocating a label for an E-LSP which is to use a signaled
 `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues a Label
 Mapping message with the Diff-Serv TLV for an E-LSP which contains
 one MAP entry for each EXP value to be supported on this E-LSP.
 When allocating a label for an L-LSP, a downstream Diff-Serv LSR
 issues a Label Mapping message with the Diff-Serv TLV for an L-LSP
 which contains the PHB Scheduling Class (PSC) to be supported on this
 L-LSP.
 Assuming the label set-up is successful, the downstream and upstream
 LSRs must:
  1. update the Diff-Serv Context associated with the established LSPs

in their ILM/FTN as specified in previous sections (incoming and

    outgoing label),

Le Faucheur, et. al. Standards Track [Page 46] RFC 3270 MPLS Support of Differentiated Services May 2002

  1. install the required Diff-Serv forwarding treatment (scheduling

and dropping behavior) for this NHLFE (outgoing label).

 An upstream Diff-Serv LSR receiving a Label Mapping message with
 multiple Diff-Serv TLVs only considers the first one as meaningful.
 The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
 An upstream Diff-Serv LSR which receives a Label Mapping message,
 with the Diff-Serv TLV for an E-LSP and does not support the
 particular PHB encoded in one or more of the MAP entries, must reject
 the mapping by sending a Label Release message which includes the
 Label TLV and the Status TLV with a Status Code of `Unsupported PHB'.
 An upstream Diff-Serv LSR receiving a Label Mapping message with the
 Diff-Serv TLV for an E-LSP and determining that the signaled
 `EXP<-->PHB mapping' is invalid, must reject the mapping by sending a
 Label Release message which includes the Label TLV and the Status TLV
 with a Status Code of Invalid `EXP<-->PHB mapping'.  The
 `EXP<-->PHB mapping' signaled in the DIFFSERV Object for an E-LSP is
 invalid when:
  1. the MAPnb field is not within the range 1 to 8, or
  1. a given EXP value appears in more than one MAP entry, or
  1. the PHBID encoding is invalid
 An upstream Diff-Serv LSR receiving a Label Mapping message with the
 Diff-Serv TLV for an L-LSP containing a PSC value which is not
 supported, must reject the mapping by sending a Label Release message
 which includes the Label TLV and the Status TLV with a Status Code of
 `Unsupported PSC'.

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

 This section describes operations when the Downstream on Demand Mode
 is used.
 When requesting a label for an E-LSP which is to use the
 preconfigured `EXP<-->PHB mapping', an upstream Diff-Serv LSR sends a
 Label Request message without the Diff-Serv TLV.
 When requesting a label for an E-LSP which is to use a signaled
 `EXP<-->PHB mapping', an upstream Diff-Serv LSR sends a Label Request
 message with the Diff-Serv TLV for an E-LSP which contains one MAP
 entry for each EXP value to be supported on this E-LSP.

Le Faucheur, et. al. Standards Track [Page 47] RFC 3270 MPLS Support of Differentiated Services May 2002

 When requesting a label for an L-LSP, an upstream Diff-Serv LSR sends
 a Label Request message with the Diff-Serv TLV for an L-LSP which
 contains the PSC to be supported on this L-LSP.
 A downstream Diff-Serv LSR sending a Label Mapping message in
 response to a Label Request message for an E-LSP or an L-LSP must not
 include a Diff-Serv TLV in this Label Mapping message.  Assuming the
 label set-up is successful, the downstream and upstream LSRs must:
  1. update the Diff-Serv Context associated with the established LSPs

in their ILM/FTN as specified in previous sections (incoming and

    outgoing label),
  1. install the required Diff-Serv forwarding treatment (scheduling

and dropping behavior) for this NHLFE (outgoing label).

 An upstream Diff-Serv LSR receiving a Label Mapping message
 containing a Diff-Serv TLV in response to its Label Request message,
 must reject the label mapping by sending a Label Release message
 which includes the Label TLV and the Status TLV with a Status Code of
 `Unexpected Diff-Serv TLV'.
 A downstream Diff-Serv LSR receiving a Label Request message with
 multiple Diff-Serv TLVs only considers the first one as meaningful.
 The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
 A downstream Diff-Serv LSR which receives a Label Request message
 with the Diff-Serv TLV for an E-LSP and does not support the
 particular PHB encoded in one (or more) of the MAP entries, must
 reject the request by sending a Notification message which includes
 the Status TLV with a Status Code of `Unsupported PHB'.
 A downstream Diff-Serv LSR receiving a Label Request message with the
 Diff-Serv TLV for an E-LSP and determining that the signaled
 `EXP<-->PHB mapping' is invalid, must reject the request by sending a
 Notification message which includes the Status TLV with a Status Code
 of Invalid `EXP<-->PHB mapping'.  The `EXP<-->PHB mapping' signaled
 in the DIFFSERV TLV for an E-LSP is invalid when:
  1. the MAPnb field is not within the range 1 to 8, or
  1. a given EXP value appears in more than one MAP entry, or
  1. the PHBID encoding is invalid

Le Faucheur, et. al. Standards Track [Page 48] RFC 3270 MPLS Support of Differentiated Services May 2002

 A downstream Diff-Serv LSR receiving a Label Request message with the
 Diff-Serv TLV for an L-LSP containing a PSC value which is not
 supported, must reject the request by sending a Notification message
 which includes the Status TLV with a Status Code of `Unsupported
 PSC'.
 A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in
 a Label Request message but is unable to allocate the required per-
 LSP context information, must reject the request sending a
 Notification message which includes the Status TLV with a Status Code
 of `Per-LSP context allocation failure'.
 A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in
 a Label Request message and supports the requested PSC but is not
 able to satisfy the label request for other reasons (e.g., no label
 available), must send a Notification message in accordance with
 existing LDP procedures [LDP] (e.g., with a `No Label Resource'
 Status Code).  This Notification message must include the requested
 Diff-Serv TLV.

6.5 Non-Handling of the Diff-Serv TLV

 An LSR that does not recognize the Diff-Serv TLV Type, on receipt of
 a Label Request message or a Label Mapping message containing the
 Diff-Serv TLV, must behave in accordance with the procedures
 specified in [LDP] for an unknown TLV whose U Bit and F Bit are set
 to 0 i.e., it must ignore the message, return a Notification message
 with `Unknown TLV' Status.

6.6 Bandwidth Information

 Bandwidth information may also be signaled at the establishment time
 of E-LSP and L-LSP, for instance for the purpose of Traffic
 Engineering, using the Traffic Parameters TLV as described in [MPLS
 CR LDP].

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

 Interfaces
 The general operations for MPLS support of Diff-Serv, including label
 forwarding and LSP setup operations are specified in the previous
 sections.  This section describes the specific operations required
 for MPLS support of Diff-Serv over PPP interfaces, LAN interfaces,
 ATM Interfaces which are not label controlled and Frame Relay
 interfaces which are not label controlled.
 On these interfaces, this specification allows any of the following
 LSP combinations per FEC:

Le Faucheur, et. al. Standards Track [Page 49] RFC 3270 MPLS Support of Differentiated Services May 2002

  1. Zero or any number of E-LSP, and
  1. Zero or any number of L-LSPs.
 A Diff-Serv capable LSR MUST support E-LSPs which use preconfigured
 `EXP<-->PHB mapping' over these interfaces.
 A Diff-Serv capable LSR MAY support E-LSPs which use signaled
 `EXP<-->PHB mapping' and L-LSPs over these interfaces.

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

 This section describes the specific operations required for MPLS
 support of Diff-Serv over label switching controlled ATM (LC-ATM)
 interfaces.
 This document allows any number of L-LSPs per FEC within an MPLS ATM
 Diff-Serv domain.  E-LSPs are not supported over LC-ATM interfaces.

8.1 Use of ATM Traffic Classes and Traffic Management mechanisms

 The use of the "ATM service categories" specified by the ATM Forum,
 of the "ATM Transfer Capabilities" specified by the ITU-T or of
 vendor specific ATM traffic classes is outside of the scope of this
 specification.  The only requirement for compliant implementation is
 that the forwarding behavior experienced by a Behavior Aggregate
 forwarded over an L-LSP by the ATM LSR MUST be compliant with the
 corresponding Diff-Serv PHB specifications.
 Since there is only one bit (CLP) for encoding the PHB drop
 precedence value over ATM links, only two different drop precedence
 levels are supported in ATM LSRs.  Sections 4.2.2 and 4.4.2 define
 how the three drop precedence levels of the AFn Ordered Aggregates
 are mapped to these two ATM drop precedence levels.  This mapping is
 in accordance with the requirements specified in [DIFF_AF] for the
 case when only two drop precedence levels are supported.
 To avoid discarding parts of the packets, frame discard mechanisms,
 such as Early Packet Discard (EPD) (see [ATMF_TM]) SHOULD be enabled
 in the ATM-LSRs for all PHBs described in this document.

8.2 LSR Implementation With LC-ATM Interfaces

 A Diff-Serv capable LSR MUST support L-LSPs over LC-ATM interfaces.
 This specification assumes that Edge-LSRs of the ATM-LSR domain use
 the "shim header" encapsulation method defined in [MPLS_ATM].
 Operations without the "shim header" encapsulation are outside the
 scope of this specification.

Le Faucheur, et. al. Standards Track [Page 50] RFC 3270 MPLS Support of Differentiated Services May 2002

9. MPLS Support of Diff-Serv over LC-FR Interfaces

 This section describes the specific operations required for MPLS
 support of Diff-Serv over label switching controlled Frame Relay
 (LC-FR) interfaces.
 This document allows any number of L-LSPs per FEC within an MPLS
 Frame Relay Diff-Serv domain.  E-LSPs are not supported over LC-FR
 interfaces.

9.1 Use of Frame Relay Traffic parameters and Traffic Management

  mechanisms
 The use of the Frame Relay traffic parameters as specified by ITU-T
 and Frame Relay-Forum or of vendor specific Frame Relay traffic
 management mechanisms is outside of the scope of this specification.
 The only requirement for compliant implementation is that the
 forwarding behavior experienced by a Behavior Aggregate forwarded
 over an L-LSP by the Frame Relay LSR MUST be compliant with the
 corresponding Diff-Serv PHB specifications.
 Since there is only one bit (DE) for encoding the PHB drop precedence
 value over Frame Relay links, only two different drop precedence
 levels are supported in Frame Relay LSRs.  Sections 4.2.3 and 4.4.3
 define how the three drop precedence levels of the AFn Ordered
 Aggregates are mapped to these two Frame Relay drop precedence
 levels.  This mapping is in accordance with the requirements
 specified in [DIFF_AF] for the case when only two drop precedence
 levels are supported.

9.2 LSR Implementation With LC-FR Interfaces

 A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay
 interfaces.
 This specification assumes that Edge-LSRs of the FR-LSR domain use
 the "generic encapsulation" method as recommended in [MPLS_FR].
 Operations without the "generic encapsulation" are outside the scope
 of this specification.

Le Faucheur, et. al. Standards Track [Page 51] RFC 3270 MPLS Support of Differentiated Services May 2002

10. IANA Considerations

 This document defines a number of objects with implications for IANA.
 This document defines in section 5.2 a new RSVP object, the DIFFSERV
 object.  This object required a number from the space defined in
 [RSVP] for those objects which, if not understood, cause the entire
 RSVP message to be rejected with an error code of "Unknown Object
 Class".  Such objects are identified by a zero in the most
 significant bit of the class number.  Within that space, this object
 required a number from the "IETF Consensus" space. "65" has been
 allocated by IANA for the DIFFSERV object.
 This document defines in section 5.5 a new RSVP error code, "Diffserv
 Error".  Error code "27" has been assigned by IANA to the "Diffserv
 Error".  This document defines values 1 through 5 of the value field
 to be used within the ERROR_SPEC object for this error code.  Future
 allocations of values in this space should be handled by IANA using
 the First Come First Served policy defined in [IANA].
 This document defines in section 6.1 a new LDP TLV, the Diffserv TLV.
 The number for this TLV has been assigned by working group consensus
 according to the policies defined in [LDP].
 This document defines in section 6.2 five new LDP Status Code values
 for Diffserv-related error conditions.  The values for the Status
 Code have been assigned by working group consensus according to the
 policies defined in [LDP].

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

12. Acknowledgments

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

Le Faucheur, et. al. Standards Track [Page 52] RFC 3270 MPLS Support of Differentiated Services May 2002

APPENDIX A. Example Deployment Scenarios

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

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

  Protection
 A Service Provider running 8 (or fewer) BAs over MPLS, not performing
 Traffic engineering, not using MPLS protection and using MPLS Shim
 Header encapsulation in his/her network, may elect to run Diff-Serv
 over MPLS using a single E-LSP per FEC established via LDP.
 Furthermore the Service Provider may elect to use the preconfigured
 `EXP<-->PHB mapping'.
 Operations can be summarized as follows:
  1. the Service Provider configures at every LSR, the bi-directional

mapping between each PHB and a value of the EXP field

    (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
  1. the Service Provider configures at every LSR, and for every

interface, the scheduling behavior for each PSC (e.g., bandwidth

    allocated to AF1) and the dropping behavior for each PHB (e.g.,
    drop profile for AF11, AF12, AF13)
  1. LSRs signal establishment of a single E-LSP per FEC using LDP in

accordance with the specification above (i.e., no Diff-Serv TLV in

    LDP Label Request/Label Mapping messages to implicitly indicate
    that the LSP is an E-LSP and that it uses the preconfigured
    mapping)

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

  Protection
 A Service Provider running more than 8 BAs over MPLS, not performing
 Traffic Engineering, not using MPLS protection and using MPLS Shim
 encapsulation in his/her network may elect to run Diff-Serv over MPLS
 using for each FEC:
  1. one E-LSP established via LDP and using the preconfigured mapping

to support a set of 8 (or less) BAs, AND

  1. one L-LSP per <FEC,OA> established via LDP for support of the

other BAs.

Le Faucheur, et. al. Standards Track [Page 53] RFC 3270 MPLS Support of Differentiated Services May 2002

 Operations can be summarized as follows:
  1. the Service Provider configures at every LSR the bi-directional

mapping between each PHB and a value of the EXP field for the BAs

    transported over the E-LSP
  1. the Service Provider configures at every LSR, and for every

interface, the scheduling behavior for each PSC supported over the

    E-LSP and the dropping behavior for each corresponding PHB
  1. the Service Provider configures at every LSR, and for every

interface, the scheduling behavior for each PSC supported over the

    L-LSPs and the dropping behavior for each corresponding PHB
  1. LSRs signal establishment of a single E-LSP per FEC for the set of

E-LSP transported BAs using LDP as specified above (i.e., no

    Diff-Serv TLV in LDP Label Request/Label Mapping messages to
    implicitly indicate that the LSP is an E-LSP and that it uses the
    preconfigured mapping)
  1. LSRs signal establishment of one L-LSP per <FEC,OA> for the other

BAs using LDP as specified above (i.e., Diff-Serv TLV in LDP Label

    Request/Label Mapping messages to indicate the L-LSP's PSC).

A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering,

  Aggregate MPLS Protection
 A Service Provider running 8 (or fewer) BAs over MPLS, performing
 aggregate Traffic Engineering (i.e., performing a single common path
 selection for all BAs), using aggregate MPLS protection (i.e.,
 restoring service to all PSCs jointly) and using MPLS Shim Header
 encapsulation in his/her network, may elect to run Diff-Serv over
 MPLS using a single E-LSP per FEC established via RSVP [RSVP_MPLS_TE]
 or CR-LDP [CR-LDP_MPLS_TE] and using the preconfigured mapping.
 Operations can be summarized as follows:
  1. the Service Provider configures at every LSR the bi-directional

mapping between each PHB and a value of the EXP field

    (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
  1. the Service Provider configures at every LSR, and for every

interface, the scheduling behavior for each PSC (e.g., bandwidth

    allocated to AF1) and the dropping behavior for each PHB (eg drop
    profile for AF11, AF12, AF13)
  1. LSRs signal establishment of a single E-LSP per FEC which will use

the preconfigured mapping:

Le Faucheur, et. al. Standards Track [Page 54] RFC 3270 MPLS Support of Differentiated Services May 2002

  • using the RSVP protocol as specified above (i.e., no DIFFSERV

RSVP Object in the PATH message containing the LABEL_REQUEST

       Object), OR
  • using the CR-LDP protocol as specified above (i.e., no Diff-

Serv TLV in LDP Label Request/Label Mapping messages).

  1. protection is activated on all the E-LSPs in order to achieve MPLS

protection via mechanisms outside the scope of this document.

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

 A Service Provider running any number of BAs over MPLS, performing
 per-OA Traffic Engineering (i.e., performing a separate path
 selection for each OA) and performing per-OA MPLS protection (i.e.,
 performing protection with potentially different levels of protection
 for the different OAs) in his/her network, may elect to run Diff-Serv
 over MPLS using one L-LSP per <FEC,OA> pair established via RSVP or
 CR-LDP.
 Operations can be summarized as follows:
  1. the Service Provider configures at every LSR, and for every

interface, the scheduling behavior for each PSC (e.g., bandwidth

    allocated to AF1) and the dropping behavior for each PHB (e.g.,
    drop profile for AF11, AF12, AF13)
  1. LSRs signal establishment of one L-LSP per <FEC,OA>:
  • using the RSVP as specified above to signal the L-LSP's PSC

(i.e., DIFFSERV RSVP Object in the PATH message containing the

       LABEL_REQUEST), OR
  • using the CR-LDP protocol as specified above to signal the L-

LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping

       messages).
  1. the appropriate level of protection is activated on the different

L-LSPs (potentially with a different level of protection for each

    PSC) via mechanisms outside the scope of this document.

Le Faucheur, et. al. Standards Track [Page 55] RFC 3270 MPLS Support of Differentiated Services May 2002

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

  Protection
 A Service Provider running 8 (or fewer) BAs over MPLS, performing
 per-OA Traffic Engineering (i.e., performing a separate path
 selection for each OA) and performing per-OA MPLS protection (i.e.,
 performing protection with potentially different levels of protection
 for the different OAs) in his/her network, may elect to run Diff-Serv
 over MPLS using one E-LSP per <FEC,OA> pair established via RSVP or
 CR-LDP.  Furthermore, the Service Provider may elect to use the
 preconfigured mapping on all the E-LSPs.
 Operations can be summarized as follows:
  1. the Service Provider configures at every LSR the bi-directional

mapping between each PHB and a value of the EXP field

    (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
  1. the Service Provider configures at every LSR, and for every

interface, the scheduling behavior for each PSC (e.g., bandwidth

    allocated to AF1) and the dropping behavior for each PHB (eg drop
    profile for AF11, AF12, AF13)
  1. LSRs signal establishment of one E-LSP per <FEC,OA>:
  • using the RSVP protocol as specified above to signal that the

LSP is an E-LSP which uses the preconfigured mapping (i.e., no

       DIFFSERV RSVP Object in the PATH message containing the
       LABEL_REQUEST), OR
  • using the CR-LDP protocol as specified above to signal that the

LSP is an E-LSP which uses the preconfigured mapping (i.e., no

       Diff-Serv TLV in LDP Label Request/Label Mapping messages)
  1. the Service Provider configures, for each E-LSP, at the head-end

of that E-LSP, a filtering/forwarding criteria so that only the

    packets belonging to a given OA are forwarded on the E-LSP
    established for the corresponding FEC and corresponding OA.
  1. the appropriate level of protection is activated on the different

E-LSPs (potentially with a different level of protection depending

    on the PSC actually transported over each E-LSP) via mechanisms
    outside the scope of this document.

Le Faucheur, et. al. Standards Track [Page 56] RFC 3270 MPLS Support of Differentiated Services May 2002

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

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

support the set of 8 (or fewer) non-traffic-engineered/non-

    protected BAs, AND
  1. one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for

support of the other BAs.

 Operations can be summarized as follows:
  1. the Service Provider configures at every LSR the bi-directional

mapping between each PHB and a value of the EXP field for the BAs

    supported over the E-LSP
  1. the Service Provider configures at every LSR, and for every

interface, the scheduling behavior for each PSC supported over the

    E-LSP and the dropping behavior for each corresponding PHB
  1. the Service Provider configures at every LSR, and for every

interface, the scheduling behavior for each PSC supported over the

    L-LSPs and the dropping behavior for each corresponding PHB
  1. LSRs signal establishment of a single E-LSP per FEC for the non-

traffic engineered BAs using LDP as specified above (i.e., no

    Diff-Serv TLV in LDP Label Request/Label Mapping messages)
  1. LSRs signal establishment of one L-LSP per <FEC,OA> for the other

BAs:

  • using the RSVP protocol as specified above to signal the L-LSP

PSC (i.e., DIFFSERV RSVP Object in the PATH message containing

       the LABEL_REQUEST Object), OR
  • using the CR-LDP protocol as specified above to signal the L-

LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping

       messages).

Le Faucheur, et. al. Standards Track [Page 57] RFC 3270 MPLS Support of Differentiated Services May 2002

  1. protection is not activated on the E-LSPs.
  1. the appropriate level of protection is activated on the different

L-LSPs (potentially with a different level of protection depending

    on the L-LSP's PSC) via mechanisms outside the scope of this
    document.

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

  Protection
 A Service Provider running more than 8 BAs over MPLS, not performing
 Traffic engineering, not performing MPLS protection and using MPLS
 Shim Header encapsulation in his/her network, may elect to run Diff-
 Serv over MPLS using two E-LSPs per FEC established via LDP and using
 signaled `EXP<-->PHB mapping'.
 Operations can be summarized as follows:
  1. the Service Provider configures at every LSR, and for every

interface, the scheduling behavior for each PSC (e.g., bandwidth

    allocated to AF1) and the dropping behavior for each PHB (e.g.,
    drop profile for AF11, AF12, AF13)
  1. LSRs signal establishment of two E-LSPs per FEC using LDP in

accordance with the specification above (i.e., Diff-Serv TLV in

    LDP Label Request/Label Mapping messages to explicitly indicate
    that the LSP is an E-LSP and its `EXP<-->PHB mapping').  The
    signaled mapping will indicate the subset of 8 (or less) BAs to be
    transported on each E-LSP and what EXP values are mapped to each
    BA on each E-LSP.

APPENDIX B. Example Bandwidth Reservation Scenarios

B.1 Scenario 1: No Bandwidth Reservation

 Consider the case where a network administrator elects to:
  1. have Diff-Serv resources entirely provisioned off-line (e.g., via

Command Line Interface, via SNMP, via COPS,…)

  1. have Shortest Path Routing used for all the Diff-Serv traffic.
 This is the closest model to provisioned Diff-Serv over non-MPLS IP.
 In that case, E-LSPs and/or L-LSPs would be established without
 signaled bandwidth.

Le Faucheur, et. al. Standards Track [Page 58] RFC 3270 MPLS Support of Differentiated Services May 2002

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

 Consider the case where a network administrator elects to:
  1. have Diff-Serv resources entirely provisioned off-line (e.g., via

Command Line Interface, via SNMP, via COPS,…)

  1. use L-LSPs
  1. have Constraint Based Routing performed separately for each PSC,

where one of the constraints is availability of bandwidth from the

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

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

  per-PSC Resource Adjustment
 Consider the case where a network administrator elects to:
  1. use L-LSPs
  1. have Constraint Based Routing performed separately for each PSC,

where one of the constraints is availability of bandwidth from the

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

Le Faucheur, et. al. Standards Track [Page 59] RFC 3270 MPLS Support of Differentiated Services May 2002

References

 [ANSI/IEEE]      ANSI/IEEE Std 802.1D, 1993 Edition, incorporating
                  IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992,
                  802.11c-1998, and P802.12e).
 [ATMF_TM]        ATM Forum, "Traffic Management Specification Version
                  4.1", March 1999.
 [CR-LDP_MPLS_TE] Jamoussi, B., Editor, Andersson, L., Callon, R. and
                  R. Dantu, "Constraint-Based LSP Setup using LDP",
                  RFC 3212, January 2002.
 [DCLASS]         Bernet, Y., "Format of the RSVP DCLASS Object", RFC
                  2996, November 2000.
 [DIFF_AF]        Heinanen, J., Baker, F., Weiss, W. and J.
                  Wroclawski, "Assured Forwarding PHB Group", RFC
                  2597, June 1999.
 [DIFF_ARCH]      Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                  Z. and W. Weiss, "An Architecture for Differentiated
                  Services", RFC 2475, December 1998.
 [DIFF_EF]        Davie, B., Charny, A., Baker, F., Bennet, J.,
                  Benson, K., Boudec, J., Chiu, A., Courtney, W.,
                  Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam,
                  K. and D. Stiliadis, "An Expedited Forwarding PHB
                  (Per-Hop Behavior)", RFC 3246, March 2002.
 [DIFF_HEADER]    Nichols, K., Blake, S., Baker, F. and D. Black,
                  "Definition of the Differentiated Services Field (DS
                  Field) in the IPv4 and IPv6 Headers", RFC 2474,
                  December 1998.
 [DIFF_NEW]       Grossman, D., "New Terminology and Clarifications
                  for Diffserv", RFC 3260, April 2002.
 [DIFF_TUNNEL]    Black, D., "Differentiated Services and Tunnels",
                  RFC 2983, October 2000.
 [ECN]            Ramakrishnan, K., Floyd, S. and D. Black, "The
                  Addition of Explicit Congestion Notification (ECN)
                  to IP", RFC 3168, September 2001.
 [IANA]           Narten, T. and H. Alvestrand, "Guidelines for
                  Writing an IANA Considerations Section in RFCs", BCP
                  26, RFC 2434, October 1998.

Le Faucheur, et. al. Standards Track [Page 60] RFC 3270 MPLS Support of Differentiated Services May 2002

 [IEEE_802.1]     ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998
                  Edition (Revision and redesignation of ISO/IEC
                  10038:98.
 [LDP]            Andersson, L., Doolan, D., Feldman, N., Fredette, A.
                  and B. Thomas, "LDP Specification", RFC 3036,
                  January 2001.
 [MPLS_ARCH]      Rosen, E., Viswanathan, A. and R. Callon,
                  "Multiprotocol Label Switching Architecture", RFC
                  3031, January 2001.
 [MPLS_ATM]       Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
                  Swallow, G., Rekhter, Y. and P. Doolan, "MPLS using
                  LDP and ATM VC Switching", RFC 3035, January 2001.
 [MPLS_ENCAPS]    Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                  Farinacci, D., Li, T. and A. Conta, "MPLS Label
                  Stack Encoding", RFC 3032, January 2001.
 [MPLS_FR]        Conta, A., Doolan, P. and A. Malis, "Use of Label
                  Switching on Frame Relay Networks Specification",
                  RFC 3034, January 2001.
 [MPLS_VPN]       Rosen, E., "BGP/MPLS VPNs", Work in Progress.
 [NULL]           Bernet, Y., Smith, A. and B. Davie, "Specification
                  of the Null Service Type", RFC 2997, November 2000.
 [PHBID]          Black, D., Brim, S., Carpenter, B. and F. Le
                  Faucheur, "Per Hop Behavior Identification Codes"
                  RFC 3140, June 2001.
 [RSVP]           Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
                  Jamin, "Resource ReSerVation Protocol (RSVP) -
                  Version 1 Functional Specification", RFC 2205,
                  September 1997.
 [RSVP_MPLS_TE]   Awduche, D., Berger, L., Gan, D., Li, T.,
                  Srinivasan, V. and G. Swallow, "Extensions to RSVP
                  for LSP Tunnels", RFC 3209, December 2001.

Le Faucheur, et. al. Standards Track [Page 61] RFC 3270 MPLS Support of Differentiated Services May 2002

Authors' Addresses

 Francois Le Faucheur
 Cisco Systems
 Village d'Entreprise Green Side - Batiment T3
 400, Avenue de Roumanille
 06410 Biot-Sophia Antipolis
 France
 Phone: +33 4 97 23 26 19
 EMail: flefauch@cisco.com
 Liwen Wu
 Cisco Systems
 3550 Cisco Way
 San Jose, CA 95134
 USA
 Phone: +1 (408) 853-4065
 EMail: liwwu@cisco.com
 Bruce Davie
 Cisco Systems
 250 Apollo Drive, Chelmsford, MA 01824
 USA
 Phone: +1 (978) 244-8000
 EMail: bsd@cisco.com
 Shahram Davari
 PMC-Sierra Inc.
 411 Legget Drive
 Kanata, Ontario K2K 3C9
 Canada
 Phone: +1 (613) 271-4018
 EMail: davari@ieee.org

Le Faucheur, et. al. Standards Track [Page 62] RFC 3270 MPLS Support of Differentiated Services May 2002

 Pasi Vaananen
 Nokia
 3 Burlington Woods Drive, Suit 250
 Burlington, MA 01803
 USA
 Phone +1 (781) 993-4900
 EMail: pasi.vaananen@nokia.com
 Ram Krishnan
 Axiowave Networks
 200 Nickerson Road
 Marlboro, MA 01752
 EMail: ram@axiowave.com
 Pierrick Cheval
 Alcatel
 5 rue Noel-Pons
 92737 Nanterre Cedex
 France
 EMail: pierrick.cheval@space.alcatel.fr
 Juha Heinanen
 Song Networks, Inc.
 Hallituskatu 16
 33200 Tampere, Finland
 EMail: jh@song.fi

Le Faucheur, et. al. Standards Track [Page 63] RFC 3270 MPLS Support of Differentiated Services May 2002

Full Copyright Statement

 Copyright (C) The Internet Society (2002).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Le Faucheur, et. al. Standards Track [Page 64]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3270.txt · Last modified: 2002/05/17 19:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki