draft-ietf-mpls-diff-ext-01.txt   draft-ietf-mpls-diff-ext-02.txt 
Francois Le Faucheur
Liwen Wu Liwen Wu
Alcatel, USA Bruce Davie
Pierrick Cheval Cisco Systems
Alcatel, USA
Shahram Davari
PMC-Sierra Inc.
Pasi Vaananen Pasi Vaananen
Nokia Nokia
Francois le Faucheur
Cisco Systems, Inc.
Bruce Davie
Cisco Systems, Inc.
Internet Draft
Expires: December, 1999
Document: draft-ietf-mpls-diff-ext-01.txt June, 1999
MPLS Support of Differentiated Services by ATM LSRs Ram Krishnan
and Frame Relay LSRs Nexabit Networks
Pierrick Cheval
Alcatel
IETF Internet Draft
Expires: April, 2000
Document: draft-ietf-mpls-diff-ext-02.txt October, 1999
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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as _work in progress._ reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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 proposes a solution for MPLS to support Differentiated This document defines a flexible solution for support of
Services (Diff-Serv) over ATM LSRs and Frame Relay LSRs. It proposes Differentiated Services (Diff-Serv) over Multi-Protocol Label
corresponding updates to the current MPLS LDP and MPLS RSVP messages Switching (MPLS) networks.
for LSP establishment.
In brief, we propose to use LSPs where the Behavior Aggregate's This solution allows the MPLS network administrator to flexibly
scheduling treatment is inferred by the LSR from the packet's label define how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label
value (VCI/DLCI) while the Behavior Aggregate's drop precedence is Switched Paths so that he/she can best match the Diff-Serv, Traffic
indicated in the ATM/FR selective discard CLP/DE field.
1 Introduction Le Faucheur, et. al 1
Wu, et. al 1 MPLS Support of Diff-Serv October 99
MPLS Support of DiffServ over ATM/FR June 99 Engineering and Fast Restoration objectives within his/her
particular network. For instance, this solution allows the network
administrator to decide whether different sets of BAs are to be
mapped onto the same LSP or mapped onto separate LSPs.
This solution relies on combined use of two types of LSPs:
- LSPs where both the Behavior Aggregate's scheduling treatment
and its drop precedence are conveyed to the LSR in the EXP field of
the MPLS Shim Header.
- LSPs where the Behavior Aggregate's scheduling treatment is
inferred by the LSR from the packet's label value while the Behavior
Aggregate's drop precedence is indicated 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
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 signalling 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.
[MPLS_ATM] and [MPLS_FR] provides detailed description of how ATM
and FR Switches can be used as MPLS LSRs and how LSPs are
established and used by those ATM LSRS and FR LSRs.
In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the
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. At the ingress node the are said to constitute a Behavior Aggregate (BA). At the ingress
packets are classified and marked with a Diff-Serv Code Point (DSCP) node of the Diff-Serv domain the packets are classified and marked
which corresponds to their Behavior Aggregate [DIFF_HEADER]. At each with a Diff-Serv Code Point (DSCP) which corresponds to their
transit node, the destination address is used to decide the next hop Behavior Aggregate. At each transit node, the DSCP is used to select
while the DSCP is used to select the Per Hop Behavior (PHB) that the Per Hop Behavior (PHB) that determines the scheduling treatment
determines the queuing treatment and, in some cases, drop and, in some cases, drop probability for each packet.
probability for each packet.
This document proposes a solution for supporting the Behavior This document specifies a solution for supporting the Diff-Serv
Aggregates, whose corresponding PHBs are currently defined (in Behavior Aggregates whose corresponding PHBs are currently defined
[DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS ATM or MPLS Frame (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network.
Relay network, i.e., an MPLS network implemented using ATM of Frame
Relay switches.
1.1 Ordering Constraints, "Scheduling Aggregate (SA)" and "Per Hop As mentioned in [DIFF_HEADER], "Service providers are not required
Scheduling (PHS)" to use the same node mechanisms or configurations to enable service
differentiation within their networks, and are free to configure the
node parameters in whatever way that is appropriate for their
service offerings and traffic engineering objectives". Thus, the
solution defined in this document gives Service Providers
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
[DIFF_AF] states that "a DS node does not reorder IP packets of the Le Faucheur et. al 2
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 MPLS Support of Diff-Serv October 99
which share such an ordering constraint to constitute a "Scheduling
Aggregate" (SA). The mechanisms described in this draft aim, in
particular, to preserve the correct ordering relationships for
packets that belong to a given SA.
We refer to the set of one or more PHBs applied to the set of while some other classes of service are supported via LSPs which are
Behavior Aggregates forming a given SA, as a "Per Hop Scheduling" not protected).
(PHS).
The PHBs currently specified are Default PHB (DF), Class Selector Beside, the solution specified in this document achieves label space
PHB group (CSx), Assured Forwarding PHB group (AFxy), Expedited conservation and reduces the volume of label set-up/tear-down
Forwarding PHB (EF). signaling where possible by only mandating set-up of multiple LSPs
for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when
useful or required.
1.1.1 DF PHS 1.1 Ordered Aggregate (OA) and PHB Scheduling Class (PSC)
Wu et. al 2 The Diff-Serv model defines [APPENDIX A] the set of Behavior
Aggregates which share an ordering constraint to constitute an
"Ordered Aggregate (OA)". It also defines the set of one or more
PHBs applied to the set of Behavior Aggregates forming a given OA,
as a "PHB Scheduling Class (PSC)".
MPLS Support of DiffServ over ATM/FR June 99 1.2 EXP-Inferred-PSC LSPs (E-LSP)
The Default PHB is a single PHB specified in [DIFF_Header]. Thus, Section 2 below specifies how a single LSP can be used to support up
the corresponding PHS comprises a single PHB and thus coincides with to eight BAs, regardless of how many OAs these BAs span. With such
the DF PHB. LSPs, the packet DSCP value gets entirely mapped into the EXP field
of the MPLS Shim Header [MPLS_ENCAPS] at the Edge of the MPLS Diff-
Serv Cloud (thus encoding both drop precedence and PSC/scheduling
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].
1.1.2 CSn PHS We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP). Detailed
operations of E-LSPs are specified in section 2 below.
[DIFF_HEADER] defines up to 8 CS Codepoints referred to as CSn, E-LSPs have the following benefits:
where 1 <= n <= 8. [DIFF_HEADER] states that "... PHBs selected by - label space is conserved by allowing "packing" of up to eight
distinct Class Selector Codepoints SHOULD be independently BAs per label (eg. when there are fewer than eight BAs in the
forwarded; that is, packets marked with different Class Selector network, this method maintains the same label space as in a non
Codepoints MAY be re-ordered". Thus, there is one PHS corresponding Diff-Serv capable MPLS network).
to each CSn PHB. Each CSn PHS comprises a single PHB and thus - label establishment signaling is then reduced since a single
coincides with this CSn PHB. 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.
1.1.3 AFCn PHS E-LSPs only allow support of eight BAs or less.
As described in [DIFF_AF], the Assured Forwarding (AF) PHB group Le Faucheur et. al 3
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 MPLS Support of Diff-Serv October 99
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 PHS. Each PHS comprises 3 PHBs and
coincides with the AF Class. Those PHSs are thus referred to as
AFCn, where 1 <= n <= 4.
1.1.4 EF PHS 1.3 Label-Inferred-PSC LSPs (L-LSP)
[DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic Section 3 below specifies how a separate LSP can be established for
requiring forwarding with low loss, low latency, low jitter. each <FEC, OA> pair between two LSR neighbors.
[DIFF_EF] defines a single PHB. Thus, the corresponding PHS
comprises a single PHB and thus coincides with the DF PHB.
1.1.5 Summary list of PHS With such LSPs, the PSC is explicitly signaled at label
establishment time so that, after label establishment, the LSR can
infer from the label value the PSC to be applied to a labeled
packet. When the Shim Header is used, the Drop Precedence to be
applied by the LSR to the labeled packet is conveyed inside the
labeled packet MPLS Shim Header using the EXP field [MPLS_ENCAPS].
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
conveyed inside the link layer header encapsulating the labeled
packet using link layer specific drop precedence (eg. Cell Loss
Priority).
The following PHSs have thus been identified: We refer to such LSPs as "Label-Inferred-PSC LSPs" (L-LSP). Detailed
- DF operations of L-LSPs are specified in section 3 below.
- CSn , 1 <= i <= 8
- AFCn, 1 <= i <= 4
- EF
1.2 LSP Establishment for Diff-Serv over ATM/FR MPLS L-LSPs allow support of any number of Behavior Aggregates.
Recognizing that L-LSPs have the following drawbacks:
- they require the use of a separate label for support of each
PSC, and
- they require more signaling operations to set up the
corresponding L-LSPs.
Wu et. al 3 1.4 Overall Operations
MPLS Support of DiffServ over ATM/FR June 99 For a given FEC, and unless media specific restrictions apply as
identified in the corresponding sections below (eg. `MPLS Support of
Diff-Serv by ATM LSRs'), this specification allows any one of the
following set of combinations within an MPLS Diff-Serv domain:
- zero or any number of E-LSPs, and
- zero or any number of L-LSPs.
- the MPLS Header of MPLS switched packets is generally not The network administrator selects the actual combination from the
visible to ATM and Frame Relay MPLS LSRs since it is encapsulated set of allowed combinations in order to best match his/her
"inside" the ATM or FR LSP "connection"; environment and objectives in terms of Diff-Serv support, Traffic
Engineering and Fast Restoration.
- MPLS Diff-Serv assumes a similar architecture to non-MPLS Examples of deployment scenarios are provided for information in
Diff-Serv whereby the appropriate forwarding/prioritisation is to be APPENPIX B.
performed at every hop (ie every MPLS LSR, including ATM LSR and FR
LSR) in accordance to the packet's Behavior Aggregate.
- ATM and Frame Relay switching hardware is generally capable 1.5 Label Forwarding Model for Diff-Serv LSRs
of selecting different scheduling behaviors (eg. Queues) for
cells/frames belonging to different connections but is generally not
capable of selecting different scheduling behaviors for cells/frames
belonging to the same ATM/Frame Relay connection;
- ATM and Frame Relay switching hardware is capable of In order to describe Label Forwarding by Diff-Serv LSRs, we model
maintaining the order of all packets or cells sent on a single the LSR Diff-Serv label switching behavior as comprising three
connection; stages:
-A- incoming PHB and FEC determination
- ATM and Frame Relay switching hardware is generally capable Le Faucheur et. al 4
of enforcing different drop priorities within a single connection
via standardized technology-specific selective drop mechanisms (Cell
Loss Priority - CLP- for ATM and Discard Eligible - DE- for Frame
Relay);
we propose that MPLS Support of Diff-Serv October 99
- all packets belonging to a single SA and the same Forwarding -B- Optional outgoing PHB determination via Local Policy and
Equivalence Class (FEC) be sent down a single LSP; Traffic Conditioning
-C- Outgoing EXP(and possibly CLP/DE) and label determination,
enforcement of outgoing PHB's forwarding behavior
- one LSP be established per <FEC, SA> pair (rather than simply This model is used below for specifying LSR Label Forwarding using
one LSP per FEC as in a network that does not support Diff-Serv). L-LSPs and E-LSPs for Diff-Serv support over MPLS.
Such an LSP is referred to as a "Label-inferred-PHS" LSP or "L-LSP";
- packets from multiple BAs of a given SA be granted a 1.6 Relationship between Label and FEC
different drop precedence through mapping into the layer 2 specific
selective discard indicator (CLP bit with ATM, DE bit with FR). [MPLS_ARCH] states in section `2.1. Overview' that:
`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
"precedence" or "class of service". They may then apply different
discard thresholds or scheduling disciplines to different packets.
MPLS allows (but does not require) the precedence or class of
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
and a precedence or class of service.'
In line with this, we observe that:
- With E-LSPs, the label represents the combination of a FEC
and the set of E-LSP transported Behavior Aggregates (BAs). Where
all the MPLS supported BAs are transported over E-LSPs, the label
then represents the complete FEC.
- With L-LSPs, the label represents the combination of a FEC
and an Ordered Aggregate (OA).
2. Detailed Operations of E-LSPs
2.1 E-LSP Establishment
Recognizing that:
- 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
[MPLS_ENCAPS];
- the Diff-Serv Code Point field (DSCP) is 6-bit long
[DIFF_HEADER] but when 8 (or less) BAs are used, the DSCP values can
be mapped entirely into the 3-bit long EXP field of the MPLS label
stack entry;
We define that:
- one LSP established for a given Forwarding Equivalent Class
(FEC) may be used for transport of up to eight BAs of that FEC;
- 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
is inferred from the EXP field of the MPLS Shim Header;
Le Faucheur et. al 5
MPLS Support of Diff-Serv October 99
- the set of transported BAs can span one or multiple OAs;
- packets belonging to this given (FEC) and from the
corresponding set of BAs are sent down this E-LSP.
- 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.
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 Internet-Draft proposes below the required RSVP, BGP and PIM. This document specifies below, respectively in
extensions to LDP and RSVP to allow establishment of one L-LSP per section 4 and section 5, how RSVP and LDP are to be used for
<FEC,SA> pair over ATM MPLS and FR MPLS. establishment of E-LSPs.
For the purpose of meeting some specific Traffic Engineering goals, 2.2 Label Forwarding
we note that:
- SAs supported by separate L-LSPs may be Traffic Engineered
separately. A path is selected independently for each SA (eg by
Constraint Based Routing or by explicit configuration) and the
Wu et. al 4 2.2.1 Incoming PHB and FEC Determination On Ingress E-LSP
MPLS Support of DiffServ over ATM/FR June 99 When receiving a labeled packet over a E-LSP of an MPLS ingress
interface, the LSR:
- determines the FEC based on the incoming label
- determines the incoming PHB by looking at the EXP field of
the top level label entry and then by looking up the PHB<-->EXP
mapping defined below in section 2.3.
corresponding L-LSPs are then established independently via RSVP or If the EXP field value of a packet received on an E-LSP is not
CR-LDP signaling; listed in the mapping defined in section 2.3, this EXP value should
- SAs supported by separate L-LSPs may be Traffic Engineered be considered invalid. LSR behavior in such situation is a local
jointly. A path is selected for the aggregate of all the considered matter and is outside the scope of this document.
SAs and the L-LSPs are then established independently along the same
common path via RSVP or CR-LDP signaling;
1.3 Explicit Congestion Notification 2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning
Explicit Congestion Notification is described in [ECN] and is This stage of Diff-Serv label switching is optional and may be used
proposed as an Experimental extension to the IP protocol. Because on an LSR to perform Behavior Aggregate demotion or promotion inside
ECN is still at the Experimental stage and its impact and an MPLS Diff-Serv domain. For the purpose of specifying Diff-Serv
interactions with Diff-Serv have not yet been specified, this over MPLS forwarding, we simply note that the PHB to be actually
Internet-Draft does not discuss ECN operations. Support for enforced, and conveyed to downstream LSRs, by an LSR (referred to as
simultaneous Diff-Serv and ECN over MPLS is left for further study. "outgoing PHB") may be different to the PHB which had been
associated with the packet by the previous LSR (referred to as
"incoming PHB").
1.4 Label Forwarding for Diff-Serv over ATM/FR MPLS 2.2.3 Outgoing EXP Field And Label Determination On Egress E-LSP
In order to describe Label Forwarding by Diff-Serv LSRs, we propose Once the outgoing PHB has been determined by the LSR as a function
to model a Diff-Serv label switching behavior as comprising three of the incoming PHB and of the optional Local Policy and Traffic
stages: Conditioning, the LSR:
-A- incoming PHB and FEC determination
-B- Optional outgoing PHB determination via Local Policy and
Traffic Conditioning
-C- Outgoing EXP field and label determination
The Diff-Serv LSR SHALL apply the scheduling/dropping behavior Le Faucheur et. al 6
corresponding to the "Outgoing PHB" in compliance with the
corresponding Diff-Serv PHB specification.
With such a model, we expect that "Diff-Serv over MPLS" label MPLS Support of Diff-Serv October 99
forwarding can be specified (from the Diff-Serv viewpoint)
separately for each method (eg. Diff-Serv over MPLS over ATM/FR,
Diff-Serv over MPLS over PPP using L-LSPs [MPLS_DIFF_PPP], Diff-Serv
over MPLS over PPP using E-LSPs [MPLS_DIFF_PPP]) by specifying -A-
and -C- for the considered method without having to specify the
complete label switching behavior (A+B+C) for every possible
incoming/outgoing combination.
This model is used below for specifying LSR Label Forwarding over - determines via local configuration that the outgoing PHB is
ATM/FR using L-LSPs for Diff-Serv support over MPLS. one of the PHBs supported by the E-LSP and determines the egress E-
LSP label for the packet's FEC
- 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 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.
1.5 Relationship with [MPLS_DIFF_PPP] 2.2.4 Simplified Forwarding
The procedures described in this Internet Draft to establish and use When Local Policy and Traffic Conditioning are not to be performed
L-LSPs to achieve support of Diff-Serv over MPLS over ATM and FR, by the LSR and the labeled packet is received on a E-LSP and is
are identical to the procedures described in [MPLS_DIFF_PPP] for L- forwarded onto an E-LSP, the Forwarding operation is simplified
LSPs as one method to achieve support of Diff-Serv over MPLS over since:
PPP. - 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.
Note that a single method (based on L-LSPs) is proposed in this 2.3 PHB<-->EXP field mapping
Internet Draft for support of Diff-Serv over MPLS over ATM/FR while
Wu et. al 5 Like the mapping between PHBs and DSCPs in a Diff-Serv network, the
mapping between PHB and EXP field is a local matter to be defined by
the Service Provider and configured on every LSR.
MPLS Support of DiffServ over ATM/FR June 99 LSRs supporting E-LSPs must allow configuration of PHB<-->EXP
mapping. This mapping applies to all the E-LSPs established on this
LSR (over interfaces belonging to a given MPLS Diff-Serv domain).
[MPLS_DIFF_PPP] defines two methods for support of Diff-Serv over The PHB<-->EXP mapping must be consistent at every LSP hop
MPLS over PPP. The other method described in [MPLS_DIFF_PPP] to throughout the MPLS Diff-Serv domain spanned by the LSP. This is
achieve support of Diff-Serv over MPLS over PPP relies on E-LSPs. E- achieved via consistent configuration by the network operator within
LSPs require that different packets of the same LSP be given the MPLS Diff-Serv domain.
different scheduling treatment by the LSR which is generally
incompatible with existing ATM/FR hardware capabilities.
2. Label Forwarding for Diff-Serv over ATM/FR MPLS Clearly, if different Behavior Aggregates transported over an E-LSP
are to be treated differently in the MPLS Diff-Serv cloud, different
values of the EXP field are to configured in the PHB<-->EXP mapping
for the corresponding PHBs.
2.2.1 Incoming PHB and FEC Determination On Ingress ATM/FR L-LSP 2.4 E-LSP Merging
When receiving an ATM/FR call/frame containing a labeled packet over Le Faucheur et. al 7
an L-LSP of an MPLS ATM ingress interface:
If the LSR is a Frame LSR (ie Egress Edge of the ATM/FR MPLS cloud), MPLS Support of Diff-Serv October 99
the LSR:
- determines the FEC based on the incoming label
- determines the PHS from the incoming label among the set of
LSPs established for that FEC
- determines the incoming PHB from the PHS and the EXP field of
the top level label entry of the encapsulated label stack in
accordance with the PHS/EXP-->PHB mapping defined in section 2.3 of
[MPLS_DIFF_PPP]
If the LSR is an ATM/FR LSR (ie ATM/FR LSR in the middle of the In an MPLS domain, two or more LSPs can be merged into one LSP at
ATM/FR MPLS cloud), the LSR: one LSR. E-LSPs are compatible with LSP Merging under the following
- determines the FEC based on the incoming VCI/DLCI condition:
- determines the PHS from the incoming VCI/DLCI among the set
of LSPs established for that FEC
- determines the "incoming" drop precedence to be applied on
the packet based on the CLP/DE field.
2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic E-LSPs can only be merged into one LSP if they support the exact
Conditioning same set of BAs.
This stage of Diff-Serv label switching is optional and may be used Since the BAs/PHBs supported over an E-LSP is not signalled at
on a Frame LSR to perform Behavior Aggregate demotion or promotion establishment time, an LSR can not rely on signaling information to
inside an MPLS Diff-Serv domain. For the purpose of specifying a enforce the above merge condition (ie that merged LSPs do support
Diff-Serv over MPLS method, we simply note that the PHB to be the exact same set of BAs). However all E-LSPs are to use the same
actually enforced by an LSR (referred to as "outgoing PHB") may be PHB<-->EXP mapping, and transport the same set of Behavior
different to the PHB which had been associated with the packet at Aggregates, within a given MPLS Diff-Serv domain. Thus, E-LSP
the previous LSR (referred to as "incoming PHB"). merging is allowed within a given MPLS Diff-Serv domain.
This stage of Diff-Serv label switching is optional and may be used E-LSP Merging at a boundary between two MPLS Diff-Serv domains is
on Frame LSRs with ATM/FR interfaces. for further study.
In the case of ATM/FR LSRs, it is expected that this optional stage 3. Detailed Operation of L-LSPs
of Diff-Serv label switching, if supported, would be limited to
CLP/DE remarking (ie remarking the "incoming CLP/DE" to a different
value in the "outgoing CLP/DE")
Wu et. al 6 3.1 L-LSP Establishment
MPLS Support of DiffServ over ATM/FR June 99 Recognizing that:
2.2.3 Outgoing CLP/DE Field and Label Determination on Egress ATM/FR - All currently defined MPLS encapsulation methods have a field
L-LSP of 3 bits or less for Diff-Serv encoding (i.e., 3-bit EXP field in
case of Shim Header and 1-bit CLP/DE bit in case of ATM/Frame
Relay).
- The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER]. So
that when more than a certain number of BAs are used (i.e., more
than 8 BAs in case of Shim Header and more than 2 BAs in case of
ATM/Frame Relay), the DS field can not be 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
Traffic Engineering (such as per OA Traffic Engineering)
We propose that:
- All packets belonging to a single OA and the same Forwarding
Equivalent Class (FEC) be sent down a single LSP;
- One LSP be established per <FEC, OA> pair (rather than simply
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
Precedence (DP) values through appropriate coding of the relevant
Le Faucheur et. al 8
MPLS Support of Diff-Serv October 99
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).
MPLS specifies how LSPs can be established via multiple signaling
protocols. Those include the Label Distribution Protocol (LDP),
RSVP, BGP and PIM. This document specifies, respectively in section
4 and section 5, how RSVP and LDP are to be used for establishment
of L-LSPs.
3.2 Label Forwarding
3.2.1 Incoming PHB and FEC Determination On Ingress L-LSP
When receiving a labeled packet over an L-LSP of an MPLS ingress
interface, the LSR:
- determines the FEC based on 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
Conditioning
This stage of Diff-Serv label switching is independent of the
ingress/egress interface media type and method used for MPLS Diff-
Serv support. It is optional and may be used on an LSR to perform
Behavior Aggregate demotion or promotion inside an MPLS Diff-Serv
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-
LSP
If the LSR is a Frame LSR (ie Ingress Edge of the ATM/FR MPLS
cloud):
Once the outgoing PHB has been determined by the LSR as a function Once the outgoing PHB has been determined by the LSR as a function
of the incoming PHB and of the optional Local Policy and Traffic of the incoming PHB and of the optional Local Policy and Traffic
Conditioning, the LSR: Conditioning, the LSR:
- determines the "outgoing" PHS by performing the "outgoing" - determines via local configuration that the outgoing PHB is
PHB--> PHS/CLP-DE mapping defined below in section 3. one of the PHBs supported by a L-LSP and determines the egress
- determines the egress L-LSP label from the packet's FEC and L-LSP label for the packet's FEC
PHS - determines the value to be written in the EXP/CLP/DLE field
- encodes the EXP field of the top level label entry shim of the top level label entry (and possibly of other level label
header of the label stack (which is encapsulated in the ATM /FR LSP) entries in the case of a hierarchical tunnel entry) by performing
in accordance with the PHB --> PHS/EXP Mapping defined in section the outgoing PHB-->EXP/PSC (resp CLP/PSC, DE/PSC) mapping defined in
2.4 of [MPLS_DIFF_PPP]. sections 6.4 (resp 7.3 and 8.3).
- determines the value to be written in the CLP/DE field of the
outgoing cell/frame by performing the outgoing PHB--> PHS/CLP-DE
mapping defined below in section 3.
- applies a scheduling/dropping behavior corresponding to the
"outgoing" PHB in compliance with the corresponding Diff-Serv PHB
specification.
If the LSR is an ATM/FR LSR (ie ATM/FR LSR in the middle of the Le Faucheur et. al 9
ATM/FR MPLS cloud):
Once the "outgoing" drop precedence (CLP/DE) has been determined by
the LSR as a function of the "incoming" drop precedence (CLP/DE) and
of the optional Local Policy and Traffic Conditioning, the LSR:
- determines the outgoing interface, the outgoing VCI/DLCI and
the output scheduling queue from the incoming VCI/DLCI
- applies a scheduling treatment corresponding to the
VCI/DLCI/label's PHS in compliance with the corresponding Diff-Serv
PHB specification
- writes the "outgoing" CLP/DE value into the outgoing
cell/frame
- applies the drop precedence corresponding to the "outgoing"
CLP/DE.
2.2.4 Simplified Forwarding on an ATM/FR LSR MPLS Support of Diff-Serv October 99
- SHALL apply the scheduling/dropping behavior corresponding to
the "Outgoing PHB" in compliance with the corresponding Diff-Serv
PHB specification.
3.2.4 Simplified Forwarding
When Local Policy and Traffic Conditioning are not to be performed When Local Policy and Traffic Conditioning are not to be performed
by the LSR, the Forwarding operation of an ATM/FR LSR is "reduced" by the LSR, and when the labeled packet is received on a L-LSP on
to traditional ATM/FR switching since: the ingress interface and is going out onto a L-LSP on an egress
- the LSR only looks at the incoming VCI/DLCI of an incoming interface of the same type, the Forwarding operation is simplified
ATM cell/FR Frame to determine the output interface, the outgoing since:
VCI/DLCI and the output scheduling queue, - the EXP/CLP/DE field does not need to be modified
- the LSR only looks at the incoming CLP/DE field to determine - the outgoing label determination depends exclusively on the
the drop precedence to be applied on the cell/frame, incoming label (ie does not depend on Local Policy and Traffic
- the MPLS Shim Header encapsulated in the ATM/FR connection Conditioning). The outgoing label is determined from the Incoming
does not need to be looked at nor modified. 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.
Wu et. al 7 3.3 Merging
MPLS Support of DiffServ over ATM/FR June 99 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
with LSP Merging under the following condition:
2.2.5 Number of Drop Precedence Levels L-LSPs can only be merged into one L-LSP if they are associated with
the same PSC.
Because the underlying standardized ATM and Frame Relay Selective Note that when L-LSPs merge, the bandwidth that is available for the
Discard mechanisms (CLP/DE) only support two levels of Drop PSC downstream of the merge point must be sufficient to carry the
Precedence, the proposed solution is limited to two levels of Drop sum of the merged traffic. This is particularly important in the
Precedence per PHS in an ATM MPLS or FR MPLS cloud. case of EF traffic. This can be ensured in multiple ways (for
instance via provisioning or via bandwidth signaling and explicit
admission control).
However, the label stack encapsulated in the ATM LSP or FR LSP is 4. RSVP Extension for Diff-Serv Support
expected to include a shim header for the top label entry with a
meaningful EXP field, which can thus be used to encode all levels of
Drop Precedence within a PHS as defined in [MPLS_DIFF_PPP].
Consequently, even if only two levels of Drop Precedence are
achieved in the ATM/FR MPLS cloud, all Drop Precedence levels (eg
the three levels of an AF Class) can be supported in PPP MPLS clouds
surrounding an ATM/FR MPLS cloud.
3. PHB Mapping into PHS and Selective Discard Mechanism The MPLS architecture does not assume a single label distribution
protocol. [RSVP_MPLS_TE] defines the extension to RSVP for
establishing label switched paths (LSPs) in MPLS networks. This
section specifies the extensions to RSVP, beyond those defined in
3.1 PHB-->PHS/CLP Mapping Le Faucheur et. al 10
The mapping from PHBs into the L-LSP PHS and the Cell Loss Priority MPLS Support of Diff-Serv October 99
(CLP) field of the ATM header is as follows:
PHB CLP PHS [RSVP_MPLS_TE], to establish label switched path (LSPs) supporting
Differentiated Services in MPLS networks.
4.1 Diff-Serv related RSVP Messages Format
One new RSVP Object is defined in this document: the DIFFSERV_PSC
Object. Detailed description of this Object is provided below. This
new Object is applicable to Path messages. This specification only
defines the use of the DIFFSERV_PSC Object in Path messages used to
establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus
containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4
and containing a LABEL_REQUEST object.
Restrictions defined in [RSVP_MPLS_TE] for support of establishment
of LSP Tunnels via RSVP are also applicable to the establishment of
LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs
are supported and Multicast LSPs are for further study.
This new DIFFSERV_PSC object is optional with respect to RSVP so
that general RSVP implementations not concerned with MPLS LSP set up
do not have to support this object.
The DIFFSERV_PSC Object is optional for support of LSP Tunnels as
defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs
in compliance with this specification MAY support the DIFFSERV_PSC
Object. A Diff-Serv capable LSR supporting L-LSPs in compliance with
this specification MUST support the DIFFSERV_PSC Object.
4.1.1 Path Message Format
The format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV_PSC> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
4.2 DIFFSERV_PSC Object
As stated earlier, the PHB Scheduling Class associated with an L-LSP
is to be specified through a new DIFFSERV_PSC object in RSVP Path
messages. The DIFFSERV_PSC object has the following format :
Le Faucheur et. al 11
MPLS Support of Diff-Serv October 99
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | T |PSCnb| PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
This is set to 4.
Class-Num
The Class-Num for a DIFFSERV_PSC object is [TBD] and identifies
a new object Class called the "Class Of Service" Class (COS
Class). (The Class-Num is to be allocated by IANA with the form
0bbbbbbb)
C-Type
The C-Type for a DIFFSERV_PSC object is 1.
Reserved
This field is set to all zeros
T
This indicates the `LSP Type'. The following values are
specified:
T Value LSP type
00 E-LSP
01 L-LSP
PSCnb
Indicates the number of PSC values included in the PSC object.
This is set to 001.
PSC
The PSC indicates the PHB Scheduling Class to be supported by the
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 October 99
- 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.
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
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 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 :
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0 0 1 0 1 0| 0 0 0 0 0 0 0 0 1 0|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4.3 Handling Diff-Serv_PSC Object
To establish an LSP tunnel with RSVP, the sender creates a Path
message with a session type of LSP_Tunnel_IPv4 and with a
LABEL_REQUEST object as per [RSVP_MPLS_TE].
Where the sender supports Diff-Serv using E-LSPs, to establish an
E-LSP tunnel with RSVP, the sender creates a Path message with a
session type of LSP_Tunnel_IPv4, with the LABEL_REQUEST object and
without the DIFFSERV_PSC object.
Optionally, to establish an E-LSP over which a single Ordered
Aggregate is going to be transported, the sender MAY create a Path
message which contains a session type of LSP_Tunnel_IPv4, contains
the LABEL_REQUEST object and contains the DIFFSERV_PSC object with
its LSP-Type field set to `E-LSP' and its PSC field set to the value
of the PSC to be supported on the E-LSP.
The destination node of an E-LSP responds to the Path message
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
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
MPLS Support of Diff-Serv October 99
may also contain any other information needed in order to properly
dispose of the packet'.
- install the required scheduling and dropping behavior for
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
L-LSP tunnel with RSVP, the sender creates a Path message with a
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
receives a path message which contains the DIFFSERV_PSC object but
which does not contain a LABEL_REQUEST object or which does not have
a session type of LSP_Tunnel_IPv4, sends a PathErr towards the
sender with the error code `Diff-Serv Error' and an error value of
`Unexpected DIFFSERV_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
recognizes the DIFFSERV_PSC 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 Value'. Those are defined below in the section
titled `Diff-Serv Errors'.
If a path message contains multiple DIFFSERV_PSC objects, only the
first one is meaningful; subsequent DIFFSERV_PSC object(s) must be
ignored and not forwarded.
Each node along the path records the DIFFSERV_PSC object, when
present, in its path state block.
The destination node of an L-LSP responds to the Path message
containing the LABEL_REQUEST object and the DIFFSERV_PSC 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
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 October 99
A Diff-Serv LSR MUST handle the situations where the reservation can
not be accepted for other reasons than those already discussed in
this section, in accordance with [RSVP_MPLS_TE] (eg. reservation
rejected by admission control, a label can not be associated).
[RSVP_MPLS_TE] identifies the conditions where LSPs can be merged to
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 COS Class's Class-Num
sends a PathErr with the error code "Unknown object class" toward
the sender. An RSVP router that recognizes the COS Class's Class-Num
but does not recognize the DIFFSERV_PSC object C-Type, sends a
PathErr with the error code "Unknown object C-Type" toward the
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 the procedures described above, certain errors must be reported
as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error
code is 26 (TBD).
The following defines error values for the Diff-Serv Error:
Value Error
1 Unsupported PSC value
2 Unexpected DIFFSERV_PSC object
4.6 Use of COS Service with E-LSPs and L-LSPs
Both E-LSPs and L-LSPs can be established with bandwidth reservation
or without bandwidth reservation.
To establish an E-LSP or an L-LSP with bandwidth reservation, Int-
Serv's Controlled Load service (or possibly Guaranteed Service) is
used and the bandwidth is signaled in the SENDER_TSPEC (respectively
FLOWSPEC) of the path (respectively Resv) message.
To establish an E-LSP or an L-LSP without bandwidth reservation, the
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
DIFFSERV_PSC object indicates to a Diff-Serv capable LSR that the
LSP to be established in an E-LSP without any bandwidth reservation.
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
Diff-Serv capable LSR that the LSP to be established in an E-LSP
without any bandwidth reservation.
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
Diff-Serv capable LSR that the LSP to be established in an L-LSP
without any bandwidth reservation.
The above is summarized in the following table:
Path Message LSP type
Service DIFFSERV_PSC LSP
Object Type
GS/CL No E-LSP with bandwidth reservation
GS/CL Yes E-LSP E-LSP with bandwidth reservation
GS/CL Yes L-LSP L-LSP with bandwidth reservation
COS No E-LSP without bandwidth reservation
COS Yes E-LSP E-LSP without bandwidth reservation
COS Yes L-LSP L-LSP without bandwidth reservation
Where:
- GS stands for Guaranteed Service
- CL stands for Controlled Load
- COS stands for COS service
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
the value of the COS field within a COS SENDER_TSPEC (respectively a
COS FLOWSPEC).
5. LDP Extensions for Diff-Serv Support
The MPLS architecture does not assume a single label distribution
protocol. [LDP] defines the Label Distribution Protocol and its
usage for establishment of label switched paths (LSPs) in MPLS
networks. This section specifies the extensions to LDP to establish
label switched path (LSPs) supporting Differentiated Services in
MPLS networks.
Two new LDP TLVs are defined in this document:
- the `DIFF-SERV_PSC' TLV
- the `Release Status' TLV
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
respect to LDP. A Diff-Serv capable LSR supporting E-LSPs in
compliance with this specification MAY support the Diff-Serv_PSC TLV
and the Release Status TLV. A Diff-Serv capable LSR supporting
L-LSPs in compliance with this specification MUST support the Diff-
Serv_PSC TLV and the Release Status TLV.
5.1 Diff-Serv related TLVs
5.1.1 Diff-Serv_PSC TLV
As stated earlier, the PHB Scheduling Class associated with an L-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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | T |PSCnb| PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U BIT =0
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.
Reserved
This field is set to all zeros
T
This indicates the `LSP Type'. The following values are
specified:
T Value LSP type
00 E-LSP
01 L-LSP
PSCnb
Indicates the number of PSC values included in the TSC TLV. This
is set to 001
PSC Value
Encoding of the PSC field is as specified in section 4.2.
5.1.2 Release Status TLV
As stated earlier, error codes are to specified through a new
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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur et. al 18
MPLS Support of Diff-Serv October 99
U BIT =0
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: 0x304.
Status Code
Indicates the reason why the label was released. This field uses
the same encoding and values as the `Status Code' word defined for
the Notification message. Additional values are defined below, in
the section titled `Status Code Values', for this Status Code
field in addition to the values currently defined in [LDP].
5.1.3 Status Code Values
The following values are defined for the Status Code field which is
used in Notification message and may be used in Label Release
messages:
Status Code E Status Data
Unsupported PSC value 0 0x00000016
Unexpected PSC value 0 0x00000017
Unexpected PSC TLV 0 0x00000018
Unexpected LSP-Type 0 0x00000019
5.2 Diff-Serv Related LDP Messages
5.2.1 Label Request Message
In Downstream on Demand mode, the Diff-Serv capable LSR requesting a
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
on Demand mode, is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur et. al 19
MPLS Support of Diff-Serv October 99
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2 Label Mapping Message
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
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
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
Unsolicited mode, is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
Le Faucheur et. al 20
MPLS Support of Diff-Serv October 99
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSC TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.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
message so that the new Release Status TLV can optionally be
included in the message. Thus the encoding of the Label Release
message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Release Status TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.4 Notification Message
This specification allows inclusion of the Diff-Serv_PSC TLV in the
Notification. Thus the encoding of the Notification message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
Le Faucheur et. al 21
MPLS Support of Diff-Serv October 99
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv_PSC TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3 Handling of the Diff-Serv_PSC TLV
5.3.1 Handling of the Diff-Serv_PSC TLV in Downstream Unsolicited Mode
This section describes operations when the Downstream Unsolicited
Mode is used.
When allocating a label for an E-LSP, a Diff-Serv capable LSR issues
a Label Mapping message without the Diff-Serv_PSC TLV.
A Diff-Serv capable LSR receiving a Label Mapping message without
the Diff-Serv_PSC TLV, 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.
- 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
a Label Mapping message which contains the Diff-Serv_PSC TLV with
its PSC field indicating the PSC of the L-LSP.
A Diff-Serv capable LSR receiving a Label Mapping message containing
the Diff-Serv_PSC TLV, 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 LSP 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 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 Release Status TLV with a Status Code
of `Unsupported 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.3.2 Handling of the Diff-Serv_PSC TLV in Downstream on Demand Mode
This section describes operations when the Downstream on Demand Mode
is used.
Le Faucheur et. al 22
MPLS Support of Diff-Serv October 99
When requesting a label for an E-LSP, a Diff-Serv capable LSR sends
a Label Request message without the Diff-Serv_PSC TLV.
Optionally, when requesting a lebel for an E-LSP over which a single
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
to a Label Request message which did not contain the Diff-Serv_PSC
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
to a Label Request message which contained the Diff-Serv_PSC TLV
with its E-LSP type set to E-LSP, may send this Label Mapping
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
the Diff-Serv_PSC TLV in response to its Label Request message for
an E-LSP, must:
- update its ILM to store the necessary Diff-Serv information.
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
the Diff-Serv_PSC TLV in response to its Label Request message for
an E-LSP which did not contain the Diff-Serv_PSC TLV, 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 TLV'.
A Diff-Serv capable LSR receiving a Label Mapping message containing
the Diff-Serv_PSC TLV in response to its Label Request message for
an E-LSP which contained the Diff-Serv_PSC TLV, must compare the
received and sent Diff-Serv_PSC TLVs.
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 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.
Le Faucheur et. al 23
MPLS Support of Diff-Serv October 99
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'.
When requesting a label for an L-LSP, a Diff-Serv capable LSR sends
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
Diff-Serv_PSC TLV containing a PSC value which is not supported or
for which no EXP/PSC<-->PHB mapping is configured, must send a
Notification message with a Status Code of `Unsupported PSC Value'.
A Diff-Serv capable LSR that recognizes the Diff-Serv_PSC 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
existing LDP procedures [LDP] (eg. with a `No Label Resource' Status
Code). This Notification message must include the requested
Diff-Serv_PSC 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
An LSR that does not recognize the Diff-Serv_PSC TLV Type, on
receipt of a Label Request message or a Label Mapping message
containing the Diff-Serv_PSC TLV, must ignore the message and return
a Notification message with _Unknown TLV_ Status.
5.5 Bandwidth Information
Bandwidth information may also be signaled at establishment time of
E-LSP and L-LSP, for instance for the purpose of Traffic
Engineering, using the Traffic Parameters TLV as described in
[MPLS CR LDP].
6. MPLS Support of Diff-Serv over PPP
The general operations for MPLS support of Diff-Serv, including
label forwarding and LSP setup operations was specified in the
previous sections. This section describes the specific operations
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
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
DF -----> 000 DF
Le Faucheur et. al 26
MPLS Support of Diff-Serv October 99
CSn -----> 000 CSn
AFn1 -----> 000 AFCn
AFn2 -----> 001 AFCn
AFn3 -----> 010 AFCn
EF -----> 000 EF
6.5 LSR implementation with PPP interfaces
For an LSR implementation with PPP interfaces, support of E-LSPs
over the PPP interfaces is mandatory with respect to this
specification. A Diff-Serv capable LSR with PPP interfaces MUST
support E-LSPs over these PPP interfaces in compliance with this
specification.
Support of L-LSPs over PPP interfaces by an LSR implementation is
optional. A Diff-Serv capable LSR MAY support L-LSPs over PPP
interfaces. However, if a Diff-Serv LSR does support L-LSPs over PPP
interfaces, then it MUST do so in compliance with all the material
from this specification pertaining to L-LSPs.
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
connection VPI/VCI values have not been established via any label
distribution protocol) is to be considered as an LSR with PPP
interfaces from the point of view of compliance to this
specification.
Similarly, an LSR running MPLS over PPP over a traditional Frame
Relay connection (ie where the Frame Realy switches do not
participate in MPLS and where the Frame Relay connection DLCI values
have not been established via any label distribution protocol) is to
be considered as an LSR with PPP interfaces from the point of view
of compliance to this specification.
7. MPLS Support of Diff-Serv by ATM LSRs
The general operations for MPLS support of Diff-Serv, including
label forwarding and LSP setup operations was specified in the
previous sections. This section describes the specific operations
required for MPLS support of Diff-Serv over ATM links.
This document allows the following set of LSP setup combinations per
FEC 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
MPLS Support of Diff-Serv October 99
DF -----> 0 DF DF -----> 0 DF
CSn -----> 0 CSn CSn -----> 0 CSn
AFn1 -----> 0 AFCn AFn1 -----> 0 AFCn
AFn2 -----> 1 AFCn AFn2 -----> 1 AFCn
AFn3 -----> 1 AFCn AFn3 -----> 1 AFCn
EF -----> 0 EF EF -----> 0 EF
3.2 PHB-->PHS/DE Mapping 7.4 Merging
The mapping from PHBs into the L-LSP PHS and the Discard Eligible The use of merging is optional. In case that merging of ATM LSPs is
(DE) field of the Frame Relay header is as follows: used, procedures described in section 3.5. of this specification
apply. Additionally, to avoid cell interleaving problems with AAL-5
merging, procedures specified in [MPLS ATM] MUST be followed.
PHB DE PHS 7.5 Use of ATM Traffic Classes and Traffic Management mechanisms
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
scope of this specification. The only requirement for compliant
implementation is that the forwarding behaviour experienced by a
Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be
compliant with the corresponding Diff-Serv PHB specifications.
To avoid discarding parts of the packets, frame discard mechanisms,
such as Early Packet Discard (EPD) SHOULD be enabled in the ATM-LSRs
for all PHBs described in this document.
7.6 LSR Implementation With ATM Interfaces
For an LSR implementation with ATM interfaces running native ATM
MPLS, support of L-LSPs over the ATM interfaces is mandatory with
respect to this specification. A Diff-Serv capable LSR with ATM
interfaces MUST support L-LSPs over these ATM interfaces in
compliance with this specification. Additionally, procedures
specified in [MPLS ATM] MUST be followed by compliant
implementation.
Support of E-LSPs over ATM interfaces running native ATM MPLS by an
LSR implementation is not allowed.
8. MPLS Support of Diff-Serv by Frame Relay LSRs
The general operations for MPLS support of Diff-Serv, including
label forwarding and LSP setup operations was specified in the
previous sections. This section describes the specific operations
required for MPLS support of Diff-Serv over Frame Relay links.
This document allows the following set of LSP setup combinations per
FEC within an MPLS Frame Relay Diff-Serv domain:
- any number of L-LSPs.
Le Faucheur et. al 29
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 DF -----> 0 DF
CSn -----> 0 CSn CSn -----> 0 CSn
AFn1 -----> 0 AFCn AFn1 -----> 0 AFCn
AFn2 -----> 1 AFCn AFn2 -----> 1 AFCn
AFn3 -----> 1 AFCn AFn3 -----> 1 AFCn
EF -----> 0 EF EF -----> 0 EF
3.3 Signaled PHS for Class Selector 8.4 Merging
As described in [DIFF_HEADER], "the Class Selector PHB Group The use of merging is optional. In case that merging of Frame Relay
identifies 8 PHBs defined via the relative probability of timely LSPs is used, procedures described in section 3.5. of this
specification apply as well as procedures in [MPLS FR].
Wu et. al 8 8.5 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms
MPLS Support of DiffServ over ATM/FR June 99 The use of the Frame Relay traffic parameters as specified by ITU-T
and Frame Relay-Forum or of vendor specific Frame Relay traffic
management mechanisms is outside of the scope of this specification.
The only requirement for compliant implementation is that the
forwarding behavior experienced by a Behavior Aggregate forwarded
over an L-LSP by the Frame Relay LSR MUST be compliant with the
corresponding Diff-Serv PHB specifications.
forwarding that they respectively offer to packets. For backwards 8.6 LSR Implementation With Frame Relay Interfaces
compatibility purposes, the Class Selector PHB Requirements are
specified as the minimum requirements compatible with most of the
deployed forwarding treatments selected by the IP Precedence field".
Quoting again from [DIFF_HEADER]: For an LSR implementation with Frame Relay interfaces running native
"In addition, we give a set of codepoints that MUST map to PHBs Frame Relay MPLS, support of L-LSPs over the Frame Relay interfaces
meeting these minimum requirements. The PHBs mapped to by these is mandatory with respect to this specification. A Diff-Serv capable
codepoints MAY have a more detailed list of specifications in LSR with Frame Relay interfaces MUST support L-LSPs over these Frame
addition to the required ones stated here". Relay interfaces in compliance with this specification.
Considering that: Support of E-LSPs over Frame Relay interfaces running native Frame
Relay MPLS by an LSR implementation is not allowed.
- this document defines how ATM/FR LSRs support some 9. MPLS Support of Diff-Serv over LAN Media
"specific/restrictive" PHB groups using their existing hardware
capabilities (including AF PHB Group and EF PHB).
- ATM/FR LSRs do not have some legacy PHBs complying with Class The general operations for MPLS support of Diff-Serv, including
Selector PHB requirements as defined in [DIFF_HEADER] paragraph label forwarding and LSP setup operations was specified in the
4.2.2.2 which are "less specific/restrictive" than the PHBs previous sections. This section describes the specific operations
addressed in this document. required for MPLS support of Diff-Serv over LAN.
- as specified in [DIFF_HEADER], Class Selector Codepoints can This document allows the following set of LSP setup combinations per
be supported by "more specific PHBs" such as the other ones FEC over an MPLS link:
addressed in this document
we propose that: - Zero or any number of E-LSP, and
- a Behavior Aggregate corresponding to a Class Selector - Zero or any number of L-LSPs.
Codepoint CSn may be mapped onto a CSn specific L-LSP with its CSn
PHS signaled at label set-up, OR
- a Behavior Aggregate corresponding to a Class Selector
Codepoint CSn may be mapped onto an L-LSP whose signaled PHS
corresponds to a "more specific/restrictive" PHB than CSn (eg AFn,
EF).
4. LSP Establishment and Message Format Le Faucheur et. al 31
4.1. Signaling extension during L-LSP establishment MPLS Support of Diff-Serv October 99
To support Diff-Serv in MPLS over ATM and Frame Relay, the PHS must 9.1. E-LSP Operations over PPP
be signaled in the MPLS label request messages and MPLS label
binding messages. The detailed format of the corresponding message
extension is described below when the signaling protocol used is LDP
or RSVP. The MPLS control application on each ATM LSR or Frame Relay
LSR along the L-LSP will process the new PHS attribute and install
the corresponding scheduling behavior for that L-LSP (eg. map the
LSP into an output queue associated with the PHS).
4.2. Merging Text to be written (in particular regarding use of 802.1 COS field).
Wu et. al 9 9.2 L-LSP Operations over PPP
MPLS Support of DiffServ over ATM/FR June 99 Text to be written (in particular regarding use of 802.1 COS field).
In an MPLS domain, two or more LSPs can be merged into one LSP at 9.3 LSR Implementation With LAN Interfaces
one LSR. The proposed support of Diff-Serv in MPLS over ATM and
Frame Relay is compatible with LSP Merging under the following
condition:
L-LSPs can only be merged into one LSP if they are associated with For an LSR implementation with LAN interfaces, support of E-LSPs
the same PHS. 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.
Note that, when L-LSPs merge, the bandwidth that is available for Support of L-LSPs over LAN interfaces by an LSR implementation is
the PHS downstream of the merge point must be sufficient to carry optional. A Diff-Serv capable LSR MAY support L-LSPs over LAN
the sum of the merged traffic. This is particularly important in the interfaces. However, if a Diff-Serv LSR does support L-LSPs over LAN
case of EF traffic. interfaces, then it MUST do so in compliance with all the material
from this specification pertaining to L-LSPs.
4.3 New RSVP Object Format 10. Operations at MPLS Diff-Serv Boundaries
This section defines a new RSVP object class and a new RSVP object 10.1 Operations at E-LSP/L-LSP Boundary Within Single MPLS Diff-Serv
within that class for support of Diff-Serv in MPLS over ATM/FR when Domain
L-LSPs are established via RSVP [MPLS_RSVP].
The new object Class is defined as the "Class Of Service" Class (COS Text to be added
Class). Its Class-Num is [TBD].
The new RSVP DIFFSERV_PHS object is defined within the COS Class to 10.2 Operations At Boundary across Diff-Serv domains
carry the PHS of the traffic to be transported on the corresponding
LSP. Its C-Type is 1.
DIFFSERV_PHS object Class = [TBD], C-Type = 1 Text to be added
0 1 2 3 11. Explicit Congestion Notification
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 = 4 | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PHS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We propose that the 16-bit PHS be encoded as specified in section 2 Explicit Congestion Notification is described in [ECN] and is
of [PHBID]. In particular, we propose that the encoding for a PHS be proposed as an Experimental extension to the IP protocol.
the smallest numerical value of the encodings for the various PHBs
in the PHS. In turn, the encoding of a single PHB defined by
standards action is the recommended DSCP value for this PHB, left-
justified in the 16 bit field, with bits 6 through 15 set to zero.
For instance, the encoding of the AFC1 PHS is the encoding of the [MPLS_ECN] discusses deployment of ECN in an MPLS network using the
AF11 PHB. Shim Header as the MPLS encapsulation. It demonstrates that,
provided a given LSP is identified as ECN-capable or as non-ECN-
capable (and consistently recognized as such by all the involved
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
field.
This object may be carried in a PATH message that contains the The details of how a given LSP is to be identified as ECN-capable or
LABEL_REQUEST object to indicate the PHS for which a label is non-ECN-capable (whether via extensions to the LSP establishment
required. The object may also be carried in a RESV message that signaling and procedures, via configuration or via other means) are
outside the scope of this specification.
Wu et. al 10 Le Faucheur et. al 32
MPLS Support of DiffServ over ATM/FR June 99 MPLS Support of Diff-Serv October 99
contains a LABEL object indicating the PHS for which the label is to However, this specification recognizes that, within an ECN-capable
be used. MPLS domain where LSPs are identified as ECN-capable or not-ECN-
capable:
As described in [MPLS_RSVP], bandwidth information may also be - Support of ECN does not require that any bit(s) from the EXP
signaled at LSP establishment time, for the purpose of Traffic field be reserved for ECN operations across all LSPs even when those
Engineering, using the SENDER_TSPEC Object (in the Path message) and LSPs are not ECN-capable. Consequently, LSPs identified as non-ECN-
the FLOWSPEC Object (in the Resv message). capable (regardless of whether this is because at least one LSR on
the LSP does not support ECN operations or whether this is because
the network administrator does not wish to use ECN on this LSP) can
make use of the full 3-bit EXP field for Diff-Serv purposes. Thus,
non-ECN-capable E-LSPs and non-ECN-capable L-LSPs can operate as
defined earlier in this document without any restriction imposed by
the fact that the MPLS domain is ECN-capable. In particular, up to 8
BAs can still be transported over a non-ECN-capable E-LSP within an
ECN-capable MPLS domain. Similarly, non-ECN-capable L-LSPs within an
ECN-capable MPLS domain can support all the drop precedence levels
of currently defined PSCs. Should a future PSC involve more than 4
drop precedence levels, non-ECN-capable L-LSPs within an ECN-capable
MPLS domain could still use the full 3-bit field EXP.
4.4. New LDP TLV - Because a single bit is required to encode the ECN
information inside the ECN-capable MPLS domain, LSPs identified as
ECN-capable can make use of two bits of the EXP field value. In
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
an ECN-capable L-LSP; since all the PSCs corresponding to PHBs
currently defined through standards action involve less than 4 drop
precedence levels, ECN support does not currently restrict Diff-Serv
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.
This section defines a new LDP TLV necessary for support of Diff- 11.1 MPLS ECN bit with Shim Header
Serv in MPLS over ATM/FR when L-LSPs are established via LDP
[MPLS_LDP] or CR-LDP [MPLS CR-LDP]. We define a new PHS TLV to
signal the PHS in a label request or label binding as follows:
0 1 2 3 Where the Shim Header is used as the MPLS encapsulation, ECN
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 information is to be encoded on ECN-capable LSPs in the first bit of
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the 3-bit EXP field in the following way:
|U|F| Type = PHS | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the TLV is [TBD]. EXP field MPLS ECN Meaning
Encoding of the PHS field is the same as encoding of the PHS in 0xx --> `ECT, not CE'
RSVP, as specified in 4.3. 1xx --> `not ECT, or ECT+CE'
We propose that the COS TLV which was specified in [LDP_03] (and where ECT stands for `ECN Capable Transport' and `CE' stands for
removed in later version of the LDP specifications) be `Congestion experienced'.
reincorporated into LDP and used to encode the PHS TLV as a nested
TLV (ie encode the PHS TLV in the COS value of the COS TLV).
Encoding the PHS TLV as a nested TLV of the COS TLV is proposed for
flexibility so that if additional TLVs need to be defined in the
future for support of Diff-Serv over MPLS, those TLVs could be
logically grouped inside the COS TLV.
Alternatively, the PHS TLV could be included in the LDP messages as Le Faucheur et. al 33
an independent TLV (ie not nested in the COS TLV).
As described in [MPLS_CR-LDP], bandwidth information may also be MPLS Support of Diff-Serv October 99
signaled at LSP establishment time, for the purpose of Traffic
Engineering, using the Traffic Parameters TLV.
5. Security Considerations Detailed specification for usage of this MPLS ECN bit is outside the
scope of this specification.
For ECN-capable E-LSPs, the PHB<-->EXP mapping defined above in the
section titled `PHB<-->EXP Field Mapping' and configured on the LSR
is only operating over the last 2 bits of the 3-bit EXP field. Thus
it has the following format:
EXP Field PHB
e00 <-----> a given PHB
e01 <-----> a given PHB
e10 <-----> a given PHB
e11 <-----> a given PHB
where `e' is the MPLS ECN bit and can take the value zero or one
depending on ECN operations.
For ECN-capable L-LSPs, the PSC/EXP-->PHB mapping defined above in
the section titled `PSC/EXP-->PHB is only operating over the last 2
bits of the 3-bit EXP field and is the following:
EXP Field PSC PHB
e00 DF -----> DF
e00 CSn -----> CSn
e00 AFCn -----> AFn1
e01 AFCn -----> AFn2
e10 AFCn -----> AFn3
e00 EF -----> EF
where `e' is the MPLS ECN bit and can take the value zero or one
depending on ECN operations.
For ECN-capable L-LSPs, the PHB--> PSC/EXP mapping defined above in
the section titled `PHB--> PSC/EXP Mapping' is only operating over
the last 2 bits of the 3-bit EXP field and is the following:
PHB EXP Field PSC
DF -----> e00 DF
CSn -----> e00 CSn
AFn1 -----> e00 AFCn
AFn2 -----> e01 AFCn
AFn3 -----> e10 AFCn
EF -----> e00 EF
where `e' is the MPLS ECN bit and can take the value zero or one
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
NOT reserved for ECN and can be used to encode any Diff-Serv
information. In particular, for non-ECN-capable E-LSPs, the
PHB<-->EXP mapping defined in the section titled `PHB<-->EXP Field
Mapping' and configured on the LSR is operating over the 3 bits of
the EXP field.
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.
6. Acknowledgments 13. Acknowledgments
Wu et. al 11 This document has benefited from discussions with K. K.
Ramakrishnan, Eric Rosen, Angela Chiu and Carol Iturralde.
MPLS Support of DiffServ over ATM/FR June 99 APPENDIX A. Ordered Aggregate (OA) and PHB Scheduling Class (PSC)
This document has benefited from discussions with Dan Tappan, Yakov This Appendix contains the definition of two Diff-Serv concepts:
Rekhter, George Swallow, Eric Rosen, and Emmanuel Desmet. - 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.
7. References 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
Le Faucheur et. al 36
MPLS Support of Diff-Serv October 99
This section does not provide additional specification and is only
here to provide examples of how this flexible approach for Diff-Serv
support over MPLS may be deployed. Pros and cons of various
deployment options for particular environments are beyond the scope
of this document.
B.1 Scenario 1: 8 BAs, no Traffic Engineering, no Fast Reroute
A Service Provider running 8 (or less) 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 a single E-LSP per FEC established
via LDP.
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
(eg. 000<-->AF11, 001<-->AF12, 010<-->AF13)
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (eg bandwdith
allocated to AF1) and the dropping behavior for each PHB (eg drop
profile for AF11, AF12, AF13)
- LSRs signal establishment of a single E-LSP per FEC using LDP
in accordance with the specification above (ie no Diff-Serv_PSC TLV
in LDP Label Request/Label Mapping messages to implicitly indicate
that the LSP is an E-LSP)
B.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no Fast
Reroute
A Service Provider running more than 8 BAs over MPLS, not performing
Traffic Engineering and not performing protection via Fast Reroute
and using MPLS Shim encapsulation in his/her network may elect to
run Diff-Serv over MPLS using for each FEC:
- one E-LSP established via LDP to support a set of 8 (or less)
BAs,
AND
- one L-LSP per <FEC,OA> established via LDP for support of the
other BAs.
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
MPLS Support of Diff-Serv October 99
- 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_PSC TLV in LDP Label Request/Label Mapping messages to
implicitly indicate that the LSP is an E-LSP)
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other
BAs using LDP as specified above (ie Diff-Serv_PSC 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
Reroute
A Service Provider running 8 (or less) BAs over MPLS, performing
aggregate Traffic Engineering (ie performing a single common path
selection for all BAs), performing aggregate protection via Fast
Reroute (ie performing Fast Reroute for all PSCs jointly) and 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 via
RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE].
Operations can be summarized as follows:
- the Service Provider configures at every LSR the
bidirectional mapping between each PHB and a value of the EXP field
(eg. 000<-->AF11, 001<-->AF12, 010<-->AF13)
- 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)
- LSRs signal establishment of a single E-LSP per FEC:
* using the RSVP protocol as specified above (ie no
DIFFSERV_PSC RSVP Object in the PATH message containing the
LABEL_REQUEST Object), OR
* using the CR-LDP protocol as specified above (ie no Diff-
Serv_PSC TLV in LDP Label Request/Label Mapping messages).
B.4 Scenario 4: per-OA Traffic Engineering/Fast Reroute
A Service Provider running any number of BAs over MPLS, performing
per-OA Traffic Engineering (ie performing a separate path selection
for each OA) and performing per-OA protection via Fast Reroute (ie
performing protection with different Fast Reroute policies for the
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
CR-LDP.
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)
- 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
L-LSP's PSC (ie DIFFSERV_PSC RSVP Object in the PATH message
containing the LABEL_REQUEST), OR
* using the CR-LDP protocol as specified above to
signal the L-LSP PSC (ie Diff-Serv_PSC TLV in LDP Label
Request/Label Mapping messages).
B.5 Scenario 5: less than 8 BAs, per-OA Traffic Engineering/Fast
Reroute
A Service Provider running less than 8 BAs over MPLS, performing
per-OA Traffic Engineering (ie performing a separate path selection
for each OA) and performing per-OA protection via Fast Reroute (ie
performing protection with different Fast Reroute policies for the
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
CR-LDP.
Operations can be summarized as follows:
- the Service Provider configures at every LSR the
bidirectional mapping between each PHB and a value of the EXP field
(eg. 000<-->AF11, 001<-->AF12, 010<-->AF13)
- 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)
- LSRs signal establishment of one L-LSP per <FEC,OA>:
* 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
message containing the LABEL_REQUEST), OR
* 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
Label Request/Label Mapping messages)
- the Service Provider configures, for each E-LSP, at the head-
end of that E-LSP, a filtering/forwarding criteria so that 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
Traffic Engineering/Fast Reroute on other BAs.
A Service Provider not performing Traffic Engineering/Fast Reroute
on 8 (or less) BAs, performing per-OA Traffic Engineering/Fast
Reroute on the other BAs (ie performing a separate path selection
for each OA corresponding to the other BAs and performing protection
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
over MPLS, using for each FEC:
- one E-LSP established via LDP to support the set of 8 (or
less) non-traffic-engineered/non-fast-rerouted BAs,
AND
Le Faucheur et. al 39
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:
- the Service Provider configures at every LSR the bi-
directional mapping between each PHB and a value of the EXP field
for the BAs supported 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
- LSRs signal establishment of a single E-LSP per FEC for the
non-traffic engineered BAs using LDP as specified above (ie no Diff-
Serv_PSC TLV in LDP Label Request/Label Mapping messages)
- LSRs signal establishment of one L-LSP per <FEC,OA> for the
other BAs:
* using the RSVP protocol as specified above to signal
the L-LSP PSC (ie DIFFSERV_PSC RSVP Object in the PATH message
containing the LABEL_REQUEST Object), OR
* using the CR-LDP protocol as specified above to
signal the L-LSP PSC (ie Diff-Serv_PSC TLV in LDP Label
Request/Label Mapping messages).
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-04.txt), Architecture", work in progress, (draft-ietf-mpls-arch-06.txt),
February 1999. August 1999.
[MPLS ATM] Davie et al., _MPLS using LDP and ATM VC Switching_, work
in progress, (draft-ietf-mpls-atm-02.txt), April 1999
[MPLS FR] Conta et al., _Use of Label Switching on Frame Relay
Networks Specification_, (draft-ietf-mpls-fr-03.txt), November 1998
[DIFF_ARCH] Blake et al., "An architecture for Differentiated [DIFF_ARCH] Blake et al., "An architecture for Differentiated
Services", RFC-2475, December 1998. Services", RFC-2475, December 1998.
[MPLS_DIFF_PPP] Le Faucheur et al, "MPLS Support of Differentiated
Services over PPP links", draft-lefaucheur-mpls-diff-ppp-00.txt,
June 99.
[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.
[MPLS_ATM] Davie et al., "MPLS using LDP and ATM VC Switching", Le Faucheur et. al 40
draft-ietf-mpls-atm-02.txt, April 1999.
[MPLS_FR] Conta et al., "Use of Label Switching on Frame Relay MPLS Support of Diff-Serv October 99
Networks", draft-ietf-mpls-fr-03.txt, November 1999.
[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.
[LDP_03] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- [MPLS_ECN] Ramakrishnan et al., "A Proposal to Incorporate ECN in
03.txt, January 99 MPLS", draft-ietf-mpls-ecn-00.txt, June 1999.
[LDP_04] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-
04.txt, April 99
[MPLS_RSVP] Awduche et al, "Extensions to RSVP for LSP Tunnels", [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-
draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999 05.txt, June 99
[MPLS CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using [RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels",
LDP", draft-ietf-mpls-cr-ldp-01.txt, February 1999 draft-ietf-mpls-rsvp-lsp-tunnel-03.txt, September 1999
[PHBID] Brim and Carpenter, "Per Hop Behavior Identification Codes", [CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using
draft-brim-diffserv-phbid-00.txt, April 99 LDP", draft-ietf-mpls-cr-ldp-03.txt, October 1999
Wu et. al 12 [PHBID] Brim et al., "Per Hop Behavior Identification Codes
draft-ietf-diffserv-phbid-00.txt, October 99
MPLS Support of DiffServ over ATM/FR June 99 Author's Addresses:
8. Author's Addresses Francois Le Faucheur
Cisco Systems
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne -
France
Phone: +33 4 92 96 75 64
Email: flefauch@cisco.com
Liwen Wu Liwen Wu
Alcatel USA Cisco Systems
44983 Knoll Square 250 Apollo Drive, Chelmsford, MA 01824, USA
Ashburn, VA 20147 Phone: (978)-244-3087
USA Email:
E-mail liwen.wu@adn.alcatel.com liwwu@cisco.com
Pierrick Cheval Bruce Davie
Alcatel USA Cisco Systems
44983 Knoll Square 250 Apollo Drive, Chelmsford, MA 01824
Ashburn, VA 20147
USA USA
Phone: (978)-244-8000
Email: bsd@cisco.com
E-mail pierrick.cheval@adn.alcatel.com Shahram Davari
PMC-Sierra Inc.
105-8555 Baxter Place
Burnaby, BC V5A 4V7
Canada
E-mail: Shahram_Davari@pmc-sierra.com
Pasi Vaananen Pasi Vaananen
Nokia Nokia
3 Burlington Woods Drive, Suite 250 3 Burlington Woods Drive, Suit 250
Burlington, MA 01803 Burlington, MA 01803
USA
E-mail pasi.vaananen@ntc.nokia.com Le Faucheur et. al 41
Francois le Faucheur MPLS Support of Diff-Serv October 99
Cisco Systems, Inc.
Les Lucioles - 291, rue Albert Caquot
06560 Valbonne
France
E-mail flefauch@cisco.com USA
Phone +1 (781) 238-4981
Email: pasi.vaananen@nokia.com
Bruce Davie Ram Krishnan
Cisco Systems, Inc. Nexabit Networks
250 Apollo Drive 200 Nickerson Road,
Chelmsford, MA, 01824 Marlboro, MA 01752
USA USA
E-mail: ram@nexabit.com
E-mail bsd@cisco.com Pierrick Cheval
Alcatel
5 rue Noel-Pons
92734 Nanterre Cedex
France
E-mail: pierrick.cheval@alcatel.fr
Wu et. al 13 Le Faucheur et. al 42
 End of changes. 

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