WDIFF

draft-ietf-mpls-diff-ext-00.txt --> draft-ietf-mpls-diff-ext-01.txt

Network Working Group Liwen Wu
Internet Draft
Alcatel, USA
Expiration Date: September 1999
Pierrick Cheval
Alcatel, USA
Pasi Vaananen
Nokia
Francois le Faucheur
Cisco Systems, Inc.
Bruce Davie
Cisco Systems, Inc.

March
Internet Draft
Expires: December, 1999
Document: draft-ietf-mpls-diff-ext-01.txt June, 1999

MPLS Support of Differentiated Services by ATM LSRs
and Frame Relay LSRs

draft-ietf-mpls-diff-ext-00.txt

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
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.

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 _work in progress." 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 updates to the current MPLS LDP and MPLS RSVP

Wu, et al. [Page 1]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

messages a solution for LSP establishment in order MPLS to support Differentiated
Services (Diff-Serv) over ATM LSRs and Frame Relay LSRs.

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 It proposes
corresponding updates to the same PFC current MPLS LDP and the same forwarding
equivalence class (FEC) should be transported over the same ATM
LSP or FR LSP;

- MPLS RSVP messages
for a given FEC, a separate ATM LSP or FR LSP should be
established for each PFC, so that multiple ATM or FR establishment.

In brief, we propose to use LSPs are
established in parallel for support of Diff-Serv;

- among where the set of PHBs transported over Behavior Aggregate's
scheduling treatment is inferred by the same ATM LSP or FR
LSP, LSR from the different PHBs' packet's label
value (VCI/DLCI) while the Behavior Aggregate's drop precedences be mapped into, and
enforced via, precedence is
indicated in the layer 2 specific ATM/FR selective discard mechanism
(CLP bit with ATM, DE bit with FR).

1. CLP/DE field.

1 Introduction

Wu, et. al 1

MPLS Support of DiffServ over ATM/FR June 99

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 signalling 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.

[MPLS_ATM] and [MPLS_FR] provides detailed description of how ATM
and FR Switches can be used as MPLS LSRs and how LSPs are
established and used by those ATM LSRS and FR LSRs.

In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the
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)
which corresponds to their Behavior Aggregate. Aggregate [DIFF_HEADER]. At each
transit node, the destination address is used to decide the next hop
while the DSCP is used to select the Per Hop Behavior (PHB) that
determines the queuing treatment and, in some cases, drop
probability for each packet.

This document proposes a solution for support of supporting the Behavior
Aggregates, whose corresponding PHBs are currently defined Diff Serv PHBs (in
[DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS ATM or MPLS Frame
Relay network, i.e., an MPLS network implemented using ATM of Frame
Relay switches.
Support of Diff Serv on other link types is for further study.

Wu, et al. [Page 2]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

1.1.

1.1 Ordering Constraints Constraints, "Scheduling Aggregate (SA)" and PHB Forwarding Classes "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
different packets of the microflow contain multiple different AF codepoints within
of the same AF class).

For the sake of generality, we define a set of PHBs Behavior Aggregates
which
impose share such an ordering constraint to be constitute a "PHB Forwarding Class" or
PFC. "Scheduling
Aggregate" (SA). The mechanisms described in this draft aim aim, in
particular, to preserve the correct ordering relationships for
packets that belong to a single
PFC.

1.2. 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

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
visible to ATM and Frame Relay MPLS LSRs since it is encapsulated
"inside" the ATM or FR LSP "connection";

- MPLS Diff-Serv assumes a similar architecture to non-MPLS
Diff-Serv whereby the appropriate forwarding/prioritisation is to be
performed at every hop (ie every MPLS LSR, including ATM LSR and FR
LSR) in accordance to the packet's Behavior Aggregate.

- ATM and Frame Relay switching hardware is generally capable
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
connection;

- ATM and Frame Relay switching hardware is generally capable
of enforcing different drop priorities within a single connection
via standardized technology-specific selective drop mechanisms (Cell
Loss Priority - CLP- for ATM and Discard Eligible - DE- for Frame
Relay);

we propose that

- all packets belonging to a single SA and the same Forwarding
Equivalence Class (FEC) be sent down a single LSP;

- one LSP Establishment be established per <FEC, SA> pair (rather than simply
one LSP per FEC as in a network that does not support Diff-Serv).
Such an LSP is referred to as a "Label-inferred-PHS" LSP or "L-LSP";

- packets from multiple BAs of a given SA be granted a
different drop precedence through mapping into the layer 2 specific
selective discard indicator (CLP bit with ATM, DE bit with FR).

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 the required
extensions to LDP and RSVP to allow establishment of one L-LSP per
<FEC,SA> pair over ATM MPLS and FR MPLS.

For the purpose of meeting some specific Traffic Engineering goals,
we note that:
- SAs supported by separate L-LSPs may be Traffic Engineered
separately. A path is selected independently for each SA (eg by
Constraint Based Routing or by explicit configuration) and the

Wu et. al 4

MPLS Support of DiffServ over ATM/FR June 99

corresponding L-LSPs are then established independently via RSVP or
CR-LDP signaling;
- SAs supported by separate L-LSPs may 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.3 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.4 Label Forwarding for Diff-Serv over ATM/FR MPLS

Recognizing that:

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

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 ATM/FR,
Diff-Serv over MPLS over PPP using L-LSPs [MPLS_DIFF_PPP], Diff-Serv
over MPLS over PPP using E-LSPs [MPLS_DIFF_PPP]) by specifying -A-
and -C- for the considered method without having to specify the
complete label switching behavior (A+B+C) for every possible
incoming/outgoing combination.

This model is used below for specifying LSR Label Forwarding over
ATM/FR using L-LSPs for Diff-Serv support over MPLS.

1.5 Relationship with [MPLS_DIFF_PPP]

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.

Note that a single method (based on L-LSPs) is proposed in this
Internet Draft for support of Diff-Serv over MPLS over ATM/FR while

Wu et. al 5

MPLS Support of DiffServ over ATM/FR June 99

[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.

2. Label Forwarding for Diff-Serv over ATM/FR MPLS Header

2.2.1 Incoming PHB and FEC Determination On Ingress ATM/FR L-LSP

When receiving an ATM/FR call/frame containing a labeled packet over
an L-LSP of an MPLS switched packets is generally not
visible to ATM and ingress interface:

If the LSR is a Frame Relay LSR (ie Egress Edge of the ATM/FR MPLS LSRs since it is encapsulated
"inside" cloud),
the ATM or FR LSP "connection"; LSR:
- ATM and Frame Relay switching hardware is generally capable of
selecting different scheduling queues for cells/frames belonging
to different connections but is generally not capable determines the FEC based on the incoming label
- determines the PHS from the incoming label among the set of selecting
different scheduling queues
LSPs established for cells/frames belonging to the same
ATM/Frame Relay connection; that FEC
- ATM determines the incoming PHB from the PHS and Frame Relay switching hardware must be capable the EXP field of
maintaining
the order top level label entry of all packets or cells sent on a single
connection;

- ATM and Frame Relay switching hardware the encapsulated label stack in
accordance with the PHS/EXP-->PHB mapping defined in section 2.3 of
[MPLS_DIFF_PPP]

If the LSR is generally capable an ATM/FR LSR (ie ATM/FR LSR in the middle of
enforcing different drop priorities within a single connection via
standardized technology-specific selective drop mechanisms (Cell
Loss Priority the
ATM/FR MPLS cloud), the LSR:
- CLP- for ATM and Discard Eligible determines the FEC based on the incoming VCI/DLCI
- DE- determines the PHS from the incoming VCI/DLCI among the set
of LSPs established for Frame
Relay);

we propose that: that FEC
- all packets belonging determines the "incoming" drop precedence to a single PFC and be applied on
the same forwarding
equivalence class (FEC) should packet based on the CLP/DE field.

2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning

This stage of Diff-Serv label switching is optional and may be sent down used
on a Frame LSR to perform Behavior Aggregate demotion or promotion
inside an MPLS Diff-Serv domain. For the purpose of specifying a single LSP;

- one LSP should be established per <PFC, FEC> pair (rather than
Diff-Serv over MPLS method, we simply one LSP per FEC as in a network note that does not support
Diff-Serv);

- multiple PHBs belonging to the same PFC PHB to be
actually enforced by an LSR (referred to as "outgoing PHB") may be granted
different
drop precedences through mapping into to the layer 2 specific

Wu, et al. [Page 3]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

selective discard indicator (CLP bit with ATM, DE bit PHB which had been associated with FR).

MPLS specifies how LSPs can be established via multiple signalling
protocols. Those include the Label Distribution Protocol (LDP), RSVP,
BGP and PIM. This Internet-Draft proposes below packet at
the required
extensions to LDP and RSVP previous LSR (referred to allow establishment as "incoming PHB").

This stage of one LSP per
<PFC, FEC> pair over ATM Diff-Serv label switching is optional and FR MPLS. may be used
on Frame LSRs with ATM/FR interfaces.

In the event that case of ATM/FR LSRs, it is desired to signal bandwidth or other resource
requirements for an LSP expected that will carry this optional stage
of Diff-Serv traffic (e.g. for
traffic engineering purposes), label switching, if supported, would be limited to
CLP/DE remarking (ie remarking the mechanisms available "incoming CLP/DE" to a different
value in the LSP
setup protocol (RSVP or LDP) may be used.

1.3. Label Forwarding for Diff-Serv "outgoing CLP/DE")

Wu et. al 6

MPLS Support of DiffServ over ATM/FR MPLS

At June 99

2.2.3 Outgoing CLP/DE Field and Label Determination on Egress ATM/FR
L-LSP

If the edge LSR is a Frame LSR (ie Ingress Edge of the ATM or FR Diff-Serv ATM/FR MPLS cloud,
cloud):
Once the Edge-LSR looks
at outgoing PHB has been determined by the DSCP LSR as a function
of the incoming packet PHB and based on 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 PFC to
which
PHS
- encodes the packet belongs, EXP field of the top level label entry shim
header of the Edge-LSR selects label stack (which is encapsulated in the LSP among ATM /FR LSP)
in accordance with the set PHB --> PHS/EXP Mapping defined in section
2.4 of LSPs established for each <FEC, PFC> pair. The ATM/FR Edge LSR
also sets [MPLS_DIFF_PPP].
- determines the value to be written in the CLP/DE bit field of the forwarded cells/frames according to
outgoing cell/frame by performing the outgoing PHB--> PHS/CLP-DE
mapping defined below between PHBs and in section 3.
- applies a scheduling/dropping behavior corresponding to the
"outgoing" PHB in compliance with the corresponding Diff-Serv PHB
specification.

If the LSR is an ATM/FR selective discard
mechanism.

In LSR (ie ATM/FR LSR in the middle of the ATM or FR Diff-Serv
ATM/FR MPLS cloud, cloud):
Once the
Intermediate-LSR only looks at "outgoing" drop precedence (CLP/DE) has been determined by
the incoming VCI/DLCI LSR as a function of an incoming
ATM cell/FR Frame to determine the output "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. The Intermediate-LSR also
looks at the CLP/DE bit of queue from the incoming cell/Frame VCI/DLCI
- applies a scheduling treatment corresponding to enforce the
appropriate drop priority.

2.
VCI/DLCI/label's PHS in compliance with the corresponding Diff-Serv
PHB Mapping specification
- writes the "outgoing" CLP/DE value into PHB-group the outgoing
cell/frame
- applies the drop precedence corresponding to the "outgoing"
CLP/DE.

2.2.4 Simplified Forwarding Classes on an ATM/FR LSR

When Local Policy and Selective Discard
Mechanisms

2.1. Assured Forwarding PHB Group

As described in [DIFF_AF], Traffic Conditioning are not to be performed
by the LSR, the Assured Forwarding (AF) PHB group
provides forwarding operation of IP packets in N independent AF classes.
Within each AF class, an IP packet ATM/FR LSR is assigned one of M different
levels of drop precedence. An IP packet that belongs "reduced"
to an AF class i
and has drop precedence j is marked with traditional ATM/FR switching since:
- the AF codepoint AFij, where
1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4) with three
levels LSR only looks at the incoming VCI/DLCI of drop precedence in each class (M=3) are defined for general
use.

Wu, et al. [Page 4]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

2.1.1. AF PHB-group Forwarding Class

As noted above, an AF class in incoming
ATM cell/FR Frame to determine the AF PHB group is output interface, the primary
example of a PHB forwarding class. To meet outgoing
VCI/DLCI and the ordering constraints
for an AF class, packets of output scheduling queue,
- the same AF class that belong LSR only looks at the incoming CLP/DE field to determine
the same
FEC must drop precedence to be sent applied on the same LSP, a sufficient condition to meet the
ordering requirements defined for AF.

Mapping from AF PHBs to PFC is as follows:

PHB PFC

AF1x -----> AFC1
AF2x -----> AFC2
AF3x -----> AFC3
AF4x -----> AFC4

2.1.2. AF drop precedences mapping into ATM CLP

Within an AF PFC, cell/frame,
- the 3 drop precedences get mapped into MPLS Shim Header encapsulated in the layer 2
technology specific selective discard indicator. Mapping from AF PHBs ATM/FR connection
does not need to be looked at nor modified.

Wu et. al 7

MPLS Support of DiffServ over ATM/FR June 99

2.2.5 Number of Drop Precedence Levels

Because the underlying standardized ATM Cell Loss Priority (CLP) is as follows:

PHB CLP bit

AFx1 -------> 0
AFx2 -------> 1
AFx3 -------> 1

2.1.3. AF drop precedences mapping into FR DE

Mapping from AF PHBs to and Frame Relay Selective
Discard Eligible (DE) mechanisms (CLP/DE) only support two levels of Drop
Precedence, the proposed solution is as
follows:

PHB DE bit

AFx1 -------> 0
AFx2 -------> 1
AFx3 --------> 1

Wu, et al. [Page 5]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

2.2. Expedited Forwarding PHB

[DIFF_EF] defines limited to two levels of Drop
Precedence per PHS in an ATM MPLS or FR MPLS cloud.

However, the Expedited Forwarding (EF) PHB label stack encapsulated in the ATM LSP or FR LSP is
expected to include a shim header for traffic
requiring forwarding the top label entry with low loss, low latency, low jitter.

2.2.1. EF PHB-group Forwarding Class

[DIFF_EF] defines a single PHB. Thus, we propose that one PHB-group
Forwarding Class
meaningful EXP field, which can thus be defined for the EF PHB.

Mapping from EF used to PFC is as follows:

PHB PFC

EF ------> EFC

2.2.2. EF drop precedences mapping into ATM CLP

A single PHB is 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 EF-group and the ATM/FR MPLS cloud, all EF packets should
receive the same (high) drop precedence (i.e., low drop
probability). Thus 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 EF DSCP to ATM PHBs into the L-LSP PHS and the Cell Loss Priority
(CLP) field of the ATM header is as follows:

PHB CLP bit PHS

DF -----> 0 DF
CSn -----> 0 CSn
AFn1 -----> 0 AFCn
AFn2 -----> 1 AFCn
AFn3 -----> 1 AFCn
EF -------> -----> 0

2.2.3. EF drop precedences

3.2 PHB-->PHS/DE Mapping

The mapping from PHBs into FR the L-LSP PHS and the Discard Eligible
(DE) field of the Frame Relay header is as follows:

PHB DE

A single 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 is Group
identifies 8 PHBs defined in via the EF-group and 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 all EF packets should
receive Class Selector PHB Requirements are
specified as the same (high) drop precedence (i.e., low drop
probability). Thus minimum requirements compatible with most of the mapping
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 DSCP 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 Frame Relay Discard
Eligible bit (DE) is as follows: a Class Selector
Codepoint CSn may be mapped onto an L-LSP whose signaled PHS
corresponds to a "more specific/restrictive" PHB DE bit

EF -------> 0

Wu, et al. [Page 6]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

3. than CSn (eg AFn,
EF).

4. LSP Establishment and Message Format

3.1. Signalling

4.1. Signaling extension during LSP L-LSP establishment

To support Diff-Serv in MPLS over ATM and Frame Relay, the PFC PHS must
be signalled signaled in the MPLS label request messages and MPLS label
binding messages. The detailed format of the corresponding message
extension is described below when the signalling signaling protocol used is LDP
or RSVP. The MPLS control application on each ATM LSR or Frame Relay
LSR along the LSP L-LSP will process the new PFC PHS attribute and install
the corresponding scheduling behavior for that L-LSP (eg. map the
LSP and its associated into an output queue.

3.2. queue associated with the PHS).

4.2. Merging

Wu et. al 9

MPLS Support of DiffServ over ATM/FR June 99

In an MPLS domain, two or more LSPs can be merged into one LSP at
one LSR. The proposed support of Diff-Serv in MPLS over ATM and
Frame Relay is compatible with LSP Merging under the following
condition:

LSPs which carry Differentiated Service traffic

L-LSPs can only be merged into one LSP if they are associated with
the same PFC. PHS.

Note that, when LSPs L-LSPs merge, the bandwidth that is available for
the
PFC 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.

3.3.

4.3 New RSVP Object Format

This section defines a new RSVP object necessary class and a new RSVP object
within that class for support of Diff-Serv in MPLS over ATM and Frame Relay ATM/FR when LSPs
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_PFC DIFFSERV_PHS object is defined within the COS Class to
carry the PHB-group
Forwarding Class (PFC) PHS of the traffic to be transported on the corresponding
LSP.

As described in [MPLS_RSVP], bandwidth information may also be
signalled 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).

Wu, et al. [Page 7]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

DIFFSERV_PFC object: Its C-Type is 1.

DIFFSERV_PHS object Class = [TBD], C-Type = 1

The PFC is an assigned number describing

We propose that the Diff Serv PHB-group
Forwarding Class 16-bit PHS be encoded as specified in section 2
of the traffic [PHBID]. In particular, we propose that will the encoding for a PHS be forwarded onto
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
LSP. Possible PFC values are:

EFC 0x00
AFC1 0x01
AFC2 0x02
AFC3 0x03
AFC4 0x04

Other values may be assigned PHB, left-
justified in the event 16 bit field, with bits 6 through 15 set to zero.

For instance, the encoding of new Diff-Serv PHBs
being defined. 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 PFC PHS for which a label is
required. The object may also be carried in a RESV message that

Wu et. al 10

MPLS Support of DiffServ over ATM/FR June 99

contains a LABEL object indicating the PFC PHS for which the label is to
be used.

3.4.

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).

4.4. New LDP TLV

This section defines a new LDP TLV necessary for support of Diff-Serv Diff-
Serv in MPLS over ATM and Frame Relay ATM/FR when LSPs L-LSPs are established via LDP
[MPLS_LDP].
[MPLS_LDP] or CR-LDP [MPLS CR-LDP]. We define a new PFC PHS TLV to
signal the PHB forwarding
class for PHS in a label request or label binding as follows:

Wu, et al. [Page 8]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

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 = PFC PHS | Length = 1 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PFC Value PHS |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Type of the TLV is [TBD]. As an alternative to defining a new
TLV, it

Encoding of the PHS field is possible the same as encoding of the PHS in
RSVP, as specified in 4.3.

We propose that the currently specifified COS TLV could which was specified in [LDP_03] (and
removed in later version of the LDP specifications) be
reincorporated into LDP and used for this purpose. Alternatively, to encode the PHS TLV specified here could be
carried as part of a nested
TLV (ie encode the PHS TLV in the COS value field of the COS TLV.

The PFC Value field is 1 octet with TLV).
Encoding the following possible values:

EFC 0x00
AFC1 0x01
AFC2 0x02
AFC3 0x03
AFC4 0x04

Other values may PHS TLV as a nested TLV of the COS TLV is proposed for
flexibility so that if additional TLVs need to be assigned defined in the event
future for support of new Diff-Serv PHBs
being defined. 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], [MPLS_CR-LDP], bandwidth information may also be
signalled
signaled at LSP establishment time, for the purpose of Traffic
Engineering, using the Traffic Parameters TLV.

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

Wu et. al 11

MPLS Support of DiffServ over ATM/FR June 99

This document has benefited from discussions with Dan Tappan, Yakov
Rekhter, George Swallow, Eric Rosen, and Emmanuel Desmet.

Wu, et al. [Page 9]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

7. References

[MPLS_ARCH] Rosen et al., "Multiprotocol Label Switching label switching
Architecture", work in progress, (draft-ietf-mpls-arch-04.txt),
March
February 1999.

[DIFF_ARCH] Blake et al, al., "An Architecture architecture for Differentiated
Services", work in progress, (draft-ietf-diffserv-arch-02.txt),
October, 1998 RFC-2475, December 1998.

[MPLS_DIFF_PPP] Le Faucheur et al, "MPLS Support of Differentiated
Services over PPP links", draft-lefaucheur-mpls-diff-ppp-00.txt,
June 99.

[DIFF_AF] Heinanen et al, al., "Assured Forwarding PHB Group", work in
progress, (draft-ietf-diffserv-af-04.txt), January 1999 RFC-2597,
June 1999.

[DIFF_EF] Jacobson et al, al., "An Expedited Forwarding PHB", work RFC-2598,
June 1999.

[DIFF_HEADER] Nichols et al., "Definition of the Differentiated
Services Field (DS Field) in
progress, (draft-ietf-diffserv-phb-ef-02.txt), March 1999

[MPLS_LDP] the IPv4 and IPv6 Headers", RFC-2474,
December 1998.

[MPLS_ATM] Davie et al., "MPLS using LDP and ATM VC Switching",
draft-ietf-mpls-atm-02.txt, April 1999.

[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, al., "LDP Specification", work in progress,
(draft-ietf-mpls-ldp-03.txt), draft-ietf-mpls-ldp-
03.txt, January 1999 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", work
in progress, (draft-ietf-mpls-rsvp-lsp-tunnel-01.txt),
draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999.

[MPLS_CR_LDP] Andersson 1999

[MPLS CR-LDP] Jamoussi et al, al., "Constraint-Based LSP Setup using
LDP", work in progress, (draft-ietf-mpls-cr-ldp-00.txt), January
1999.

7. 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
Alcatel USA
44983 Knoll Square
Ashburn, VA 20147
USA

E-mail:

E-mail liwen.wu@adn.alcatel.com

Pierrick Cheval
Alcatel USA
44983 Knoll Square
Ashburn, VA 20147
USA

E-mail:

E-mail pierrick.cheval@adn.alcatel.com

Wu, et al. [Page 10]

Internet Draft draft-ietf-mpls-diff-ext-00.txt March 1999

Pasi Vaananen
Nokia
3 Burlington Woods Drive, Suite 250
Burlington, MA 01803
USA

E-mail:

E-mail pasi.vaananen@ntc.nokia.com

Francois le Faucheur
Cisco Systems, Inc.
16 av du Quebec,
Villebon-BP 706,
91961
Les Ulis Lucioles - 291, rue Albert Caquot
06560 Valbonne
France

E-mail:

E-mail flefauch@cisco.com

Bruce Davie
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
USA

E-mail:

E-mail bsd@cisco.com

Wu, et al. [Page 11]

Wu et. al 13

----