tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3270

 
 
 

Multi-Protocol Label Switching (MPLS) Support of Differentiated Services

Part 2 of 3, p. 22 to 49
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 22 
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.

Top      Up      ToC       Page 23 
   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.

Top      Up      ToC       Page 24 
   When considering a label entry corresponding to an incoming E-LSP for
   Incoming PHB Determination, the LSR:

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

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

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

Top      Up      ToC       Page 25 
   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:

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

Top      Up      ToC       Page 26 
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:

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

Top      Up      ToC       Page 27 
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:

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

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

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

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

Top      Up      ToC       Page 28 
   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:

   -  it is actually a `EXP-->PHB mapping'

   -  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

Top      Up      ToC       Page 29 
   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:

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

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

   -  it is actually a `CLP-->PHB mapping'

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

Top      Up      ToC       Page 30 
   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:

   -  it is actually a `DE-->PHB mapping'

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

Top      Up      ToC       Page 31 
   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:

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

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

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

   -  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':

Top      Up      ToC       Page 32 
         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:

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

Top      Up      ToC       Page 33 
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:

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

Top      Up      ToC       Page 34 
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.

Top      Up      ToC       Page 35 
   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.

Top      Up      ToC       Page 36 
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].

Top      Up      ToC       Page 37 
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:

   -  with a session type of LSP_Tunnel_IPv4,

   -  with the LABEL_REQUEST object, and

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

   -  with a session type of LSP_Tunnel_IPv4,

   -  with the LABEL_REQUEST object, and

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

   -  with a session type of LSP_Tunnel_IPv4,

Top      Up      ToC       Page 38 
   -  with the LABEL_REQUEST object,

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

   -  with a session type of LSP_Tunnel_IPv4,

   -  with the LABEL_REQUEST object,

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

Top      Up      ToC       Page 39 
   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:

   -  with the LABEL object

   -  without a DIFFSERV object.

   Assuming the label request is accepted and a label is allocated, the
   Diff-Serv LSRs (sender, destination, intermediate nodes) must:

   -  update the Diff-Serv Context associated with the established LSPs
      in their ILM/FTN as specified in previous sections (incoming and
      outgoing label),

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

   -  the MAPnb field is not within the range 0 to 8 or

   -  a given EXP value appears in more than one MAP entry, or

   -  the PHBID encoding is invalid.

Top      Up      ToC       Page 40 
   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.

Top      Up      ToC       Page 41 
   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.

Top      Up      ToC       Page 42 
   One new LDP TLV is defined in this document:

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

Top      Up      ToC       Page 43 
      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].

Top      Up      ToC       Page 44 
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)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 45 
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)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 46 
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:

   -  update the Diff-Serv Context associated with the established LSPs
      in their ILM/FTN as specified in previous sections (incoming and
      outgoing label),

Top      Up      ToC       Page 47 
   -  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:

   -  the MAPnb field is not within the range 1 to 8, or

   -  a given EXP value appears in more than one MAP entry, or

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

Top      Up      ToC       Page 48 
   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:

   -  update the Diff-Serv Context associated with the established LSPs
      in their ILM/FTN as specified in previous sections (incoming and
      outgoing label),

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

   -  the MAPnb field is not within the range 1 to 8, or

   -  a given EXP value appears in more than one MAP entry, or

   -  the PHBID encoding is invalid

Top      Up      ToC       Page 49 
   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].



(page 49 continued on part 3)

Next RFC Part