Network Working Group Liwen Wu
Internet Draft Alcatel, USA
Expiration Date: August 1999
Pierrick Cheval
Alcatel, USA
Pasi Vaananen
Nokia
Francois le Faucheur
Cisco Systems, Inc.
Bruce Davie
Cisco Systems, Inc.
February 1999
MPLS Support of Differentiated Services by ATM LSRs and Frame Relay LSRs
draft-wu-mpls-diff-ext-01.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 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
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-wu-mpls-diff-ext-01.txt February 1999
messages for LSP establishment in order 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 to the same PFC and the same forwarding
equivalence class (FEC) should be transported over the same ATM
LSP or FR LSP;
- for a given FEC, a separate ATM LSP or FR LSP should be
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
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
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.
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. 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 the currently
defined Diff Serv PHBs 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-wu-mpls-diff-ext-01.txt February 1999
1.1. Ordering Constraints and PHB Forwarding Classes
[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
of the microflow contain multiple AF codepoints within the same AF
class). For the sake of generality, we define a set of PHBs which
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
Recognizing that:
- 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";
- 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 of selecting
different scheduling queues for cells/frames belonging to the same
ATM/Frame Relay connection;
- ATM and Frame Relay switching hardware must be 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 PFC and the same forwarding
equivalence class (FEC) should be sent down a single LSP;
- one LSP should be established per <PFC, FEC> pair (rather than
simply one LSP per FEC as in a network that does not support
Diff-Serv);
- multiple PHBs belonging to the same PFC be granted different
drop precedences through mapping into the layer 2 specific
Wu, et al. [Page 3]
Internet Draft draft-wu-mpls-diff-ext-01.txt February 1999
selective discard indicator (CLP bit with ATM, DE bit 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 the required
extensions to LDP and RSVP to allow establishment of one LSP per
<PFC, FEC> pair over ATM and FR MPLS.
In the event that it is desired to signal bandwidth or other resource
requirements for an LSP that will carry Diff-Serv traffic (e.g. for
traffic engineering purposes), the mechanisms available in the LSP
setup protocol (RSVP or LDP) may be used.
1.3. Label Forwarding for Diff-Serv over ATM/FR MPLS
At the edge of the ATM or FR Diff-Serv MPLS cloud, the Edge-LSR looks
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
Intermediate-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 Intermediate-LSR also
looks at the CLP/DE bit of the incoming cell/Frame to enforce the
appropriate drop priority.
2. PHB Mapping into PHB-group Forwarding Classes and Selective Discard
Mechanisms
2.1. Assured Forwarding PHB Group
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.
Wu, et al. [Page 4]
Internet Draft draft-wu-mpls-diff-ext-01.txt February 1999
2.1.1. AF PHB-group Forwarding Class
As noted above, an AF class in the AF PHB group is the primary
example of a PHB forwarding class. To meet the ordering constraints
for an AF class, packets of the same AF class that belong to the same
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:
PHB PFC
AF1x -----> AFC1
AF2x -----> AFC2
AF3x -----> AFC3
AF4x -----> AFC4
2.1.2. AF drop precedences mapping into ATM CLP
Within an AF PFC, the 3 drop precedences get mapped into the layer 2
technology specific selective discard indicator. Mapping from AF PHBs
to 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 Frame Relay Discard Eligible (DE) is as
follows:
PHB DE bit
AFx1 -------> 0
AFx2 -------> 1
AFx3 --------> 1
Wu, et al. [Page 5]
Internet Draft draft-wu-mpls-diff-ext-01.txt February 1999
2.2. Expedited Forwarding PHB
[DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic
requiring forwarding 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 be defined for the EF PHB.
Mapping from EF to PFC is as follows:
PHB PFC
EF ------> EFC
2.2.2. EF drop precedences mapping into ATM CLP
A single PHB is defined in the EF-group and the all EF packets should
receive the same (high) drop precedence (i.e., low drop
probability). Thus the mapping from EF DSCP to ATM Cell Loss Priority
(CLP) is as follows:
PHB CLP bit
EF -------> 0
2.2.3. EF drop precedences mapping into FR DE
A single PHB is defined in the EF-group and the all EF packets should
receive the same (high) drop precedence (i.e., low drop
probability). Thus the mapping from EF DSCP to Frame Relay Discard
Eligible bit (DE) is as follows:
PHB DE bit
EF -------> 0
Wu, et al. [Page 6]
Internet Draft draft-wu-mpls-diff-ext-01.txt February 1999
3. LSP Establishment and Message Format
3.1. Signalling extension during LSP establishment
To support Diff-Serv in MPLS over ATM and Frame Relay, the PFC must
be signalled 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 protocol used is LDP
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
corresponding scheduling behavior for that LSP and its associated
output queue.
3.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 ATM and Frame
Relay is compatible with LSP Merging under the following condition:
LSPs which carry Differentiated Service traffic can only be merged
into one LSP if they are associated with the same PFC.
Note that, when LSPs merge, the bandwidth that is available for the
PFC 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. New RSVP Object Format
This section defines a new object necessary for support of Diff-Serv
in MPLS over ATM and Frame Relay when LSPs are established via RSVP
[MPLS_RSVP].
The new RSVP DIFFSERV_PFC object is defined to carry the PHB-group
Forwarding Class (PFC) 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-wu-mpls-diff-ext-01.txt February 1999
DIFFSERV_PFC 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 | PFC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PFC is an assigned number describing the Diff Serv PHB-group
Forwarding Class of the traffic that will be forwarded onto this
LSP. Possible PFC values are:
EFC 0x00
AFC1 0x01
AFC2 0x02
AFC3 0x03
AFC4 0x04
Other values may be assigned in the event of new Diff-Serv PHBs
being defined.
This object may be carried in a PATH message that contains the
LABEL_REQUEST object to indicate the PFC for which a label is
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
be used.
3.4. New LDP TLV
This section defines a new LDP TLV necessary for support of Diff-Serv
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
class for a label request or label binding as follows:
Wu, et al. [Page 8]
Internet Draft draft-wu-mpls-diff-ext-01.txt February 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 | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PFC Value |
+-+-+-+-+-+-+-+-+
The Type of the TLV is [TBD]. As an alternative to defining a new
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:
EFC 0x00
AFC1 0x01
AFC2 0x02
AFC3 0x03
AFC4 0x04
Other values may be assigned in the event of new Diff-Serv PHBs
being defined.
As described in [MPLS_CR_LDP], bandwidth information may also be
signalled at LSP establishment time, for the purpose of Traffic
Engineering, using the Traffic Parameters TLV.
4. 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.
5. Acknowledgments
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-wu-mpls-diff-ext-01.txt February 1999
6. 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", work in progress, (draft-ietf-diffserv-arch-02.txt),
October, 1998
[DIFF_AF] Heinanen et al, "Assured Forwarding PHB Group", work in
progress, (draft-ietf-diffserv-af-04.txt), January 1999
[DIFF_EF] Jacobson et al, "An Expedited Forwarding PHB", work in
progress, (draft-ietf-diffserv-phb-ef-02.txt), February 1999
[MPLS_LDP] Andersson et al, "LDP Specification", work in progress,
(draft-ietf-mpls-ldp-03.txt), January 1999
[MPLS_RSVP] Awduche et al, "Extensions to RSVP for LSP Tunnels", work
in progress, (draft-ietf-mpls-rsvp-lsp-tunnel-01.txt), February 1999.
[MPLS_CR_LDP] Andersson et al, "Constraint-Based LSP Setup using
LDP", work in progress, (draft-ietf-mpls-cr-ldp-00.txt), January
1999.
7. Author's Addresses
Liwen Wu
Alcatel USA
44983 Knoll Square
Ashburn, VA 20147
USA
E-mail: liwen.wu@adn.alcatel.com
Pierrick Cheval
Alcatel USA
44983 Knoll Square
Ashburn, VA 20147
USA
E-mail: pierrick.cheval@adn.alcatel.com
Wu, et al. [Page 10]
Internet Draft draft-wu-mpls-diff-ext-01.txt February 1999
Pasi Vaananen
Nokia
3 Burlington Woods Drive, Suite 250
Burlington, MA 01803
USA
E-mail: pasi.vaananen@ntc.nokia.com
Francois le Faucheur
Cisco Systems, Inc.
16 av du Quebec,
Villebon-BP 706,
91961 Les Ulis
France
E-mail: flefauch@cisco.com
Bruce Davie
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
USA
E-mail: bsd@cisco.com
Wu, et al. [Page 11]