draft-ietf-mpls-diff-ext-00.txt   draft-ietf-mpls-diff-ext-01.txt 
Liwen Wu
Network Working Group Liwen Wu Alcatel, USA
Internet Draft Alcatel, USA
Expiration Date: September 1999
Pierrick Cheval Pierrick Cheval
Alcatel, USA Alcatel, USA
Pasi Vaananen Pasi Vaananen
Nokia Nokia
Francois le Faucheur Francois le Faucheur
Cisco Systems, Inc. Cisco Systems, Inc.
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
Internet Draft
Expires: December, 1999
Document: draft-ietf-mpls-diff-ext-01.txt June, 1999
March 1999 MPLS Support of Differentiated Services by ATM LSRs
and Frame Relay LSRs
MPLS Support of Differentiated Services by ATM LSRs and Frame Relay LSRs
draft-ietf-mpls-diff-ext-00.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026. Internet-Drafts are
Working documents of the Internet Engineering Task Force (IETF), its
Internet-Drafts are working documents of the Internet Engineering areas, and its working groups. Note that other groups may also
Task Force (IETF), its areas, and its working groups. Note that distribute working documents as Internet-Drafts.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet- Drafts as reference at any time. It is inappropriate to use Internet- Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as _work in progress._
The list of current Internet-Drafts can be accessed The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document proposes updates to the current MPLS LDP and MPLS RSVP This document proposes a solution for MPLS to support Differentiated
messages for LSP establishment in order to support Differentiated Services (Diff-Serv) over ATM LSRs and Frame Relay LSRs. It proposes
Services (Diff-Serv) over ATM LSRs and Frame Relay LSRs. corresponding updates to the current MPLS LDP and MPLS RSVP messages
for LSP establishment.
In brief, we propose that:
- a set of PHBs that requires no misordering of packets in a
microflow (even if the microflow contains packets for more than
one PHB) be defined as a PHB forwarding class (PFC);
- packets that belong to the same PFC and the same forwarding In brief, we propose to use LSPs where the Behavior Aggregate's
equivalence class (FEC) should be transported over the same ATM scheduling treatment is inferred by the LSR from the packet's label
LSP or FR LSP; value (VCI/DLCI) while the Behavior Aggregate's drop precedence is
indicated in the ATM/FR selective discard CLP/DE field.
- for a given FEC, a separate ATM LSP or FR LSP should be 1 Introduction
established for each PFC, so that multiple ATM or FR LSPs are
established in parallel for support of Diff-Serv;
- among the set of PHBs transported over the same ATM LSP or FR Wu, et. al 1
LSP, the different PHBs' drop precedences be mapped into, and
enforced via, the layer 2 specific selective discard mechanism
(CLP bit with ATM, DE bit with FR).
1. Introduction MPLS Support of DiffServ over ATM/FR June 99
In an MPLS domain [MPLS_ARCH], when a stream of data traverses a In an MPLS domain [MPLS_ARCH], when a stream of data traverses a
common path, a Label Switched Path (LSP) can be established using common path, a Label Switched Path (LSP) can be established using
MPLS signalling protocols. At the ingress Label Switch Router (LSR), MPLS signalling protocols. At the ingress Label Switch Router (LSR),
each packet is assigned a label and is transmitted downstream. At each packet is assigned a label and is transmitted downstream. At
each LSR along the LSP, the label is used to forward the packet to each LSR along the LSP, the label is used to forward the packet to
the next hop. the next hop.
In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the IP [MPLS_ATM] and [MPLS_FR] provides detailed description of how ATM
packets crossing a link and requiring the same Diff-Serv behavior are and FR Switches can be used as MPLS LSRs and how LSPs are
said to constitute a Behavior Aggregate. At the ingress node the established and used by those ATM LSRS and FR LSRs.
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. At the ingress node the
packets are classified and marked with a Diff-Serv Code Point (DSCP) packets are classified and marked with a Diff-Serv Code Point (DSCP)
which corresponds to their Behavior Aggregate. At each transit node, which corresponds to their Behavior Aggregate [DIFF_HEADER]. At each
the destination address is used to decide the next hop while the DSCP transit node, the destination address is used to decide the next hop
is used to select the Per Hop Behavior (PHB) that determines the while the DSCP is used to select the Per Hop Behavior (PHB) that
queuing treatment and, in some cases, drop probability for each determines the queuing treatment and, in some cases, drop
packet. probability for each packet.
This document proposes a solution for support of the currently This document proposes a solution for supporting the Behavior
defined Diff Serv PHBs over an MPLS ATM or MPLS Frame Relay network, Aggregates, whose corresponding PHBs are currently defined (in
i.e., an MPLS network implemented using ATM of Frame Relay switches. [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS ATM or MPLS Frame
Support of Diff Serv on other link types is for further study. Relay network, i.e., an MPLS network implemented using ATM of Frame
Relay switches.
1.1. Ordering Constraints and PHB Forwarding Classes 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 [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 packets same microflow if they belong to the same AF class" (even if
of the microflow contain multiple AF codepoints within the same AF different packets of the microflow contain different AF codepoints
class). For the sake of generality, we define a set of PHBs which of the same AF class).
impose such an ordering constraint to be a "PHB Forwarding Class" or
PFC. The mechanisms described in this draft aim to preserve the
correct ordering relationships for packets that belong to a single
PFC.
1.2. LSP Establishment for Diff-Serv over ATM/FR MPLS 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.
Recognizing that: 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
Wu et. al 2
MPLS Support of DiffServ over ATM/FR June 99
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 <= n <= 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.
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 LSP Establishment for Diff-Serv over ATM/FR MPLS
Recognizing that
Wu et. al 3
MPLS Support of DiffServ over ATM/FR June 99
- the MPLS Header of MPLS switched packets is generally not - the MPLS Header of MPLS switched packets is generally not
visible to ATM and Frame Relay MPLS LSRs since it is encapsulated visible to ATM and Frame Relay MPLS LSRs since it is encapsulated
"inside" the ATM or FR LSP "connection"; "inside" the ATM or FR LSP "connection";
- ATM and Frame Relay switching hardware is generally capable of - MPLS Diff-Serv assumes a similar architecture to non-MPLS
selecting different scheduling queues for cells/frames belonging Diff-Serv whereby the appropriate forwarding/prioritisation is to be
to different connections but is generally not capable of selecting performed at every hop (ie every MPLS LSR, including ATM LSR and FR
different scheduling queues for cells/frames belonging to the same LSR) in accordance to the packet's Behavior Aggregate.
ATM/Frame Relay connection;
- ATM and Frame Relay switching hardware must be capable of - ATM and Frame Relay switching hardware is generally capable
of selecting different scheduling behaviors (eg. Queues) for
cells/frames belonging to different connections but is generally not
capable of selecting different scheduling behaviors for cells/frames
belonging to the same ATM/Frame Relay connection;
- ATM and Frame Relay switching hardware is capable of
maintaining the order of all packets or cells sent on a single maintaining the order of all packets or cells sent on a single
connection; connection;
- ATM and Frame Relay switching hardware is generally capable of - ATM and Frame Relay switching hardware is generally capable
enforcing different drop priorities within a single connection via of enforcing different drop priorities within a single connection
standardized technology-specific selective drop mechanisms (Cell via standardized technology-specific selective drop mechanisms (Cell
Loss Priority - CLP- for ATM and Discard Eligible - DE- for Frame Loss Priority - CLP- for ATM and Discard Eligible - DE- for Frame
Relay); Relay);
we propose that: we propose that
- all packets belonging to a single PFC and the same forwarding - all packets belonging to a single SA and the same Forwarding
equivalence class (FEC) should be sent down a single LSP; Equivalence Class (FEC) be sent down a single LSP;
- one LSP should be established per <PFC, FEC> pair (rather than - one LSP be established per <FEC, SA> pair (rather than simply
simply one LSP per FEC as in a network that does not support one LSP per FEC as in a network that does not support Diff-Serv).
Diff-Serv); Such an LSP is referred to as a "Label-inferred-PHS" LSP or "L-LSP";
- multiple PHBs belonging to the same PFC be granted different - packets from multiple BAs of a given SA be granted a
drop precedences through mapping into the layer 2 specific different drop precedence through mapping into the layer 2 specific
selective discard indicator (CLP bit with ATM, DE bit with FR). selective discard indicator (CLP bit with ATM, DE bit with FR).
MPLS specifies how LSPs can be established via multiple signalling MPLS specifies how LSPs can be established via multiple signaling
protocols. Those include the Label Distribution Protocol (LDP), RSVP, protocols. Those include the Label Distribution Protocol (LDP),
BGP and PIM. This Internet-Draft proposes below the required RSVP, BGP and PIM. This Internet-Draft proposes below the required
extensions to LDP and RSVP to allow establishment of one LSP per extensions to LDP and RSVP to allow establishment of one L-LSP per
<PFC, FEC> pair over ATM and FR MPLS. <FEC,SA> pair over ATM MPLS and FR MPLS.
In the event that it is desired to signal bandwidth or other resource For the purpose of meeting some specific Traffic Engineering goals,
requirements for an LSP that will carry Diff-Serv traffic (e.g. for we note that:
traffic engineering purposes), the mechanisms available in the LSP - SAs supported by separate L-LSPs may be Traffic Engineered
setup protocol (RSVP or LDP) may be used. separately. A path is selected independently for each SA (eg by
Constraint Based Routing or by explicit configuration) and the
1.3. Label Forwarding for Diff-Serv over ATM/FR MPLS Wu et. al 4
At the edge of the ATM or FR Diff-Serv MPLS cloud, the Edge-LSR looks MPLS Support of DiffServ over ATM/FR June 99
at the DSCP of the incoming packet and based on the FEC and PFC to
which the packet belongs, the Edge-LSR selects the LSP among the set
of LSPs established for each <FEC, PFC> pair. The ATM/FR Edge LSR
also sets the CLP/DE bit of the forwarded cells/frames according to
the mapping defined below between PHBs and ATM/FR selective discard
mechanism.
In the middle of the ATM or FR Diff-Serv MPLS cloud, the corresponding L-LSPs are then established independently via RSVP or
Intermediate-LSR only looks at the incoming VCI/DLCI of an incoming CR-LDP signaling;
ATM cell/FR Frame to determine the output interface, the outgoing - SAs supported by separate L-LSPs may be Traffic Engineered
VCI/DLCI and the output scheduling queue. The Intermediate-LSR also jointly. A path is selected for the aggregate of all the considered
looks at the CLP/DE bit of the incoming cell/Frame to enforce the SAs and the L-LSPs are then established independently along the same
appropriate drop priority. common path via RSVP or CR-LDP signaling;
2. PHB Mapping into PHB-group Forwarding Classes and Selective Discard 1.3 Explicit Congestion Notification
Mechanisms
2.1. Assured Forwarding PHB Group 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.
As described in [DIFF_AF], the Assured Forwarding (AF) PHB group 1.4 Label Forwarding for Diff-Serv over ATM/FR MPLS
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.
2.1.1. AF PHB-group Forwarding Class 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
As noted above, an AF class in the AF PHB group is the primary The Diff-Serv LSR SHALL apply the scheduling/dropping behavior
example of a PHB forwarding class. To meet the ordering constraints corresponding to the "Outgoing PHB" in compliance with the
for an AF class, packets of the same AF class that belong to the same corresponding Diff-Serv PHB specification.
FEC must be sent on the same LSP, a sufficient condition to meet the
ordering requirements defined for AF.
Mapping from AF PHBs to PFC is as follows: 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 ATM/FR,
Diff-Serv over MPLS over PPP using L-LSPs [MPLS_DIFF_PPP], Diff-Serv
over MPLS over PPP using E-LSPs [MPLS_DIFF_PPP]) by specifying -A-
and -C- for the considered method without having to specify the
complete label switching behavior (A+B+C) for every possible
incoming/outgoing combination.
PHB PFC This model is used below for specifying LSR Label Forwarding over
ATM/FR using L-LSPs for Diff-Serv support over MPLS.
AF1x -----> AFC1 1.5 Relationship with [MPLS_DIFF_PPP]
AF2x -----> AFC2
AF3x -----> AFC3
AF4x -----> AFC4
2.1.2. AF drop precedences mapping into ATM CLP The procedures described in this Internet Draft to establish and use
L-LSPs to achieve support of Diff-Serv over MPLS over ATM and FR,
are identical to the procedures described in [MPLS_DIFF_PPP] for L-
LSPs as one method to achieve support of Diff-Serv over MPLS over
PPP.
Within an AF PFC, the 3 drop precedences get mapped into the layer 2 Note that a single method (based on L-LSPs) is proposed in this
technology specific selective discard indicator. Mapping from AF PHBs Internet Draft for support of Diff-Serv over MPLS over ATM/FR while
to ATM Cell Loss Priority (CLP) is as follows:
PHB CLP bit Wu et. al 5
AFx1 -------> 0 MPLS Support of DiffServ over ATM/FR June 99
AFx2 -------> 1
AFx3 -------> 1
2.1.3. AF drop precedences mapping into FR DE [MPLS_DIFF_PPP] defines two methods for support of Diff-Serv over
MPLS over PPP. The other method described in [MPLS_DIFF_PPP] to
achieve support of Diff-Serv over MPLS over PPP relies on E-LSPs. E-
LSPs require that different packets of the same LSP be given
different scheduling treatment by the LSR which is generally
incompatible with existing ATM/FR hardware capabilities.
Mapping from AF PHBs to Frame Relay Discard Eligible (DE) is as 2. Label Forwarding for Diff-Serv over ATM/FR MPLS
follows:
PHB DE bit 2.2.1 Incoming PHB and FEC Determination On Ingress ATM/FR L-LSP
AFx1 -------> 0 When receiving an ATM/FR call/frame containing a labeled packet over
AFx2 -------> 1 an L-LSP of an MPLS ATM ingress interface:
AFx3 --------> 1
2.2. Expedited Forwarding PHB If the LSR is a Frame LSR (ie Egress Edge of the ATM/FR MPLS cloud),
the LSR:
- determines the FEC based on the incoming label
- determines the PHS from the incoming label among the set of
LSPs established for that FEC
- determines the incoming PHB from the PHS and the EXP field of
the top level label entry of the encapsulated label stack in
accordance with the PHS/EXP-->PHB mapping defined in section 2.3 of
[MPLS_DIFF_PPP]
[DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic If the LSR is an ATM/FR LSR (ie ATM/FR LSR in the middle of the
requiring forwarding with low loss, low latency, low jitter. ATM/FR MPLS cloud), the LSR:
- determines the FEC based on the incoming VCI/DLCI
- determines the PHS from the incoming VCI/DLCI among the set
of LSPs established for that FEC
- determines the "incoming" drop precedence to be applied on
the packet based on the CLP/DE field.
2.2.1. EF PHB-group Forwarding Class 2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning
[DIFF_EF] defines a single PHB. Thus, we propose that one PHB-group This stage of Diff-Serv label switching is optional and may be used
Forwarding Class be defined for the EF PHB. on a Frame 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").
Mapping from EF to PFC is as follows: This stage of Diff-Serv label switching is optional and may be used
on Frame LSRs with ATM/FR interfaces.
PHB PFC In the case of ATM/FR LSRs, it is expected that this optional stage
of Diff-Serv label switching, if supported, would be limited to
CLP/DE remarking (ie remarking the "incoming CLP/DE" to a different
value in the "outgoing CLP/DE")
EF ------> EFC Wu et. al 6
2.2.2. EF drop precedences mapping into ATM CLP MPLS Support of DiffServ over ATM/FR June 99
A single PHB is defined in the EF-group and the all EF packets should 2.2.3 Outgoing CLP/DE Field and Label Determination on Egress ATM/FR
receive the same (high) drop precedence (i.e., low drop L-LSP
probability). Thus the mapping from EF DSCP to ATM Cell Loss Priority
(CLP) is as follows:
PHB CLP bit If the LSR is a Frame LSR (ie Ingress Edge of the ATM/FR MPLS
cloud):
Once the outgoing PHB has been determined by the LSR as a function
of the incoming PHB and of the optional Local Policy and Traffic
Conditioning, the LSR:
- determines the "outgoing" PHS by performing the "outgoing"
PHB--> PHS/CLP-DE mapping defined below in section 3.
- determines the egress L-LSP label from the packet's FEC and
PHS
- encodes the EXP field of the top level label entry shim
header of the label stack (which is encapsulated in the ATM /FR LSP)
in accordance with the PHB --> PHS/EXP Mapping defined in section
2.4 of [MPLS_DIFF_PPP].
- determines the value to be written in the CLP/DE field of the
outgoing cell/frame by performing the outgoing PHB--> PHS/CLP-DE
mapping defined below in section 3.
- applies a scheduling/dropping behavior corresponding to the
"outgoing" PHB in compliance with the corresponding Diff-Serv PHB
specification.
EF -------> 0 If the LSR is an ATM/FR LSR (ie ATM/FR LSR in the middle of the
ATM/FR MPLS cloud):
Once the "outgoing" drop precedence (CLP/DE) has been determined by
the LSR as a function of the "incoming" drop precedence (CLP/DE) and
of the optional Local Policy and Traffic Conditioning, the LSR:
- determines the outgoing interface, the outgoing VCI/DLCI and
the output scheduling queue from the incoming VCI/DLCI
- applies a scheduling treatment corresponding to the
VCI/DLCI/label's PHS in compliance with the corresponding Diff-Serv
PHB specification
- writes the "outgoing" CLP/DE value into the outgoing
cell/frame
- applies the drop precedence corresponding to the "outgoing"
CLP/DE.
2.2.3. EF drop precedences mapping into FR DE 2.2.4 Simplified Forwarding on an ATM/FR LSR
A single PHB is defined in the EF-group and the all EF packets should When Local Policy and Traffic Conditioning are not to be performed
receive the same (high) drop precedence (i.e., low drop by the LSR, the Forwarding operation of an ATM/FR LSR is "reduced"
probability). Thus the mapping from EF DSCP to Frame Relay Discard to traditional ATM/FR switching since:
Eligible bit (DE) is as follows: - the LSR only looks at the incoming VCI/DLCI of an incoming
ATM cell/FR Frame to determine the output interface, the outgoing
VCI/DLCI and the output scheduling queue,
- the LSR only looks at the incoming CLP/DE field to determine
the drop precedence to be applied on the cell/frame,
- the MPLS Shim Header encapsulated in the ATM/FR connection
does not need to be looked at nor modified.
PHB DE bit Wu et. al 7
EF -------> 0 MPLS Support of DiffServ over ATM/FR June 99
3. LSP Establishment and Message Format 2.2.5 Number of Drop Precedence Levels
3.1. Signalling extension during LSP establishment Because the underlying standardized ATM and Frame Relay Selective
Discard mechanisms (CLP/DE) only support two levels of Drop
Precedence, the proposed solution is limited to two levels of Drop
Precedence per PHS in an ATM MPLS or FR MPLS cloud.
To support Diff-Serv in MPLS over ATM and Frame Relay, the PFC must However, the label stack encapsulated in the ATM LSP or FR LSP is
be signalled in the MPLS label request messages and MPLS label expected to include a shim header for the top label entry with a
meaningful EXP field, which can thus be used to encode all levels of
Drop Precedence within a PHS as defined in [MPLS_DIFF_PPP].
Consequently, even if only two levels of Drop Precedence are
achieved in the ATM/FR MPLS cloud, all Drop Precedence levels (eg
the three levels of an AF Class) can be supported in PPP MPLS clouds
surrounding an ATM/FR MPLS cloud.
3. PHB Mapping into PHS and Selective Discard Mechanism
3.1 PHB-->PHS/CLP Mapping
The mapping from PHBs into the L-LSP PHS and the Cell Loss Priority
(CLP) field of the ATM header is as follows:
PHB CLP PHS
DF -----> 0 DF
CSn -----> 0 CSn
AFn1 -----> 0 AFCn
AFn2 -----> 1 AFCn
AFn3 -----> 1 AFCn
EF -----> 0 EF
3.2 PHB-->PHS/DE Mapping
The mapping from PHBs into the L-LSP PHS and the Discard Eligible
(DE) field of the Frame Relay header is as follows:
PHB DE PHS
DF -----> 0 DF
CSn -----> 0 CSn
AFn1 -----> 0 AFCn
AFn2 -----> 1 AFCn
AFn3 -----> 1 AFCn
EF -----> 0 EF
3.3 Signaled PHS for Class Selector
As described in [DIFF_HEADER], "the Class Selector PHB Group
identifies 8 PHBs defined via the relative probability of timely
Wu et. al 8
MPLS Support of DiffServ over ATM/FR June 99
forwarding that they respectively offer to packets. For backwards
compatibility purposes, the Class Selector PHB Requirements are
specified as the minimum requirements compatible with most of the
deployed forwarding treatments selected by the IP Precedence field".
Quoting again from [DIFF_HEADER]:
"In addition, we give a set of codepoints that MUST map to PHBs
meeting these minimum requirements. The PHBs mapped to by these
codepoints MAY have a more detailed list of specifications in
addition to the required ones stated here".
Considering that:
- this document defines how ATM/FR LSRs support some
"specific/restrictive" PHB groups using their existing hardware
capabilities (including AF PHB Group and EF PHB).
- ATM/FR LSRs do not have some legacy PHBs complying with Class
Selector PHB requirements as defined in [DIFF_HEADER] paragraph
4.2.2.2 which are "less specific/restrictive" than the PHBs
addressed in this document.
- as specified in [DIFF_HEADER], Class Selector Codepoints can
be supported by "more specific PHBs" such as the other ones
addressed in this document
we propose that:
- a Behavior Aggregate corresponding to a Class Selector
Codepoint CSn may be mapped onto a CSn specific L-LSP with its CSn
PHS signaled at label set-up, OR
- a Behavior Aggregate corresponding to a Class Selector
Codepoint CSn may be mapped onto an L-LSP whose signaled PHS
corresponds to a "more specific/restrictive" PHB than CSn (eg AFn,
EF).
4. LSP Establishment and Message Format
4.1. Signaling extension during L-LSP establishment
To support Diff-Serv in MPLS over ATM and Frame Relay, the PHS must
be signaled in the MPLS label request messages and MPLS label
binding messages. The detailed format of the corresponding message binding messages. The detailed format of the corresponding message
extension is described below when the signalling protocol used is LDP extension is described below when the signaling protocol used is LDP
or RSVP. The MPLS control application on each ATM LSR or Frame Relay or RSVP. The MPLS control application on each ATM LSR or Frame Relay
LSR along the LSP will process the new PFC attribute and install the LSR along the L-LSP will process the new PHS attribute and install
corresponding scheduling behavior for that LSP and its associated the corresponding scheduling behavior for that L-LSP (eg. map the
output queue. LSP into an output queue associated with the PHS).
3.2. Merging 4.2. Merging
In an MPLS domain, two or more LSPs can be merged into one LSP at one Wu et. al 9
LSR. The proposed support of Diff-Serv in MPLS over ATM and Frame
Relay is compatible with LSP Merging under the following condition:
LSPs which carry Differentiated Service traffic can only be merged MPLS Support of DiffServ over ATM/FR June 99
into one LSP if they are associated with the same PFC.
Note that, when LSPs merge, the bandwidth that is available for the In an MPLS domain, two or more LSPs can be merged into one LSP at
PFC downstream of the merge point must be sufficient to carry the sum one LSR. The proposed support of Diff-Serv in MPLS over ATM and
of the merged traffic. This is particularly important in the case of Frame Relay is compatible with LSP Merging under the following
EF traffic. condition:
3.3. New RSVP Object Format L-LSPs can only be merged into one LSP if they are associated with
the same PHS.
This section defines a new object necessary for support of Diff-Serv Note that, when L-LSPs merge, the bandwidth that is available for
in MPLS over ATM and Frame Relay when LSPs are established via RSVP the PHS downstream of the merge point must be sufficient to carry
[MPLS_RSVP]. the sum of the merged traffic. This is particularly important in the
case of EF traffic.
The new RSVP DIFFSERV_PFC object is defined to carry the PHB-group 4.3 New RSVP Object Format
Forwarding Class (PFC) of the traffic to be transported on the
corresponding LSP.
As described in [MPLS_RSVP], bandwidth information may also be This section defines a new RSVP object class and a new RSVP object
signalled at LSP establishment time, for the purpose of Traffic within that class for support of Diff-Serv in MPLS over ATM/FR when
Engineering, using the SENDER_TSPEC Object (in the Path message) and L-LSPs are established via RSVP [MPLS_RSVP].
the FLOWSPEC Object (in the Resv message).
DIFFSERV_PFC object: Class = [TBD], C-Type = 1 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.
DIFFSERV_PHS object Class = [TBD], C-Type = 1
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 4 | Class-Num | C-Type | | Length = 4 | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PFC | | Reserved | PHS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PFC is an assigned number describing the Diff Serv PHB-group We propose that the 16-bit PHS be encoded as specified in section 2
Forwarding Class of the traffic that will be forwarded onto this of [PHBID]. In particular, we propose that the encoding for a PHS be
LSP. Possible PFC values are: the smallest numerical value of the encodings for the various PHBs
in the PHS. In turn, the encoding of a single PHB defined by
EFC 0x00 standards action is the recommended DSCP value for this PHB, left-
AFC1 0x01 justified in the 16 bit field, with bits 6 through 15 set to zero.
AFC2 0x02
AFC3 0x03
AFC4 0x04
Other values may be assigned in the event of new Diff-Serv PHBs For instance, the encoding of the AFC1 PHS is the encoding of the
being defined. AF11 PHB.
This object may be carried in a PATH message that contains the This object may be carried in a PATH message that contains the
LABEL_REQUEST object to indicate the PFC for which a label is LABEL_REQUEST object to indicate the PHS for which a label is
required. The object may also be carried in a RESV message that required. The object may also be carried in a RESV message that
contains a LABEL object indicating the PFC for which the label is to
Wu et. al 10
MPLS Support of DiffServ over ATM/FR June 99
contains a LABEL object indicating the PHS for which the label is to
be used. be used.
3.4. New LDP TLV 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).
This section defines a new LDP TLV necessary for support of Diff-Serv 4.4. New LDP TLV
in MPLS over ATM and Frame Relay when LSPs are established via LDP
[MPLS_LDP]. We define a new PFC TLV to signal the PHB forwarding This section defines a new LDP TLV necessary for support of Diff-
class for a label request or label binding as follows: Serv in MPLS over ATM/FR when L-LSPs are established via LDP
[MPLS_LDP] or CR-LDP [MPLS CR-LDP]. We define a new PHS TLV to
signal the PHS in a label request or label binding as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = PFC | Length = 1 | |U|F| Type = PHS | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PFC Value | | PHS |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the TLV is [TBD]. As an alternative to defining a new The Type of the TLV is [TBD].
TLV, it is possible that the currently specifified COS TLV could be
used for this purpose. Alternatively, the TLV specified here could be
carried as part of the value field of the COS TLV.
The PFC Value field is 1 octet with the following possible values: Encoding of the PHS field is the same as encoding of the PHS in
RSVP, as specified in 4.3.
EFC 0x00 We propose that the COS TLV which was specified in [LDP_03] (and
AFC1 0x01 removed in later version of the LDP specifications) be
AFC2 0x02 reincorporated into LDP and used to encode the PHS TLV as a nested
AFC3 0x03 TLV (ie encode the PHS TLV in the COS value of the COS TLV).
AFC4 0x04 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.
Other values may be assigned in the event of new Diff-Serv PHBs Alternatively, the PHS TLV could be included in the LDP messages as
being defined. an independent TLV (ie not nested in the COS TLV).
As described in [MPLS_CR_LDP], bandwidth information may also be As described in [MPLS_CR-LDP], bandwidth information may also be
signalled at LSP establishment time, for the purpose of Traffic signaled at LSP establishment time, for the purpose of Traffic
Engineering, using the Traffic Parameters TLV. Engineering, using the Traffic Parameters TLV.
4. Security Considerations 5. Security Considerations
This document does not introduce any new security issues beyond those This document does not introduce any new security issues beyond
inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms those inherent in Diff-Serv, MPLS and RSVP, and may use the same
proposed for those technologies. mechanisms proposed for those technologies.
5. Acknowledgments 6. Acknowledgments
Wu et. al 11
MPLS Support of DiffServ over ATM/FR June 99
This document has benefited from discussions with Dan Tappan, Yakov This document has benefited from discussions with Dan Tappan, Yakov
Rekhter, George Swallow, Eric Rosen, and Emmanuel Desmet. Rekhter, George Swallow, Eric Rosen, and Emmanuel Desmet.
6. References 7. References
[MPLS_ARCH] Rosen et al., "Multiprotocol Label Switching [MPLS_ARCH] Rosen et al., "Multiprotocol label switching
Architecture", work in progress, (draft-ietf-mpls-arch-04.txt), Architecture", work in progress, (draft-ietf-mpls-arch-04.txt),
March 1999. February 1999.
[DIFF_ARCH] Blake et al, "An Architecture for Differentiated [DIFF_ARCH] Blake et al., "An architecture for Differentiated
Services", work in progress, (draft-ietf-diffserv-arch-02.txt), Services", RFC-2475, December 1998.
October, 1998
[DIFF_AF] Heinanen et al, "Assured Forwarding PHB Group", work in [MPLS_DIFF_PPP] Le Faucheur et al, "MPLS Support of Differentiated
progress, (draft-ietf-diffserv-af-04.txt), January 1999 Services over PPP links", draft-lefaucheur-mpls-diff-ppp-00.txt,
June 99.
[DIFF_EF] Jacobson et al, "An Expedited Forwarding PHB", work in [DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597,
progress, (draft-ietf-diffserv-phb-ef-02.txt), March 1999 June 1999.
[MPLS_LDP] Andersson et al, "LDP Specification", work in progress, [DIFF_EF] Jacobson et al., "An Expedited Forwarding PHB", RFC-2598,
(draft-ietf-mpls-ldp-03.txt), January 1999 June 1999.
[MPLS_RSVP] Awduche et al, "Extensions to RSVP for LSP Tunnels", work [DIFF_HEADER] Nichols et al., "Definition of the Differentiated
in progress, (draft-ietf-mpls-rsvp-lsp-tunnel-01.txt), March 1999. Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474,
December 1998.
[MPLS_CR_LDP] Andersson et al, "Constraint-Based LSP Setup using [MPLS_ATM] Davie et al., "MPLS using LDP and ATM VC Switching",
LDP", work in progress, (draft-ietf-mpls-cr-ldp-00.txt), January draft-ietf-mpls-atm-02.txt, April 1999.
1999.
7. Author's Addresses [MPLS_FR] Conta et al., "Use of Label Switching on Frame Relay
Networks", draft-ietf-mpls-fr-03.txt, November 1999.
[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
[MPLS_RSVP] Awduche et al, "Extensions to RSVP for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999
[MPLS CR-LDP] 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
Wu et. al 12
MPLS Support of DiffServ over ATM/FR June 99
8. Author's Addresses
Liwen Wu Liwen Wu
Alcatel USA Alcatel USA
44983 Knoll Square 44983 Knoll Square
Ashburn, VA 20147 Ashburn, VA 20147
USA USA
E-mail: liwen.wu@adn.alcatel.com E-mail liwen.wu@adn.alcatel.com
Pierrick Cheval Pierrick Cheval
Alcatel USA Alcatel USA
44983 Knoll Square 44983 Knoll Square
Ashburn, VA 20147 Ashburn, VA 20147
USA USA
E-mail: pierrick.cheval@adn.alcatel.com E-mail pierrick.cheval@adn.alcatel.com
Pasi Vaananen Pasi Vaananen
Nokia Nokia
3 Burlington Woods Drive, Suite 250 3 Burlington Woods Drive, Suite 250
Burlington, MA 01803 Burlington, MA 01803
USA USA
E-mail: pasi.vaananen@ntc.nokia.com E-mail pasi.vaananen@ntc.nokia.com
Francois le Faucheur Francois le Faucheur
Cisco Systems, Inc. Cisco Systems, Inc.
16 av du Quebec, Les Lucioles - 291, rue Albert Caquot
Villebon-BP 706, 06560 Valbonne
91961 Les Ulis
France France
E-mail: flefauch@cisco.com E-mail flefauch@cisco.com
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
USA USA
E-mail: bsd@cisco.com E-mail bsd@cisco.com
Wu et. al 13
 End of changes. 

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