RFC 3270
Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
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.
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.
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.
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'.
3.4.3.1 `Default PHB-->DE mapping'
PHB DE Bit DF ----> 0 CSn ----> 0 AFn1 ----> 0 AFn2 ----> 1 AFn3 ----> 1 EF ----> 03.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.
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.
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
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.
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.
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':
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'.
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.
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.
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.
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].
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,
- 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.
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.
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.
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.
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.
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].
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 0x010000056.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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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),
- 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.
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
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)
