RFC3270 - Multi-Protocol Label Switching (MPLS) Support of D(2)

时间:2005-02-17 来源: 作者: 点击:
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
  
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 ----> 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.

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 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

The general operations for MPLS support of Diff-Serv, including label
forwarding and LSP setup operations are specified in the previous
sections. This section describes the specific operations required
for MPLS support of Diff-Serv over PPP interfaces, LAN interfaces,
ATM Interfaces which are not label controlled and Frame Relay
interfaces which are not label controlled.

On these interfaces, this specification allows any of the following
LSP combinations per FEC:

- Zero or any number of E-LSP, and

- Zero or any number of L-LSPs.

A Diff-Serv capable LSR MUST support E-LSPs which use preconfigured
`EXP<-->PHB mapping' over these interfaces.

A Diff-Serv capable LSR MAY support E-LSPs which use signaled
`EXP<-->PHB mapping' and L-LSPs over these interfaces.

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

This section describes the specific operations required for MPLS
support of Diff-Serv over label switching controlled ATM (LC-ATM)
interfaces.

This document allows any number of L-LSPs per FEC within an MPLS ATM
Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces.

8.1 Use of ATM Traffic Classes and Traffic Management mechanisms

The use of the "ATM service categories" specified by the ATM Forum,
of the "ATM Transfer Capabilities" specified by the ITU-T or of
vendor specific ATM traffic classes is outside of the scope of this
specification. The only requirement for compliant implementation is
that the forwarding behavior experienced by a Behavior Aggregate
forwarded over an L-LSP by the ATM LSR MUST be compliant with the
corresponding Diff-Serv PHB specifications.

Since there is only one bit (CLP) for encoding the PHB drop
precedence value over ATM links, only two different drop precedence
levels are supported in ATM LSRs. Sections 4.2.2 and 4.4.2 define
how the three drop precedence levels of the AFn Ordered Aggregates
are mapped to these two ATM drop precedence levels. This mapping is
in accordance with the requirements specified in [DIFF_AF] for the
case when only two drop precedence levels are supported.

To avoid discarding parts of the packets, frame discard mechanisms,
such as Early Packet Discard (EPD) (see [ATMF_TM]) SHOULD be enabled
in the ATM-LSRs for all PHBs described in this document.

8.2 LSR Implementation With LC-ATM Interfaces

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

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

This section describes the specific operations required for MPLS
support of Diff-Serv over label switching controlled Frame Relay
(LC-FR) interfaces.

This document allows any number of L-LSPs per FEC within an MPLS
Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR
interfaces.

9.1 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms

The use of the Frame Relay traffic parameters as specified by ITU-T
and Frame Relay-Forum or of vendor specific Frame Relay traffic
management mechanisms is outside of the scope of this specification.
The only requirement for compliant implementation is that the
forwarding behavior experienced by a Behavior Aggregate forwarded
over an L-LSP by the Frame Relay LSR MUST be compliant with the
corresponding Diff-Serv PHB specifications.

Since there is only one bit (DE) for encoding the PHB drop precedence
value over Frame Relay links, only two different drop precedence
levels are supported in Frame Relay LSRs. Sections 4.2.3 and 4.4.3
define how the three drop precedence levels of the AFn Ordered
Aggregates are mapped to these two Frame Relay drop precedence
levels. This mapping is in accordance with the requirements
specified in [DIFF_AF] for the case when only two drop precedence
levels are supported.

9.2 LSR Implementation With LC-FR Interfaces

A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay
interfaces.

This specification assumes that Edge-LSRs of the FR-LSR domain use
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容