Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3270

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

Pages: 64
Proposed Standard
Errata
Updates:  3032
Updated by:  5462
Part 2 of 3 – Pages 22 to 49
First   Prev   Next

Top   ToC   RFC3270 - Page 22   prevText

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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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   ToC   RFC3270 - 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 Section