Internet Draft
F. Le Faucheur
Cisco Systems
Shahram Davari
PMC-Sierra Inc.
Ram Krishnan
Nexabit Networks
Pasi Vaananen
Nokia
B. Davie
Cisco Systems
IETF Internet Draft
Expires: December, 1999
Document: draft-lefaucheur-mpls-diff-ppp-00.txt June, 1999
MPLS Support of Differentiated Services over PPP links
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 proposes a flexible solution for MPLS to support
Differentiated Services (Diff-Serv) over PPP links.
This solution allows the service provider to flexibly define how
Diff-Serv Behavior Aggregates (BAs) are mapped onto LSPs so that
he/she can best match the Diff-Serv and Traffic Engineering
objectives within his/her particular network. For instance, this
solution allows the service provider to decide whether 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 the Behavior Aggregate's scheduling treatment is
inferred by the LSR from the packet's label value while the Behavior
Le Faucheur, et. al 1
MPLS Support of DiffServ over PPP June 99
Aggregate's drop precedence is indicated in the EXP field of the
MPLS PPP Header.
- LSPs where both the Behavior Aggregate's scheduling treatment
and drop precedence are conveyed to the LSR in the EXP field of the
MPLS PPP Header.
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 proposes 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, where
LSRs are interconnected via PPP links.
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 proposed in this document aims at allowing Service
Providers the flexibility to select how Diff-Serv classes of service
should be Routed or Traffic Engineered within their domain (eg.
separate classes of services supported via separate LSPs and
Routed separately, all classes of service supported on the same LSP
and Routed or Traffic Engineered together).
Beside, the solution proposed in this document aims at maximizing
label space usage and minimizing the volume of label set-up/tear-
down signaling where possible by only mandating set-up of multiple
LSPs for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when
useful or required.
1.1. Ordering Constraints, "Scheduling Aggregate (SA)" and "Per Hop
Scheduling (PHS) "
[DIFF_AF] states that "a DS node does not reorder IP packets of the
same microflow if they belong to the same AF class" (even if
Le Faucheur et. al 2
MPLS Support of DiffServ over PPP June 99
different packets of the microflow contain different AF codepoints
of the same AF class).
For the sake of generality, we define a set of Behavior Aggregates
which share such an ordering constraint to constitute a "Scheduling
Aggregate_ (SA). The mechanisms described in this draft aim, in
particular, to preserve the correct ordering relationships for
packets that belong to a given SA.
We refer to the set of one or more PHBs applied to the set of
Behavior Aggregates forming a given SA, as a _Per Hop Scheduling_
(PHS).
The PHBs currently specified are Default PHB (DF), Class Selector
PHB group (CSx), Assured Forwarding PHB group (AFxy), Expedited
Forwarding PHB (EF).
1.1.1 DF PHS
The Default PHB is a single PHB specified in [DIFF_Header]. Thus,
the corresponding PHS comprises a single PHB and thus coincides with
the DF PHB.
1.1.2 CSn PHS
[DIFF_HEADER] defines up to 8 CS Codepoints referred to as CSn,
where 1 <= i <= 8. [DIFF_HEADER] states that "... PHBs selected by
distinct Class Selector Codepoints SHOULD be independently
forwarded; that is, packets marked with different Class Selector
Codepoints MAY be re-ordered". Thus, there is one PHS corresponding
to each CSn PHB. Each CSn PHS comprises a single PHB and thus
coincides with this CSn PHB.
1.1.3 AFCn PHS
As described in [DIFF_AF], the Assured Forwarding (AF) PHB group
provides forwarding of IP packets in N independent AF classes.
Within each AF class, an IP packet is assigned one of M different
levels of drop precedence. An IP packet that belongs to an AF class
i and has drop precedence j is marked with the AF codepoint AFij,
where 1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4)
with three levels of drop precedence in each class (M=3) are
defined for general use.
[DIFF_AF] states that "a DS node does not reorder IP packets of the
same microflow if they belong to the same AF class" (even if
different packets of the microflow contain different AF codepoints
of the same AF class). As noted above, each AF class in the AF PHB
group is the primary example of a PHS. Each PHS comprises 3 PHBs and
coincides with the AF Class. Those PHSs are thus referred to as
AFCn, where 1 <= n <= 4.
Le Faucheur et. al 3
MPLS Support of DiffServ over PPP June 99
1.1.4 EF PHS
[DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic
requiring forwarding with low loss, low latency, low jitter.
[DIFF_EF] defines a single PHB. Thus, the corresponding PHS
comprises a single PHB and thus coincides with the DF PHB.
1.1.5 Summary list of PHS
The following PHSs have thus been identified:
- DF
- CSn , 1 <= i <= 8
- AFCn, 1 <= i <= 4
- EF
1.2 Label-Inferred-PHS LSPs (L-LSP)
We propose below, in section 2, a method for Diff-Serv over MPLS
over PPP where one LSP is established per pair between two
PPP LSR neighbours.
This method relies on explicit signaling of the PHS at label
establishment time so that, after label establishment, the LSR can
infer from the label value the PHS to be applied to a labeled
packets. Drop Precedence to be applied by the LSR to the labeled
packet is conveyed inside the packet MPLS Shim Header [MPLS_ENCAPS]
using the EXP field.
We refer to such LSPs as " Label-Inferred-PHS LSPs" (L-LSP).
Detailed Operation of L-LSPs is specified in section 2 below.
L-LSPs offer the following benefits:
- they support any number of Behavior Aggregates allowed by the
Diff-Serv architecture, and
- they support separate routing/traffic-engineering of PHSs.
L-LSPs have the following drawbacks:
- they require the use of separate LSPs for support of
different PHSs, and
- they require more signaling operations to set up these
L-LSPs.
1.3 EXP-Inferred-PHS LSPs (E-LSP)
We propose below, in section 3, a method where up to eight BAs can
be supported via a single LSP, regardless of how many SAs these BAs
span. In this method, the DSCP value get entirely mapped into the
EXP field of the MPLS Shim Header [MPLS_ENCAPS] at the Edge of the
MPLS PPP Cloud (thus encoding both drop precedence and
PHS/scheduling information). In other words, both PHS and Drop
Le Faucheur et. al 4
MPLS Support of DiffServ over PPP June 99
Precedence are conveyed in each labeled packet using the EXP field
of the MPLS Shim Header [MPLS_ENCAPS].
We refer to such LSPs as "EXP-inferred-PHS LSPs" (E-LSP). Detailed
Operation of E-LSPs is specified in section 3 below.
E-LSPs have the following benefits, where separate routing or
separate traffic-engineering of PHSs is not required:
- label space is conserved by "packing" 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
network).
- label establishment signaling is reduced since a single LSP
is established for up to eight BAs (eg. when there are fewer than
eight BAs in the network, this method maintains the same level of
signaling as in a non-Diff-Serv capable network)
-the amount of forwarding state is reduced, as a single
forwarding entry can support up to 8 BAs.
- operation of Diff-Serv MPLS over E-LSPs is analogous to
operations of Diff-Serv in non-MPLS networks in the sense that the
Diff-Serv PHB is triggered exclusively by a field explicitly encoded
in every packet based on locally configured PHB mapping. This is
expected to facilitate migration from non-MPLS Diff-Serv to MPLS
Diff-Serv operations in some networks.
- some early implementations of E-LSPs exist today and
experiments have confirmed proper operations and usefulness.
E-LSPs have the following drawbacks:
- they only support up to eight BAs, and
- they do not allow routing/traffic-engineering of individual
PHSs.
1.4 Overall Approach
We propose a flexible solution for Diff-Serv support by MPLS over
PPP links where the Service Provider can use both E-LSPs and L-LSPs
in the combination that best match his/her environment and
objectives in terms of Diff-Serv support and Traffic Engineering.
For instance, a Service Provider who:
- supports fewer than eight BAs, and
- does not perform traffic engineering or performs aggregate
traffic engineering of all SAs jointly,
may use a single E-LSP per FEC.
A Service Provider who:
- performs traffic engineering of each SA separately
may use one L-LSP per .
A Service Provider who
- supports more than eight BAs, and
Le Faucheur et. al 5
MPLS Support of DiffServ over PPP June 99
- does not perform traffic engineering or performs traffic
engineering of traffic aggregates where one traffic aggregate
comprises multiple SAs,
may use:
- a single E-LSP per FEC for supporting up to eight BAs (BAs
corresponding to SAs that can be traffic engineered jointly)
- one L-LSP per for supporting other.
Those are just examples of how a Service Provider can use
combinations of E-LSPs and L-LSPs to best match his/her environment.
Clearly, other combinations could be used in the environments
described above and other environments can also be supported.
When selecting a combination of E-LSPs and L-LSPs to meet some
specific Traffic Engineering goals, it is important to note that:
- SAs supported by the same E-LSP can be Traffic Engineered
jointly. A path is selected for the BAs of all the supported SAs (eg
by Constraint Based Routing or by explicit configuration) and the
corresponding E-LSP is then established along that path via RSVP or
CR-LDP signaling;
- SAs supported by the same E-LSP CANNOT be Traffic Engineered
separately. Since the BAs of all the transported SAs are to be label
switched via the same LSP, all these SAs follow a single path;
- SAs supported by separate L-LSPs can be Traffic Engineered
separately. A path is selected independently for each SA (eg by
Constraint Based Routing or by explicit configuration) and the
corresponding L-LSPs are then established independently via RSVP or
CR-LDP signaling;
- SAs supported by separate L-LSPs can be Traffic Engineered
jointly. A path is selected for the aggregate of all the considered
SAs and the L-LSPs are then established independently along the same
common path via RSVP or CR-LDP signaling;
1.5 Explicit Congestion Notification
Explicit Congestion Notification is described in [ECN] and is
proposed as an Experimental extension to the IP protocol. Because
ECN is still at the Experimental stage and its impact and
interactions with Diff-Serv have not yet been specified, this
Internet-Draft does not discuss ECN operations. Support for
simultaneous Diff-Serv and ECN over MPLS is left for further study.
1.6 Label Forwarding Model for Diff-Serv LSRs
In order to describe Label Forwarding by Diff-Serv LSRs, we propose
to model a Diff-Serv label switching behavior as comprising three
stages:
-A- incoming PHB and FEC determination
-B- Optional outgoing PHB determination via Local Policy and
Traffic Conditioning
-C- Outgoing EXP field and label determination
Le Faucheur et. al 6
MPLS Support of DiffServ over PPP June 99
The Diff-Serv LSR SHALL apply the scheduling/dropping behavior
corresponding to the _Outgoing PHB_ in compliance with the
corresponding Diff-Serv PHB specification.
With such a model, we expect that "Diff-Serv over MPLS" label
forwarding can be specified (from the Diff-Serv viewpoint)
separately for each method (eg. Diff-Serv over MPLS over PPP using
L-LSPs, Diff-Serv over MPLS over PPP using E-LSPs, Diff-Serv over
MPLS over ATM/FR) by specifying -A- and -C- for the considered
method without having to specify the complete label switching
behavior (A+B+C) for every possible incoming/outgoing combination.
This model is used below for specifying LSR Label Forwarding over
PPP links using L-LSPs and E-LSPs for Diff-Serv support over MPLS.
2. Detailed Operation of L-LSPs
This section is based on [MPLS_DIFF_PPP].
2.1 L-LSP Establishment
Recognizing that:
- MPLS over PPP links requires the use of a Shim Header which
consists of a label stack with one or more entries [MPLS_ENCAPS];
- The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER], so
that when more than 8 BAs are used , the DSCP field can not be
mapped entirely into the 3-bit long EXP field of the MPLS label
stack entry;
- Some Service Providers have a requirement for fine grain
Traffic Engineering (such as per SA Traffic Engineering)
We propose that:
- All packets belonging to a single SA and the same Forwarding
Equivalent Class (FEC) be sent down a single LSP;
- One LSP be established per pair (rather than simply
one LSP per FEC as in an MPLS network that does not support Diff-
Serv). Such an LSP is referred to as a "Label-inferred-PHS" LSP or
"L-LSP";
- Multiple BAs belonging to the same SA be granted different Drop
Precedence (DP) values through appropriate coding of the EXP field
of the top label entry of the shim header.
MPLS specifies how LSPs can be established via multiple signaling
protocols. Those include the Label Distribution Protocol (LDP),
RSVP, BGP and PIM. This Internet-Draft proposes below, in section
Le Faucheur et. al 7
MPLS Support of DiffServ over PPP June 99
2.5, the required extensions to LDP and RSVP to allow establishment
of one L-LSP per pair over PPP MPLS.
2.2 Label Forwarding
2.2.1 Incoming PHB and FEC Determination On Ingress L-LSP
When receiving a labeled packet over an L-LSP of an MPLS PPP ingress
interface, the LSR:
- determines the FEC based on the incoming label
- determines the PHS from the incoming label among the set of
LSPs established for that FEC
- determines the incoming PHB from the PHS and the EXP field of
the top level label entry in accordance with the PHS/EXP-->PHB
mapping defined below in section 2.3.
If the EXP field value of a packet received on an L-LSP is such that
the PHS/EXP combination is not listed in the mapping of section 2.3,
this PHS/EXP combination should be considered invalid. LSR behavior
in such situation is a local matter and is outside the scope of this
document.
2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning
This stage of Diff-Serv label switching is independent of the
ingress/egress interface media type and method used for MPLS Diff-
Serv support. It is optional and may be used on an LSR to perform
Behavior Aggregate demotion or promotion inside an MPLS Diff-Serv
domain. For the purpose of specifying a Diff-Serv over MPLS method,
we simply note that the PHB to be actually enforced by an LSR
(referred to as "outgoing PHB") may be different to the PHB which
had been associated with the packet at the previous LSR (referred to
as "incoming PHB").
2.2.3 Outgoing EXP Field and Label Determination on Egress L-LSP
Once the outgoing PHB has been determined by the LSR as a function
of the incoming PHB and of the optional Local Policy and Traffic
Conditioning, the LSR:
- determines via local configuration that the outgoing PHB is
one of the PHBs supported by a L-LSP and determines the egress
L-LSP label for the packet's FEC
- determines the value to be written in the EXP field of the
top level label entry (and possibly of other level label entries in
the case of a hierarchical tunnel entry) by performing the outgoing
PHB-->EXP/PHS mapping defined below in section 2.4.
2.2.4 Simplified Forwarding
Le Faucheur et. al 8
MPLS Support of DiffServ over PPP June 99
When Local Policy and Traffic Conditioning are not to be performed
by the LSR, and when the labeled packet is received on a L-LSP PPP
interface and is going out onto a L-LSP PPP interface, the
Forwarding operation is simplified since:
- the EXP field does not need to be modified
- the outgoing label can be directly determined from the
incoming label (ie as in non Diff-Serv capable LSRs)
2.3 PHS/EXP --> PHB Mapping
The mapping from L-LSP PHS and from EXP field of the shim header
into PHBs is as follows:
EXP Field PHS PHB
000 DF -----> DF
000 CSn -----> CSn
000 AFCn -----> AFn1
001 AFCn -----> AFn2
010 AFCn -----> AFn3
000 EF -----> EF
2.4 PHB --> PHS/EXP Mapping
The mapping from PHBs into the L-LSP PHS and the EXP field of the
shim header is as follows:
PHB EXP Field PHS
DF -----> 000 DF
CSn -----> 000 CSn
AFn1 -----> 000 AFCn
AFn2 -----> 001 AFCn
AFn3 -----> 010 AFCn
EF -----> 000 EF
2.5 L-LSP Establishment and Message Format
2.5.1 Signaling extension during L-LSP establishment
To support Diff-Serv in MPLS over PPP using L-LSPs, the PHS must be
signaled at label establishment time in the MPLS label request
messages and MPLS label binding messages. The detailed format of the
corresponding message extension is described below when the
signaling protocol used is LDP or RSVP. The MPLS control application
on each LSR along the L-LSP will process the new PHS attribute and
install the corresponding scheduling behavior for that LSP (eg. map
the LSP into an output queue associated with the PHS).
Le Faucheur et. al 9
MPLS Support of DiffServ over PPP June 99
2.5.2 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 over PPP is
compatible with LSP Merging under the following condition:
L-LSPs can only be merged into one L-LSP if they are associated with
the same PHS.
Note that when L-LSPs merge, the bandwidth that is available for the
PHS downstream of the merge point must be sufficient to carry the
sum of the merged traffic. This is particularly important in the
case of EF traffic.
2.5.3 New RSVP Object Format
This section defines a new RSVP object class and a new RSVP object
within that class for support of Diff-Serv in MPLS over PPP when
L-LSPs are established via RSVP [MPLS_RSVP].
The new object Class is defined as the "Class Of Service" Class (COS
Class). Its Class-Num is [TBD].
The new RSVP DIFFSERV_PHS object is defined within the COS Class to
carry the PHS of the traffic to be transported on the corresponding
LSP. Its C-Type is 1.
As described in [MPLS_RSVP], bandwidth information may also be
signaled at LSP establishment time, for the purpose of Traffic
Engineering, using the SENDER_TSPEC Object (in the Path message) and
the FLOWSPEC Object (in the Resv message).
DIFFSERV_PHS object Class = [TBD], C-Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 4 | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PHS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We propose that the 16-bit PHS be encoded as specified in section 2
of [PHBID]. In particular, we propose that the encoding for a PHS be
the smallest numerical value of the encodings for the various PHBs
in the PHS. In turn, the encoding of a single PHB defined by
standards action is the recommended DSCP value for this PHB, left-
justified in the 16 bit field, with bits 6 through 15 set to zero.
Le Faucheur et. al 10
MPLS Support of DiffServ over PPP June 99
For instance, the encoding of the AFC1 PHS is the encoding of the
AF11 PHB.
This object may be carried in a PATH message that contains the
LABEL_REQUEST object to indicate the PHS for which a label is
required. The object may also be carried in a RESV message that
contains a LABEL object indicating the PHS for which the label is to
be used.
2.5.4 New LDP TLV
This section defines a new LDP TLV necessary for support of Diff-
Serv in MPLS over PPP when L-LSPs are established via LDP
[MPLS_LDP]. We define a new PHS TLV to signal the PHS in a label
request or label binding 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = PHS | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the TLV is [TBD].
Encoding of the PHS field is the same as encoding of the PHS in
RSVP, as specified in 2.5.3.
We propose that the COS TLV which was specified in [LDP_03] (and
removed in later version of the LDP specifications) be
reincorporated into LDP and used to encode the PHS TLV as a nested
TLV (ie encode the PHS TLV in the COS value of the COS TLV).
Encoding the PHS TLV as a nested TLV of the COS TLV is proposed for
flexibility so that if additional TLVs need to be defined in the
future for support of Diff-Serv over MPLS, those TLVs could be
logically grouped inside the COS TLV.
Alternatively, the PHS TLV could be included in the LDP messages as
an independent TLV (ie not nested in the COS TLV).
As described in [MPLS_CR_LDP], bandwidth information may also be
signaled at LSP establishment time, for the purpose of Traffic
Engineering, using the Traffic Parameters TLV.
3 Detailed Operations of E-LSPs
3.1 E-LSP establishment
Recognizing that:
Le Faucheur et. al 11
MPLS Support of DiffServ over PPP June 99
- MPLS over PPP links requires the use of a Shim Header which
consists of a label stack with one or more entries [MPLS_ENCAPS];
- The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER] but
when 8 (or less) BAs are used, the DSCP values can be mapped
entirely into the 3-bit long EXP field of the MPLS label stack
entry;
- Some Service Providers do not have requirements for fine
grain Traffic Engineering and want to traffic engineer all/multiple
SAs jointly.
We propose that:
- One LSP be established per Forwarding Equivalent Class (FEC)
for transport of up to eight BAs of that FEC;
- all packets belonging to the same (FEC) and from the set of up
to eight BAs (which can span multiple SAs) be sent down this LSP.
Such an LSP is referred to as an "EXP-inferred-PHS" LSP or _E-LSP_;
- Multiple BAs belonging to the same FEC and transported over the
same E-LSP be granted different scheduling treatment and different
drop precedence by the PPP MPLS LSR based on the EXP field which is
appropriately encoded at label imposition time to reflect both the
PHS and the drop precedence of the PHB corresponding to the packet's
BA.
MPLS specifies how LSPs can be established via multiple signaling
protocols. Those include the Label Distribution Protocol (LDP),
RSVP, BGP and PIM. This Internet-Draft specifies below, in section
3.5, how LDP and RSVP are to be used for establishment of an E-LSP
over a PPP link for support of up to eight BAs.
3.2 Label Forwarding
3.2.1 Incoming PHB and FEC Determination On Ingress E-LSP
When receiving a labelled packet over a E-LSP of an MPLS PPP ingress
interface, the LSR:
- determines the FEC based on the incoming label
- determines the incoming PHB by looking at the EXP field of
the top level label entry and performing the EXP-->PHB mapping
defined below in section 3.4.
If the EXP field value of a packet received on an E-LSP is not
listed in the mapping of section 2.3, this EXP value should be
considered invalid. LSR behavior in such situation is a local matter
and is outside the scope of this document.
Le Faucheur et. al 12
MPLS Support of DiffServ over PPP June 99
3.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning
This stage of Diff-Serv label switching is independent of the
ingress/egress interface media type and method used for MPLS Diff-
Serv support. It is optional and may be used on an LSR to perform
Behavior Aggregate demotion or Promotion inside an MPLS Diff-Serv
domain. For the purpose of specifying a Diff-Serv over MPLS method,
we simply note that the PHB to be actually enforced by an LSR
(referred to as "outgoing PHB") may be different to the PHB which
had been associated with the packet by the previous LSR (referred to
as "incoming PHB").
3.2.3 Outgoing EXP Field And Label Determination On Egress E-LSP
Once the outgoing PHB has been determined by the LSR as a function
of the incoming PHB and of the optional Local Policy and Traffic
Conditioning, the LSR:
- determines via local configuration that the outgoing PHB is
one of the PHBs supported by the E-LSP and determines the egress E-
LSP label for the packet's FEC
- determines the value to be written in the EXP field of the
top level label entry (and possibly of other level label entries in
the case of a hierarchical tunnel entry) by performing the outgoing
PHB-->EXP mapping defined below in section 3.3.
3.2.4 Simplified Forwarding
When Local Policy and Traffic Conditioning are not to be performed
by the LSR and the labeled packet is received on a E-LSP PPP
interface and is going out onto a E-LSP PPP interface, the
Forwarding operation is simplified since:
- the EXP field does not need to be modified
- the outgoing label can be directly determined from the
incoming label (ie as in non Diff-Serv capable LSRs)
3.3 PHB-->EXP field mapping
Like the mapping between PHBs and DSCPs in a Diff-Serv network, the
mapping from PHB to EXP field is a local matter to be defined by the
Service Provider and configured on every LSR. The requirements on
this mapping are that:
- each of the eight (or less) PHBs to be supported over the E-
LSP must map to a different encoding of the 3-bit EXP field (so the
mapping can be inverted back from EXP field to PHB at egress)
- the mapping must be consistent at every PPP LSP hop
throughout the Diff-Serv domain spanned by the LSP
3.4 EXP-->PHB mapping
Similarly the mapping from EXP field to PHB is a local matter. The
requirement on this mapping is that:
Le Faucheur et. al 13
MPLS Support of DiffServ over PPP June 99
- it must be the exact inverse of the PHB to EXP field mapping
- it must be consistent at every PPP LSP hop throughout the
Diff-Serv domain spanned by the LSP
3.5 Signalling During E-LSP establishment
To support Diff-Serv in MPLS over PPP using E-LSPs, the fact that
the LSP is a E-LSP must be conveyed in the MPLS label request
messages and MPLS label binding messages. The method to achieve this
is described below when the signaling protocol used is RSVP or LDP.
The MPLS control application on each PPP LSR along the E-LSP will
notice that the LSP is a E-LSP and install the corresponding
scheduling and drop behavior for that LSP based on the EXP<-->PHB
mapping locally configured for E-LSP operations.
3.5.1 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 over PPP using E-
LSPs is compatible with LSP Merging under the following condition:
E-LSPs can only be merged into one LSP if they support the exact
same set of BAs.
3.5.2 RSVP Signaling for E-LSPs
A new DIFFSERV_PHS RSVP Object has been defined above in section
2.5.3 to explicitly signal that an LSP is a L-LSP and to indicate
the PHS associated with the L-LSP.
We propose that no new RSVP Object be defined for E-LSPs. Rather, we
propose that the fact that the LSP is an E-LSP be implicitly
conveyed by the absence of DIFFSERV_PHS RSVP Object in a PATH
message containing a LABEL_REQUEST Object and in a RESV message
containing the LABEL Object.
3.5.3 LDP Signaling for E-LSPs
A new PHS TLV has been defined above in section 2.5.4 to explicitly
signal that an LSP is an L-LSP and to indicate the PHS associated
with the LSP.
We propose that no new LDP TLV be defined for E-LSPs. Rather, we
propose that the fact that the LSP is an E-LSP be implicitly
conveyed by the absence of PHS TLV in a label request or label
binding message.
4. Example Deployment Scenarios
This section does not provide additional specification of the
proposed approach and is only here to provide examples of how this
Le Faucheur et. al 14
MPLS Support of DiffServ over PPP June 99
flexible approach for Diff-Serv support over MPLS over PPP may be
deployed. Pros and cons of various deployment options for particular
environments are beyond the scope of this document.
4.1 Scenario 1: 8 BAs, no Traffic Engineering
A Service Provider running 8 (or less) BAs and not performing
Traffic engineering in his/her network may elect to run Diff-Serv
over MPLS over PPP links using a single E-LSP per FEC established
via LDP.
Operations can be summarized as follows:
- the Service Provider configures at every PPP LSR the bi-
directional mapping between each PHB and a value of the EXP field
- PPP LSRs signal establishment of a single E-LSP per FEC using
LDP in accordance with section 3.5.3 above (ie no PHS TLV in LDP
label request and label binding messages to implicitly indicate that
the LSP is a E-LSP)
4.2 Scenario 2: 8 BAs, no Traffic Engineering
A Service Provider running 8 (or less) BAs and not performing
Traffic engineering in his/her network may alternatively elect to
run Diff-Serv over MPLS over PPP links using one L-LSP per
established via LDP.
Operations can be summarised as follows:
- the Service Provider configures on every PPP LSR the
parameters pertaining to the scheduling behavior that should be
installed for the L-LSP by the control application for each PHS
- PPP LSRs signal establishment of one L-LSP per using
the LDP protocol and the LDP extension defined in section 2.5.4
above to signal the L-LSP PHS (ie PHS TLV in LDP label request and
label binding messages).
4.3 Scenario 3: 8 BAs, Aggregate Traffic Engineering
A Service Provider running 8 (or less) BAs and performing aggregate
Traffic Engineering (ie performing a single common path selection
for all BAs) in his/her network may elect to run Diff-Serv over MPLS
over PPP links using a single E-LSP per FEC established via RSVP
[RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE].
Operations can be summarized as follows:
- the Service Provider configures at every PPP LSR the
bidirectional mapping between each PHB and a value of the EXP field
- PPP LSRs signal establishment of a single E-LSP per FEC using
:
* the RSVP protocol in accordance with section 3.5.2 above
(ie no DIFFSERV_PHS RSVP Object in the PATH message containing the
LABEL_REQUEST Object and in the RESV message containing the LABEL
Object), OR
Le Faucheur et. al 15
MPLS Support of DiffServ over PPP June 99
* using the CR-LDP protocol in accordance with section
2.5.3 above (ie no PHS TLV in LDP label request and label binding
messages).
4.3 Scenario 3: per-SA Traffic Engineering
Regardless of the number of BAs supported, a Service Provider
performing per-SA Traffic Engineering (ie performing a separate path
selection for each SA) in his/her network MUST run Diff-Serv over
MPLS over PPP links using one L-LSP per pair established
via RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE].
Operations can be summarised as follows:
- the Service Provider configures on every PPP LSR the
parameters pertaining to the scheduling behavior that should be
installed for the L-LSP by the control application for each PHS
- PPP LSRs signal establishment of one L-LSP per
using:
* the RSVP protocol and the RSVP extension defined in
section 2.5.3 above to signal the L-LSP (ie DIFFSERV_PHS RSVP Object
in the PATH message containing the LABEL_REQUEST Object and in the
RESV message containing the LABEL Object), OR
* using the CR-LDP protocol and the LDP extension
defined in section 2.5.4 above to signal the L-LSP PHS (ie PHS TLV
in LDP label request and label binding messages).
4.4 Scenario 4: More than 8 BAs, no Traffic Engineering
A Service Provider running more than 8 BAs and not performing
Traffic Engineering in his/her network may elect to run Diff-Serv
over MPLS over PPP links using one L-LSP per pair
established via LDP.
Operations can be summarised as follows:
- the Service Provider configures on every PPP LSR the
parameters pertaining to the scheduling behavior that should be
installed for the L-LSP by the control application for each PHS
- PPP LSRs signal establishment of one L-LSP per using
the LDP protocol and the LDP extension defined in section 2.5.4
above to signal the L-LSP PHS (ie PHS TLV in LDP label request and
label binding messages).
4.5 Scenario 5: no Traffic Engineering on 8 BAs, per-SA Traffic
Aggregate on other BAs.
A Service Provider not performing Traffic Engineering on 8 (or less)
BAs and performing per-SA Traffic Engineering on the other BAs (ie
performing a separate path selection for each SA corresponding to
the other BAs) in his/her network may elect to run Diff-Serv over
MPLS over PPP links, using for each FEC:
- one E-LSP established via LDP to support the set of 8 (or
less) non-traffic engineered BAs,
Le Faucheur et. al 16
MPLS Support of DiffServ over PPP June 99
AND
- one L-LSP per pair established via RSVP
[RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] for support of the other
BAs.
Operations can be summarised as follows:
- the Service Provider configures at every PPP LSR the bi-
directional mapping between each PHB of the non-traffic-engineered
BAs (supported by the E-LSP) and a value of the EXP field
- the Service Provider configures on every PPP LSR the
parameters pertaining to the scheduling behavior that should be
installed for the L-LSP by the control application for each PHS
- PPP LSRs signal establishment of a single E-LSP per FEC for
the non-traffic engineered BAs using LDP in accordance with section
3.5.3 above (ie no PHS TLV in LDP label request and label binding
messages to implicitly indicate that the LSP is a E-LSP)
- PPP LSRs signal establishment of one L-LSP per for
the traffic engineered BAs using:
* the RSVP protocol and the RSVP extension defined in
section 2.5.3 above to signal the L-LSP (ie DIFFSERV_PHS RSVP Object
in the PATH message containing the LABEL_REQUEST Object and in the
RESV message containing the LABEL Object), OR
* using the CR-LDP protocol and the LDP extension
defined in section 2.5.4 above to signal the L-LSP PHS (ie PHS TLV
in LDP label request and label binding messages).
5. Security Considerations
This document does not introduce any new security issues beyond
those inherent in Diff-Serv, MPLS and RSVP, and may use the same
mechanisms proposed for those technologies.
6. Acknowledgments
This document has benefited from discussions with Dan Tappan, Yakov
Rekhter, George Swallow, Kathleen Nichols and Brian Carpenter.
7. References
[MPLS_ARCH] Rosen et al., "Multiprotocol label switching
Architecture", work in progress, (draft-ietf-mpls-arch-04.txt),
February 1999.
[DIFF_ARCH] Blake et al., "An architecture for Differentiated
Services", RFC-2475, December 1998.
[MPLS_DIFF_PPP] Davari et al., "MPLS Support of Differentiated
Services over PPP links", draft-davari-mpls-diff-ppp-00.txt, April
99.
Le Faucheur et. al 17
MPLS Support of DiffServ over PPP June 99
[DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597,
June 1999.
[DIFF_EF] Heinanen et al., "An Expedited Forwarding PHB", RFC-2598,
June 1999.
[MPLS_ENCAPS] Rosen et al., "MPLS Label Stack Encoding", work in
progress, (draft-ietf-mpls-label-encaps-03.txt), September 1998.
[DIFF_HEADER] Nichols et al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474,
December 1998.
[ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion
Notification (ECN) to IP", RFC-2481, January 1999.
[LDP_03] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-
03.txt, January 99
[LDP_04] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-
04.txt, April 99
[RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999
[CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using
LDP", draft-ietf-mpls-cr-ldp-01.txt, February 1999
[PHBID] Brim and Carpenter, "Per Hop Behavior Identification Codes",
draft-brim-diffserv-phbid-00.txt, April 99
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
Shahram Davari
PMC-Sierra Inc.
105-8555 Baxter Place
Burnaby, BC V5A 4V7
Canada
E-mail: Shahram_Davari@pmc-sierra.com
Ram Krishnan
Nexabit Networks
200 Nickerson Road,
Marlboro, MA 01752
Le Faucheur et. al 18
MPLS Support of DiffServ over PPP June 99
USA
E-mail: ram@nexabit.com
Pasi Vanannen
Nokia
3 Burlington Woods Drive, Suit 250
Burlington, MA 01803
USA
Email: pasi.vaananen@ntc.nokia.com
Bruce Davie
Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824, USA
Phone: (978)-244-8000
Email: bsd@cisco.com
Le Faucheur et. al 19