draft-ietf-mpls-diff-ext-02.txt   draft-ietf-mpls-diff-ext-03.txt 
skipping to change at line 18 skipping to change at line 19
Pasi Vaananen Pasi Vaananen
Nokia Nokia
Ram Krishnan Ram Krishnan
Nexabit Networks Nexabit Networks
Pierrick Cheval Pierrick Cheval
Alcatel Alcatel
Juha Heinanen
Telia Finland
IETF Internet Draft IETF Internet Draft
Expires: April, 2000 Expires: October, 2000
Document: draft-ietf-mpls-diff-ext-02.txt October, 1999 Document: draft-ietf-mpls-diff-ext-03.txt February, 2000
MPLS Support of Differentiated Services MPLS Support of Differentiated Services
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
Working documents of the Internet Engineering Task Force (IETF), its Working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at line 49 skipping to change at line 53
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines a flexible solution for support of This document defines a flexible solution for support of
Differentiated Services (Diff-Serv) over Multi-Protocol Label Differentiated Services (Diff-Serv) over Multi-Protocol Label
Switching (MPLS) networks. Switching (MPLS) networks.
This solution allows the MPLS network administrator to flexibly
define how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label
Switched Paths so that he/she can best match the Diff-Serv, Traffic
Le Faucheur, et. al 1 Le Faucheur, et. al 1
MPLS Support of Diff-Serv October 99 MPLS Support of Diff-Serv February 00
This solution allows the MPLS network administrator to select how
Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched
Paths so that he/she can best match the Diff-Serv, Traffic
Engineering and Fast Restoration objectives within his/her Engineering and Fast Restoration objectives within his/her
particular network. For instance, this solution allows the network particular network. For instance, this solution allows the network
administrator to decide whether different sets of BAs are to be administrator to decide whether different sets of BAs are to be
mapped onto the same LSP or mapped onto separate LSPs. mapped onto the same LSP or mapped onto separate LSPs.
This solution relies on combined use of two types of LSPs: This solution relies on combined use of two types of LSPs:
- LSPs where both the Behavior Aggregate's scheduling treatment - LSPs which can transport multiple Ordered Aggregates, so that
and its drop precedence are conveyed to the LSR in the EXP field of the EXP field of the MPLS Shim Header conveys to the LSR the PHB
the MPLS Shim Header. to be applied to the packet (covering both information about the
- LSPs where the Behavior Aggregate's scheduling treatment is packet's scheduling treatment and its drop precedence).
inferred by the LSR from the packet's label value while the Behavior - LSPs which only transport a single Ordered Aggregate, so that
Aggregate's drop precedence is indicated in the EXP field of the the packet's scheduling treatment is inferred by the LSR
MPLS Shim Header or in the encapsulating link layer specific exclusively from the packet's label value while the packet's
selective drop mechanism (ATM, Frame Relay, 802.1). drop precedence is conveyed in the EXP field of the MPLS Shim
Header or in the encapsulating link layer specific selective
drop mechanism (ATM, Frame Relay, 802.1).
1. Introduction 1. Introduction
In an MPLS domain [MPLS_ARCH], when a stream of data traverses a In an MPLS domain [MPLS_ARCH], when a stream of data traverses a
common path, a Label Switched Path (LSP) can be established using common path, a Label Switched Path (LSP) can be established using
MPLS signaling protocols. At the ingress Label Switch Router (LSR), MPLS signaling protocols. At the ingress Label Switch Router (LSR),
each packet is assigned a label and is transmitted downstream. At each packet is assigned a label and is transmitted downstream. At
each LSR along the LSP, the label is used to forward the packet to each LSR along the LSP, the label is used to forward the packet to
the next hop. the next hop.
skipping to change at line 92 skipping to change at line 97
IP packets crossing a link and requiring the same Diff-Serv behavior IP packets crossing a link and requiring the same Diff-Serv behavior
are said to constitute a Behavior Aggregate (BA). At the ingress are said to constitute a Behavior Aggregate (BA). At the ingress
node of the Diff-Serv domain the packets are classified and marked node of the Diff-Serv domain the packets are classified and marked
with a Diff-Serv Code Point (DSCP) which corresponds to their with a Diff-Serv Code Point (DSCP) which corresponds to their
Behavior Aggregate. At each transit node, the DSCP is used to select Behavior Aggregate. At each transit node, the DSCP is used to select
the Per Hop Behavior (PHB) that determines the scheduling treatment the Per Hop Behavior (PHB) that determines the scheduling treatment
and, in some cases, drop probability for each packet. and, in some cases, drop probability for each packet.
This document specifies a solution for supporting the Diff-Serv This document specifies a solution for supporting the Diff-Serv
Behavior Aggregates whose corresponding PHBs are currently defined Behavior Aggregates whose corresponding PHBs are currently defined
(in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This
solution also offers flexibility for easy support of PHBs that may
be defined in the future.
As mentioned in [DIFF_HEADER], "Service providers are not required As mentioned in [DIFF_HEADER], "Service providers are not required
to use the same node mechanisms or configurations to enable service to use the same node mechanisms or configurations to enable service
differentiation within their networks, and are free to configure the differentiation within their networks, and are free to configure the
node parameters in whatever way that is appropriate for their node parameters in whatever way that is appropriate for their
service offerings and traffic engineering objectives". Thus, the service offerings and traffic engineering objectives". Thus, the
solution defined in this document gives Service Providers solution defined in this document gives Service Providers
flexibility in selecting how Diff-Serv classes of service are Routed flexibility in selecting how Diff-Serv classes of service are Routed
or Traffic Engineered within their domain (eg. separate classes of
services supported via separate LSPs and Routed separately, all
classes of service supported on the same LSP and Routed or Traffic
Engineered together). Similarly, the solution gives Service
Providers flexibility in how Diff-Serv classes of service can be
protected via MPLS Fast Restoration (eg. some classes of service
supported via LSPs which are protected via MPLS Fast Restoration
Le Faucheur et. al 2 Le Faucheur et. al 2
MPLS Support of Diff-Serv October 99 MPLS Support of Diff-Serv February 00
while some other classes of service are supported via LSPs which are or Traffic Engineered within their domain (eg. separate classes of
not protected). services supported via separate LSPs and Routed separately, all
classes of service supported on the same LSP and Routed together).
Similarly, the solution gives Service Providers flexibility in how
Diff-Serv classes of service can be protected via MPLS Fast
Restoration (eg. some classes of service supported via LSPs which
are protected via MPLS Fast Restoration while some other classes of
service are supported via LSPs which are not protected).
Beside, the solution specified in this document achieves label space Beside, the solution specified in this document achieves label space
conservation and reduces the volume of label set-up/tear-down conservation and reduces the volume of label set-up/tear-down
signaling where possible by only mandating set-up of multiple LSPs signaling where possible by only resorting to multiple LSPs for a
for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or
useful or required. required.
This specification allows support of Differentiated Services for
both IPv4 and IPv6 traffic transported over an MPLS network.
This document only describes operations for unicast. Multicast
support is for future study
1.1 Ordered Aggregate (OA) and PHB Scheduling Class (PSC) 1.1 Ordered Aggregate (OA) and PHB Scheduling Class (PSC)
The Diff-Serv model defines [APPENDIX A] the set of Behavior The Diff-Serv model defines [DIFF_NEW] the set of Behavior
Aggregates which share an ordering constraint to constitute an Aggregates which share an ordering constraint to constitute an
"Ordered Aggregate (OA)". It also defines the set of one or more "Ordered Aggregate (OA)". It also defines the set of one or more
PHBs applied to the set of Behavior Aggregates forming a given OA, PHBs that are applied to this set of Behavior Aggregates to
as a "PHB Scheduling Class (PSC)". constitute a "PHB Scheduling Class (PSC)".
1.2 EXP-Inferred-PSC LSPs (E-LSP) 1.2 EXP-Inferred-PSC LSPs (E-LSP)
Section 2 below specifies how a single LSP can be used to support up A single LSP can be used to support up to eight BAs of a given FEC,
to eight BAs, regardless of how many OAs these BAs span. With such regardless of how many OAs these BAs span. With such LSPs, the EXP
LSPs, the packet DSCP value gets entirely mapped into the EXP field field of the MPLS Shim Header [MPLS_ENCAPS] is used by the LSR to
of the MPLS Shim Header [MPLS_ENCAPS] at the Edge of the MPLS Diff- determine the PHB to be applied to the packet. This includes both
Serv Cloud (thus encoding both drop precedence and PSC/scheduling the PSC and the drop preference.
information). In other words, both PSC and Drop Precedence are
conveyed in each labeled packet using the EXP field of the MPLS Shim
Header [MPLS_ENCAPS].
We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP). Detailed We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the
operations of E-LSPs are specified in section 2 below. PSC of a packet transported on this LSP depends on the EXP field
value for that packet.
E-LSPs have the following benefits: The mapping from EXP field to PHB (ie to PSC and drop precedence)
- label space is conserved by allowing "packing" of up to eight for a given such LSP, is either explicitly signaled at label set-up
BAs per label (eg. when there are fewer than eight BAs in the or relying on a pre-configured mapping.
network, this method maintains the same label space as in a non
Diff-Serv capable MPLS network).
- label establishment signaling is then reduced since a single
LSP is established for up to eight BAs (eg. when there are fewer
than eight BAs in the network, this method maintains the same level
of signaling as in a non-Diff-Serv capable MPLS network)
- the amount of forwarding state is also reduced, as a single
forwarding entry can support up to 8 BAs.
- operation of Diff-Serv MPLS over E-LSPs is analogous to
operations of Diff-Serv in non-MPLS networks in the sense that the
Diff-Serv PHB is triggered exclusively by a field explicitly encoded
in every packet based on locally configured PHB mapping. This is
expected to facilitate migration from non-MPLS Diff-Serv to MPLS
Diff-Serv operations in some networks.
- some early implementations of E-LSPs exist today and
experiments have confirmed proper operations and usefulness.
E-LSPs only allow support of eight BAs or less. Detailed operations of E-LSPs are specified in section 3 below.
Le Faucheur et. al 3 1.3 Label-Only-Inferred-PSC LSPs (L-LSP)
MPLS Support of Diff-Serv October 99 A separate LSP can be established for a single <FEC, OA> pair.
1.3 Label-Inferred-PSC LSPs (L-LSP) Le Faucheur et. al 3
Section 3 below specifies how a separate LSP can be established for MPLS Support of Diff-Serv February 00
each <FEC, OA> pair between two LSR neighbors.
With such LSPs, the PSC is explicitly signaled at label With such LSPs, the PSC is explicitly signaled at label
establishment time so that, after label establishment, the LSR can establishment time so that, after label establishment, the LSR can
infer from the label value the PSC to be applied to a labeled infer exclusively from the label value the PSC to be applied to a
packet. When the Shim Header is used, the Drop Precedence to be labeled packet. When the Shim Header is used, the Drop Precedence to
applied by the LSR to the labeled packet is conveyed inside the be applied by the LSR to the labeled packet, is conveyed inside the
labeled packet MPLS Shim Header using the EXP field [MPLS_ENCAPS]. labeled packet MPLS Shim Header using the EXP field [MPLS_ENCAPS].
When the Shim Header is not used (eg. MPLS Over ATM), the Drop When the Shim Header is not used (eg. MPLS Over ATM), the Drop
Precedence to be applied by the LSR to the labeled packet is Precedence to be applied by the LSR to the labeled packet is
conveyed inside the link layer header encapsulating the labeled conveyed inside the link layer header encapsulation using link layer
packet using link layer specific drop precedence (eg. Cell Loss specific drop precedence fields (eg. ATM Cell Loss Priority).
Priority).
We refer to such LSPs as "Label-Inferred-PSC LSPs" (L-LSP). Detailed
operations of L-LSPs are specified in section 3 below.
L-LSPs allow support of any number of Behavior Aggregates.
L-LSPs have the following drawbacks: We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP)
- they require the use of a separate label for support of each since the PSC can be fully inferred from the label without any other
PSC, and information (eg. regardless of the EXP field value). Detailed
- they require more signaling operations to set up the operations of L-LSPs are specified in section 4 below.
corresponding L-LSPs.
1.4 Overall Operations 1.4 Overall Operations
For a given FEC, and unless media specific restrictions apply as For a given FEC, and unless media specific restrictions apply as
identified in the corresponding sections below (eg. `MPLS Support of identified in the sections 7, 8, 9 and 10 below, this specification
Diff-Serv by ATM LSRs'), this specification allows any one of the allows any one of the following combinations within an MPLS Diff-
following set of combinations within an MPLS Diff-Serv domain: Serv domain:
- zero or any number of E-LSPs, and - zero or any number of E-LSPs, and
- zero or any number of L-LSPs. - zero or any number of L-LSPs.
The network administrator selects the actual combination from the The network administrator selects the actual combination of LSPs
set of allowed combinations in order to best match his/her from the set of allowed combinations and selects how the Behavior
environment and objectives in terms of Diff-Serv support, Traffic Aggregates are actually transported over this combination of LSPs,
Engineering and Fast Restoration. in order to best match his/her environment and objectives in terms
of Diff-Serv support, Traffic Engineering and Fast Restoration.
Criteria for selecting such a combination are outside the scope of
this specification; However in order to respect ordering
constraints, all packets of a given microflow, possibly spanning
multiple BAs of a given Ordered Aggregate, MUST be transported over
the same LSP. Conversely, each LSP MUST be capable of supporting all
the (active) PHBs of a given PSC.
Examples of deployment scenarios are provided for information in Examples of deployment scenarios are provided for information in
APPENPIX B. APPENPIX A.
1.5 Label Forwarding Model for Diff-Serv LSRs
In order to describe Label Forwarding by Diff-Serv LSRs, we model
the LSR Diff-Serv label switching behavior as comprising three
stages:
-A- incoming PHB and FEC determination
Le Faucheur et. al 4
MPLS Support of Diff-Serv October 99
-B- Optional outgoing PHB determination via Local Policy and
Traffic Conditioning
-C- Outgoing EXP(and possibly CLP/DE) and label determination,
enforcement of outgoing PHB's forwarding behavior
This model is used below for specifying LSR Label Forwarding using
L-LSPs and E-LSPs for Diff-Serv support over MPLS.
1.6 Relationship between Label and FEC 1.5 Relationship between Label and FEC
[MPLS_ARCH] states in section `2.1. Overview' that: [MPLS_ARCH] states in section `2.1. Overview' that:
`Some routers analyze a packet's network layer header not merely to `Some routers analyze a packet's network layer header not merely to
choose the packet's next hop, but also to determine a packet's choose the packet's next hop, but also to determine a packet's
"precedence" or "class of service". They may then apply different "precedence" or "class of service". They may then apply different
discard thresholds or scheduling disciplines to different packets. discard thresholds or scheduling disciplines to different packets.
MPLS allows (but does not require) the precedence or class of MPLS allows (but does not require) the precedence or class of
service to be fully or partially inferred from the label. In this service to be fully or partially inferred from the label. In this
case, one may say that the label represents the combination of a FEC case, one may say that the label represents the combination of a FEC
and a precedence or class of service.' and a precedence or class of service.'
Le Faucheur et. al 4
MPLS Support of Diff-Serv February 00
In line with this, we observe that: In line with this, we observe that:
- With E-LSPs, the label represents the combination of a FEC - With E-LSPs, the label represents the combination of a FEC and
and the set of E-LSP transported Behavior Aggregates (BAs). Where the set of Behavior Aggregates (BAs) transported over the E-
all the MPLS supported BAs are transported over E-LSPs, the label LSP). Where all the supported BAs are transported over an E-LSP,
then represents the complete FEC. the label then represents the complete FEC.
- With L-LSPs, the label represents the combination of a FEC - With L-LSPs, the label represents the combination of a FEC and
and an Ordered Aggregate (OA). an Ordered Aggregate (OA).
2. Detailed Operations of E-LSPs 2. Label Forwarding Model for Diff-Serv LSRs
2.1 E-LSP Establishment Since different Ordered Aggregates of a given FEC may be transported
over different LSPs, the label swapping decision of a Diff-Serv LSR
clearly depends on the forwarded packet's Behavior Aggregate. Also,
since the IP DS field of a forwarded packet may not be directly
visible to an LSR, the way to determine the PHB to be applied to a
received packet and to encode the PHB into a transmitted packet is
different to a non-MPLS Diff-Serv Router.
In order to describe Label Forwarding by Diff-Serv LSRs, we model
the LSR Diff-Serv label switching behavior as comprising four
stages:
- Incoming PHB Determination (A)
- Optional Outgoing PHB Determination via Local Policy and Traffic
Conditioning (B)
- Label Swapping (C)
- Encoding of Diff-Serv information into Encapsulation Layer
(EXP,CLP,DE,User_Priority) (D)
Obviously, to enforce the Diff-Serv service differentiation the LSR
MUST also apply the forwarding treatment corresponding to the
Outgoing PHB.
This model is illustrated below:
--Inc_label(*)--------------------------->I===I---Outg_label (**)-->
\ 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===I \--------/
`Encaps' designates the Diff-Serv related information encoded in the
MPLS Encapsulation layer (eg EXP field, ATM CLP, Frame Relay DE,
802.1 User_Priority)
(*) when the LSR performs label imposition, the incoming packet is
received unlabelled.
Le Faucheur et. al 5
MPLS Support of Diff-Serv February 00
(**) when the LSR performs label disposition, the outgoing packet is
transmitted unlabelled.
This model is presented here to illustrate operations of Diff-Serv
LSRs and does not constrain actual implementation.
2.1 Incoming PHB Determination
This stage determines which Behavior Aggregate the received packet
belongs to.
2.1.1 Incoming PHB Determination for received labelled packets
This specification defines one default method for this determination
which allows for regular support of Diff-Serv over MPLS. This method
considers only the outer encapsulation (ie outer label entry or ATM
encapsulation or Frame Relay encapsulation) and ignores other label
entries which may be present in the stack. It combines:
- the Diff-Serv context associated with the incoming label and
stored in the Incoming Label Map (ILM). See section 2.3 below
for details on information comprising the Diff-Serv context.
- the Diff-Serv related information that is encoded in the
corresponding encapsulation layer (ie in EXP field of MPLS Shim
layer or in CLP/DE field of the link layer encapsulation) of the
received label packet.
The details of this method depend on the incoming LSP type and on
the incoming MPLS encapsulation and are defined below in sections
3.3 and 4.3.
Support for this default method is mandatory for compliance to this
specification.
Optionally, other methods for Incoming PHB Determination may also be
supported. Other methods may take into account other information in
addition to, or instead of, the information used by the mandatory
method. For instance, other method could take into account the DS
field of the encapsulated packet or the EXP field of a label header
deeper in the label stack. Such methods are beyond the scope of this
specification.
2.1.2 Incoming PHB Determination for received unlabelled packets
For packets received unlabelled, this stage operates exactly as with
a non-MPLS IP Diff-Serv Router and uses the DS field.
2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning
This stage of Diff-Serv label switching is optional and may be used
on an LSR to perform traffic conditioning including Behavior
Aggregate demotion or promotion. It is outside the scope of this
Le Faucheur et. al 6
MPLS Support of Diff-Serv February 00
specification. For the purpose of specifying Diff-Serv over MPLS
forwarding, we simply note that the PHB to be actually enforced, and
conveyed to downstream LSRs, by an LSR (referred to as "outgoing
PHB") may be different to the PHB which had been associated with the
packet by the previous LSR (referred to as "incoming PHB").
When this stage is not present, the "outgoing PHB" is simply
identical to the "incoming PHB".
For packets received unlabelled, this stage operates as with a non-
MPLS IP Diff-Serv Router.
2.3 Label Swapping
[MPLS_ARCH] describes how label swapping is performed by LSRs on
incoming labeled packets using an Incoming Label Map (ILM), where
each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH]
also describes how label imposition is performed by LSRs on incoming
unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each
incoming FEC is mapped to one or multiple NHLFEs.
A Diff-Serv Context for a label is defined as comprising:
- `LSP type (ie E-LSP or L-LSP)'
- `supported PHBs'
- `Encaps-->PHB mapping' for an incoming label
- `Set of PHB-->Encaps mappings' for an outgoing label
The present specification defines that a Diff-Serv Context is stored
in the ILM for each incoming label.
[MPLS_ARCH] states that the `NHLFE may also contain any other
information needed in order to properly dispose of the packet'. In
accordance with this, the present specification defines that a Diff-
Serv context is stored in the NHLFE for each outgoing label which is
swapped or pushed.
This Diff-Serv context information is populated into the ILM and the
FTN at label establishment time.
If the label corresponds to an E-LSP for which no EXP<-->PHB mapping
has been explicitly signaled at LSP setup, the `supported PHBs' is
populated with the set of PHBs of the preconfigured
EXP<-->PHB Mapping, which is discussed below in section 3.2.1.
If the label corresponds to an E-LSP for which an EXP<-->PHB mapping
has been explicitly signaled at LSP setup, the `supported PHBs' is
populated with the set of PHBs of the signaled EXP<-->PHB mapping.
If the label corresponds to an L-LSP, the `supported PHBs' is
populated with the set of PHBs forming the PSC that is signaled at
LSP set-up.
Le Faucheur et. al 7
MPLS Support of Diff-Serv February 00
The details of how the `Encaps-->PHB mapping' or `Set of
PHB-->Encaps 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 of
NHLFEs that contains more than one element, exactly one element of
the set must be chosen before the packet is forwarded. The
procedures for choosing an element from the set are beyond the scope
of this document. Having the ILM [respectively, FTN] map a label
[respectively, a FEC] to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths."
In accordance with this, the present specification allows that an
incoming label [respectively FEC] is mapped, for Diff-Serv purposes,
to multiple NHLFEs (for instance where different NHLFEs correspond
to egress labels supporting different sets of PHBs). When a label
[respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR MUST
choose one of the NHLFEs whose Diff-Serv context indicates that it
supports the Outgoing PHB of the forwarded packet.
When a label [respectively FEC] maps to multiple NHLFEs which
supports the Outgoing PHB, the procedure for choosing one among
those is outside the scope of this document. This situation may be
encountered where it is desired to do load balancing of a Behavior
Aggregate over multiple LSPs. In such situations, in order to
respect ordering constraints, all packets of a given microflow MUST
be transported over the same LSP.
2.4 Encoding Diff-Serv information into Encapsulation Layer
This stage determines how to encode the fields of the MPLS
encapsulation layer which convey Diff-Serv information (eg MPLS Shim
EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).
2.4.1 Encoding Diff-Serv information for transmitted labeled packets
This specification defines one default method for this encoding
which allows regular support of Diff-Serv over MPLS. This method
takes into account:
- the Outgoing PHB
- the Diff-Serv context associated with each swapped/pushed label
of the selected NHLFE (`Set of PHB-->Encaps mappings').
This method defines that the Outgoing PHB is reflected into:
- the EXP field value of all the swapped or pushed label entries
- the CLP/DE bit when the packet is encapsulated into ATM/Frame
Relay,
- the 802.1 User_Priority field of the 802.1 Tag Control
Information when the packet is encapsulated into LAN interfaces
supporting multiple Traffic Classes,
Le Faucheur et. al 8
MPLS Support of Diff-Serv February 00
The details of this method depend on the outgoing LSP type and on
the outgoing MPLS encapsulation and are defined below in sections
3.5 and 4.5.
Support for this default method is mandatory for compliance to this
specification.
Optionally, other methods for encoding Diff-Serv information into
the Encapsulation layer may also be supported to allow for more
sophisticated Diff-Serv operations over MPLS. Other methods may
affect encapsulation fields differently.
2.4.2 Encoding Diff-Serv information for transmitted unlabelled packets
This specification defines one default method for this encoding
which allows regular support of Diff-Serv over MPLS.
Support for this default method is mandatory for compliance to this
specification.
For packets transmitted unlabelled (ie LSR performing label
disposition), the default encoding method writes the DSCP of the
Outgoing PHB into the DS field.
Optionally, other encoding methods may also be supported to allow
for more sophisticated Diff-Serv operations over MPLS. Other methods
may affect the DS field differently. One example would be a method
where the IP packet's DS field is left unchanged regardless of the
Outgoing PHB. Such a method would allow `MPLS Diff-Serv
Transparency' ie it would allow support of Differentiated Services
in the MPLS backbone based on a Diff-Serv policy which is specific
to the MPLS cloud (and different from the Diff-Serv policy applied
in the non-MPLS clouds around the MPLS cloud) since the IP DS field
would be transported transparently through the MPLS cloud. Details
of such methods are outside the scope of this specification.
3. Detailed Operations of E-LSPs
3.1 E-LSP Definition
Recognizing that: Recognizing that:
- Certain MPLS encapsulations (such as PPP and LAN) make use of a - Certain MPLS encapsulations (such as PPP and LAN) make use of a
Shim Header which consists of a label stack with one or more entries Shim Header which consists of a label stack with one or more
[MPLS_ENCAPS]; entries [MPLS_ENCAPS] each with a 3-bit EXP field;
- the Diff-Serv Code Point field (DSCP) is 6-bit long - the Differentiated-Service (DS) field is 6-bit long
[DIFF_HEADER] but when 8 (or less) BAs are used, the DSCP values can [DIFF_HEADER] potentially allowing support of up to 64 Behavior
be mapped entirely into the 3-bit long EXP field of the MPLS label Aggregates
stack entry;
Le Faucheur et. al 9
MPLS Support of Diff-Serv February 00
- any subset of 8 (or less) DSCP values can be mapped entirely
into the 3-bit long EXP field of the MPLS label stack entry;
We define that: We define that:
- one LSP established for a given Forwarding Equivalent Class - an LSP established for a given Forwarding Equivalent Class (FEC)
(FEC) may be used for transport of up to eight BAs of that FEC; may be used for transport of up to eight BAs of that FEC;
- the set of transported BAs can span multiple OAs;
- for a given OA transported over the LSP, all supported BAs of
this OA are transported over the LSP;
- such an LSP is referred to as an "EXP-inferred-PSC" LSP or - such an LSP is referred to as an "EXP-inferred-PSC" LSP or
"E-LSP" because the PSC to be applied to a labeled packet by the LSR "E-LSP" because the PSC to be applied to a labeled packet by the
is inferred from the EXP field of the MPLS Shim Header; LSR depends on the EXP field value in the MPLS Shim Header;
Le Faucheur et. al 5 - packets belonging to this given (FEC) and from the corresponding
set of BAs are sent down this E-LSP.
MPLS Support of Diff-Serv October 99 - multiple BAs belonging to the same FEC and transported over the
same E-LSP are granted different scheduling treatment and
different drop precedence by the MPLS LSR based on the EXP field
which is appropriately encoded to reflect both the PSC and the
drop precedence of the PHB corresponding to the packet's BA.
- the set of transported BAs can span one or multiple OAs; - the mapping between EXP field and PHB to be applied by the LSR
for a given E-LSP is either explicitly signaled at label set-up
or relies on a preconfigured mapping.
- packets belonging to this given (FEC) and from the Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the
corresponding set of BAs are sent down this E-LSP. pre-configured mapping are capable of transporting the same common
set of 8, or less, BAs. Each of those E-LSPs may actually transport
this full set of BAs or any arbitrary subset of it.
- multiple BAs belonging to the same FEC and transported over the For a given FEC, two given E-LSPs using signaled EXP<-->PHB mapping
same E-LSP are granted different scheduling treatment and different can support the same or different sets of Ordered Aggregates.
drop precedence by the MPLS LSR based on the EXP field which is
appropriately encoded to reflect both the PSC and the drop For a given FEC, there may be more than one E-LSP carrying the same
precedence of the PHB corresponding to the packet's BA. OA, for example for purposes of load balancing of the OA. In that
case, in order to respect ordering constraints, all packets of a
given microflow must be transported over the same LSP.
MPLS specifies how LSPs can be established via multiple signaling MPLS specifies how LSPs can be established via multiple signaling
protocols. Those include the Label Distribution Protocol (LDP), protocols. Those include the Label Distribution Protocol (LDP),
RSVP, BGP and PIM. This document specifies below, respectively in RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP
section 4 and section 5, how RSVP and LDP are to be used for are to be used for establishment of E-LSPs.
establishment of E-LSPs.
2.2 Label Forwarding 3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP
2.2.1 Incoming PHB and FEC Determination On Ingress E-LSP Le Faucheur et. al 10
When receiving a labeled packet over a E-LSP of an MPLS ingress MPLS Support of Diff-Serv February 00
This section defines how the `Encaps-->PHB mapping' of the Diff-Serv
context is populated for an incoming E-LSP in order to support the
mandatory default method for Incoming PHB determination.
The `Encaps-->PHB mapping' is always of the form `EXP-->PHB
mapping'.
If the label corresponds to an E-LSP for which no EXP<-->PHB mapping
has been explicitly signaled at LSP setup, the `EXP-->PHB mapping'
is populated based on the Preconfigured EXP<-->PHB Mapping which is
discussed below in section 3.2.1.
If the label corresponds to an E-LSP for which an EXP<-->PHB mapping
has been explicitly signaled at LSP setup, the `EXP-->PHB mapping'
is populated as per the signaled EXP<-->PHB mapping.
3.2.1 Preconfigured EXP<-->PHB mapping
LSRs supporting E-LSPs which uses the preconfigured EXP<-->PHB
mapping must allow local configuration of this EXP<-->PHB mapping.
This mapping applies to all the E-LSPs established on this LSR
without a mapping explicitly signaled at set-up time.
The preconfigured EXP<-->PHB mapping must either be consistent at
every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the
LSP or appropriate remarking of the EXP field must be performed by
the LSR whenever a different preconfigured mapping is used on the
ingress and egress interfaces.
3.3 Incoming PHB Determination On Incoming E-LSP
This section defines the mandatory default method for Incoming PHB
determination for a labeled packet received on an E-LSP. This method
requires that the `Encaps-->PHB mapping' is populated as defined
above in section 3.2.
When receiving a labeled packet over an E-LSP of an MPLS ingress
interface, the LSR: interface, the LSR:
- determines the FEC based on the incoming label
- determines the incoming PHB by looking at the EXP field of -determines the EXP-->PHB mapping by looking up the
the top level label entry and then by looking up the PHB<-->EXP `Encaps-->PHB mapping' of the Diff-Serv context associated with
mapping defined below in section 2.3. the incoming label in the ILM.
- determines the incoming PHB by looking up the EXP field of the
top level label entry into the EXP-->PHB mapping table.
If the EXP field value of a packet received on an E-LSP is not If the EXP field value of a packet received on an E-LSP is not
listed in the mapping defined in section 2.3, this EXP value should included in the EXP-->PHB mapping associated with this LSP, this EXP
be considered invalid. LSR behavior in such situation is a local value should be considered invalid. LSR behavior in such situation
matter and is outside the scope of this document. is a local matter and is outside the scope of this document.
2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic 3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP
Conditioning
This stage of Diff-Serv label switching is optional and may be used Le Faucheur et. al 11
on an LSR to perform Behavior Aggregate demotion or promotion inside
an MPLS Diff-Serv domain. For the purpose of specifying Diff-Serv
over MPLS forwarding, we simply note that the PHB to be actually
enforced, and conveyed to downstream LSRs, by an LSR (referred to as
"outgoing PHB") may be different to the PHB which had been
associated with the packet by the previous LSR (referred to as
"incoming PHB").
2.2.3 Outgoing EXP Field And Label Determination On Egress E-LSP MPLS Support of Diff-Serv February 00
Once the outgoing PHB has been determined by the LSR as a function This section defines how the `Set of PHB-->Encaps mappings' of the
of the incoming PHB and of the optional Local Policy and Traffic Diff-Serv context is populated for an outgoing E-LSP in order to
Conditioning, the LSR: support the mandatory default method for Encoding of Diff-Serv
information in the Encapsulation Layer.
Le Faucheur et. al 6 3.4.1 `PHB-->EXP mapping'
MPLS Support of Diff-Serv October 99 One `PHB-->EXP mapping' is always added to the `Set of PHB-->Encaps
mappings' of the Diff-Serv context for an outgoing E-LSP.
- determines via local configuration that the outgoing PHB is If the label corresponds to an E-LSP for which no EXP<-->PHB mapping
one of the PHBs supported by the E-LSP and determines the egress E- has been explicitly signaled at LSP setup, this `PHB-->EXP mapping'
LSP label for the packet's FEC is populated based on the Preconfigured EXP<-->PHB Mapping which is
- determines the value to be written in the EXP field of the discussed above in section 3.2.1.
top level label entry (and possibly of other level label entries in
the case of a hierarchical tunnel entry) by looking up the
PHB<-->EXP mapping defined below in section 2.3 for the outgoing
PHB.
- SHALL apply the scheduling/dropping behavior corresponding to
the Outgoing PHB in compliance with the corresponding Diff-Serv PHB
specification.
2.2.4 Simplified Forwarding 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.
When Local Policy and Traffic Conditioning are not to be performed 3.4.2 `PHB-->802.1 mapping'
by the LSR and the labeled packet is received on a E-LSP and is
forwarded onto an E-LSP, the Forwarding operation is simplified
since:
- the EXP field does not need to be modified
- the outgoing label determination depends exclusively on the
incoming label (ie does not depend on Local Policy and Traffic
Conditioning). The outgoing label is determined from the Incoming
Label Map (ILM) using the same procedures as with non Diff-Serv LSPs
(ie the incoming label is used as the index into the ILM to identify
the NHLFE independently of the Diff-Serv operations)
- the scheduling/dropping behavior to be applied is determined
exclusively from the unmodified EXP field value.
2.3 PHB<-->EXP field mapping If the outgoing interface is a LAN interface on which multiple 802.1
Traffic Classes are supported as per [IEEE_802.1], one `PHB-->802.1
mapping' is added to the `Set of PHB-->Encaps mappings' of the Diff-
Serv context for the outgoing E-LSP. This mapping is populated at
label set-up based on the Preconfigured PHB-->802.1 mapping defined
below in section 3.4.2.1.
Like the mapping between PHBs and DSCPs in a Diff-Serv network, the Notice that the `Set of PHB-->Encaps mappings' then contains both a
mapping between PHB and EXP field is a local matter to be defined by `PHB-->EXP mapping' and a `PHB-->802.1 mapping'.
the Service Provider and configured on every LSR.
LSRs supporting E-LSPs must allow configuration of PHB<-->EXP 3.4.2.1 Preconfigured `PHB-->802.1 Mapping'
mapping. This mapping applies to all the E-LSPs established on this
LSR (over interfaces belonging to a given MPLS Diff-Serv domain).
The PHB<-->EXP mapping must be consistent at every LSP hop At the time of producing this specification, there are no
throughout the MPLS Diff-Serv domain spanned by the LSP. This is standardized mapping from PHBs to 802.1 Traffic Classes.
achieved via consistent configuration by the network operator within
the MPLS Diff-Serv domain.
Clearly, if different Behavior Aggregates transported over an E-LSP Consequently, an LSR supporting multiple 802.1 Traffic Classes over
are to be treated differently in the MPLS Diff-Serv cloud, different LAN interfaces must allow local configuration of a `PHB-->802.1
values of the EXP field are to configured in the PHB<-->EXP mapping Mapping'. This mapping applies to all the outgoing LSPs established
for the corresponding PHBs. by the LSR on such LAN interfaces.
2.4 E-LSP Merging 3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing
E-LSP
Le Faucheur et. al 7 This section defines the mandatory default method for encoding of
Diff-Serv related information into the MPLS encapsulation Layer to
be used when a packet is transmitted onto an E-LSP. This method
requires that the `Set of PHB-->Encaps mappings' is populated as
defined above in section 3.4.
MPLS Support of Diff-Serv October 99 The LSR first determines the `Set of PHB-->Encaps Mapping'
associated with the outer label of the NHLFE.
Le Faucheur et. al 12
MPLS Support of Diff-Serv February 00
3.5.1 `PHB-->EXP mapping'
For all the labels which are swapped or pushed, the LSR:
- determines the PHB-->EXP mapping by looking up the
`Set of PHB-->Encaps mapping' of the Diff-Serv context
associated with the corresponding label in the NHLFE.
- 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-->802.1 mapping'
If the `Set of PHB-->Encaps mapping' of the outer label 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 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 one LSR. E-LSPs are compatible with LSP Merging under the following
condition: condition:
E-LSPs can only be merged into one LSP if they support the exact E-LSPs can only be merged into one LSP if they support the
same set of BAs. exact same set of BAs.
Since the BAs/PHBs supported over an E-LSP is not signalled at For E-LSPs using signaled EXP<-->PHB mapping, the above merge
establishment time, an LSR can not rely on signaling information to condition MUST be enforced by LSRs through explicit checking at
enforce the above merge condition (ie that merged LSPs do support label setup that the exact same set of PHBs is supported on the
the exact same set of BAs). However all E-LSPs are to use the same merged LSPs.
PHB<-->EXP mapping, and transport the same set of Behavior
Aggregates, within a given MPLS Diff-Serv domain. Thus, E-LSP
merging is allowed within a given MPLS Diff-Serv domain.
E-LSP Merging at a boundary between two MPLS Diff-Serv domains is For E-LSPs using the preconfigured EXP<-->PHB mapping, since the
for further study. 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.
3. Detailed Operation of L-LSPs 4. Detailed Operation of L-LSPs
3.1 L-LSP Establishment 4.1 L-LSP Definition
Recognizing that: Recognizing that:
- All currently defined MPLS encapsulation methods have a field - All currently defined MPLS encapsulation methods have a field of
of 3 bits or less for Diff-Serv encoding (i.e., 3-bit EXP field in 3 bits or less for Diff-Serv encoding (i.e., 3-bit EXP field in
Le Faucheur et. al 13
MPLS Support of Diff-Serv February 00
case of Shim Header and 1-bit CLP/DE bit in case of ATM/Frame case of Shim Header and 1-bit CLP/DE bit in case of ATM/Frame
Relay). Relay).
- The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER]. So - The Differentiated-Services (DS) field is 6-bit long
that when more than a certain number of BAs are used (i.e., more [DIFF_HEADER] potentially allowing support of up to 64 Behavior
than 8 BAs in case of Shim Header and more than 2 BAs in case of Aggregates. So that when more than a certain number of BAs are
ATM/Frame Relay), the DS field can not be mapped entirely into the used (i.e., more than 8 BAs in case of Shim Header and more than
appropriate field of MPLS encapsulation header (i.e., EXP field in 2 BAs in case of ATM/Frame Relay), the DS field can not be
case of Shim Header and CLP/DE field in case of ATM/Frame Relay); mapped entirely into the appropriate field of MPLS encapsulation
header (i.e., EXP field in case of Shim Header and CLP/DE field
in case of ATM/Frame Relay);
- Some Service Providers have a requirement for fine grain We define that:
Traffic Engineering (such as per OA Traffic Engineering)
We propose that: - an LSP established for a given Forwarding Equivalent Class (FEC)
may be used for transport of the BAs comprised in one Ordered
Aggregate (OA) for that FEC;
- All packets belonging to a single OA and the same Forwarding - all BAs of this OA can be transported over the LSP;
Equivalent Class (FEC) be sent down a single LSP;
- One LSP be established per <FEC, OA> pair (rather than simply - BAs from other OAs can not transported over the LSP;
one LSP per FEC as in an MPLS network that does not support Diff-
Serv). Such an LSP is referred to as a "Label-inferred-PSC" LSP or
"L-LSP";
- Multiple BAs belonging to the same OA be granted different Drop - BAs from the OA transported over the LSP are given the
Precedence (DP) values through appropriate coding of the relevant appropriate scheduling treatment based on the PSC which is
explicitly signaled at label set-up time.
Le Faucheur et. al 8 - Such an LSP is referred to as a "Label-Only-inferred-PSC" LSP or
"L-LSP";
MPLS Support of Diff-Serv October 99 - Multiple BAs from OA transported over the LSP are granted
different drop precedence by the MPLS LSR based on the
appropriately encoded relevant field of MPLS encapsulation
header (EXP field of the top label entry for the shim header,
CLP/DE bit in case of ATM/Frame Relay); The mapping between the
relevant field of the MPLS encapsulation and the drop precedence
is a well-known mapping.
field of MPLS encapsulation header (EXP field of the top label entry For a given FEC, there may be more than one L-LSP carrying the same
for the shim header, CLP/DE bit in case of ATM/Frame Relay). OA, for example for purposes of load balancing of the OA. In that
case, in order to respect ordering constraints, all packets of a
given microflow must be transported over the same LSP.
MPLS specifies how LSPs can be established via multiple signaling MPLS specifies how LSPs can be established via multiple signaling
protocols. Those include the Label Distribution Protocol (LDP), protocols. Those include the Label Distribution Protocol (LDP),
RSVP, BGP and PIM. This document specifies, respectively in section RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP
4 and section 5, how RSVP and LDP are to be used for establishment are to be used for establishment of L-LSPs.
of L-LSPs.
3.2 Label Forwarding 4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP
3.2.1 Incoming PHB and FEC Determination On Ingress L-LSP This section defines how the `Encaps-->PHB mapping' of the Diff-Serv
context is populated for an incoming L-LSP for support of the
mandatory default method for Incoming PHB determination.
Le Faucheur et. al 14
MPLS Support of Diff-Serv February 00
4.2.1 `EXP-->PHB mapping'
If the LSR terminates the MPLS Shim Layer (i.e. it is not an
ATM-LSR or FR-LSR as defined in [MPLS ATM][MPLS FR], and it does not
receive packets without an MPLS shim layer on an LC-ATM or LC-FR
interface) then the `Encaps-->PHB mapping' is populated at label
setup in the following way:
- it is actually a `EXP-->PHB mapping'
- the mapping is a function of the PSC which is carried on this
LSP, and uses the relevant `EXP->PHB mapping' for this PSC as
defined in Section 4.2.1.1 below.
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
000 ----> AF11
001 ----> AF12
010 ----> AF13
4.2.1.1 EXP/PSC --> PHB mapping
In order to populate the `Encaps-->PHB mapping', the mapping from
the L-LSP PSCs and the EXP field of the shim header into PHBs is
specified as follows:
EXP Field PSC PHB
000 DF <----> DF
000 CSn <----> CSn
000 AFn <----> AFn1
001 AFn <----> AFn2
010 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 or it
receives packets without a shim on an LC-ATM interface), then the
`Encaps-->PHB mapping' of the Diff-Serv context for this incoming
L-LSP is populated at label setup 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 uses the relevant `CLP-->PHB mapping' for this PSC as
defined in Section 4.2.2.1 below.
For example if the incoming label corresponds to an L-LSP supporting
the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with:
Le Faucheur et. al 15
MPLS Support of Diff-Serv February 00
CLP Field PHB
0 ----> AF11
1 ----> AF12
4.2.2.1 CLP/PSC --> PHB mapping
In order to populate the `Encaps-->PHB mapping', the mapping from
the L-LSP PSCs and the CLP bit of the ATM cell header into PHBs is
specified as follows:
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 or it
receives packets without a shim on an LC-FR interface), then the
`Encaps-->PHB mapping' of the Diff-Serv context for this incoming
L-LSP is populated at label setup 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 uses the relevant `DE-->PHB mapping' for this PSC as
defined in Section 4.2.3.1 below.
4.2.3.1 DE/PSC --> PHB mapping
In order to populate the `Encaps-->PHB mapping', the mapping from
the L-LSP PSCs and the DE bit of the Frame Relay header into PHBs is
specified as follows:
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 the mandatory default method for Incoming PHB
determination for a labeled packet received on an L-LSP. This method
requires that the `Encaps-->PHB mapping' is populated as defined
above in section 4.2.
Le Faucheur et. al 16
MPLS Support of Diff-Serv February 00
When receiving a labeled packet over an L-LSP of an MPLS ingress When receiving a labeled packet over an L-LSP of an MPLS ingress
interface, the LSR: interface, the LSR first determines the `Encaps-->PHB mapping'
- determines the FEC based on the incoming label associated with the incoming label.
- determines the PSC from the incoming label among the set of
LSPs established for that FEC
- determines the incoming PHB from the PSC and the EXP/CLP/DLE
field of the top level label entry in accordance with the
PSC/EXP(resp PSC/CLP, PSC/DE) -->PHB mappings defined below in
sections 6.3 (resp 7.2 and 8.2).
3.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic 4.3.1 `EXP-->PHB mapping'
Conditioning
This stage of Diff-Serv label switching is independent of the If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping',
ingress/egress interface media type and method used for MPLS Diff- then the LSR:
Serv support. It is optional and may be used on an LSR to perform - determines the incoming PHB by looking at the EXP field of the
Behavior Aggregate demotion or promotion inside an MPLS Diff-Serv top level label entry and by using the EXP-->PHB mapping.
domain. For the purpose of specifying a Diff-Serv over MPLS method,
we simply note that the PHB to be actually enforced by an LSR
(referred to as "outgoing PHB") may be different to the PHB which
had been associated with the packet at the previous LSR (referred to
as "incoming PHB").
3.2.3 Outgoing EXP/CLP/DE Field and Label Determination on Egress L- If the received EXP field value is not included in the EXP-->PHB
LSP mapping, this EXP value should be considered invalid. LSR behavior
in such situation is a local matter and is outside the scope of this
document.
Once the outgoing PHB has been determined by the LSR as a function 4.3.2 `CLP-->PHB mapping'
of the incoming PHB and of the optional Local Policy and Traffic
Conditioning, the LSR:
- determines via local configuration that the outgoing PHB is
one of the PHBs supported by a L-LSP and determines the egress
L-LSP label for the packet's FEC
- determines the value to be written in the EXP/CLP/DLE field
of the top level label entry (and possibly of other level label
entries in the case of a hierarchical tunnel entry) by performing
the outgoing PHB-->EXP/PSC (resp CLP/PSC, DE/PSC) mapping defined in
sections 6.4 (resp 7.3 and 8.3).
Le Faucheur et. al 9 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 by using the CLP-->PHB mapping.
MPLS Support of Diff-Serv October 99 If the received CLP field value is not included in the CLP-->PHB
mapping, this CLP value should be considered invalid. LSR behavior
in such situation is a local matter and is outside the scope of this
document.
- SHALL apply the scheduling/dropping behavior corresponding to 4.3.3 `DE-->PHB mapping'
the "Outgoing PHB" in compliance with the corresponding Diff-Serv
PHB specification.
3.2.4 Simplified Forwarding 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.
When Local Policy and Traffic Conditioning are not to be performed If the received DE field value is not included in the DE-->PHB
by the LSR, and when the labeled packet is received on a L-LSP on mapping, this DE value should be considered invalid. LSR behavior in
the ingress interface and is going out onto a L-LSP on an egress such situation is a local matter and is outside the scope of this
interface of the same type, the Forwarding operation is simplified document.
since:
- the EXP/CLP/DE field does not need to be modified
- the outgoing label determination depends exclusively on the
incoming label (ie does not depend on Local Policy and Traffic
Conditioning). The outgoing label is determined from the Incoming
Label Map (ILM) using the same procedures as with non Diff-Serv LSPs
(ie the incoming label is used as the index into the ILM to identify
the NHLFE independently of the Diff-Serv operations)
- the scheduling behavior to be applied is determined
exclusively from the Diff-Serv information stored in the NHLFE for
the incoming label
- the dropping behavior to be applied is determined exclusively
from the Diff-Serv information stored in the NHLFE for the incoming
label and from the incoming EXP/CLP/DE field
More information is provided below in the sections titled `RSVP
extensions for Diff-Serv Support' and `LDP extensions for Diff-Serv
Support' on what is the Diff-Serv information stored in NHLFEs.
3.3 Merging 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 for an outgoing L-LSP for support of
the mandatory default method for Encoding Diff-Serv Information into
Encapsulation on Outgoing L-LSP.
4.4.1 `PHB-->EXP mapping'
If the LSR uses an MPLS Shim Layer over this outgoing label (i.e. it
is not an ATM-LSR or FR-LSR and it does not transmit packets without
an MPLS Shim Layer on a LC-ATM or LC-FR interface), then one
Le Faucheur et. al 17
MPLS Support of Diff-Serv February 00
`PHB-->EXP mapping' is added at label setup to the `Set of
PHB-->Encaps mapping' in the Diff-Serv context 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 uses the
relevant `PHB-->EXP mapping' for this PSC as defined in section
4.4.1.1 below.
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 ----> 000
AF12 ----> 001
AF13 ----> 010
4.4.1.1 PHB-->PSC/EXP mapping
In order to populate the `Set of PHB-->Encaps mappings', the mapping
from the PHBs into the L-LSP PSC and the EXP field of the shim
header is specified as follows:
PHB PSC EXP Field
DF ----> DF 000
CSn ----> CSn 000
AFn1 ----> AFn 000
AFn2 ----> AFn 001
AFn3 ----> AFn 010
EF ----> EF 000
4.4.2 `PHB-->CLP mapping'
If the LSR uses ATM encapsulation (i.e. it is an ATM-LSR or sends
packets on an LC-ATM interface), then one `PHB-->CLP mapping' is
added at label setup to the `Set of PHB-->Encaps mappings' in the
Diff-Serv context for this outgoing L-LSP. This `PHB-->CLP mapping'
is populated in the following way:
- it is a function of the PSC supported on this LSP, and uses the
relevant `PHB-->CLP mapping' for this PSC as defined below in
section 4.4.2.1.
For example if the outgoing label corresponds to an L-LSP supporting
the AF1 PSC, then the `PHB-->Encaps mapping' will be populated with:
PHB CLP Field
AF11 ----> 0
AF12 ----> 1
AF13 ----> 1
Le Faucheur et. al 18
MPLS Support of Diff-Serv February 00
Notice that the if the LSR is transmitting packets over a LC-ATM
interface using the MPLS Shim Header, then the `Set of PHB-->Encaps
mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP
mapping'.
4.4.2.1 PHB-->PSC/CLP mapping
In order to populate the `Set of PHB-->Encaps mappings', the mapping
from the PHBs into the L-LSP PSC and the CLP bit of the ATM cell
header is specified as follows:
PHB PSC CLP Bit
DF ----> DF 0
CSn ----> CSn 0
AFn1 ----> AFn 0
AFn2 ----> AFn 1
AFn3 ----> AFn 1
EF ----> EF 0
4.4.3 `PHB-->DE mapping'
If the LSR uses Frame Relay encapsulation (i.e. it is a FR-LSR or
sends packets on an LC-FR interface), one `PHB-->DE mapping' is
added at label setup to the `Set of PHB-->Encaps mapping' in the
Diff-Serv context for this outgoing L-LSP and is populated in the
following way:
- it is a function of the PSC supported on this LSP, and uses the
relevant `PHB-->DE mapping' for this PSC as defined below in
section 4.4.3.1.
Notice that if the LSR is sending packets over a LC-FR interfaces
using the MPLS Shim Header, then the `Set of PHB-->Encaps mappings'
contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'.
4.4.3.1 PHB-->PSC/DE mapping
In order to populate the `Set of PHB-->Encaps mappings', the mapping
from the PHBs into the L-LSP PSC and the DE bit of the Frame Relay
header is specified as follows:
PHB PSC DE Bit
DF ----> DF 0
CSn ----> CSn 0
AFn1 ----> AFn 0
AFn2 ----> AFn 1
AFn3 ----> AFn 1
EF ----> EF 0
4.4.4 `PHB-->802.1 mapping'
Le Faucheur et. al 19
MPLS Support of Diff-Serv February 00
If the outgoing interface is a LAN interface on which multiple
Traffic Classes are supported as defined in [IEEE_802.1], then one
`PHB-->802.1 mapping' is added at label setup to the `Set of
PHB-->Encaps mappings' in the Diff-Serv context for this outgoing
L-LSP. This `PHB-->802.1 mapping' is populated in the following way:
- it is a function of the PSC supported on this LSP, and uses the
relevant `PHB-->802.1 mapping' for this PSC from the
Preconfigured `PHB-->802.1 mapping' defined above in section
3.4.2.1.
Notice that if the LSR is transmitting packets over a LAN interface
supporting multiple 802.1 Traffic Classes, then the `Set of
PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a
`PHB-->802.1 mapping'.
4.5 Encoding Diff-Serv Information into Encapsulation on Outgoing
L-LSP
This section defines the mandatory default method for encoding of
Diff-Serv related information into the MPLS encapsulation Layer to
be used when a packet is transmitted onto an L-LSP. This method
requires that the `Set of PHB-->Encaps mappings' is populated as
defined above in section 4.4.
The LSR first determines the `Set of PHB-->Encaps mapping'
associated with the outer label of the NHLFE.
4.5.1 `PHB-->EXP mapping'
If the `Set of PHB-->Encaps mapping' of the outer label contains a
mapping of the form `PHB-->EXP mapping', then, for all the labels
which are swapped or pushed, the LSR:
- determines the PHB-->EXP mapping by looking up the
`PHB-->Encaps mapping' of the Diff-Serv context associated with
the corresponding label in the NHLFE.
- 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.
4.5.2 `PHB-->CLP mapping'
If the `Set of PHB-->Encaps mapping' of the outer label 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
Layer encapsulation by looking up the "outgoing PHB" in this
PHB-->CLP mapping table.
4.5.3 `PHB-->DE mapping'
If the `Set of PHB-->Encaps mapping' of the outer label contains a
mapping of the form `PHB-->DE mapping', then the LSR:
Le Faucheur et. al 20
MPLS Support of Diff-Serv February 00
- determines the value to be written in the DE field of the Frame
Relay encapsulation by looking up the "outgoing PHB" in this
PHB-->DE mapping table.
4.5.4 `PHB-->802.1 mapping'
If the `Set of PHB-->Encaps mapping' of the outer label 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.
4.6 L-LSP Merging
In an MPLS domain, two or more LSPs can be merged into one LSP at In an MPLS domain, two or more LSPs can be merged into one LSP at
one LSR. The proposed support of Diff-Serv in MPLS is compatible one LSR. The proposed support of Diff-Serv in MPLS is compatible
with LSP Merging under the following condition: with LSP Merging under the following condition:
L-LSPs can only be merged into one L-LSP if they are associated with L-LSPs can only be merged into one L-LSP if they support the
the same PSC. 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 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 PSC downstream of the merge point must be sufficient to carry the
sum of the merged traffic. This is particularly important in the sum of the merged traffic. This is particularly important in the
case of EF traffic. This can be ensured in multiple ways (for case of EF traffic. This can be ensured in multiple ways (for
instance via provisioning or via bandwidth signaling and explicit instance via provisioning, or via bandwidth signaling and explicit
admission control). admission control).
4. RSVP Extension for Diff-Serv Support 5. RSVP Extension for Diff-Serv Support
The MPLS architecture does not assume a single label distribution The MPLS architecture does not assume a single label distribution
protocol. [RSVP_MPLS_TE] defines the extension to RSVP for protocol. [RSVP_MPLS_TE] defines the extension to RSVP for
establishing label switched paths (LSPs) in MPLS networks. This establishing label switched paths (LSPs) in MPLS networks. This
section specifies the extensions to RSVP, beyond those defined in section specifies the extensions to RSVP, beyond those defined in
Le Faucheur et. al 10
MPLS Support of Diff-Serv October 99
[RSVP_MPLS_TE], to establish label switched path (LSPs) supporting [RSVP_MPLS_TE], to establish label switched path (LSPs) supporting
Differentiated Services in MPLS networks. Differentiated Services in MPLS networks.
4.1 Diff-Serv related RSVP Messages Format 5.1 Diff-Serv related RSVP Messages Format
One new RSVP Object is defined in this document: the DIFFSERV_PSC One new RSVP Object is defined in this document: the DIFFSERV
Object. Detailed description of this Object is provided below. This Object. Detailed description of this Object is provided below. This
new Object is applicable to Path messages. This specification only new Object is applicable to Path messages. This specification only
defines the use of the DIFFSERV_PSC Object in Path messages used to defines the use of the DIFFSERV Object in Path messages used to
establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus
containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4
and containing a LABEL_REQUEST object. and containing a LABEL_REQUEST object.
Le Faucheur et. al 21
MPLS Support of Diff-Serv February 00
Restrictions defined in [RSVP_MPLS_TE] for support of establishment Restrictions defined in [RSVP_MPLS_TE] for support of establishment
of LSP Tunnels via RSVP are also applicable to the establishment of of LSP Tunnels via RSVP are also applicable to the establishment of
LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs
are supported and Multicast LSPs are for further study. are supported and Multicast LSPs are for further study.
This new DIFFSERV_PSC object is optional with respect to RSVP so This new DIFFSERV object is optional with respect to RSVP so that
that general RSVP implementations not concerned with MPLS LSP set up general RSVP implementations not concerned with MPLS LSP set up do
do not have to support this object. not have to support this object.
The DIFFSERV_PSC Object is optional for support of LSP Tunnels as The DIFFSERV Object is optional for support of LSP Tunnels as
defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs
in compliance with this specification MAY support the DIFFSERV_PSC using the preconfigured EXP<-->PHB mapping in compliance with this
Object. A Diff-Serv capable LSR supporting L-LSPs in compliance with specification MAY support the DIFFSERV Object. A Diff-Serv capable
this specification MUST support the DIFFSERV_PSC Object. 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.
4.1.1 Path Message Format 5.1.1 Path Message Format
The format of the Path message is as follows: The format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV_PSC> ] [ <DIFFSERV> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
[ <sender descriptor> ] [ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ] <sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ] [ <ADSPEC> ]
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
4.2 DIFFSERV_PSC Object 5.2 DIFFSERV Object
As stated earlier, the PHB Scheduling Class associated with an L-LSP The DIFFSERV object formats are shown below. Currently there are two
is to be specified through a new DIFFSERV_PSC object in RSVP Path possible C_Types. Type 1 is a DIFFSERV object for an E-LSP. Type 2
messages. The DIFFSERV_PSC object has the following format : is a DIFFSERV object for an L-LSP.
Le Faucheur et. al 11 5.2.1. DIFFSERV object for an E-LSP:
MPLS Support of Diff-Serv October 99 class = TBD, C_Type = 1 (need to get an official class num from the
IANA with the form 0bbbbbbb)
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type | | Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | T |PSCnb| PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
This is set to 4. Le Faucheur et. al 22
Class-Num MPLS Support of Diff-Serv February 00
The Class-Num for a DIFFSERV_PSC object is [TBD] and identifies +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a new object Class called the "Class Of Service" Class (COS | MAP (1) |
Class). (The Class-Num is to be allocated by IANA with the form +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0bbbbbbb) | |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Type Reserved : 28 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
The C-Type for a DIFFSERV_PSC object is 1. 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 (decimal).
Reserved MAP : 32 bits
Each MAP entry defines the mapping between one EXP field value
and one PHB. The MAP entry has the following format:
This field is set to all zeros 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T Reserved : 13 bits
This field is reserved. It must be set to zero on
transmission and must be ignored on receipt.
This indicates the `LSP Type'. The following values are EXP : 3 bits
specified: This field contains the value of the EXP field for the
EXP<-->PHB mapping defined in this MAP entry.
T Value LSP type PHBID : 16 bits
00 E-LSP This field contains the PHBID of the PHB for the
01 L-LSP EXP<-->PHB mapping defined in this MAP entry. The PHBID
is encoded as specified in section 2 of [PHBID].
PSCnb 5.2.2 DIFFSERV object for an L-LSP:
Indicates the number of PSC values included in the PSC object. class = TBD, C_Type = 2 (class num is the same as DIFFSERV object
This is set to 001. for E-LSP))
PSC 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PSC indicates the PHB Scheduling Class to be supported by the Le Faucheur et. al 23
L-LSP. The 16-bit PSC is encoded as specified in section 2 of
[PHBID]:
- Where the PSC comprises a single PHB defined by standards
action, the encoding for the PSC is the encoding for this single
PHB. It is the recommended DSCP value for that PHB, left-
justified in the 16-bit field, with bits 6 through 15 set to
zero.
Le Faucheur et. al 12 MPLS Support of Diff-Serv February 00
MPLS Support of Diff-Serv October 99 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 section 2 of [PHBID]:
- Where the PSC comprises a single PHB defined by standards
action, the encoding for the PSC is the encoding for this
single PHB. It is the recommended DSCP value for that PHB,
left-justified in the 16-bit field, with bits 6 through 15 set
to zero.
- Where the PSC comprises multiple PHBs defined by standards - Where the PSC comprises multiple PHBs defined by standards
action, the PSC encoding is the encoding for this set of PHB. It action, the PSC encoding is the encoding for this set of PHB.
is the smallest numerical value of the recommended DSCP for the It is the smallest numerical value of the recommended DSCP for
various PHBs in the PSC, left-justified in the 16 bit field, with the various PHBs in the PSC, left-justified in the 16 bit
bits 6 through 13 and bit 15 set to zero and with bit 14 set to field, with bits 6 through 13 and bit 15 set to zero and with
one. bit 14 set to one.
For instance, the encoding of the EF PSC is : For instance, the encoding of the EF PSC is :
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 0 1 1 1 0| 0 0 0 0 0 0 0 0 0 0| | 1 0 1 1 1 0| 0 0 0 0 0 0 0 0 0 0|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For instance, the encoding of the AF1 PSC is : For instance, the encoding of the AF1 PSC is :
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 0 1 0 1 0| 0 0 0 0 0 0 0 0 1 0| | 0 0 1 0 1 0| 0 0 0 0 0 0 0 0 1 0|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3 Handling Diff-Serv_PSC Object 5.3 Handling Diff-Serv Object
To establish an LSP tunnel with RSVP, the sender creates a Path To establish an LSP tunnel with RSVP, the sender creates a Path
message with a session type of LSP_Tunnel_IPv4 and with a message with a session type of LSP_Tunnel_IPv4 and with a
LABEL_REQUEST object as per [RSVP_MPLS_TE]. LABEL_REQUEST object as per [RSVP_MPLS_TE].
Where the sender supports Diff-Serv using E-LSPs, to establish an Where the sender supports Diff-Serv, to establish with RSVP an E-LSP
E-LSP tunnel with RSVP, the sender creates a Path message with a tunnel which uses the Preconfigured EXP<-->PHB mapping, the sender
session type of LSP_Tunnel_IPv4, with the LABEL_REQUEST object and creates a Path message:
without the DIFFSERV_PSC object. - with a session type of LSP_Tunnel_IPv4,
- with the LABEL_REQUEST object, and
- without the DIFFSERV object.
Optionally, to establish an E-LSP over which a single Ordered Where the sender supports Diff-Serv, to establish with RSVP an E-LSP
Aggregate is going to be transported, the sender MAY create a Path tunnel which uses a signaled EXP<-->PHB mapping, the sender creates
message which contains a session type of LSP_Tunnel_IPv4, contains a Path message :
the LABEL_REQUEST object and contains the DIFFSERV_PSC object with - with a session type of LSP_Tunnel_IPv4,
its LSP-Type field set to `E-LSP' and its PSC field set to the value - with the LABEL_REQUEST object,
of the PSC to be supported on the E-LSP.
The destination node of an E-LSP responds to the Path message Le Faucheur et. al 24
containing the LABEL_REQUEST object by sending a Resv message
containing the LABEL object and no DIFFSERV_PSC object.
When receiving a Resv message containing a LABEL object and MPLS Support of Diff-Serv February 00
associated with a Path message which contained a LABEL_REQUEST
object and no DIFFSERV_PSC object (or which contained the
DIFFSERV_PSC object with its LSP-Type set to E-LSP), assuming the
reservation can be accepted and a label can be associated with the
reservation, a Diff-Serv E-LSP capable LSR must:
- update its Incoming Label Map (ILM) [MPLS_ARCH] to store the
necessary Diff-Serv information. This includes the fact that the
Next Hop Label Forwarding Entry (NHLFE) corresponds to an E-LSP.
This is in accordance with [MPLS_ARCH] which states that the `NHLFE
Le Faucheur et. al 13 - with the DIFFSERV object for an E-LSP containing one MAP entry
for each EXP value to be supported on this E-LSP.
MPLS Support of Diff-Serv October 99 Where the sender supports Diff-Serv, 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.
may also contain any other information needed in order to properly If a path message contains multiple DIFFSERV objects, only the first
dispose of the packet'. one is meaningful; subsequent DIFFSERV object(s) must be ignored and
- install the required scheduling and dropping behavior for not forwarded.
this NHLFE in order to support Diff-Serv label forwarding as
specified for E-LSPs in section 2.2.
Where the sender supports Diff-Serv using L-LSPs, to establish an Each node along the path records the DIFFSERV object, when present,
L-LSP tunnel with RSVP, the sender creates a Path message with a in its path state block.
session type of LSP_Tunnel_IPv4, with the LABEL_REQUEST object and
with the DIFFSERV_PSC object. The DIFFSERV_PSC object has its LSP-
Type set to L-LSP and its the PSC value indicating the PHB
Scheduling Class to be supported by the L-LSP.
An RSVP router that does recognizes the DIFFSERV_PSC object and that The destination node of an E-LSP or L-LSP responds to the Path
receives a path message which contains the DIFFSERV_PSC object but message containing the LABEL_REQUEST object by sending a Resv
which does not contain a LABEL_REQUEST object or which does not have message:
a session type of LSP_Tunnel_IPv4, sends a PathErr towards the - with the LABEL object
sender with the error code `Diff-Serv Error' and an error value of - without a DIFFSERV object.
`Unexpected DIFFSERV_PSC object'. Those are defined below in the
section titled `Diff-Serv Errors'.
A node receiving a Path message with the DIFFSERV_PSC object, which Assuming the reservation is accepted and a label is associated with
recognizes the DIFFSERV_PSC object but does not support the the reservation, the Diff-Serv LSRs (sender, destination,
particular PSC encoded in the PSC field, sends a PathErr towards the intermediate nodes) must:
sender with the error code `Diff-Serv Error' and an error value of - update the Diff-Serv context associated with the established
`Unsupported PSC Value'. Those are defined below in the section LSPs in their ILM/FTN as specified in previous sections
titled `Diff-Serv Errors'. (incoming and outgoing label),
- install the required Diff-Serv forwarding treatment (scheduling
and dropping behavior) for this NHLFE (outgoing label).
If a path message contains multiple DIFFSERV_PSC objects, only the An RSVP router that does recognizes the DIFFSERV object and that
first one is meaningful; subsequent DIFFSERV_PSC object(s) must be receives a path message which contains the DIFFSERV object but which
ignored and not forwarded. 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.
Each node along the path records the DIFFSERV_PSC object, when A node receiving a Path message with the DIFFSERV object for E-LSP,
present, in its path state block. 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.
The destination node of an L-LSP responds to the Path message A node receiving a Path message with the DIFFSERV object for E-LSP,
containing the LABEL_REQUEST object and the DIFFSERV_PSC object by which recognizes the DIFFSERV object but determines that the
sending a Resv message containing the LABEL object and no signaled EXP<-->PHB mapping is invalid, sends a PathErr towards the
DIFFSERV_PSC object. sender with the error code `Diff-Serv Error' and an error value of
`Invalid EXP<-->PHB mapping'. Those are defined below in section
When receiving a Resv message containing a LABEL object and Le Faucheur et. al 25
associated with a Path message which contained a LABEL_REQUEST
object and the DIFFSERV_PSC object with its LSP-Type set to L-LSP,
assuming the reservation can be accepted and a label can be
associated with the reservation, a Diff-Serv L-LSP capable LSR must:
- update its ILM to store the necessary Diff-Serv information.
This includes the fact that the NHLFE corresponds to an L-LSP and
its PSC.
- install the required scheduling and dropping behavior for
this NHLFE to support Diff-Serv label forwarding as specified for L-
LSPs in section 3.2.
Le Faucheur et. al 14 MPLS Support of Diff-Serv February 00
MPLS Support of Diff-Serv October 99 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 1 to 8 decimal, or
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
A node 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.
A Diff-Serv LSR MUST handle the situations where the reservation can A Diff-Serv LSR MUST handle the situations where the reservation can
not be accepted for other reasons than those already discussed in not be accepted for other reasons than those already discussed in
this section, in accordance with [RSVP_MPLS_TE] (eg. reservation this section, in accordance with [RSVP_MPLS_TE] (eg. reservation
rejected by admission control, a label can not be associated). rejected by admission control, a label can not be associated).
[RSVP_MPLS_TE] identifies the conditions where LSPs can be merged to 5.4 Non-support of the Diff-Serv Object
constitute a multipoint-to-point LSP. When the LSPs to be merged are
L-LSPs, those can only be merged if an additional condition is met:
the DIFFSERV_PSC object in their respective path messages must all
be strictly identical.
4.4 Non-support of the Diff-Serv_PSC Object An RSVP router 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 ie. it must send a
PathErr with the error code `Unknown object class' toward the
sender.
An RSVP router that does not recognize the COS Class's Class-Num An RSVP router that recognizes the DIFFSERV object Class-Num but
sends a PathErr with the error code "Unknown object class" toward does not recognize the DIFFSERV object C-Type, must behave in
the sender. An RSVP router that recognizes the COS Class's Class-Num accordance with the procedures specified in [RSVP] for an unknown C-
but does not recognize the DIFFSERV_PSC object C-Type, sends a type ie. It must send a PathErr with the error code `Unknown object
PathErr with the error code "Unknown object C-Type" toward the C-Type' toward the sender.
sender. This causes the path set-up to fail. The sender should
notify management that a L-LSP cannot be established and possibly
take action to retry reservation establishment without the
DIFFSERV_PSC object (eg. attempt use of E-LSPs as a back-up
strategy).
4.5 Error Codes For Diff-Serv In both situations, this causes the path set-up to fail. The sender
should notify management that a L-LSP cannot be established and
possibly take action to retry reservation establishment without the
DIFFSERV object (eg. 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 In the procedures described above, certain errors must be reported
as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error
code is 26 (TBD). code is 26 (TBD).
The following defines error values for the Diff-Serv Error: The following defines error values for the Diff-Serv Error:
Value Error Value Error
1 Unsupported PSC value 1 Unexpected DIFFSERV object
2 Unexpected DIFFSERV_PSC object 2 Unsupported PHB
3 Invalid EXP<-->PHB mapping
4 Unsupported PSC
4.6 Use of COS Service with E-LSPs and L-LSPs Le Faucheur et. al 26
MPLS Support of Diff-Serv February 00
5.6 Use of COS Service with E-LSPs and L-LSPs
Both E-LSPs and L-LSPs can be established with bandwidth reservation Both E-LSPs and L-LSPs can be established with bandwidth reservation
or without bandwidth reservation. or without bandwidth reservation.
To establish an E-LSP or an L-LSP with bandwidth reservation, Int- To establish an E-LSP or an L-LSP with bandwidth reservation, Int-
Serv's Controlled Load service (or possibly Guaranteed Service) is Serv's Controlled Load service (or possibly Guaranteed Service) is
used and the bandwidth is signaled in the SENDER_TSPEC (respectively used and the bandwidth is signaled in the SENDER_TSPEC (respectively
FLOWSPEC) of the path (respectively Resv) message. FLOWSPEC) of the path (respectively Resv) message.
To establish an E-LSP or an L-LSP without bandwidth reservation, the To establish an E-LSP or an L-LSP without bandwidth reservation, the
Class of Service service defined in [RSVP_MPLS_TE] is used. Class of Service service defined in [RSVP_MPLS_TE] is used.
Le Faucheur et. al 15
MPLS Support of Diff-Serv October 99
A Path message containing a COS SENDER_TSPEC and not containing a A Path message containing a COS SENDER_TSPEC and not containing a
DIFFSERV_PSC object indicates to a Diff-Serv capable LSR that the DIFFSERV object indicates to a Diff-Serv capable LSR that the LSP to
LSP to be established in an E-LSP without any bandwidth reservation. be established in an E-LSP using the Preconfigured mapping and
without any bandwidth reservation.
A Path message containing a COS SENDER_TSPEC and containing a A Path message containing a COS SENDER_TSPEC and containing a
DIFFSERV_PSC object with its LSP-Type set to E-LSP indicates to a DIFFSERV object for E-LSP indicates to a Diff-Serv capable LSR that
Diff-Serv capable LSR that the LSP to be established in an E-LSP the LSP to be established in an E-LSP using a signaled mapping and
without any bandwidth reservation. without any bandwidth reservation.
A Path message containing a COS SENDER_TSPEC and containing a A Path message containing a COS SENDER_TSPEC and containing a
DIFFSERV_PSC object with its LSP-Type set to L-LSP indicates to a DIFFSERV object for LSP indicates to a Diff-Serv capable LSR that
Diff-Serv capable LSR that the LSP to be established in an L-LSP the LSP to be established in an L-LSP without any bandwidth
without any bandwidth reservation. reservation.
The above is summarized in the following table: The above is summarized in the following table:
Path Message LSP type Path Message LSP type
Service DIFFSERV_PSC LSP Service DIFFSERV
Object Type Object
GS/CL No E-LSP with bandwidth reservation GS/CL No E-LSP + preconf mapping + bandw reservation
GS/CL Yes E-LSP E-LSP with bandwidth reservation GS/CL Yes/E-LSP E-LSP + signaled mapping + bandw reservation
GS/CL Yes L-LSP L-LSP with bandwidth reservation GS/CL Yes/L-LSP L-LSP + bandw reservation
COS No E-LSP without bandwidth reservation COS No E-LSP + preconf mapping + no bandw reservation
COS Yes E-LSP E-LSP without bandwidth reservation COS Yes/E-LSP E-LSP + signaled mapping + no band reservation
COS Yes L-LSP L-LSP without bandwidth reservation COS Yes/L-LSP L-LSP + no bandw reservation
Where: Where:
- GS stands for Guaranteed Service - GS stands for Guaranteed Service
- CL stands for Controlled Load - CL stands for Controlled Load
- COS stands for COS service - COS stands for COS service
When processing a path (respectively Resv) message for an E-LSP or When processing a path (respectively Resv) message for an E-LSP or
an L-LSP using the COS service, a Diff-Serv capable LSR must ignore an L-LSP using the COS service, a Diff-Serv capable LSR must ignore
the value of the COS field within a COS SENDER_TSPEC (respectively a the value of the COS field within a COS SENDER_TSPEC (respectively a
COS FLOWSPEC). COS FLOWSPEC).
5. LDP Extensions for Diff-Serv Support Le Faucheur et. al 27
MPLS Support of Diff-Serv February 00
6. LDP Extensions for Diff-Serv Support
The MPLS architecture does not assume a single label distribution The MPLS architecture does not assume a single label distribution
protocol. [LDP] defines the Label Distribution Protocol and its protocol. [LDP] defines the Label Distribution Protocol and its
usage for establishment of label switched paths (LSPs) in MPLS usage for establishment of label switched paths (LSPs) in MPLS
networks. This section specifies the extensions to LDP to establish networks. This section specifies the extensions to LDP to establish
label switched path (LSPs) supporting Differentiated Services in label switched path (LSPs) supporting Differentiated Services in
MPLS networks. MPLS networks.
Two new LDP TLVs are defined in this document: One new LDP TLV is defined in this document:
- the `DIFF-SERV_PSC' TLV - the Diff-Serv TLV
- the `Release Status' TLV Detailed description of this TLV is provided below.
Detailed descriptions of these TLV are provided below.
Le Faucheur et. al 16
MPLS Support of Diff-Serv October 99
As described in [LDP], there are two modes for label distribution:
Downstream Unsolicited and Downstream on Demand.
When an E-LSP is established using Downstream on Demand mode, the
Label Request message and the Label Mapping message usually do not
include the new Diff-Serv_PSC. In the case where, a single Ordered
Aggregate is to be transported over the E-LSP, the Label Request
message and the Label Mapping message may optionally include the new
Diff-Serv_PSC (with its LSP-type defined below set to `E-LSP').
When an E-LSP is established using Downstream Unsolicited mode, the
new Diff-Serv_PSC MUST not be carried in the Label Request message
nor in the Label Mapping message.
When an L-LSP is established using Downstream on Demand mode, the
new DIFF-SERV_PSC TLV MUST be carried in the Label Request Message
to indicate the PHB Scheduling Class (PSC) of the LSP and may
optionaly be carried in the Label Mapping message.
When an L-LSP is established using Downstream Unsolicited mode, the
new DIFF-SERV_PSC TLV MUST be carried in the Label Mapping Message
to indicate the PHB Scheduling Class (PSC) of the LSP.
The Release Status TLV is to be used to include diagnostic
information in Label Release messages when handling Diff-Serv
related errors.
The new Diff-Serv_PSC and Release Status TLVs are optional with The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv
respect to LDP. A Diff-Serv capable LSR supporting E-LSPs in capable LSR supporting E-LSPs which uses the Preconfigured
compliance with this specification MAY support the Diff-Serv_PSC TLV EXP<-->PHB mapping in compliance with this specification MAY support
and the Release Status TLV. A Diff-Serv capable LSR supporting the Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which
L-LSPs in compliance with this specification MUST support the Diff- uses the signaled EXP<-->PHB mapping in compliance with this
Serv_PSC TLV and the Release Status TLV. 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.
5.1 Diff-Serv related TLVs 6.1 Diff-Serv TLV
5.1.1 Diff-Serv_PSC TLV The Diff-Serv TLV has the following formats:
As stated earlier, the PHB Scheduling Class associated with an L-LSP Diff-Serv TLV for an E-LSP:
is to be specified through a new Diff-Serv_PSC TLV in LDP messages.
The Diff-Serv_PSC TLV has the following format:
0 1 2 3 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 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 (0x901) | Length | |U|F| Type = PSC (0x901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | T |PSCnb| PSC | |T| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
U BIT =0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
Le Faucheur et. al 17 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS Support of Diff-Serv October 99
If this new TLV is unknown to the LSR, the LSR must reject the
whole message and return a notification
F BIT = 0
If this TLV is unknown to a LSR, this new TLV is NOT forwarded.
Type
The Type of the PSC TLV is: 0x901.
Length
This is set to 4. T:1 bit
LSP Type. This is set to 0 for an E-LSP
Reserved Reserved : 28 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
This field is set to all zeros MAPnb : 4 bits
T Le Faucheur et. al 28
This indicates the `LSP Type'. The following values are MPLS Support of Diff-Serv February 00
specified:
T Value LSP type Indicates the number of MAP entries included in the DIFFSERV
00 E-LSP Object. This can be set to any value from 1 to 8 (decimal).
01 L-LSP
PSCnb MAP : 32 bits
Each MAP entry defines the mapping between one EXP field value
and one PHB. The MAP entry has the following format:
Indicates the number of PSC values included in the TSC TLV. This 0 1 2 3
is set to 001 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PSC Value Reserved : 13 bits
This field is reserved. It must be set to zero on
transmission and must be ignored on receipt.
Encoding of the PSC field is as specified in section 4.2. EXP : 3 bits
This field contains the value of the EXP field for the
EXP<-->PHB mapping defined in this MAP entry.
5.1.2 Release Status TLV 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 section 2 of [PHBID].
As stated earlier, error codes are to specified through a new Diff-Serv TLV for an L-LSP:
Release Status TLV in LDP Label Release messages when E-LSP or L-LSP
set-up fails. The Release Status TLV has the following format:
0 1 2 3 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 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 (0x304) | Length | |U|F| Type = PSC (0x901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | |T| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur et. al 18 T:1 bit
LSP Type. This is set to 1 for an L-LSP
MPLS Support of Diff-Serv October 99
U BIT =0
If this new TLV is unknown to the LSR, the LSR must reject the Reserved : 16 bits
whole message and return a notification This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
F BIT = 0 PSC : 16 bits
The PSC indicates a PHB Scheduling Class to be supported by the
LSP. The PSC is encoded as specified in section 2 of [PHBID]:
- Where the PSC comprises a single PHB defined by standards
action, the encoding for the PSC is the encoding for this
single PHB. It is the recommended DSCP value for that PHB,
left-justified in the 16-bit field, with bits 6 through 15 set
to zero.
If this TLV is unknown to a LSR, this new TLV is NOT forwarded. Le Faucheur et. al 29
Type MPLS Support of Diff-Serv February 00
The Type of the PSC TLV is: 0x304. - Where the PSC comprises multiple PHBs defined by standards
action, the PSC encoding is the encoding for this set of PHB.
It is the smallest numerical value of the recommended DSCP for
the various PHBs in the PSC, left-justified in the 16 bit
field, with bits 6 through 13 and bit 15 set to zero and with
bit 14 set to one.
Status Code For instance, the encoding of the EF PSC is :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Indicates the reason why the label was released. This field uses For instance, the encoding of the AF1 PSC is :
the same encoding and values as the `Status Code' word defined for 0 1
the Notification message. Additional values are defined below, in 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
the section titled `Status Code Values', for this Status Code +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
field in addition to the values currently defined in [LDP]. |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.3 Status Code Values 6.2 Diff-Serv Status Code Values
The following values are defined for the Status Code field which is The following values are defined for the Status Code field of the
used in Notification message and may be used in Label Release Status TLV:
messages:
Status Code E Status Data Status Code E Status Data
Unsupported PSC value 0 0x00000016 Unsupported PHB 0 0x00000016
Unexpected PSC value 0 0x00000017 Invalid EXP<-->PHB mapping 0 0x00000017
Unexpected PSC TLV 0 0x00000018 Unsupported PSC 0 0x00000018
Unexpected LSP-Type 0 0x00000019 Unexpected Diff-Serv TLV 0 0x00000019
5.2 Diff-Serv Related LDP Messages
5.2.1 Label Request Message 6.3 Diff-Serv Related LDP Messages
In Downstream on Demand mode, the Diff-Serv capable LSR requesting a 6.3.1 Label Request Message
label for an L-LSP includes the new Diff-Serv_PSC TLV in the Label
Request message to signal that the LSP is an L-LSP and to indicate
the PSC associated with the LSP.
The format of the Label Request message for an L-LSP in Downstream The format of the Label Request message is extended as follows, to
on Demand mode, is as follows: optionally include the Diff-Serv TLV:
0 1 2 3 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 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 | |0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur et. al 19
MPLS Support of Diff-Serv October 99
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSC TLV | | Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2 Label Mapping Message Le Faucheur et. al 30
In Downstream Unsolicited mode, the Diff-Serv capable LSR allocating
a label for an L-LSP includes the Diff-Serv_PSC TLV in the Label
Mapping message to signal that the LSP is an L-LSP and to indicate
the PSC associated with the LSP.
The format of the Label Mapping message for an L-LSP in Downstream
Unsolicited mode, is as follows:
0 1 2 3 MPLS Support of Diff-Serv February 00
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In Downstream on Demand mode, the Diff-Serv capable LSR allocating a 6.3.2 Label Mapping Message
label for an L-LSP in response to a Label Request message containing
the Diff-Serv_PSC TLV, may optionally include the same Diff-Serv_PSC
TLV in the Label Mapping message to confirm the PSC associated with
the LSP.
The format of the Label Mapping message for an L-LSP in Downstream The format of the Label Mapping message is extended as follows, to
Unsolicited mode, is as follows: optionally include the Diff-Serv TLV:
0 1 2 3 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 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 | |0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV | | Label TLV |
Le Faucheur et. al 20
MPLS Support of Diff-Serv October 99
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSC TLV (optional) | | Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.3 Label Release Message 6.3.3 Label Release Message
[LDP] specifies that `an LSR sends a Label Release message to an LDP
peer to signal the peer that the LSR no longer needs specific FEC-
label mappings previously requested of and/or advertised by the
peer.'
This specification extends the use of the Label Release message so
that, when an LSR cannot accept a label mapping for an E-LSP or an
L-LSP, the LSR should send a Label Release message to the LDP Peer
to signal the peer that the LSR cannot accept the label mapping.
This specification also extends the encoding of the Label Release The format of the Label Release message is extended as follows, to
message so that the new Release Status TLV can optionally be optionally include the Status TLV:
included in the message. Thus the encoding of the Label Release
message is:
0 1 2 3 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 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 | |0| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) | | Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Release Status TLV (optional) | | Status TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.4 Notification Message 6.3.4 Notification Message
This specification allows inclusion of the Diff-Serv_PSC TLV in the The format of the Notification message is extended as follows, to
Notification. Thus the encoding of the Notification message is: optionally include the Diff-Serv TLV:
0 1 2 3 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 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 | |0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV | | Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
Le Faucheur et. al 21 Le Faucheur et. al 31
MPLS Support of Diff-Serv October 99 MPLS Support of Diff-Serv February 00
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv_PSC TLV (optional) | | Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3 Handling of the Diff-Serv_PSC TLV 6.4 Handling of the Diff-Serv TLV
5.3.1 Handling of the Diff-Serv_PSC TLV in Downstream Unsolicited Mode 6.3.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode
This section describes operations when the Downstream Unsolicited This section describes operations when the Downstream Unsolicited
Mode is used. Mode is used.
When allocating a label for an E-LSP, a Diff-Serv capable LSR issues When allocating a label for an E-LSP which is to use the
a Label Mapping message without the Diff-Serv_PSC TLV. preconfigured EXP<-->PHB mapping, a downstream Diff-Serv LSR issues
a Label Mapping message without the Diff-Serv TLV.
A Diff-Serv capable LSR receiving a Label Mapping message without When allocating a label for an E-LSP which is to use a signaled
the Diff-Serv_PSC TLV, must: EXP<-->PHB mapping, a downstream Diff-Serv LSR issues a Label
- update its Incoming Label Map (ILM) [MPLS_ARCH] to store the Mapping message with the Diff-Serv TLV for an E-LSP which contains
necessary Diff-Serv information. This includes the fact that the one MAP entry for each EXP value to be supported on this E-LSP.
Next Hop Label Forwarding Entry (NHLFE) corresponds to an E-LSP.
- install the required scheduling and dropping behavior for
this NHLFE to support Diff-Serv forwarding as specified for E-LSPs
in section 2.2.
When allocating a label for an L-LSP, a Diff-Serv capable LSR issues When allocating a label for an L-LSP, a downstream Diff-Serv LSR
a Label Mapping message which contains the Diff-Serv_PSC TLV with issues a Label Mapping message with the Diff-Serv TLV for an L-LSP
its PSC field indicating the PSC of the L-LSP. which contains the PHB Scheduling Class (PSC) to be supported on
this L-LSP.
A Diff-Serv capable LSR receiving a Label Mapping message containing Assuming the label set-up is successful, the downstream and upstream
the Diff-Serv_PSC TLV, must: LSRs must:
- update its ILM to store the necessary Diff-Serv information. - update the Diff-Serv context associated with the established
This includes the fact that the NHLFE corresponds to an L-LSP and LSPs in their ILM/FTN as specified in previous sections
its PSC. (incoming and outgoing label),
- install the required scheduling and dropping behavior for - install the required Diff-Serv forwarding treatment (scheduling
this LSP to support Diff-Serv forwarding as specified for L-LSPs in and dropping behavior) for this NHLFE (outgoing label).
section 3.2.
A Diff-Serv capable LSR receiving a Label Mapping message with the An upstream Diff-Serv LSR receiving a Label Mapping message with
Diff-Serv_PSC TLV containing a PSC value which is not supported, multiple Diff-Serv TLVs only considers the first one as meaningful.
must reject the mapping by sending a Label Release message which The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
includes the Label TLV and the Release Status TLV with a Status Code
of `Unsupported PSC Value'.
A Diff-Serv capable LSR receiving a Label Mapping message with An upstream Diff-Serv LSR which receives a Label Mapping message
multiple Diff-Serv_PSC TLVs only considers the first one as with the Diff-Serv TLV for an E-LSP and does not support the
meaningful. The LSR must ignore and not forward the subsequent Diff- particular PHB encoded in one, or more, of the MAP entries, must
Serv_PSC TLV(s). 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'.
5.3.2 Handling of the Diff-Serv_PSC TLV in Downstream on Demand Mode 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:
This section describes operations when the Downstream on Demand Mode Le Faucheur et. al 32
is used.
Le Faucheur et. al 22 MPLS Support of Diff-Serv February 00
MPLS Support of Diff-Serv October 99 - the MAPnb field is not within the range 1 to 8 decimal, or
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
When requesting a label for an E-LSP, a Diff-Serv capable LSR sends An upstream Diff-Serv LSR receiving a Label Mapping message with the
a Label Request message without the Diff-Serv_PSC TLV. 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'.
Optionally, when requesting a lebel for an E-LSP over which a single 6.3.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode
Ordered Aggregate is to going to be transported, the Diff-Serv
capable LSR may send a Label Request message containing the Diff-
Serv_PSC TLV with its LSP type set to E-LSP and its PSC field set to
the value of the PSC to be supported on the E-LSP.
A Diff-Serv capable LSR sending a Label Mapping message in response This section describes operations when the Downstream on Demand Mode
to a Label Request message which did not contain the Diff-Serv_PSC is used.
TLV, must not include Diff-Serv_PSC TLV in this Label Mapping
message.
A Diff-Serv capable LSR sending a Label Mapping message in response When requesting a label for an E-LSP which is to use the
to a Label Request message which contained the Diff-Serv_PSC TLV preconfigured EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a
with its E-LSP type set to E-LSP, may send this Label Mapping Label Request message without the Diff-Serv TLV.
message without the Diff-Serv_PSC TLV. Optionally, the LSR may send
this Label Mapping message with the Diff-Serv_PSC TLV with its LSP-
Type set to E-LSP and its PSC field set to the same value as the one
received in the Label Request message.
A Diff-Serv capable LSR receiving a Label Mapping message without When requesting a label for an E-LSP which is to use a signaled
the Diff-Serv_PSC TLV in response to its Label Request message for EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a Label Request
an E-LSP, must: message with the Diff-Serv TLV for an E-LSP which contains one MAP
- update its ILM to store the necessary Diff-Serv information. entry for each EXP value to be supported on this E-LSP.
This includes the fact that the NHLFE corresponds to an E-LSP.
- install the required scheduling and dropping behavior for
this NHLFE to support Diff-Serv forwarding as specified for E-LSPs
in section 2.2.
A Diff-Serv capable LSR receiving a Label Mapping message containing When requesting a label for an L-LSP, an upstream Diff-Serv LSR
the Diff-Serv_PSC TLV in response to its Label Request message for sends a Label Request message with the Diff-Serv TLV for an L-LSP
an E-LSP which did not contain the Diff-Serv_PSC TLV, must reject which contains the PSC to be supported on this L-LSP.
the label mapping by sending a Label Release message which includes
the Label TLV and the Release Status TLV with a Status Code of
`Unexpected PSC TLV'.
A Diff-Serv capable LSR receiving a Label Mapping message containing A downstream Diff-Serv LSR sending a Label Mapping message in
the Diff-Serv_PSC TLV in response to its Label Request message for response to a Label Request message for an E-LSP or an L-LSP must
an E-LSP which contained the Diff-Serv_PSC TLV, must compare the not include a Diff-Serv TLV in this Label Mapping message.
received and sent Diff-Serv_PSC TLVs.
If those are equal, the LSR must: Assuming the label set-up is successful, the downstream and upstream
- update its ILM to store the necessary Diff-Serv information. LSRs must:
This includes the fact that the NHLFE corresponds to an E-LSP. - update the Diff-Serv context associated with the established
- install the required scheduling and dropping behavior for LSPs in their ILM/FTN as specified in previous sections
this NHLFE to support Diff-Serv forwarding as specified for E-LSPs (incoming and outgoing label),
in section 2.2. - install the required Diff-Serv forwarding treatment (scheduling
and dropping behavior) for this NHLFE (outgoing label).
Le Faucheur et. al 23 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'.
MPLS Support of Diff-Serv October 99 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).
If those are not equal because they have a different LSP-Type, the A downstream Diff-Serv LSR which receives a Label Request message
LSR must reject the Label Mapping by sending a Label Release message with the Diff-Serv TLV for an E-LSP and does not support the
which includes the Label TLV and the Release Status TLV with a
Status Code of `Unexpected LSP-Type'.
If those are not equal because they have a different PSC value, the Le Faucheur et. al 33
LSR must reject the Label Mapping by sending a Label Release message
which includes the Label TLV and the Release Status TLV with a
Status Code of `Unexpected PSC Value'.
When requesting a label for an L-LSP, a Diff-Serv capable LSR sends MPLS Support of Diff-Serv February 00
a Label Request message with the Diff-Serv_PSC TLV which indicates
the PSC of the L-LSP.
A Diff-Serv capable LSR receiving a Label Request message with the particular PHB encoded in one (or more) of the MAP entries, must
Diff-Serv_PSC TLV containing a PSC value which is not supported or reject the request by sending a Notification message which includes
for which no EXP/PSC<-->PHB mapping is configured, must send a the Status TLV with a Status Code of `Unsupported PHB'.
Notification message with a Status Code of `Unsupported PSC Value'.
A Diff-Serv capable LSR that recognizes the Diff-Serv_PSC TLV Type A downstream Diff-Serv LSR receiving a Label Request message with
in a Label Request message and supports the requested PSC but is not the Diff-Serv TLV for an E-LSP and determining that the signaled
able to satisfy the label request for other reasons (eg no label 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 decimal, 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 and supports the requested PSC but is not
able to satisfy the label request for other reasons (eg. no label
available), must send a Notification message in accordance with available), must send a Notification message in accordance with
existing LDP procedures [LDP] (eg. with a `No Label Resource' Status existing LDP procedures [LDP] (eg. with a `No Label Resource' Status
Code). This Notification message must include the requested Code). This Notification message must include the requested
Diff-Serv_PSC TLV. Diff-Serv TLV.
A Diff-Serv capable LSR sending a Label Mapping message in response
to a Label Request message which contained the Diff-Serv_PSC TLV,
may optionally include the exact same Diff-Serv_PSC TLV in this
Label Mapping message.
A Diff-Serv capable LSR receiving a Label Mapping message without
the Diff-Serv_PSC TLV in response to its Label Request message for
an L-LSP, must:
- update its ILM to store the necessary Diff-Serv information.
This includes the fact that the NHLFE corresponds to an L-LSP and
its PSC.
- install the required scheduling and dropping behavior for
this NHLFE to support Diff-Serv forwarding as specified for L-LSPs
in section 3.2.
A Diff-Serv capable LSR receiving a Label Mapping message with the
Diff-Serv_PSC TLV in response to its Label Request message for an L-
LSP, must verify that the Diff-Serv_PSC TLV received in the Label
Mapping message is equal to the Diff-Serv_PSC TLV sent in the Label
Request message.
If those are equal, the LSR must:
- update its ILM to store the necessary Diff-Serv information.
This includes the fact that the NHLFE corresponds to an L-LSP and
its PSC
Le Faucheur et. al 24
MPLS Support of Diff-Serv October 99
- install the required scheduling and dropping behavior for
this NHLFE to support Diff-Serv forwarding as specified for L-LSPs
in section 3.2.
If those are not equal because they have a different LSP-Type, the
LSR must reject the Label Mapping by sending a Label Release message
which includes the Label TLV and the Release Status TLV with a
Status Code of `Unexpected LSP-Type'.
If those are not equal because they have a different PSC value, the
LSR must reject the Label Mapping by sending a Label Release message
which includes the Label TLV and the Release Status TLV with a
Status Code of `Unexpected PSC Value'.
A Diff-Serv capable LSR receiving a Label Mapping message with
multiple Diff-Serv_PSC TLVs only considers the first one as
meaningful. The LSR must ignore and not forward the subsequent Diff-
Serv_PSC TLV(s).
5.4 Non-Handling of the Diff-Serv_PSC TLV 6.4 Non-Handling of the Diff-Serv TLV
An LSR that does not recognize the Diff-Serv_PSC TLV Type, on An LSR that does not recognize the Diff-Serv TLV Type, on receipt of
receipt of a Label Request message or a Label Mapping message a Label Request message or a Label Mapping message containing the
containing the Diff-Serv_PSC TLV, must ignore the message and return Diff-Serv TLV, must behave in accordance with the procedures
a Notification message with _Unknown TLV_ Status. specified in [LDP] for an unknown TLV whose U Bit and F Bit are set
to 0 ie. it must ignore the message, return a Notification message
with `Unknown TLV' Status.
5.5 Bandwidth Information 6.5 Bandwidth Information
Bandwidth information may also be signaled at establishment time of Bandwidth information may also be signaled at establishment time of
E-LSP and L-LSP, for instance for the purpose of Traffic E-LSP and L-LSP, for instance for the purpose of Traffic
Engineering, using the Traffic Parameters TLV as described in Engineering, using the Traffic Parameters TLV as described in
[MPLS CR LDP]. [MPLS CR LDP].
6. MPLS Support of Diff-Serv over PPP 7. MPLS Support of Diff-Serv over PPP
The general operations for MPLS support of Diff-Serv, including The general operations for MPLS support of Diff-Serv, including
label forwarding and LSP setup operations was specified in the label forwarding and LSP setup operations are specified in the
previous sections. This section describes the specific operations previous sections. This section describes the specific operations
required for MPLS support of Diff-Serv over PPP links. While required for MPLS support of Diff-Serv over PPP links. While
sections 7, 8 and 9 focus on other media specific operations, namely
ATM, Frame Relay and LAN respectively.
This document allows the following set of LSP setup combinations per
FEC within an MPLS PPP Diff-Serv domain:
- Zero or any number of E-LSP, and
- Zero or any number of L-LSPs.
6.1. E-LSP Operations over PPP
Le Faucheur et. al 25
MPLS Support of Diff-Serv October 99
Since MPLS uses the Shim Header for encapuslation over PPP, E-LSPs
are supported over PPP. The E-LSP setup, label forwarding and
merging operations over PPP follows exactly the procedures defined
in section 2. No additional PPP specific procedures are defined for
E-LSPs.
6.2 L-LSP Operations over PPP
L-LSPs are also supported over PPP. The L-LSP operations over PPP
follows the general procedures of section 3. However, the following
PPP specific procedures are also defined for L-LSP operations over
PPP :
- An MPLS PPP ingress interface determines the incoming PHB
from the PSC and the EXP field of the top level label entry in
accordance with the PSC/EXP -->PHB mappings defined below in section
6.3.
- If the EXP field value of a packet received on an L-LSP is Le Faucheur et. al 34
such that the PSC/EXP combination is not listed in the mapping of
section 6.3, this PSC/EXP combination should be considered invalid.
LSR behavior in such situation is a local matter and is outside the
scope of this document.
- An MPLS PPP egress interface determines the value to be
written in the EXP field of the top level label entry (and possibly
of other level label entries in the case of a hierarchical tunnel
entry) by performing the outgoing PHB-->EXP/PSC mapping defined
below in section 6.4.
6.3 PSC/EXP --> PHB mapping
The mapping from the L-LSP PSC and the EXP field of the shim header
into PHBs is as follows:
EXP Field PSC PHB
000 DF -----> DF
000 CSn -----> CSn
000 AFCn -----> AFn1
001 AFCn -----> AFn2
010 AFCn -----> AFn3
000 EF -----> EF
6.4 PHB --> PSC/EXP mapping
The mapping from PHBs into the L-LSP PSC and the EXP field of the
shim header is as follows:
PHB EXP Field PSC MPLS Support of Diff-Serv February 00
DF -----> 000 DF sections 8, 9 and 10 focus on other media specific operations,
namely ATM, Frame Relay and LAN respectively.
Le Faucheur et. al 26 This document allows any of the following LSP combinations per FEC
within an MPLS PPP Diff-Serv domain:
MPLS Support of Diff-Serv October 99 - Zero or any number of E-LSP, and
- Zero or any number of L-LSPs.
CSn -----> 000 CSn 7.1 LSR implementation with PPP interfaces
AFn1 -----> 000 AFCn
AFn2 -----> 001 AFCn
AFn3 -----> 010 AFCn
EF -----> 000 EF
6.5 LSR implementation with PPP interfaces A Diff-Serv capable LSR with PPP interfaces MUST support, over these
PPP interfaces, E-LSPs which use the pre-configured EXP<-->PHB
mapping, in compliance with all the material from this specification
pertaining to those types of LSPs.
For an LSR implementation with PPP interfaces, support of E-LSPs A Diff-Serv capable LSR with PPP interfaces MAY support, over these
over the PPP interfaces is mandatory with respect to this PPP interfaces, E-LSPs which use a signaled EXP<-->PHB mapping. If a
specification. A Diff-Serv capable LSR with PPP interfaces MUST Diff-Serv LSR does support E-LSPs which use a signaled EXP<-->PHB
support E-LSPs over these PPP interfaces in compliance with this mapping over PPP interfaces, then it MUST do so in compliance with
specification. all the material from this specification pertaining to those types
of LSPs.
Support of L-LSPs over PPP interfaces by an LSR implementation is A Diff-Serv capable LSR with PPP interfaces MAY support L-LSPs over
optional. A Diff-Serv capable LSR MAY support L-LSPs over PPP these PPP interfaces. If a Diff-Serv LSR does support L-LSPs over
interfaces. However, if a Diff-Serv LSR does support L-LSPs over PPP PPP interfaces, then it MUST do so in compliance with all the
interfaces, then it MUST do so in compliance with all the material material from this specification pertaining to L-LSPs.
from this specification pertaining to L-LSPs.
An LSR running MPLS over PPP over a traditional ATM connection (ie An LSR running MPLS over PPP over a traditional ATM connection (ie.
where the ATM switches do not participate in MPLS and where the ATM where the ATM switches do not participate in MPLS and where the ATM
connection VPI/VCI values have not been established via any label connection VPI/VCI values have not been established via any label
distribution protocol) is to be considered as an LSR with PPP distribution protocol) is to be considered as an LSR with PPP
interfaces from the point of view of compliance to this interfaces from the point of view of compliance to this
specification. specification.
Similarly, an LSR running MPLS over PPP over a traditional Frame Similarly, an LSR running MPLS over PPP over a traditional Frame
Relay connection (ie where the Frame Realy switches do not Relay connection (ie. where the Frame Relay switches do not
participate in MPLS and where the Frame Relay connection DLCI values participate in MPLS and where the Frame Relay connection DLCI values
have not been established via any label distribution protocol) is to have not been established via any label distribution protocol) is to
be considered as an LSR with PPP interfaces from the point of view be considered as an LSR with PPP interfaces from the point of view
of compliance to this specification. of compliance to this specification.
7. MPLS Support of Diff-Serv by ATM LSRs 8. MPLS Support of Diff-Serv by ATM LSRs
The general operations for MPLS support of Diff-Serv, including The general operations for MPLS support of Diff-Serv, including
label forwarding and LSP setup operations was specified in the label forwarding and LSP setup operations was specified in the
previous sections. This section describes the specific operations previous sections. This section describes the specific operations
required for MPLS support of Diff-Serv over ATM links. required for MPLS support of Diff-Serv over ATM links.
This document allows the following set of LSP setup combinations per This document allows the following set of LSP combinations per FEC
FEC within an MPLS ATM Diff-Serv domain: within an MPLS ATM Diff-Serv domain:
- any number of L-LSPs.
7.1 L-LSP Operations over ATM
The L-LSP operations over ATM follows the general procedures of
section 3. However, the following ATM specific procedures are also
defined for L-LSP operations over ATM links :
Le Faucheur et. al 27
MPLS Support of Diff-Serv October 99
- An MPLS ATM ingress interface determines the incoming PHB
from the PSC and the ATM Cell Loss Probability (CLP) bit in
accordance with the incoming PSC/CLP-->PHB mapping defined
below in section 7.2;
- If the CLP value of a packet received on an L-LSP is such that
the PSC/CLP combination is not listed in the mapping of section
7.2, this PSC/CLP combination should be considered invalid. LSR
behavior in such situation is a local matter and is outside the
scope of this document.
- An MPLS ATM egress interface determines the value to be
written in the ATM Cell Loss Probability (CLP) bit by
performing the outgoing PHB-->PSC/CLP mapping defined below in
section 7.3. This is performed by an LSR on the Edge of the ATM
Diff-Serv MPLS Cloud and is performed by an ATM LSR in the
middle of the ATM Diff-Serv MPLS cloud when doing optional
Local Policy and Traffic Conditioning. When not doing optional
Local Policy and Traffic Conditioning, an LSR in the middle of
the ATM Diff-Serv MPLS cloud may simply leave the CLP bit
untouched;
- when packet is segmented to cells on edge LSR, all cells of
the packet SHOULD be encoded with the same CLP bit value.
7.2 PSC/CLP --> PHB mapping
The mapping from L-LSP PSC and CLP bit of the ATM cell header into
PHBs is as follows:
CLP Bit PSC PHB
0 DF -----> DF
0 CSn -----> CSn
0 AFCn -----> AFn1
1 AFCn -----> AFn2 / AFn3
0 EF -----> EF
Since there is only one bit for encoding the PHB drop precedence
value over ATM links, only two different drop precedence levels are
supported in ATM LSRs. The behaviour for AF MUST comply to
procedures described in [DIFF_AF] for the case when only two drop
precedence levels are supported.
7.3 PHB --> PSC/CLP mapping
The mapping from PHBs into the L-LSP PSC and the CLP bit of the ATM
cell header is as follows:
PHB CLP Bit PSC
Le Faucheur et. al 28 Le Faucheur et. al 35
MPLS Support of Diff-Serv October 99 MPLS Support of Diff-Serv February 00
DF -----> 0 DF - any number of L-LSPs.
CSn -----> 0 CSn
AFn1 -----> 0 AFCn
AFn2 -----> 1 AFCn
AFn3 -----> 1 AFCn
EF -----> 0 EF
7.4 Merging 8.1 Merging
The use of merging is optional. In case that merging of ATM LSPs is The use of merging is optional. In case that merging of ATM LSPs is
used, procedures described in section 3.5. of this specification used, procedures described in section 3.6 of this specification
apply. Additionally, to avoid cell interleaving problems with AAL-5 apply. Additionally, to avoid cell interleaving problems with AAL-5
merging, procedures specified in [MPLS ATM] MUST be followed. merging, procedures specified in [MPLS ATM] MUST be followed.
7.5 Use of ATM Traffic Classes and Traffic Management mechanisms 8.2 Use of ATM Traffic Classes and Traffic Management mechanisms
The use of the ATM traffic classes as specified by ITU-T and ATM- The use of the ATM traffic classes as specified by ITU-T and ATM-
Forum or of vendor specific ATM traffic classes is outside of the Forum or of vendor specific ATM traffic classes is outside of the
scope of this specification. The only requirement for compliant scope of this specification. The only requirement for compliant
implementation is that the forwarding behaviour experienced by a implementation is that the forwarding behavior experienced by a
Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be
compliant with the corresponding Diff-Serv PHB specifications. compliant with the corresponding Diff-Serv PHB specifications.
Since there is only one bit for encoding the PHB drop precedence
value over ATM links, only two different drop precedence levels are
supported in ATM LSRs. The behavior for AF MUST comply to procedures
described in [DIFF_AF] for the case when only two drop precedence
levels are supported.
To avoid discarding parts of the packets, frame discard mechanisms, To avoid discarding parts of the packets, frame discard mechanisms,
such as Early Packet Discard (EPD) SHOULD be enabled in the ATM-LSRs such as Early Packet Discard (EPD) SHOULD be enabled in the ATM-LSRs
for all PHBs described in this document. for all PHBs described in this document.
7.6 LSR Implementation With ATM Interfaces 8.3 LSR Implementation With ATM Interfaces
For an LSR implementation with ATM interfaces running native ATM A Diff-Serv capable LSR with ATM interfaces MUST support L-LSPs over
MPLS, support of L-LSPs over the ATM interfaces is mandatory with these ATM interfaces in compliance with all the material from this
respect to this specification. A Diff-Serv capable LSR with ATM specification pertaining to those types of LSPs. Additionally,
interfaces MUST support L-LSPs over these ATM interfaces in procedures specified in [MPLS ATM] MUST be followed by compliant
compliance with this specification. Additionally, procedures
specified in [MPLS ATM] MUST be followed by compliant
implementation. implementation.
Support of E-LSPs over ATM interfaces running native ATM MPLS by an Support of E-LSPs over ATM interfaces running native ATM MPLS by an
LSR implementation is not allowed. LSR implementation is not allowed.
8. MPLS Support of Diff-Serv by Frame Relay LSRs 9. MPLS Support of Diff-Serv by Frame Relay LSRs
The general operations for MPLS support of Diff-Serv, including The general operations for MPLS support of Diff-Serv, including
label forwarding and LSP setup operations was specified in the label forwarding and LSP setup operations was specified in the
previous sections. This section describes the specific operations previous sections. This section describes the specific operations
required for MPLS support of Diff-Serv over Frame Relay links. required for MPLS support of Diff-Serv over Frame Relay links.
This document allows the following set of LSP setup combinations per This document allows the following set of LSP combinations per FEC
FEC within an MPLS Frame Relay Diff-Serv domain: within an MPLS Frame Relay Diff-Serv domain:
- any number of L-LSPs. - any number of L-LSPs.
Le Faucheur et. al 29 9.1 Merging
MPLS Support of Diff-Serv October 99
8.1 L-LSP Operations over Frame Relay
The L-LSP operations over Frame Relay follows the general procedures
of section 3. However, the following Frame Relay specific procedures
are also defined for L-LSP operations over Frame Relay links :
- An MPLS Frame Relay ingress interface determines the incoming
PHB from the PSC and the Frame Relay Discard Eligible(DE) bit
in accordance with the incoming PSC/CLP-->PHB mapping defined
below in section 8.2;
- If the DE value of a packet received on an L-LSP is such that
the PSC/DE combination is not listed in the mapping of section
8.2, this PSC/DE combination should be considered invalid. LSR
behavior in such situation is a local matter and is outside the
scope of this document.
- An MPLS Frame Relay egress interface determines the value to
be written in the Frame Relay Discard Eligible (DE) bit by
performing the outgoing PHB-->PSC/DE mapping defined below in
section 8.3. This is performed by an LSR on the Edge of the
Frame Relay Diff-Serv MPLS Cloud and is performed by an Frame
Relay LSR in the middle of the Frame Relay Diff-Serv MPLS cloud
when doing optional Local Policy and Traffic Conditioning. When
not doing optional Local Policy and Traffic Conditioning, an
LSR in the middle of the Frame Relay Diff-Serv MPLS cloud may
simply leave the DE bit untouched;
8.2 PSC/DE --> PHB mapping
The mapping from L-LSP PSC and DE bit of the Frame Relay header into
PHBs is as follows:
DE Bit PSC PHB
0 DF -----> DF
0 CSn -----> CSn
0 AFCn -----> AFn1
1 AFCn -----> AFn2 / AFn3
0 EF -----> EF
Since there is only one bit for encoding the PHB drop precedence
value over Frame Relay links, only two different drop precedence
levels are supported in Frame Relay LSRs. The behaviour for AF MUST
comply to procedures described in [DIFF_AF] for the case when only
two drop precedence levels are supported.
8.3 PHB --> PSC/DE mapping
The mapping from PHBs into the L-LSP PSC and the DE bit of the Frame
Relay header is as follows:
Le Faucheur et. al 30
MPLS Support of Diff-Serv October 99
PHB DE Bit PSC
DF -----> 0 DF Le Faucheur et. al 36
CSn -----> 0 CSn
AFn1 -----> 0 AFCn
AFn2 -----> 1 AFCn
AFn3 -----> 1 AFCn
EF -----> 0 EF
8.4 Merging MPLS Support of Diff-Serv February 00
The use of merging is optional. In case that merging of Frame Relay The use of merging is optional. In case that merging of Frame Relay
LSPs is used, procedures described in section 3.5. of this LSPs is used, procedures described in section 3.6 of this
specification apply as well as procedures in [MPLS FR]. specification apply as well as procedures in [MPLS FR].
8.5 Use of Frame Relay Traffic parameters and Traffic Management 9.2 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms mechanisms
The use of the Frame Relay traffic parameters as specified by ITU-T The use of the Frame Relay traffic parameters as specified by ITU-T
and Frame Relay-Forum or of vendor specific Frame Relay traffic and Frame Relay-Forum or of vendor specific Frame Relay traffic
management mechanisms is outside of the scope of this specification. management mechanisms is outside of the scope of this specification.
The only requirement for compliant implementation is that the The only requirement for compliant implementation is that the
forwarding behavior experienced by a Behavior Aggregate forwarded forwarding behavior experienced by a Behavior Aggregate forwarded
over an L-LSP by the Frame Relay LSR MUST be compliant with the over an L-LSP by the Frame Relay LSR MUST be compliant with the
corresponding Diff-Serv PHB specifications. corresponding Diff-Serv PHB specifications.
8.6 LSR Implementation With Frame Relay Interfaces Since there is only one bit for encoding the PHB drop precedence
value over Frame Relay links, only two different drop precedence
levels are supported in Frame Relay LSRs. The behavior for AF MUST
comply to procedures described in [DIFF_AF] for the case when only
two drop precedence levels are supported.
For an LSR implementation with Frame Relay interfaces running native 9.3 LSR Implementation With Frame Relay Interfaces
Frame Relay MPLS, support of L-LSPs over the Frame Relay interfaces
is mandatory with respect to this specification. A Diff-Serv capable A Diff-Serv capable LSR with Frame Relay interfaces MUST support
LSR with Frame Relay interfaces MUST support L-LSPs over these Frame L-LSPs over these Frame Relay interfaces in compliance with all the
Relay interfaces in compliance with this specification. material from this specification pertaining to those types of LSPs.
Support of E-LSPs over Frame Relay interfaces running native Frame Support of E-LSPs over Frame Relay interfaces running native Frame
Relay MPLS by an LSR implementation is not allowed. Relay MPLS by an LSR implementation is not allowed.
9. MPLS Support of Diff-Serv over LAN Media 10. MPLS Support of Diff-Serv over LAN Media
The general operations for MPLS support of Diff-Serv, including The general operations for MPLS support of Diff-Serv, including
label forwarding and LSP setup operations was specified in the label forwarding and LSP setup operations was specified in the
previous sections. This section describes the specific operations previous sections. This section describes the specific operations
required for MPLS support of Diff-Serv over LAN. required for MPLS support of Diff-Serv over LAN.
This document allows the following set of LSP setup combinations per This document allows the following set of LSP setup combinations per
FEC over an MPLS link: FEC over an MPLS link:
- Zero or any number of E-LSP, and - Zero or any number of E-LSP, and
- Zero or any number of L-LSPs. - Zero or any number of L-LSPs.
Le Faucheur et. al 31 10.1 LSR Implementation With LAN Interfaces
MPLS Support of Diff-Serv October 99
9.1. E-LSP Operations over PPP
Text to be written (in particular regarding use of 802.1 COS field).
9.2 L-LSP Operations over PPP
Text to be written (in particular regarding use of 802.1 COS field).
9.3 LSR Implementation With LAN Interfaces
For an LSR implementation with LAN interfaces, support of E-LSPs
over the LAN interfaces is mandatory with respect to this
specification. A Diff-Serv capable LSR with LAN interfaces MUST
support E-LSPs over these LAN interfaces in compliance with this
specification.
Support of L-LSPs over LAN interfaces by an LSR implementation is
optional. A Diff-Serv capable LSR MAY support L-LSPs over LAN
interfaces. However, if a Diff-Serv LSR does support L-LSPs over LAN
interfaces, then it MUST do so in compliance with all the material
from this specification pertaining to L-LSPs.
10. Operations at MPLS Diff-Serv Boundaries A Diff-Serv capable LSR with LAN interfaces MUST support, over these
LAN interfaces, E-LSPs which use the pre-configured EXP<-->PHB
mapping, in compliance with all the material from this specification
pertaining to those types of LSPs.
10.1 Operations at E-LSP/L-LSP Boundary Within Single MPLS Diff-Serv Le Faucheur et. al 37
Domain
Text to be added MPLS Support of Diff-Serv February 00
10.2 Operations At Boundary across Diff-Serv domains A Diff-Serv capable LSR with LAN interfaces MAY support, over these
LAN interfaces, E-LSPs which use a signaled EXP<-->PHB mapping. If a
Diff-Serv LSR does support E-LSPs which use a signaled EXP<-->PHB
mapping over LAN interfaces, then it MUST do so in compliance with
all the material from this specification pertaining to those types
of LSPs.
Text to be added A Diff-Serv capable LSR MAY support L-LSPs over LAN interfaces. If a
Diff-Serv LSR does support L-LSPs over LAN interfaces, then it MUST
do so in compliance with all the material from this specification
pertaining to L-LSPs.
11. Explicit Congestion Notification 11. Explicit Congestion Notification
Explicit Congestion Notification is described in [ECN] and is Explicit Congestion Notification is described in [ECN] and is
proposed as an Experimental extension to the IP protocol. proposed as an Experimental extension to the IP protocol.
[MPLS_ECN] discusses deployment of ECN in an MPLS network using the [MPLS_ECN] discusses deployment of ECN in an MPLS network using the
Shim Header as the MPLS encapsulation. It demonstrates that, Shim Header as the MPLS encapsulation. It demonstrates that,
provided a given LSP is identified as ECN-capable or as non-ECN- provided a given LSP is identified as ECN-capable or as non-ECN-
capable (and consistently recognized as such by all the involved capable (and consistently recognized as such by all the involved
LSRs), then ECN can be supported in an MPLS domain where the Shim LSRs), then ECN can be supported in an MPLS domain where the Shim
Header is used as the MPLS encapsulation via a single bit of the EXP Header is used as the MPLS encapsulation via a single bit of the EXP
field. field.
The details of how a given LSP is to be identified as ECN-capable or The details of how a given LSP is to be identified as ECN-capable or
non-ECN-capable (whether via extensions to the LSP establishment non-ECN-capable (whether via extensions to the LSP establishment
signaling and procedures, via configuration or via other means) are signaling and procedures, via configuration or via other means) are
outside the scope of this specification. outside the scope of this specification.
Le Faucheur et. al 32
MPLS Support of Diff-Serv October 99
However, this specification recognizes that, within an ECN-capable However, this specification recognizes that, within an ECN-capable
MPLS domain where LSPs are identified as ECN-capable or not-ECN- MPLS domain where LSPs are identified as ECN-capable or not-ECN-
capable: capable:
- Support of ECN does not require that any bit(s) from the EXP - Support of ECN does not require that any bit(s) from the EXP
field be reserved for ECN operations across all LSPs even when those field be reserved for ECN operations across all LSPs even when
LSPs are not ECN-capable. Consequently, LSPs identified as non-ECN- those LSPs are not ECN-capable. Consequently, LSPs identified as
capable (regardless of whether this is because at least one LSR on non-ECN-capable (regardless of whether this is because at least
the LSP does not support ECN operations or whether this is because one LSR on the LSP does not support ECN operations or whether
the network administrator does not wish to use ECN on this LSP) can this is because the network administrator does not wish to use
make use of the full 3-bit EXP field for Diff-Serv purposes. Thus, ECN on this LSP) can make use of the full 3-bit EXP field for
non-ECN-capable E-LSPs and non-ECN-capable L-LSPs can operate as Diff-Serv purposes. Thus, non-ECN-capable E-LSPs and non-ECN-
defined earlier in this document without any restriction imposed by capable L-LSPs can operate as defined earlier in this document
the fact that the MPLS domain is ECN-capable. In particular, up to 8 without any restriction imposed by the fact that the MPLS domain
BAs can still be transported over a non-ECN-capable E-LSP within an is ECN-capable. In particular, up to 8 BAs can still be
ECN-capable MPLS domain. Similarly, non-ECN-capable L-LSPs within an transported over a non-ECN-capable E-LSP within an ECN-capable
ECN-capable MPLS domain can support all the drop precedence levels MPLS domain. Similarly, non-ECN-capable L-LSPs within an ECN-
of currently defined PSCs. Should a future PSC involve more than 4 capable MPLS domain can support all the drop precedence levels
drop precedence levels, non-ECN-capable L-LSPs within an ECN-capable of currently defined PSCs. Should a future PSC involve more than
MPLS domain could still use the full 3-bit field EXP. 4 drop precedence levels, non-ECN-capable L-LSPs within an ECN-
- Because a single bit is required to encode the ECN Le Faucheur et. al 38
information inside the ECN-capable MPLS domain, LSPs identified as
ECN-capable can make use of two bits of the EXP field value. In MPLS Support of Diff-Serv February 00
particular, up to 4 BAs can be transported over an ECN-capable E-
LSP. Similarly, up to 4 drop precedence levels can be supported over capable MPLS domain could still use the full 3-bit field EXP.
an ECN-capable L-LSP; since all the PSCs corresponding to PHBs
currently defined through standards action involve less than 4 drop - Because a single bit is required to encode the ECN information
precedence levels, ECN support does not currently restrict Diff-Serv inside the ECN-capable MPLS domain, LSPs identified as ECN-
operations over L-LSPs. Should a PSC corresponding to future PHBs capable can make use of two bits of the EXP field value for
defined by standards action or corresponding to local use or Diff-Serv purposes. In particular, up to 4 BAs can be
experimental PHBs, involve more than 4 drop precedence levels, then transported over an ECN-capable E-LSP. Similarly, up to 4 drop
ECN support over the corresponding LSP would constrain the PSC to 4 precedence levels can be supported over an ECN-capable L-LSP;
drop precedence levels; relative benefits of additional precedence since all the PSCs corresponding to PHBs currently defined
levels beyond 4, would then be weighted by the network administrator through standards action involve less than 4 drop precedence
over the benefits of ECN, to determine whether it is preferable to levels, ECN support does not currently restrict Diff-Serv
support this PSC over an ECN-capable or non-ECN-capable LSP. operations over L-LSPs. Should a PSC corresponding to future
PHBs defined by standards action or corresponding to local use
or experimental PHBs, involve more than 4 drop precedence
levels, then ECN support over the corresponding LSP would
constrain the PSC to 4 drop precedence levels; relative benefits
of additional precedence levels beyond 4, would then be weighted
by the network administrator over the benefits of ECN, to
determine whether it is preferable to support this PSC over an
ECN-capable or non-ECN-capable LSP.
11.1 MPLS ECN bit with Shim Header 11.1 MPLS ECN bit with Shim Header
Where the Shim Header is used as the MPLS encapsulation, ECN Where the Shim Header is used as the MPLS encapsulation, ECN
information is to be encoded on ECN-capable LSPs in the first bit of information is to be encoded on ECN-capable LSPs in the first bit of
the 3-bit EXP field in the following way: the 3-bit EXP field in the following way:
EXP field MPLS ECN Meaning EXP field MPLS ECN Meaning
0xx --> `ECT, not CE' 0xx --> `ECT, not CE'
1xx --> `not ECT, or ECT+CE' 1xx --> `not ECT, or ECT+CE'
where ECT stands for `ECN Capable Transport' and `CE' stands for where ECT stands for `ECN Capable Transport' and `CE' stands for
`Congestion experienced'. `Congestion experienced'.
Le Faucheur et. al 33
MPLS Support of Diff-Serv October 99
Detailed specification for usage of this MPLS ECN bit is outside the Detailed specification for usage of this MPLS ECN bit is outside the
scope of this specification. scope of this document.
For ECN-capable E-LSPs, the PHB<-->EXP mapping defined above in the For ECN-capable E-LSPs using preconfigured mapping, the
section titled `PHB<-->EXP Field Mapping' and configured on the LSR Preconfigured EXP<-->PHB mapping defined above in section 3.2.1 is
is only operating over the last 2 bits of the 3-bit EXP field. Thus only operating over the last 2 bits of the 3-bit EXP field. For ECN-
it has the following format: capable E-LSPs using signaled mapping, the signaled EXP<-->PHB
mapping is only operating over the last 2 bits of the 3-bit EXP
field. Thus it has the following format:
EXP Field PHB EXP Field PHB
e00 <-----> a given PHB e00 <-----> a given PHB
e01 <-----> a given PHB e01 <-----> a given PHB
e10 <-----> a given PHB e10 <-----> a given PHB
e11 <-----> a given PHB e11 <-----> a given PHB
Le Faucheur et. al 39
MPLS Support of Diff-Serv February 00
where `e' is the MPLS ECN bit and can take the value zero or one where `e' is the MPLS ECN bit and can take the value zero or one
depending on ECN operations. depending on ECN operations.
For ECN-capable L-LSPs, the PSC/EXP-->PHB mapping defined above in For ECN-capable L-LSPs, the `EXP/PSC-->PHB mapping' defined above in
the section titled `PSC/EXP-->PHB is only operating over the last 2 section 4.2.1.1 is only operating over the last 2 bits of the 3-bit
bits of the 3-bit EXP field and is the following: EXP field and is the following:
EXP Field PSC PHB EXP Field PSC PHB
e00 DF -----> DF e00 DF -----> DF
e00 CSn -----> CSn e00 CSn -----> CSn
e00 AFCn -----> AFn1 e00 AFn -----> AFn1
e01 AFCn -----> AFn2 e01 AFn -----> AFn2
e10 AFCn -----> AFn3 e10 AFn -----> AFn3
e00 EF -----> EF e00 EF -----> EF
where `e' is the MPLS ECN bit and can take the value zero or one where `e' is the MPLS ECN bit and can take the value zero or one
depending on ECN operations. depending on ECN operations.
For ECN-capable L-LSPs, the PHB--> PSC/EXP mapping defined above in For ECN-capable L-LSPs, the `PHB--> PSC/EXP mapping' defined above
the section titled `PHB--> PSC/EXP Mapping' is only operating over in the section 4.4.1.1 is only operating over the last 2 bits of the
the last 2 bits of the 3-bit EXP field and is the following: 3-bit EXP field and is the following:
PHB EXP Field PSC PHB EXP Field PSC
DF -----> e00 DF DF -----> e00 DF
CSn -----> e00 CSn CSn -----> e00 CSn
AFn1 -----> e00 AFCn AFn1 -----> e00 AFn
AFn2 -----> e01 AFCn AFn2 -----> e01 AFn
AFn3 -----> e10 AFCn AFn3 -----> e10 AFn
EF -----> e00 EF EF -----> e00 EF
where `e' is the MPLS ECN bit and can take the value zero or one where `e' is the MPLS ECN bit and can take the value zero or one
depending on ECN operations. depending on ECN operations.
Le Faucheur et. al 34
MPLS Support of Diff-Serv October 99
For non-ECN-capable LSPs, the first bit of the 3-bit EXP field is For non-ECN-capable LSPs, the first bit of the 3-bit EXP field is
NOT reserved for ECN and can be used to encode any Diff-Serv NOT reserved for ECN and can be used to encode any Diff-Serv
information. In particular, for non-ECN-capable E-LSPs, the information. In particular, for non-ECN-capable E-LSPs, the
PHB<-->EXP mapping defined in the section titled `PHB<-->EXP Field EXP<-->PHB mapping defined in the section titled `EXP<-->PHB Field
Mapping' and configured on the LSR is operating over the 3 bits of Mapping' and configured on the LSR is operating over the 3 bits of
the EXP field. the EXP field.
12. Security Considerations 12. Security Considerations
This document does not introduce any new security issues beyond This document does not introduce any new security issues beyond
those inherent in Diff-Serv, MPLS and RSVP, and may use the same those inherent in Diff-Serv, MPLS and RSVP, and may use the same
mechanisms proposed for those technologies. mechanisms proposed for those technologies.
13. Acknowledgments 13. Acknowledgments
This document has benefited from discussions with K. K. Le Faucheur et. al 40
Ramakrishnan, Eric Rosen, Angela Chiu and Carol Iturralde.
APPENDIX A. Ordered Aggregate (OA) and PHB Scheduling Class (PSC)
This Appendix contains the definition of two Diff-Serv concepts:
- the Ordered Aggregate (OA)
- the PHB Scheduling Class (PSC)
In the future, it is expected that these definitions will be
incorporated in new versions of the Diff-Serv specifications.
A.1 Ordered Aggregate (OA)
[DIFF_AF] states that "a DS node does not reorder IP packets of the
same microflow if they belong to the same AF class" (even if
different packets of the microflow contain different AF codepoints
of the same AF class).
For the sake of generality, we define a set of Behavior Aggregates
which share such an ordering constraint to constitute a "Ordered
Aggregate" (OA).
A.2 PHB Scheduling Class (PSC)
We refer to the set of one or more PHBs applied to the set of
Behavior Aggregates forming a given OA, as a "PHB Scheduling Class"
(PSC).
The PHBs currently specified are Default PHB (DF), Class Selector
PHB group (CSx), Assured Forwarding PHB group (AFxy), Expedited
Forwarding PHB (EF).
Le Faucheur et. al 35
MPLS Support of Diff-Serv October 99
A.2.1 DF PSC
The Default PHB is a single PHB specified in [DIFF_Header]. Thus,
the corresponding PSC comprises a single PHB and thus coincides with
the DF PHB.
A.2.2 CSn PSC
[DIFF_HEADER] defines up to 8 CS Codepoints referred to as CSn,
where 1 <= i <= 8. [DIFF_HEADER] states that "... PHBs selected by
distinct Class Selector Codepoints SHOULD be independently
forwarded; that is, packets marked with different Class Selector
Codepoints MAY be re-ordered". Thus, there is one PSC corresponding
to each CSn PHB. Each CSn PSC comprises a single PHB and thus
coincides with this CSn PHB.
A.2.3 AFn PSC
As described in [DIFF_AF], the Assured Forwarding (AF) PHB group
provides forwarding of IP packets in N independent AF classes.
Within each AF class, an IP packet is assigned one of M different
levels of drop precedence. An IP packet that belongs to an AF class
i and has drop precedence j is marked with the AF codepoint AFij,
where 1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4)
with three levels of drop precedence in each class (M=3) are
defined for general use.
[DIFF_AF] states that "a DS node does not reorder IP packets of the
same microflow if they belong to the same AF class" (even if
different packets of the microflow contain different AF codepoints
of the same AF class). As noted above, each AF class in the AF PHB
group is the primary example of a PSC. Each PSC comprises 3 PHBs and
coincides with the AF Class. Those PSCs are thus referred to as AFn,
where 1 <= n <= 4.
A.2.4 EF PSC
[DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic
requiring forwarding with low loss, low latency, low jitter.
[DIFF_EF] defines a single PHB. Thus, the corresponding PSC
comprises a single PHB and thus coincides with the DF PHB.
A.2.5 Summary list of PSC
The following PSCs have thus been identified:
- DF
- CSn , 1 <= i <= 8
- AFn, 1 <= i <= 4
- EF
APPENDIX B. Example Deployment Scenarios MPLS Support of Diff-Serv February 00
Le Faucheur et. al 36 This document has benefited from discussions with K. K.
Ramakrishnan, Eric Rosen, Angela Chiu and Carol Iturralde.
MPLS Support of Diff-Serv October 99 APPENDIX A. Example Deployment Scenarios
This section does not provide additional specification and is only This section does not provide additional specification and is only
here to provide examples of how this flexible approach for Diff-Serv here to provide examples of how this flexible approach for Diff-Serv
support over MPLS may be deployed. Pros and cons of various support over MPLS may be deployed. Pros and cons of various
deployment options for particular environments are beyond the scope deployment options for particular environments are beyond the scope
of this document. of this document.
B.1 Scenario 1: 8 BAs, no Traffic Engineering, no Fast Reroute A.1 Scenario 1: 8 (or less) BAs, no Traffic Engineering, no Fast
Reroute
A Service Provider running 8 (or less) BAs over MPLS, not performing A Service Provider running 8 (or less) BAs over MPLS, not performing
Traffic engineering, not performing protection via Fast Reroute and Traffic engineering, not performing protection via Fast Reroute and
using MPLS Shim Header encapsulation in his/her network, may elect using MPLS Shim Header encapsulation in his/her network, may elect
to run Diff-Serv over MPLS using a single E-LSP per FEC established to run Diff-Serv over MPLS using a single E-LSP per FEC established
via LDP. via LDP. Furthermore the Service Provider may elect to use the
preconfigured EXP<-->PHB mapping.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the bi- - the Service Provider configures at every LSR the bi-directional
directional mapping between each PHB and a value of the EXP field mapping between each PHB and a value of the EXP field
(eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13)
- the Service Provider configures at every LSR, and for every - the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (eg bandwdith interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg drop allocated to AF1) and the dropping behavior for each PHB (eg
profile for AF11, AF12, AF13) drop profile for AF11, AF12, AF13)
- LSRs signal establishment of a single E-LSP per FEC using LDP - LSRs signal establishment of a single E-LSP per FEC using LDP in
in accordance with the specification above (ie no Diff-Serv_PSC TLV accordance with the specification above (ie no Diff-Serv TLV in
in LDP Label Request/Label Mapping messages to implicitly indicate LDP Label Request/Label Mapping messages to implicitly indicate
that the LSP is an E-LSP) that the LSP is an E-LSP and that it uses the preconfigured
mapping)
B.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no Fast A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no Fast
Reroute Reroute
A Service Provider running more than 8 BAs over MPLS, not performing A Service Provider running more than 8 BAs over MPLS, not performing
Traffic Engineering and not performing protection via Fast Reroute Traffic Engineering and not performing protection via Fast Reroute
and using MPLS Shim encapsulation in his/her network may elect to and using MPLS Shim encapsulation in his/her network may elect to
run Diff-Serv over MPLS using for each FEC: run Diff-Serv over MPLS using for each FEC:
- one E-LSP established via LDP to support a set of 8 (or less) - one E-LSP established via LDP and using the preconfigured
BAs, mapping to support a set of 8 (or less) BAs, AND
AND
- one L-LSP per <FEC,OA> established via LDP for support of the - one L-LSP per <FEC,OA> established via LDP for support of the
other BAs. other BAs.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the bi-
directional mapping between each PHB and a value of the EXP field
for the BAs transported over the E-LSP
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over the
E-LSP and the dropping behavior for each corresponding PHB
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over the
L-LSPs and the dropping behavior for each corresponding PHB
Le Faucheur et. al 37 Le Faucheur et. al 41
MPLS Support of Diff-Serv October 99 MPLS Support of Diff-Serv February 00
- LSRs signal establishment of a single E-LSP per FEC for the - the Service Provider configures at every LSR the bi-directional
set of E-LSP transported BAs using LDP as specified above (ie no mapping between each PHB and a value of the EXP field for the
Diff-Serv_PSC TLV in LDP Label Request/Label Mapping messages to BAs transported over the E-LSP
implicitly indicate that the LSP is an E-LSP) - the Service Provider configures at every LSR, and for every
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other interface, the scheduling behavior for each PSC supported over
BAs using LDP as specified above (ie Diff-Serv_PSC TLV in LDP Label the E-LSP and the dropping behavior for each corresponding PHB
Request/Label Mapping messages to indicate the L-LSP's PSC). - the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over
the L-LSPs and the dropping behavior for each corresponding PHB
- LSRs signal establishment of a single E-LSP per FEC for the set
of E-LSP transported BAs using LDP as specified above (ie no
Diff-Serv TLV in LDP Label Request/Label Mapping messages to
implicitly indicate that the LSP is an E-LSP and that it uses
the preconfigured mapping)
- LSRs signal establishment of one L-LSP per <FEC,OA> for the
other BAs using LDP as specified above (ie Diff-Serv TLV in LDP
Label Request/Label Mapping messages to indicate the L-LSP's
PSC).
B.3 Scenario 3: 8 BAs, Aggregate Traffic Engineering, Aggregate Fast A.3 Scenario 3: 8 BAs, Aggregate Traffic Engineering, Aggregate Fast
Reroute Reroute
A Service Provider running 8 (or less) BAs over MPLS, performing A Service Provider running 8 (or less) BAs over MPLS, performing
aggregate Traffic Engineering (ie performing a single common path aggregate Traffic Engineering (ie performing a single common path
selection for all BAs), performing aggregate protection via Fast selection for all BAs), performing aggregate protection via Fast
Reroute (ie performing Fast Reroute for all PSCs jointly) and using Reroute (ie performing Fast Reroute for all PSCs jointly) and using
MPLS Shim Header encapsulation in his/her network, may elect to run MPLS Shim Header encapsulation in his/her network, may elect to run
Diff-Serv over MPLS using a single E-LSP per FEC established via Diff-Serv over MPLS using a single E-LSP per FEC established via
RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE]. RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the
preconfigured mapping.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the - the Service Provider configures at every LSR the bi-directional
bidirectional mapping between each PHB and a value of the EXP field mapping between each PHB and a value of the EXP field
(eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13)
- the Service Provider configures at every LSR, and for every - the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (eg bandwidth interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg drop allocated to AF1) and the dropping behavior for each PHB (eg
profile for AF11, AF12, AF13) drop profile for AF11, AF12, AF13)
- LSRs signal establishment of a single E-LSP per FEC: - LSRs signal establishment of a single E-LSP per FEC which will
* using the RSVP protocol as specified above (ie no use the preconfigured mapping:
DIFFSERV_PSC RSVP Object in the PATH message containing the * using the RSVP protocol as specified above (ie no DIFFSERV
LABEL_REQUEST Object), OR RSVP Object in the PATH message containing the LABEL_REQUEST
Object), OR
* using the CR-LDP protocol as specified above (ie no Diff- * using the CR-LDP protocol as specified above (ie no Diff-
Serv_PSC TLV in LDP Label Request/Label Mapping messages). Serv TLV in LDP Label Request/Label Mapping messages).
B.4 Scenario 4: per-OA Traffic Engineering/Fast Reroute A.4 Scenario 4: per-OA Traffic Engineering/Fast Reroute
A Service Provider running any number of BAs over MPLS, performing A Service Provider running any number of BAs over MPLS, performing
per-OA Traffic Engineering (ie performing a separate path selection per-OA Traffic Engineering (ie performing a separate path selection
for each OA) and performing per-OA protection via Fast Reroute (ie for each OA) and performing per-OA protection via Fast Reroute (ie
Le Faucheur et. al 42
MPLS Support of Diff-Serv February 00
performing protection with different Fast Reroute policies for the performing protection with different Fast Reroute policies for the
different OAs) in his/her network, may elect to run Diff-Serv over different OAs) in his/her network, may elect to run Diff-Serv over
MPLS using one L-LSP per <FEC,OA> pair established via RSVP or MPLS using one L-LSP per <FEC,OA> pair established via RSVP or
CR-LDP. CR-LDP.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR, and for every - the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (eg bandwidth interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg drop allocated to AF1) and the dropping behavior for each PHB (eg
profile for AF11, AF12, AF13) drop profile for AF11, AF12, AF13)
- LSRs signal establishment of one L-LSP per <FEC,OA>: - LSRs signal establishment of one L-LSP per <FEC,OA>:
Le Faucheur et. al 38
MPLS Support of Diff-Serv October 99
* using the RSVP as specified above to signal the * using the RSVP as specified above to signal the
L-LSP's PSC (ie DIFFSERV_PSC RSVP Object in the PATH message L-LSP's PSC (ie DIFFSERV RSVP Object in the PATH message
containing the LABEL_REQUEST), OR containing the LABEL_REQUEST), OR
* using the CR-LDP protocol as specified above to * using the CR-LDP protocol as specified above to
signal the L-LSP PSC (ie Diff-Serv_PSC TLV in LDP Label signal the L-LSP PSC (ie Diff-Serv TLV in LDP Label
Request/Label Mapping messages). Request/Label Mapping messages).
B.5 Scenario 5: less than 8 BAs, per-OA Traffic Engineering/Fast A.5 Scenario 5: 8 (or less) BAs, per-OA Traffic Engineering/Fast
Reroute Reroute
A Service Provider running less than 8 BAs over MPLS, performing A Service Provider running 8 (or less) 8 BAs over MPLS, performing
per-OA Traffic Engineering (ie performing a separate path selection per-OA Traffic Engineering (ie performing a separate path selection
for each OA) and performing per-OA protection via Fast Reroute (ie for each OA) and performing per-OA protection via Fast Reroute (ie
performing protection with different Fast Reroute policies for the performing protection with different Fast Reroute policies for the
different OAs) in his/her network, may elect to run Diff-Serv over different OAs) in his/her network, may elect to run Diff-Serv over
MPLS using one E-LSP per <FEC,OA> pair established via RSVP or MPLS using one E-LSP per <FEC,OA> pair established via RSVP or
CR-LDP. CR-LDP. Furthermore, the Service Provider may elect to use the
preconfigured mapping on all the E-LSPs.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the - the Service Provider configures at every LSR the bi-directional
bidirectional mapping between each PHB and a value of the EXP field mapping between each PHB and a value of the EXP field
(eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13)
- the Service Provider configures at every LSR, and for every - the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (eg bandwidth interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg drop allocated to AF1) and the dropping behavior for each PHB (eg
profile for AF11, AF12, AF13) drop profile for AF11, AF12, AF13)
- LSRs signal establishment of one L-LSP per <FEC,OA>: - LSRs signal establishment of one E-LSP per <FEC,OA>:
* using the RSVP protocol as specified above to signal * using the RSVP protocol as specified above to signal
that the LSP is an E-LSP (ie no DIFFSERV_PSC RSVP Object in the PATH that the LSP is an E-LSP which uses the preconfigured mapping
message containing the LABEL_REQUEST), OR (ie no DIFFSERV RSVP Object in the PATH message containing the
LABEL_REQUEST), OR
* using the CR-LDP protocol as specified above to * using the CR-LDP protocol as specified above to
signal that the LSP is an E-LSP (ie no Diff-Serv_PSC TLV in LDP signal that the LSP is an E-LSP which uses the preconfigured
Label Request/Label Mapping messages) mapping (ie no Diff-Serv TLV in LDP Label Request/Label Mapping
- the Service Provider configures, for each E-LSP, at the head- messages)
end of that E-LSP, a filtering/forwarding criteria so that packets - the Service Provider configures, for each E-LSP, at the head-end
belonging to a given OA are forwarded on the E-LSP established for of that E-LSP, a filtering/forwarding criteria so that only the
the corresponding FEC and corresponding OA. packets belonging to a given OA are forwarded on the E-LSP
established for the corresponding FEC and corresponding OA.
B.6 Scenario 6: no Traffic Engineering/Fast Reroute on 8 BAs, per-OA Le Faucheur et. al 43
MPLS Support of Diff-Serv February 00
A.6 Scenario 6: no Traffic Engineering/Fast Reroute on 8 BAs, per-OA
Traffic Engineering/Fast Reroute on other BAs. Traffic Engineering/Fast Reroute on other BAs.
A Service Provider not performing Traffic Engineering/Fast Reroute A Service Provider not performing Traffic Engineering/Fast Reroute
on 8 (or less) BAs, performing per-OA Traffic Engineering/Fast on 8 (or less) BAs, performing per-OA Traffic Engineering/Fast
Reroute on the other BAs (ie performing a separate path selection Reroute on the other BAs (ie performing a separate path selection
for each OA corresponding to the other BAs and performing protection for each OA corresponding to the other BAs and performing protection
with a different policy for each of these OA) and using the MPLS with a different policy for each of these OA) and using the MPLS
Shim encapsulation in his/her network may elect to run Diff-Serv Shim encapsulation in his/her network may elect to run Diff-Serv
over MPLS, using for each FEC: over MPLS, using for each FEC:
- one E-LSP established via LDP to support the set of 8 (or - one E-LSP using the preconfigured mapping established via LDP to
less) non-traffic-engineered/non-fast-rerouted BAs, support the set of 8 (or less) non-traffic-engineered/non-fast-
AND rerouted BAs, AND
- one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for
Le Faucheur et. al 39 support of the other BAs.
MPLS Support of Diff-Serv October 99
- one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP
for support of the other BAs.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the bi- - the Service Provider configures at every LSR the bi-directional
directional mapping between each PHB and a value of the EXP field mapping between each PHB and a value of the EXP field for the
for the BAs supported over the E-LSP BAs supported over the E-LSP
- the Service Provider configures at every LSR, and for every - the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over the interface, the scheduling behavior for each PSC supported over
E-LSP and the dropping behavior for each corresponding PHB the E-LSP and the dropping behavior for each corresponding PHB
- the Service Provider configures at every LSR, and for every - the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over the interface, the scheduling behavior for each PSC supported over
L-LSPs and the dropping behavior for each corresponding PHB the L-LSPs and the dropping behavior for each corresponding PHB
- LSRs signal establishment of a single E-LSP per FEC for the - LSRs signal establishment of a single E-LSP per FEC for the non-
non-traffic engineered BAs using LDP as specified above (ie no Diff- traffic engineered BAs using LDP as specified above (ie no Diff-
Serv_PSC TLV in LDP Label Request/Label Mapping messages) Serv TLV in LDP Label Request/Label Mapping messages)
- LSRs signal establishment of one L-LSP per <FEC,OA> for the - LSRs signal establishment of one L-LSP per <FEC,OA> for the
other BAs: other BAs:
* using the RSVP protocol as specified above to signal * using the RSVP protocol as specified above to signal
the L-LSP PSC (ie DIFFSERV_PSC RSVP Object in the PATH message the L-LSP PSC (ie DIFFSERV RSVP Object in the PATH message
containing the LABEL_REQUEST Object), OR containing the LABEL_REQUEST Object), OR
* using the CR-LDP protocol as specified above to * using the CR-LDP protocol as specified above to
signal the L-LSP PSC (ie Diff-Serv_PSC TLV in LDP Label signal the L-LSP PSC (ie Diff-Serv TLV in LDP Label
Request/Label Mapping messages). Request/Label Mapping messages).
A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no Fast
Reroute
A Service Provider running more than 8 BAs over MPLS, not performing
Traffic engineering, not performing protection via Fast Reroute and
using MPLS Shim Header encapsulation in his/her network, may elect
to run Diff-Serv over MPLS using two E-LSPs per FEC established via
LDP and using signaled EXP<-->PHB mapping.
Operations can be summarized as follows:
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg
drop profile for AF11, AF12, AF13)
Le Faucheur et. al 44
MPLS Support of Diff-Serv February 00
- LSRs signal establishment of two E-LSPs per FEC using LDP in
accordance with the specification above (ie Diff-Serv TLV in LDP
Label Request/Label Mapping messages to explicitly indicate that
the LSP is an E-LSP and its EXP<--> mapping). The signaled
mapping will indicate the subset of 8 (or less) BAs to be
transported on each E-LSP and what EXP values are mapped to each
BA on each E-LSP.
References References
[MPLS_ARCH] Rosen et al., "Multiprotocol label switching [MPLS_ARCH] Rosen et al., "Multiprotocol label switching
Architecture", work in progress, (draft-ietf-mpls-arch-06.txt), Architecture", work in progress, (draft-ietf-mpls-arch-06.txt),
August 1999. August 1999.
[MPLS ATM] Davie et al., _MPLS using LDP and ATM VC Switching_, work [MPLS ATM] Davie et al., _MPLS using LDP and ATM VC Switching_, work
in progress, (draft-ietf-mpls-atm-02.txt), April 1999 in progress, (draft-ietf-mpls-atm-02.txt), April 1999
[MPLS FR] Conta et al., _Use of Label Switching on Frame Relay [MPLS FR] Conta et al., _Use of Label Switching on Frame Relay
skipping to change at line 2210 skipping to change at line 2488
[DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597, [DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597,
June 1999. June 1999.
[DIFF_EF] Jacobson et al., "An Expedited Forwarding PHB", RFC-2598, [DIFF_EF] Jacobson et al., "An Expedited Forwarding PHB", RFC-2598,
June 1999. June 1999.
[DIFF_HEADER] Nichols et al., "Definition of the Differentiated [DIFF_HEADER] Nichols et al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474, Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474,
December 1998. December 1998.
Le Faucheur et. al 40
MPLS Support of Diff-Serv October 99
[ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion [ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion
Notification (ECN) to IP", RFC-2481, January 1999. Notification (ECN) to IP", RFC-2481, January 1999.
[MPLS_ECN] Ramakrishnan et al., "A Proposal to Incorporate ECN in [MPLS_ECN] Ramakrishnan et al., "A Proposal to Incorporate ECN in
MPLS", draft-ietf-mpls-ecn-00.txt, June 1999. MPLS", draft-ietf-mpls-ecn-00.txt, June 1999.
[LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-
05.txt, June 99 05.txt, June 99
[RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", [RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-tunnel-03.txt, September 1999 draft-ietf-mpls-rsvp-lsp-tunnel-03.txt, September 1999
[CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using [CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using
LDP", draft-ietf-mpls-cr-ldp-03.txt, October 1999 LDP", draft-ietf-mpls-cr-ldp-03.txt, October 1999
[PHBID] Brim et al., "Per Hop Behavior Identification Codes [PHBID] Brim et al., "Per Hop Behavior Identification Codes
draft-ietf-diffserv-phbid-00.txt, October 99 draft-ietf-diffserv-phbid-00.txt, October 99
Le Faucheur et. al 45
MPLS Support of Diff-Serv February 00
[DIFF_NEW] Grossman, _New Terminology for Diffserv_, draft-ietf-
diffserv-new-terms-02.txt, November 99
[IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998
Edition (Revision and redesignation of ISO/IEC 10038:98
[ANSI/IEEE Std 802.1D, 1993 Edition], incorporating IEEE
supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and
P802.12e)
Author's Addresses: Author's Addresses:
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne -
France France
Phone: +33 4 92 96 75 64 Phone: +33 4 92 96 75 64
Email: flefauch@cisco.com Email: flefauch@cisco.com
Liwen Wu Liwen Wu
Cisco Systems Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824, USA 250 Apollo Drive, Chelmsford, MA 01824,
Phone: (978)-244-3087 USA
Email: Phone: +1 (978) 244-3087
Email: liwwu@cisco.com
liwwu@cisco.com
Bruce Davie Bruce Davie
Cisco Systems Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824 250 Apollo Drive, Chelmsford, MA 01824
USA USA
Phone: (978)-244-8000 Phone: +1 (978) 244-8000
Email: bsd@cisco.com Email: bsd@cisco.com
Shahram Davari Shahram Davari
PMC-Sierra Inc. PMC-Sierra Inc.
105-8555 Baxter Place 105-8555 Baxter Place
Burnaby, BC V5A 4V7 Burnaby, BC V5A 4V7
Canada Canada
E-mail: Shahram_Davari@pmc-sierra.com E-mail: Shahram_Davari@pmc-sierra.com
Pasi Vaananen Pasi Vaananen
Nokia Nokia
3 Burlington Woods Drive, Suit 250 3 Burlington Woods Drive, Suit 250
Burlington, MA 01803 Burlington, MA 01803
Le Faucheur et. al 41
MPLS Support of Diff-Serv October 99
USA USA
Phone +1 (781) 238-4981 Phone +1 (781) 238-4981
Email: pasi.vaananen@nokia.com Email: pasi.vaananen@nokia.com
Ram Krishnan Ram Krishnan
Nexabit Networks Nexabit Networks
200 Nickerson Road, 200 Nickerson Road,
Marlboro, MA 01752 Marlboro, MA 01752
Le Faucheur et. al 46
MPLS Support of Diff-Serv February 00
USA USA
E-mail: ram@nexabit.com E-mail: ram@nexabit.com
Pierrick Cheval Pierrick Cheval
Alcatel Alcatel
5 rue Noel-Pons 5 rue Noel-Pons
92734 Nanterre Cedex 92734 Nanterre Cedex
France France
E-mail: pierrick.cheval@alcatel.fr E-mail: pierrick.cheval@alcatel.fr
Le Faucheur et. al 42 Juha Heinanen
Telia Finland
E-mail: jh@lohi.eng.telia.fi
Le Faucheur et. al 47
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/