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