As per Relevance of the word different, we have this rfc below:
Network Working Group F. Le Faucheur,
Request for Comments: 3270 L.
Category: Standards Track B.
Cisco
S.
PMC-Sierra Inc
P.
R.
Axiowave
P.
J.
Song
May 2002
Multi-Protocol Label Switching (MPLS
Support of Differentiated
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document defines a flexible solution for support
Differentiated Services (Diff-Serv) over Multi-Protocol
Switching (MPLS) networks
This solution allows the MPLS network administrator to select
Diff-Serv Behavior Aggregates (BAs) are mapped onto Label
Paths (LSPs) so that he/she can best match the Diff-Serv,
Engineering and protection objectives within his/her
network. For instance, this solution allows the
administrator to decide whether different sets of BAs are to
mapped onto the same LSP or mapped onto separate LSPs
Le Faucheur, et. al. Standards Track [Page 1]
RFC 3270 MPLS Support of Differentiated Services May 2002
Table of
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6
1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7
1.4 Overall Operations. . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Relationship between Label and FEC. . . . . . . . . . . . . . . 8
1.6 Bandwidth Reservation for E-LSPs and L-LSPs . . . . . . . . . . 8
2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models . 9
2.1 Label Forwarding Model for Diff-Serv LSRs . . . . . . . . . . . 9
2.2 Incoming PHB Determination. . . . . . . . . . . . . . . . . . .10
2.3 Outgoing PHB Determination With Optional Traffic Conditioning .11
2.4 Label Forwarding. . . . . . . . . . . . . . . . . . . . . . . .11
2.5 Encoding Diff-Serv Information Into Encapsulation Layer . . . .13
2.6 Diff-Serv Tunneling Models over MPLS. . . . . . . . . . . . . .13
3. Detailed Operations of E-LSPs. . . . . . . . . . . . . . . . . .22
3.1 E-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .22
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP . .23
3.3 Incoming PHB Determination On Incoming E-LSP. . . . . . . . . .23
3.4 Populating the `Set of PHB-->Encaps mappings' for an
E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
3.5 Encoding Diff-Serv information into Encapsulation Layer
Outgoing E-LSP. . . . . . . . . . . . . . . . . . . . . . . . .26
3.6 E-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .27
4. Detailed Operation of L-LSPs. . . . . . . . . . . . . . . . . .28
4.1 L-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .28
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP . .28
4.3 Incoming PHB Determination On Incoming L-LSP. . . . . . . . . .30
4.4 Populating the `Set of PHB-->Encaps mappings' for an
L-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
4.5 Encoding Diff-Serv Information into Encapsulation Layer
Outgoing L-LSP. . . . . . . . . . . . . . . . . . . . . . . . .33
4.6 L-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .34
5. RSVP Extension for Diff-Serv Support . . . . . . . . . . . . . .34
5.1 Diff-Serv related RSVP Messages Format. . . . . . . . . . . . .34
5.2 DIFFSERV Object . . . . . . . . . . . . . . . . . . . . . . . .35
5.3 Handling DIFFSERV Object. . . . . . . . . . . . . . . . . . . .37
5.4 Non-support of the DIFFSERV Object. . . . . . . . . . . . . . .40
5.5 Error Codes For Diff-Serv . . . . . . . . . . . . . . . . . . .40
5.6 Intserv Service Type. . . . . . . . . . . . . . . . . . . . . .41
6. LDP Extensions for Diff-Serv Support . . . . . . . . . . . . . .41
6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . . .42
6.2 Diff-Serv Status Code Values. . . . . . . . . . . . . . . . . .44
6.3 Diff-Serv Related LDP Messages. . . . . . . . . . . . . . . . .44
6.4 Handling of the Diff-Serv TLV . . . . . . . . . . . . . . . . .46
6.5 Non-Handling of the Diff-Serv TLV . . . . . . . . . . . . . . .49
6.6 Bandwidth Information . . . . . . . . . . . . . . . . . . . . .49
Le Faucheur, et. al. Standards Track [Page 2]
RFC 3270 MPLS Support of Differentiated Services May 2002
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM
Non-LC-FR Interfaces . . . . . . . . . . . . . . . . . . . . . .49
8. MPLS Support of Diff-Serv over LC-ATM Interfaces . . . . . . . .50
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms. .50
8.2 LSR Implementation With LC-ATM Interfaces . . . . . . . . . . .50
9. MPLS Support of Diff-Serv over LC-FR Interfaces. . . . . . . . .51
9.1 Use of Frame Relay Traffic parameters and Traffic
mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . .51
9.2 LSR Implementation With LC-FR Interfaces. . . . . . . . . . . .51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .52
11. Security Considerations . . . . . . . . . . . . . . . . . . . .52
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .52
APPENDIX A. Example Deployment Scenarios. . . . . . . . . . . . . .53
APPENDIX B. Example Bandwidth Reservation Scenarios . . . . . . . .58
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .62
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .64
1.
In an MPLS domain [MPLS_ARCH], when a stream of data traverses
common path, a Label Switched Path (LSP) can be established
MPLS signaling protocols. At the ingress Label Switch Router (LSR),
each packet is assigned a label and is transmitted downstream.
each LSR along the LSP, the label is used to forward the packet
the next hop
In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the
packets crossing a link and requiring the same Diff-Serv behavior
said to constitute a Behavior Aggregate (BA). At the ingress node
the Diff-Serv domain, the packets are classified and marked with
Diff-Serv Code Point (DSCP) which corresponds to their
Aggregate. At each transit node, the DSCP is used to select the
Hop Behavior (PHB) that determines the scheduling treatment and,
some cases, drop probability for each packet
This document specifies a solution for supporting the Diff-
Behavior Aggregates whose corresponding PHBs are currently
(in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network.
solution also offers flexibility for easy support of PHBs that may
defined in the future
This solution relies on the combined use of two types of LSPs
- LSPs which can transport multiple Ordered Aggregates, so that
EXP field of the MPLS Shim Header conveys to the LSR the PHB to
applied to the packet (covering both information about
packet's scheduling treatment and its drop precedence).
Le Faucheur, et. al. Standards Track [Page 3]
RFC 3270 MPLS Support of Differentiated Services May 2002
- LSPs which only transport a single Ordered Aggregate, so that
packet's scheduling treatment is inferred by the LSR
from the packet's label value while the packet's drop
is conveyed in the EXP field of the MPLS Shim Header or in
encapsulating link layer specific selective drop mechanism (ATM
Frame Relay, 802.1).
As mentioned in [DIFF_HEADER], "Service providers are not required
use the same node mechanisms or configurations to enable
differentiation within their networks, and are free to configure
node parameters in whatever way that is appropriate for their
offerings and traffic engineering objectives". Thus, the
defined in this document gives Service Providers flexibility
selecting how Diff-Serv classes of service are Routed or
Engineered within their domain (e.g., separate classes of
supported via separate LSPs and Routed separately, all classes
service supported on the same LSP and Routed together).
Because MPLS is path-oriented it can potentially provide faster
more predictable protection and restoration capabilities in the
of topology changes than conventional hop by hop routed IP systems
In this document we refer to such capabilities as "MPLS protection".
Although such capabilities and associated mechanisms are outside
scope of this specification, we note that they may offer
levels of protection to different LSPs. Since the solution
here allow Service Providers to choose how Diff-Serv classes
services are mapped onto LSPs, the solution also gives
Providers flexibility in the level of protection provided
different Diff-Serv classes of service (e.g., some classes of
can be supported by LSPs which are protected while some other
of service are supported by LSPs which are not protected).
Furthermore, the solution specified in this document achieves
space conservation and reduces the volume of label set-up/tear-
signaling where possible by only resorting to multiple LSPs for
given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful
required
This specification allows support of Differentiated Services for
IPv4 and IPv6 traffic transported over an MPLS network.
document only describes operations for unicast. Multicast support
for future study
The solution described in this document does not preclude
signaled or configured use of the EXP bits to support
Congestion Notification [ECN] simultaneously with Diff-Serv
MPLS. However, techniques for supporting ECN in an MPLS
are outside the scope of this document
Le Faucheur, et. al. Standards Track [Page 4]
RFC 3270 MPLS Support of Differentiated Services May 2002
1.1
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.
The reader is assumed to be familiar with the terminology
[MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR], including
following
FEC Forwarding Equivalency
FTN FEC-To-NHLFE
ILM Incoming Label
LC-ATM Label Switching Controlled-ATM (interface
LC-FR Label Switching Controlled-Frame Relay (interface
LSP Label Switched
LSR Label Switch
MPLS Multi-Protocol Label
NHLFE Next Hop Label Forwarding
The reader is assumed to be familiar with the terminology
[DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF], including
following
AF Assured
BA Behavior
CS Class
DF Default
DSCP Differentiated Services Code
EF Expedited
PHB Per Hop
Le Faucheur, et. al. Standards Track [Page 5]
RFC 3270 MPLS Support of Differentiated Services May 2002
The reader is assumed to be familiar with the terminology
[DIFF_NEW], including the following
OA Ordered Aggregate. The set of Behavior Aggregates
share an ordering constraint
PSC PHB Scheduling Class. The set of one or more PHB(s
that are applied to the Behavior Aggregate(s)
to a given OA. For example, AF1x is a PSC
the AF11, AF12 and AF13 PHBs. EF is an example of
comprising a single PHB, the EF PHB
The following acronyms are also used
CLP Cell Loss
DE Discard
SNMP Simple Network Management
Finally, the following acronyms are defined in this specification
E-LSP EXP-Inferred-PSC
L-LSP Label-Only-Inferred-PSC
1.2 EXP-Inferred-PSC LSPs (E-LSP
A single LSP can be used to support one or more OAs. Such LSPs
support up to eight BAs of a given FEC, regardless of how many
these BAs span. With such LSPs, the EXP field of the MPLS
Header is used by the LSR to determine the PHB to be applied to
packet. This includes both the PSC and the drop preference
We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since
PSC of a packet transported on this LSP depends on the EXP
value for that packet
The mapping from the EXP field to the PHB (i.e., to PSC and
precedence) for a given such LSP, is either explicitly signaled
label set-up or relies on a pre-configured mapping
Detailed operations of E-LSPs are specified in section 3 below
Le Faucheur, et. al. Standards Track [Page 6]
RFC 3270 MPLS Support of Differentiated Services May 2002
1.3 Label-Only-Inferred-PSC LSPs (L-LSP
A separate LSP can be established for a single pair.
such LSPs, the PSC is explicitly signaled at the time of
establishment, so that after label establishment, the LSR can
exclusively from the label value the PSC to be applied to a
packet. When the Shim Header is used, the Drop Precedence to
applied by the LSR to the labeled packet, is conveyed inside
labeled packet MPLS Shim Header using the EXP field. When the
Header is not used (e.g., MPLS Over ATM), the Drop Precedence to
applied by the LSR to the labeled packet is conveyed inside the
layer header encapsulation using link layer specific drop
fields (e.g., ATM CLP).
We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP)
the PSC can be fully inferred from the label without any
information (e.g., regardless of the EXP field value).
operations of L-LSPs are specified in section 4 below
1.4 Overall
For a given FEC, and unless media specific restrictions apply
identified in the sections 7, 8 and 9 below, this
allows any one of the following combinations within an MPLS Diff-
domain
- zero or any number of E-LSPs,
- zero or any number of L-LSPs
The network administrator selects the actual combination of LSPs
the set of allowed combinations and selects how the
Aggregates are actually transported over this combination of LSPs,
order to best match his/her environment and objectives in terms
Diff-Serv support, Traffic Engineering and MPLS Protection.
for selecting such a combination are outside the scope of
specification
For a given FEC, there may be more than one LSP carrying the same OA
for example for purposes of load balancing of the OA; However
order to respect ordering constraints, all packets of a
microflow, possibly spanning multiple BAs of a given
Aggregate, MUST be transported over the same LSP. Conversely,
LSP MUST be capable of supporting all the (active) BAs of a given OA
Examples of deployment scenarios are provided for information
APPENDIX A
Le Faucheur, et. al. Standards Track [Page 7]
RFC 3270 MPLS Support of Differentiated Services May 2002
1.5 Relationship between Label and
[MPLS_ARCH] states in section `2.1. Overview' that: `Some
analyze a packet's network layer header not merely to choose
packet's next hop, but also to determine a packet's "precedence"
"class of service". They may then apply different discard
or scheduling disciplines to different packets. MPLS allows (
does not require) the precedence or class of service to be fully
partially inferred from the label. In this case, one may say
the label represents the combination of a FEC and a precedence
class of service.'
In line with this, we observe that
- With E-LSPs, the label represents the combination of a FEC and
set of BAs transported over the E-LSP. Where all the
BAs are transported over an E-LSP, the label then represents
complete FEC
- With L-LSPs, the label represents the combination of a FEC and
OA
1.6 Bandwidth Reservation for E-LSPs and L-
Regardless of which label binding protocol is used, E-LSPs and L-
may be established with or without bandwidth reservation
Establishing an E-LSP or L-LSP with bandwidth reservation means
bandwidth requirements for the LSP are signaled at LSP
time. Such signaled bandwidth requirements may be used by LSRs
establishment time to perform admission control of the signaled
over the Diff-Serv resources provisioned (e.g., via configuration
SNMP or policy protocols) for the relevant PSC(s). Such
bandwidth requirements may also be used by LSRs at establishment
to perform adjustment to the Diff-Serv resources associated with
relevant PSC(s) (e.g., adjust PSC scheduling weight).
Note that establishing an E-LSP or L-LSP with bandwidth
does not mean that per-LSP scheduling is required. Since E-LSPs
L-LSPs are specified in this document for support of
Services, the required forwarding treatment (scheduling and
policy) is defined by the appropriate Diff-Serv PHB. This
treatment MUST be applied by the LSR at the granularity of the BA
MUST be compliant with the relevant PHB specification
Le Faucheur, et. al. Standards Track [Page 8]
RFC 3270 MPLS Support of Differentiated Services May 2002
When bandwidth requirements are signaled at the establishment of
L-LSP, the signaled bandwidth is obviously associated with the L
LSP's PSC. Thus, LSRs which use the signaled bandwidth to
admission control may perform admission control over Diff-
resources, which are dedicated to the PSC (e.g., over the
guaranteed to the PSC through its scheduling weight).
When bandwidth requirements are signaled at the establishment of
E-LSP, the signaled bandwidth is associated collectively with
whole LSP and therefore with the set of transported PSCs. Thus,
which use the signaled bandwidth to perform admission control
perform admission control over global resources, which are shared
the set of PSCs (e.g., over the total bandwidth of the link).
Examples of scenarios where bandwidth reservation is not used
scenarios where bandwidth reservation is used are provided
information in APPENDIX B
2. Label Forwarding Model for Diff-Serv LSRs and Tunneling
2.1 Label Forwarding Model for Diff-Serv
Since different Ordered Aggregates of a given FEC may be
over different LSPs, the label swapping decision of a Diff-Serv
clearly depends on the forwarded packet's Behavior Aggregate. Also
since the IP DS field of a forwarded packet may not be
visible to an LSR, the way to determine the PHB to be applied to
received packet and to encode the PHB into a transmitted packet,
different than a non-MPLS Diff-Serv Router
Thus, in order to describe Label Forwarding by Diff-Serv LSRs,
model the LSR Diff-Serv label switching behavior, comprised of
stages
- Incoming PHB Determination (A
- Outgoing PHB Determination with Optional Traffic Conditioning(B
- Label Forwarding (C
- Encoding of Diff-Serv information into Encapsulation Layer (EXP
CLP, DE, User_Priority) (D
Each stage is described in more detail in the following sections
Obviously, to enforce the Diff-Serv service differentiation the
MUST also apply the forwarding treatment corresponding to
Outgoing PHB
Le Faucheur, et. al. Standards Track [Page 9]
RFC 3270 MPLS Support of Differentiated Services May 2002
This model is illustrated below
--Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)-->
\ I I \
\---->I===I I C I \-->I===I--Encaps->
I A I I===I--Outg_PHB->I===I I D I (&)
-Encaps->I===I--Inc_PHB->I B I \ /->I===
(*) I===I \--------+
\----Forwarding-->
(PHB
"Encaps" designates the Diff-Serv related information encoded in
MPLS Encapsulation layer (e.g., EXP field, ATM CLP, Frame Relay DE
802.1 User_Priority
(*) when the LSR behaves as an MPLS ingress node, the incoming
may be received unlabelled
(&) when the LSR behaves as an MPLS egress node, the outgoing
may be transmitted unlabelled
This model is presented here to describe the functional operations
Diff-Serv LSRs and does not constrain actual implementation
2.2 Incoming PHB
This stage determines which Behavior Aggregate the received
belongs to
2.2.1 Incoming PHB Determination Considering a Label Stack
Sections 3.3 and 4.3 provide the details on how to perform
PHB Determination considering a given received label stack
and/or received incoming MPLS encapsulation information depending
the incoming LSP type and depending on the incoming
encapsulation
Section 2.6 provides the details of which label stack entry
consider for the Incoming PHB Determination depending on
supported Diff-Serv tunneling mode
2.2.2 Incoming PHB Determination Considering IP
Section 2.6 provides the details of when the IP Header is to
considered for incoming PHB determination, depending on the
Diff-Serv tunneling model. In those cases where the IP header is
Le Faucheur, et. al. Standards Track [Page 10]
RFC 3270 MPLS Support of Differentiated Services May 2002
be used, this stage operates exactly as with a non-MPLS IP Diff-
Router and uses the DS field to determine the incoming PHB
2.3 Outgoing PHB Determination With Optional Traffic
The traffic conditioning stage is optional and may be used on an
to perform traffic conditioning including Behavior Aggregate
or promotion. It is outside the scope of this specification.
the purpose of specifying Diff-Serv over MPLS forwarding, we
note that the PHB to be actually enforced and conveyed to
LSRs by an LSR (referred to as "outgoing PHB"), may be different
the PHB which had been associated with the packet by the previous
(referred to as "incoming PHB").
When the traffic conditioning stage is not present, the "
PHB" is simply identical to the "incoming PHB".
2.4 Label
[MPLS_ARCH] describes how label swapping is performed by LSRs
incoming labeled packets using an Incoming Label Map (ILM),
each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH
also describes how label imposition is performed by LSRs on
unlabelled packets using a FEC-to-NHLFEs Map (FTN), where
incoming FEC is mapped to one or multiple NHLFEs
A Diff-Serv Context for a label is comprised of
- `LSP type (i.e., E-LSP or L-LSP)'
- `supported PHBs
- `Encaps-->PHB mapping' for an incoming
- `Set of PHB-->Encaps mappings' for an outgoing
The present specification defines that a Diff-Serv Context is
in the ILM for each incoming label
[MPLS_ARCH] states that the `NHLFE may also contain any
information needed in order to properly dispose of the packet'.
accordance with this, the present specification defines that a Diff
Serv Context is stored in the NHLFE for each outgoing label that
swapped or pushed
This Diff-Serv Context information is populated into the ILM and
FTN at label establishment time
Le Faucheur, et. al. Standards Track [Page 11]
RFC 3270 MPLS Support of Differentiated Services May 2002
If the label corresponds to an E-LSP for which no `EXP<-->
mapping' has been explicitly signaled at LSP setup, the `
PHBs' is populated with the set of PHBs of the
`EXP<-->PHB mapping', which is discussed below in section 3.2.1.
If the label corresponds to an E-LSP for which an `EXP<-->
mapping' has been explicitly signaled at LSP setup, the `
PHBs' is populated with the set of PHBs of the signaled `EXP<-->
mapping'.
If the label corresponds to an L-LSP, the `supported PHBs'
populated with the set of PHBs forming the PSC that is signaled
LSP set-up
The details of how the `Encaps-->PHB mapping' or `Set of PHB-->
mappings' are populated are defined below in sections 3 and 4.
[MPLS_ARCH] also states that
"If the ILM [respectively, FTN] maps a particular label to a set
NHLFEs that contain more than one element, exactly one element of
set must be chosen before the packet is forwarded. The
for choosing an element from the set are beyond the scope of
document. Having the ILM [respectively, FTN] map a
[respectively, a FEC] to a set containing more than one NHLFE may
useful if, e.g., it is desired to do load balancing over
equal-cost paths."
In accordance with this, the present specification allows that
incoming label [respectively FEC] may be mapped, for Diff-
purposes, to multiple NHLFEs (for instance where different
correspond to egress labels supporting different sets of PHBs).
a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv
MUST choose one of the NHLFEs whose Diff-Serv Context indicates
it supports the Outgoing PHB of the forwarded packet
When a label [respectively FEC] maps to multiple NHLFEs which
the Outgoing PHB, the procedure for choosing one among those
outside the scope of this document. This situation may
encountered where it is desired to do load balancing of a
Aggregate over multiple LSPs. In such situations, in order
respect ordering constraints, all packets of a given microflow
be transported over the same LSP
Le Faucheur, et. al. Standards Track [Page 12]
RFC 3270 MPLS Support of Differentiated Services May 2002
2.5 Encoding Diff-Serv Information Into Encapsulation
This stage determines how to encode the fields which convey Diff-
information in the transmitted packet (e.g., MPLS Shim EXP, ATM CLP
Frame Relay DE, 802.1 User_Priority).
2.5.1 Encoding Diff-Serv Information Into Transmitted Label
Sections 3.5 and 4.5 provide the details on how to perform Diff-
information encoding into a given transmitted label stack
and/or transmitted MPLS encapsulation information depending on
corresponding outgoing LSP type and depending on the
encapsulation
Section 2.6 provides the details in which label stack entry
perform Diff-Serv information encoding into depending on
supported Diff-Serv tunneling mode
2.5.2 Encoding Diff-Serv Information Into Transmitted IP
To perform Diff-Serv Information Encoding into the transmitted
IP header, this stage operates exactly as with a non-MPLS IP Diff
Serv Router and encodes the DSCP of the Outgoing PHB into the
field
Section 2.6 provides the details of when Diff-Serv
Encoding is to be performed into transmitted IP header depending
the supported Diff-Serv tunneling mode
2.6 Diff-Serv Tunneling Models over
2.6.1 Diff-Serv Tunneling
[DIFF_TUNNEL] considers the interaction of Differentiated
with IP tunnels of various forms. MPLS LSPs are not a form of "
tunnels" since the MPLS encapsulating header does not contain an
header and thus MPLS LSPs are not considered in [DIFF_TUNNEL].
However, although not a form of "IP tunnel", MPLS LSPs are a form
"tunnel".
From the Diff-Serv standpoint, LSPs share a number of
characteristics with IP Tunnels
- Intermediate nodes (i.e., Nodes somewhere along the LSP span)
see and operate on the "outer" Diff-Serv information
- LSPs are unidirectional
Le Faucheur, et. al. Standards Track [Page 13]
RFC 3270 MPLS Support of Differentiated Services May 2002
- The "outer" Diff-Serv information can be modified at any of
intermediate nodes
However, from the Diff-Serv standpoint, LSPs also have a
property compared to IP Tunnels
- There is generally no behavior analogous to Penultimate
Popping (PHP) used with IP Tunnels. Furthermore, PHP results
the "outer" Diff-Serv information associated with the LSP
being visible to the LSP egress. In situations where
information is not meaningful at the LSP Egress, this is
not an issue at all. In situations where this information
meaningful at the LSP Egress, then it must somehow be carried
some other means
The two conceptual models for Diff-Serv tunneling over IP
defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv
MPLS but their respective detailed operations is somewhat
over MPLS. These two models are the Pipe Model and the
Model. Their operations over MPLS are specified in the
sections. Discussion and definition of alternative tunneling
are outside the scope of this specification
2.6.2 Pipe
With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide
intermediate MPLS nodes between LSP Ingress and Egress from
Diff-Serv perspective
In this model, tunneled packets must convey two meaningful pieces
Diff-Serv information
- the Diff-Serv information which is meaningful to
nodes along the LSP span including the LSP Egress (which we
to as the "LSP Diff-Serv Information"). This LSP Diff-
Information is not meaningful beyond the LSP Egress:
Traffic Conditioning at intermediate nodes on the LSP span
the LSP Diff-Serv information or not, this updated Diff-
information is not considered meaningful beyond the LSP Egress
is ignored
- the Diff-Serv information which is meaningful beyond the
Egress (which we refer to as the "Tunneled Diff-
Information"). This information is to be conveyed by the
Ingress to the LSP Egress. This Diff-Serv information is
meaningful to the intermediate nodes on the LSP span
Le Faucheur, et. al. Standards Track [Page 14]
RFC 3270 MPLS Support of Differentiated Services May 2002
Operation of the Pipe Model without PHP is illustrated below
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E (M*)
(M) represents the "LSP Diff-Serv information
(m) represents the "Tunneled Diff-Serv information
(*) The LSP Egress considers the LSP Diff-Serv information
in the outer header (i.e., before the pop) in order to apply
Diff-Serv forwarding treatment (i.e., actual PHB
I represents the LSP ingress
E represents the LSP egress
With the Pipe Model, the "LSP Diff-Serv Information" needs to
conveyed to the LSP Egress so that it applies its
treatment based on it. The "Tunneled Diff-Serv information"
needs to be conveyed to the LSP Egress so it can be conveyed
downstream
Since both require that Diff-Serv information be conveyed to the
Egress, the Pipe Model operates only without PHP
The Pipe Model is particularly appropriate for environments in which
- the cloud upstream of the incoming interface of the LSP
and the cloud downstream of the outgoing interface of the
Egress are in Diff-Serv domains which use a common set of Diff
Serv service provisioning policies and PHB definitions, while
LSP spans one (or more) Diff-Serv domain(s) which use(s)
different set of Diff-Serv service provisioning policies and
- the outgoing interface of the LSP Egress is in the (last) Diff
Serv domain spanned by the LSP
As an example, consider the case where a service provider is
an MPLS VPN service (see [MPLS_VPN] for an example of MPLS
architecture) including Diff-Serv differentiation. Say that
collection of sites is interconnected via such an MPLS VPN service
Now say that this collection of sites is managed under a
administration and is also supporting Diff-Serv
differentiation. If the VPN site administration and the
Le Faucheur, et. al. Standards Track [Page 15]
RFC 3270 MPLS Support of Differentiated Services May 2002
Provider are not sharing the exact same Diff-Serv policy (
instance not supporting the same number of PHBs), then operation
Diff-Serv in the Pipe Model over the MPLS VPN service would allow
VPN Sites Diff-Serv policy to operate consistently throughout
ingress VPN Site and Egress VPN Site and transparently over
Service Provider Diff-Serv domain. It may be useful to view
LSPs as linking the Diff-Serv domains at their endpoints into
single Diff-Serv region by making these endpoints
contiguous even though they may be physically separated
intermediate network nodes
The Pipe Model MUST be supported
For support of the Pipe Model over a given LSP without PHP, an
performs the Incoming PHB Determination and the Diff-Serv
Encoding in the following manner
- when receiving an unlabelled packet, the LSR performs Incoming
Determination considering the received IP Header
- when receiving a labeled packet, the LSR performs Incoming
Determination considering the outer label entry in the
label stack. In particular, when a pop operation is to
performed for the considered LSP, the LSR performs Incoming
Determination BEFORE the pop
- when performing a push operation for the considered LSP, the LSR
o encodes Diff-Serv Information corresponding to the OUTGOING
in the transmitted label entry corresponding to the
label
o encodes Diff-Serv Information corresponding to the INCOMING
in the encapsulated header (swapped label entry or IP header).
- when performing a swap-only operation for the considered LSP,
LSR encodes Diff-Serv Information in the transmitted label
that contains the swapped
- when performing a pop operation for the considered LSP, the
does not perform Encoding of Diff-Serv Information into the
exposed by the pop operation (i.e., the LSR leaves the
header "as is").
2.6.2.1 Short Pipe
The Short Pipe Model is an optional variation of the Pipe
described above. The only difference is that, with the Short
Le Faucheur, et. al. Standards Track [Page 16]
RFC 3270 MPLS Support of Differentiated Services May 2002
Model, the Diff-Serv forwarding treatment at the LSP Egress
applied based on the "Tunneled Diff-Serv Information" (i.e., Diff
Serv information conveyed in the encapsulated header) rather than
the "LSP Diff-Serv information" (i.e., Diff-Serv information
in the encapsulating header).
Operation of the Short Pipe Model without PHP is illustrated below
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header)
(M) represents the "LSP Diff-Serv information
(m) represents the "Tunneled Diff-Serv information
I represents the LSP ingress
E represents the LSP egress
Since the LSP Egress applies its forwarding treatment based on
"Tunneled Diff-Serv Information", the "LSP Diff-Serv information
does not need to be conveyed by the penultimate node to the
Egress. Thus the Short Pipe Model can also operate with PHP
Operation of the Short Pipe Model with PHP is illustrated below
=========== LSP ============================>
---Swap--(M)--...--Swap------
/ (outer header) \
(M) (M
/ \
>--(m)-Push.................(m).............Pop-(m)--E--(m)-->
I (inner header) P (M*)
(M) represents the "LSP Diff-Serv information
(m) represents the "Tunneled Diff-Serv information
(*) The Penultimate LSR considers the LSP Diff-Serv
received in the outer header (i.e., before the pop) in order
apply its Diff-Serv forwarding treatment (i.e., actual PHB
I represents the LSP ingress
P represents the LSP penultimate
E represents the LSP egress
Le Faucheur, et. al. Standards Track [Page 17]
RFC 3270 MPLS Support of Differentiated Services May 2002
The Short Pipe Model is particularly appropriate for environments
which
- the cloud upstream of the incoming interface of the LSP
and the cloud downstream of the outgoing interface of the
Egress are in Diff-Serv domains which use a common set of Diff
Serv service provisioning policies and PHB definitions, while
LSP spans one (or more) Diff-Serv domain(s) which use(s)
different set of Diff-Serv service provisioning policies and
- the outgoing interface of the LSP Egress is in the same Diff-
domain as the cloud downstream of it
Since each outgoing interface of the LSP Egress is in the same Diff
Serv domain as the cloud downstream of it, each outgoing
may potentially be in a different Diff-Serv domain, and the
Egress needs to be configured with awareness of every
Diff-Serv policy. This operational overhead is justified in
situations where the respective downstream Diff-Serv policies
better suited to offering service differentiation over each
interface than the common Diff-Serv policy used on the LSP span.
example of such a situation is where a Service Provider offers
MPLS VPN service and where some VPN users request that their own
Diff-Serv policy be applied to control service differentiation on
dedicated link from the LSP Egress to the destination VPN site
rather than the Service Provider's Diff-Serv policy
The Short Pipe Model MAY be supported
For support of the Short Pipe Model over a given LSP without PHP,
LSR performs the Incoming PHB Determination and the Diff-
information Encoding in the same manner as with the Pipe Model
the following exception
- when receiving a labeled packet, the LSR performs Incoming
Determination considering the header (label entry or IP header
which is used to do the actual forwarding. In particular, when
pop operation is to be performed for the considered LSP, the
performs Incoming PHB Determination AFTER the pop
For support of the Short Pipe Model over a given LSP with PHP, an
performs Incoming PHB Determination and Diff-Serv
Encoding in the same manner as without PHP with the
exceptions
Le Faucheur, et. al. Standards Track [Page 18]
RFC 3270 MPLS Support of Differentiated Services May 2002
- the Penultimate LSR performs Incoming PHB
considering the outer label entry in the received label stack.
other words, when a pop operation is to be performed for
considered LSP, the Penultimate LSR performs Incoming
Determination BEFORE the pop
Note that the behavior of the Penultimate LSR in the Short Pipe
with PHP, is identical to the behavior of the LSP Egress in the
Mode (necessarily without PHP).
2.6.3 Uniform
With the Uniform Model, MPLS tunnels (aka LSPs) are viewed
artifacts of the end-to-end path from the Diff-Serv standpoint.
Tunnels may be used for forwarding purposes but have no
impact on Diff-Serv. In this model, any packet contains exactly
piece of Diff-Serv information which is meaningful and is
encoded in the outer most label entry (or in the IP DSCP where the
packet is transmitted unlabelled for instance at the egress of
LSP). Any Diff-Serv information encoded somewhere else (e.g.,
deeper label entries) is of no significance to intermediate nodes
to the tunnel egress and is ignored. If Traffic Conditioning
intermediate nodes on the LSP span affects the "outer" Diff-
information, the updated Diff-Serv information is the one
meaningful at the egress of the LSP
Operation of the Uniform Model without PHP is illustrated below
========== LSP =============================>
---Swap--(M)--...-Swap--(M)--Swap----
/ (outer header) \
(M) (M
/ \
>--(M)--Push...............(x).......................Pop--(M)->
I (inner header)
(M) represents the Meaningful Diff-Serv information encoded in
corresponding header
(x) represents non-meaningful Diff-Serv information
I represents the LSP ingress
E represents the LSP egress
Le Faucheur, et. al. Standards Track [Page 19]
RFC 3270 MPLS Support of Differentiated Services May 2002
Operation of the Uniform Model with PHP is illustrated below
========== LSP =========================>
---Swap-(M)-...-Swap------
/ (outer header) \
(M) (M
/ \
>--(M)--Push..............(x)............Pop-(M)--E--(M)->
I (inner header)
(M) represents the Meaningful Diff-Serv information encoded in
corresponding header
(x) represents non-meaningful Diff-Serv information
I represents the LSP ingress
P represents the LSP penultimate
E represents the LSP egress
The Uniform Model for Diff-Serv over MPLS is such that, from
Diff-Serv perspective, operations are exactly identical to
operations if MPLS was not used. In other words, MPLS is
transparent to the Diff-Serv operations
Use of the Uniform Model allows LSPs to span Diff-Serv
boundaries without any other measure in place than an inter-
Traffic Conditioning Agreement at the physical boundary between
Diff-Serv domains and operating exclusively on the "outer" header
since the meaningful Diff-Serv information is always visible
modifiable in the outmost label entry
The Uniform Model MAY be supported
For support of the Uniform Model over a given LSP, an LSR
Incoming PHB Determination and Diff-Serv information Encoding in
following manner
- when receiving an unlabelled packet, the LSR performs Incoming
Determination considering the received IP Header
- when receiving a labeled packet, the LSR performs Incoming
Determination considering the outer label entry in the
label stack. In particular, when a pop operation is to
performed for the considered LSP, the LSR performs Incoming
Determination BEFORE the pop
Le Faucheur, et. al. Standards Track [Page 20]
RFC 3270 MPLS Support of Differentiated Services May 2002
- when performing a push operation for the considered LSP, the
encodes Diff-Serv Information in the transmitted label
corresponding to the pushed label. The Diff-Serv
encoded in the encapsulated header (swapped label entry or
Header) is of no importance
- when performing a swap-only operation for the considered LSP,
LSR encodes Diff-Serv Information in the transmitted label
that contains the swapped label
- when PHP is used, the Penultimate LSR needs to be aware of
"Set of PHB-->Encaps mappings" for the label corresponding to
exposed header (or the `PHB-->DSCP mapping') in order to
Diff-Serv Information Encoding. Methods for providing
mapping awareness are outside the scope of this specification.
an example, the "PHB-->DSCP mapping" may be locally configured
As another example, in some environments, it may be
for the Penultimate LSR to assume that the "Set of PHB-->
mappings" to be used for the outgoing label in the exposed
is the "Set of PHB-->Encaps mappings" that would be used by
LSR if the LSR was not doing PHP. Note also that
specification assumes that the Penultimate LSR does not
label swapping over the label entry exposed by the pop
(and in fact that it does not even look at the exposed label).
Consequently, restrictions may apply to the Diff-Serv
Encoding that can be performed by the Penultimate LSR.
example, this specification does not allow situations where
Penultimate LSR pops a label corresponding to an E-LSP
two PSCs, while the header exposed by the pop contains
values for two L-LSPs each supporting one PSC, since the Diff-
Information Encoding would require selecting one label or
other
Note that LSR behaviors for the Pipe, the Short Pipe and the
Model only differ when doing a push or a pop. Thus,
LSRs which perform swap only operations for an LSP, behave in
the same way, regardless of whether they are behaving in the Pipe
Short Pipe or the Uniform model. With a Diff-Serv
supporting multiple Tunneling Models, only LSRs behaving as
Ingress, Penultimate LSR or LSP Egress need to be configured
operate in a particular Model. Signaling to associate a Diff-
tunneling model on a per-LSP basis is not within the scope of
specification
Le Faucheur, et. al. Standards Track [Page 21]
RFC 3270 MPLS Support of Differentiated Services May 2002
2.6.4
Through the label stack mechanism, MPLS allows LSP tunneling to
to any depth. We observe that with such nesting, the push of
N+1 takes place on a subsequent (or the same) LSR to the LSR
the push for level N, while the pop of level N+1 takes place on
previous (or the same) LSR to the LSR doing the pop of level N.
a given level N LSP, the Ingress LSR doing the push and the LSR
the pop (Penultimate LSR or LSP Egress) must operate in the
Tunneling Model (i.e., Pipe, Short Pipe or Uniform). However,
is no requirement for consistent tunneling models across levels
that LSPs at different levels may be operating in different
Models
Hierarchical operations are illustrated below in the case of
levels of tunnels
+--------Swap--...---+
/ (outmost header) \
/ \
Push(2).................(2)
/ (outer header) \
/ \
>>---Push(1)........................(1)Pop-->>
(inner header
(1) Tunneling Model 1
(2) Tunneling Model 2
Tunneling Model 2 may be the same as or may be different
Tunneling Model 1.
For a given LSP of level N, the LSR must perform the Incoming
Determination and the Diff-Serv information Encoding as specified
section 2.6.2, 2.6.2.1 and 2.6.3 according to the Tunneling Model
this level N LSP and independently of the Tunneling Model of
level LSPs
3. Detailed Operations of E-
3.1 E-LSP
E-LSPs are defined in section 1.2.
Within a given MPLS Diff-Serv domain, all the E-LSPs relying on
pre-configured mapping are capable of transporting the same
set of 8, or fewer, BAs. Each of those E-LSPs may actually
this full set of BAs or any arbitrary subset of it
Le Faucheur, et. al. Standards Track [Page 22]
RFC 3270 MPLS Support of Differentiated Services May 2002
For a given FEC, two given E-LSPs using a signaled `EXP<-->
mapping' can support the same or different sets of
Aggregates
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-
This section defines how the `Encaps-->PHB mapping' of the Diff-
Context is populated for an incoming E-LSP in order to allow
PHB determination
The `Encaps-->PHB mapping' for an E-LSP is always of the
`EXP-->PHB mapping'.
If the label corresponds to an E-LSP for which no `EXP<-->
mapping' has been explicitly signaled at LSP setup, the `EXP-->
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<-->
mapping' has been explicitly signaled at LSP setup, the `EXP-->
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<-->
mapping' must allow local configuration of this `EXP<-->PHB mapping'.
This mapping applies to all the E-LSPs established on this
without a mapping explicitly signaled at set-up time
The preconfigured `EXP<-->PHB mapping' must either be consistent
every E-LSP hop throughout the MPLS Diff-Serv domain spanned by
LSP or appropriate remarking of the EXP field must be performed
the LSR whenever a different preconfigured mapping is used on
ingress and egress interfaces
In case, the preconfigured `EXP<-->PHB mapping' has not actually
configured by the Network Administrator, the LSR should use a
preconfigured `EXP<-->PHB mapping' which maps all EXP values to
Default PHB
3.3 Incoming PHB Determination On Incoming E-
This section defines how Incoming PHB Determination is carried
when the considered label entry in the received label
corresponds to an E-LSP. This requires that the `Encaps-->
mapping' is populated as defined in section 3.2.
Le Faucheur, et. al. Standards Track [Page 23]
RFC 3270 MPLS Support of Differentiated Services May 2002
When considering a label entry corresponding to an incoming E-LSP
Incoming PHB Determination, the LSR
- determines the `EXP-->PHB mapping' by looking up the `Encaps-->
mapping' of the Diff-Serv Context associated in the ILM with
considered incoming E-LSP label
- determines the incoming PHB by looking up the EXP field of
considered label entry in the `EXP-->PHB mapping' table
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-
This section defines how the `Set of PHB-->Encaps mappings' of
Diff-Serv Context is populated at label setup for an outgoing E-
in order to allow Encoding of Diff-Serv information in
Encapsulation Layer
3.4.1 `PHB-->EXP mapping
An outgoing E-LSP must always have a `PHB-->EXP mapping' as part
the `Set of PHB-->Encaps mappings' of its Diff-Serv Context
If the label corresponds to an E-LSP for which no `EXP<-->
mapping' has been explicitly signaled at LSP setup, this `PHB-->
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<-->
mapping' has been explicitly signaled at LSP setup, the `PHB-->
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
switching controlled, then one `PHB-->CLP mapping' is added to
`Set of PHB-->Encaps mappings' for this outgoing LSP.
`PHB-->CLP mapping' is populated in the following way
- it is a function of the PHBs supported on this LSP, and may
the relevant mapping entries for these PHBs from the
`PHB-->CLP mapping' defined in section 3.4.2.1. Mappings
than the one defined in section 3.4.2.1 may be used.
particular, if a mapping from PHBs to CLP is standardized in
future for operations of Diff-Serv over ATM, such a
mapping may then be used
Le Faucheur, et. al. Standards Track [Page 24]
RFC 3270 MPLS Support of Differentiated Services May 2002
For example if the outgoing label corresponds to an LSP
the AF1 PSC, then the `PHB-->CLP mapping' may be populated with
PHB CLP
AF11 ----> 0
AF12 ----> 1
AF13 ----> 1
EF ----> 0
Notice that in this case the `Set of PHB-->Encaps mappings'
both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'.
3.4.2.1 Default `PHB-->CLP mapping
PHB CLP
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
label switching controlled, one `PHB-->DE mapping' is added to
`Set of PHB-->Encaps mappings' for this outgoing LSP and is
in the following way
- it is a function of the PHBs supported on this LSP, and may
the relevant mapping entries for these PHBs from the
`PHB-->DE mapping' defined in section 3.4.3.1. Mappings
than the one defined in section 3.4.3.1 may be used.
particular, if a mapping from PHBs to DE is standardized in
future for operations of Diff-Serv over Frame Relay, such
standardized mapping may then be used
Notice that in this case the `Set of PHB-->Encaps mappings'
both a `PHB-->EXP mapping' and a `PHB-->DE mapping'.
Le Faucheur, et. al. Standards Track [Page 25]
RFC 3270 MPLS Support of Differentiated Services May 2002
3.4.3.1 `Default PHB-->DE mapping
PHB DE
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
`PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings
for this outgoing LSP. This `PHB-->802.1 mapping' is populated
the following way
- it is a function of the PHBs supported on this LSP, and uses
relevant mapping entries for these PHBs from the
`PHB-->802.1 mapping' defined in section 3.4.4.1.
Notice that the `Set of PHB-->Encaps mappings' then contains both
`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
standardized mapping from PHBs to 802.1 Traffic Classes
Consequently, an LSR supporting multiple 802.1 Traffic Classes
LAN interfaces must allow local configuration of a `PHB-->802.1
mapping'. This mapping applies to all the outgoing LSPs
by the LSR on such LAN interfaces
3.5 Encoding Diff-Serv information into Encapsulation Layer On
E-
This section defines how to encode Diff-Serv information into
MPLS encapsulation Layer for a given transmitted label
corresponding to an outgoing E-LSP. This requires that the `Set
PHB-->Encaps mappings' be populated as defined in section 3.4.
The LSR first determines the `Set of PHB-->Encaps mappings' of
Diff-Serv Context associated with the corresponding label in
NHLFE
Le Faucheur, et. al. Standards Track [Page 26]
RFC 3270 MPLS Support of Differentiated Services May 2002
3.5.1 `PHB-->EXP mapping
If the `Set of PHB-->Encaps mappings' contains a mapping of the
`PHB-->EXP mapping', then the LSR
- determines the value to be written in the EXP field of
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
`PHB-->CLP mapping', then the LSR
- determines the value to be written in the CLP field of the
encapsulation header, by looking up the "outgoing PHB" in
`PHB-->CLP mapping' table
3.5.3 `PHB-->DE mapping
If the `Set of PHB-->Encaps mappings' contains a mapping of the
`PHB-->DE mapping', then the LSR
- determines the value to be written in the DE field of the
Relay encapsulation header, by looking up the "outgoing PHB"
this `PHB-->DE mapping' table
3.5.4 `PHB-->802.1 mapping
If the `Set of PHB-->Encaps mappings' contains a mapping of the
`PHB-->802.1 mapping', then the LSR
- determines the value to be written in the User_Priority field
the Tag Control Information of the 802.1 encapsulation
[IEEE_802.1], by looking up the "outgoing PHB" in this 'PHB--
>802.1 mapping' table
3.6 E-LSP
In an MPLS domain, two or more LSPs can be merged into one LSP at
LSR. E-LSPs are compatible with LSP Merging under the
condition
E-LSPs can only be merged into one LSP if they support the
same set of BAs
Le Faucheur, et. al. Standards Track [Page 27]
RFC 3270 MPLS Support of Differentiated Services May 2002
For E-LSPs using a signaled `EXP<-->PHB mapping', the above
condition MUST be enforced by LSRs through explicit checking at
setup that the exact same set of PHBs is supported on the
LSPs
For E-LSPs using the preconfigured `EXP<-->PHB mapping', since
PHBs supported over an E-LSP is not signaled at establishment time
an LSR can not rely on signaling information to enforce the
merge. However all E-LSPs using the preconfigured `EXP<-->
mapping' are required to support the same set of Behavior
within a given MPLS Diff-Serv domain. Thus, merging of E-LSPs
the preconfigured `EXP<-->PHB mapping' is allowed within a given
Diff-Serv domain
4. Detailed Operation of L-
4.1 L-LSP
L-LSPs are defined in section 1.3.
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-
This section defines how the `Encaps-->PHB mapping' of the Diff-
Context is populated at label setup for an incoming L-LSP in order
allow Incoming PHB determination
4.2.1 `EXP-->PHB mapping
If the LSR terminates the MPLS Shim Layer over this incoming L-
and the L-LSP ingresses on an interface which is not ATM nor
Relay, then the `Encaps-->PHB mapping' is populated in the
way
- it is actually a `EXP-->PHB mapping
- this mapping is a function of the PSC which is carried on
LSP, and must use the relevant mapping entries for this PSC
the Mandatory `EXP/PSC-->PHB mapping' defined in Section 4.2.1.1.
For example if the incoming label corresponds to an L-LSP
the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with
EXP Field
001 ----> AF11
010 ----> AF12
011 ----> AF13
Le Faucheur, et. al. Standards Track [Page 28]
RFC 3270 MPLS Support of Differentiated Services May 2002
An LSR, supporting L-LSPs over PPP interfaces and LAN interfaces,
an example of an LSR terminating the Shim layer over
interfaces which are not ATM nor Frame Relay
If the LSR terminates the MPLS Shim Layer over this incoming L-
and the L-LSP ingresses on an ATM or Frame Relay interface, then
`Encaps-->PHB mapping' is populated in the following way
- it should actually be a `EXP-->PHB mapping'. Alternative
ways of populating the `Encaps-->PHB mapping' might be defined
the future (e.g., using a 'CLP/EXP--> PHB mapping' or
'DE/EXP-->PHB mapping') but are outside the scope of
document
- when the `Encaps-->PHB mapping' is an `EXP-->PHB mapping',
`EXP-->PHB mapping' mapping is a function of the PSC which
carried on the L-LSP, and must use the relevant mapping
for this PSC from the Mandatory `EXP/PSC-->PHB mapping' defined
Section 4.2.1.1.
An Edge-LSR of an ATM-MPLS domain or of a FR-MPLS domain is
example of an LSR terminating the shim layer over an ingress ATM/
interface
4.2.1.1 Mandatory `EXP/PSC --> PHB mapping
EXP Field PSC
000 DF ---->
000 CSn ---->
001 AFn ----> AFn
010 AFn ----> AFn
011 AFn ----> AFn
000 EF ---->
4.2.2 `CLP-->PHB mapping
If the LSR does not terminate an MPLS Shim Layer over this
label and uses ATM encapsulation (i.e., it is an ATM-LSR), then
`Encaps-->PHB mapping' for this incoming L-LSP is populated in
following way
- it is actually a `CLP-->PHB mapping
- the mapping is a function of the PSC, which is carried on
LSP, and should use the relevant mapping entries for this PSC
the Default `CLP/PSC-->PHB mapping' defined in Section 4.2.2.1.
Le Faucheur, et. al. Standards Track [Page 29]
RFC 3270 MPLS Support of Differentiated Services May 2002
For example if the incoming label corresponds to an L-LSP
the AF1 PSC, then the `Encaps-->PHB mapping' should be
with
CLP Field
0 ----> AF11
1 ----> AF12
4.2.2.1 Default `CLP/PSC --> PHB mapping
CLP Bit PSC
0 DF ---->
0 CSn ---->
0 AFn ----> AFn
1 AFn ----> AFn
0 EF ---->
4.2.3 `DE-->PHB mapping
If the LSR does not terminate an MPLS Shim Layer over this
label and uses Frame Relay encapsulation (i.e., it is a FR-LSR),
the `Encaps-->PHB mapping' for this incoming L-LSP is populated
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
Default `DE/PSC-->PHB mapping' defined in Section 4.2.3.1.
4.2.3.1 Default `DE/PSC --> PHB mapping
DE Bit PSC
0 DF ---->
0 CSn ---->
0 AFn ----> AFn
1 AFn ----> AFn
0 EF ---->
4.3 Incoming PHB Determination On Incoming L-
This section defines how Incoming PHB determination is carried
when the considered label entry in the received label
corresponds to an L-LSP. This requires that the `Encaps-->
mapping' is populated as defined in section 4.2.
Le Faucheur, et. al. Standards Track [Page 30]
RFC 3270 MPLS Support of Differentiated Services May 2002
When considering a label entry corresponding to an incoming L-
for Incoming PHB Determination, the LSR first determines
`Encaps-->PHB mapping' associated with the corresponding label
