[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

MPLS Working Group                         Liwen Wu, Pierrick Cheval
Internet Draft                                           Alcatel USA
Expiration Date: May 1999
                                                       Pasi Vaananen

                                                     November   1998

               MPLS Extensions for Differential Services

0. Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working docu-
   ments 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".

   To learn the current status of any Internet-Draft, please check the
   "1id- abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

1. Abstract

   This document provides new message formats and the updates of the
   current MPLS LDP messages and MPLS RSVP messages to support the
   differentiated services (DiffServ).

   We first discuss the extension to the current MPLS architecture
   [MPLSARCH] to support differentiated services [DIFFARCH] over MPLS

   For a Behavior Aggregate (BA), we define  "Behavior Aggregate
   Selector (BAS)" which related to the forwarding queue behavior, and
   define "Behavior Modifier (BM)" which related to the dropping
   behavior. Each DiffServ Per Hop Behavior (PHB) can be represented
   using either BAS only or combination of BAS and BM.

   In brief, we propose that all LSRs on the path of a single MPLS LSP
   apply the same Behavior Aggregate Selector (BAS) for the traffic

Wu, Cheval, Vaananen                                            [Page 1]

Internet Draft       draft-wu-mpls-diff-ext-00.txt         November 1998

   carried in this LSP, on the basis of behavior class selector that is
   specified as part of LSP set-up process. Behavior Modifier (BM),
   carried as part of label encapsulation header, is used to further
   modify the  behavior selected by BAS. Behavior modifiers are carried
   as part of MPLS shim header, ATM cell header or Frame Relay header,
   and can be used to indicate, e.g. drop priority or congestion
   indication inside a single BAS.

   This proposal is not intended to prevent any potential future
   evolution that would accomodate multiple, different Behavior
   Aggregate Selectors (BAS) within a single LSP.

2. Introduction

   In an MPLS domain, when a stream of data traverses a same path, an
   Label Switch Path (LSP) can be established through MPLS signalling
   protocols. At the ingress Label Switch Router (LSR), the packet is
   assigned with a label and is transmitted downstream. At each LSR
   along the LSP, the label is used to forward the packet to the next

   In a DiffServ domain, when a stream of data have a same forwarding
   behavior, packets belong to that stream are assigned with the same
   behavioral aggregate. At the ingress node the packet is classified
   and assigned with a Differentiated Services Code Point (DSCP). which
   represents a class of service. At each transit node, the destination
   address is used to decide the next hop. The DSCP is used to select
   the Per Hop Behaviour (PHB) that determines the queuing treatment
   and, in some cases, drop propability inside the queue for each

   To combine the MPLS and Diffserv together, when a stream of data
   traverse the same path and is forwarded using same PHB, an LSP can be
   established, leading to selection of same queuing treatment in LSRs
   along the path.

   Each PHB is then mapped to the established BAS, or the combination of
   BAS (determined by label) and BM field, when drop priority or other
   treatment that modifies the forwarding treatment inside the queue is

   The method and consequences of building an LSP which can support
   multiple BAS are for further study (FFS).

2.1 The Next Hop Label Forwarding Entry (NHLFE)

   As described in [MPLSARCH] document, The "Next Hop Label Forwarding
   Entry" (NHLFE) is used when forwarding a labeled packet. It contains

Wu, Cheval, Vaananen                                            [Page 2]

Internet Draft       draft-wu-mpls-diff-ext-00.txt         November 1998

   the following information:

     1. the packet's next hop

     2. the data link encapsulation to use when transmitting the packet

     3. the way to encode the label stack when transmitting the packet

     4. the operation to perform on the packet's label stack

   To combine MPLS and Diffserv, the NHLFE will be extended to include:

     5. the packet's behavior aggregate selector, which determines the
     queuing treatment of the packet carried on this LSP.

2.2 Setting Up an LSP Which Support Differentiated Services

   As described in [MPLSARCH], an LSP can be established through
   "downstream-on-demand" or "downstream" label distribution.

   "Downstream-on-demand" means an upstream LSR explicitly requests from
   its next hop for a particular FEC, a label binding for that FEC,
   whereas "downstream" means an downstream LSR to distribute bindings
   to upstream LSRs that have not explicitly requested them.

   To support DiffServ, the Diffserv related behavioral aggregate
   attributes will be added to the MPLS label request messages and MPLS
   label binding messages. The detailed format of these messages will be
   explained later. The MPLS control application on each LSR along the
   LSP will process the new attributes and install the DiffServ
   forwarding behavior for that LSP.

2.3 Issues Related to Label-Merge

   In an MPLS domain, two or more LSPs can be merged into one LSP at one
   LSR.  Here LSPs which carry certain Differentiated Service traffic
   can only be merged into one LSP, if they carry the traffic which
   belongs to the same behavioral aggregate.

   As of today, in differentiated service domain, there are 2 kinds of
   PHBs defined:

   -- EF PHB [DIFF_EF]

     The EF traffic is forwarded with low loss, low latency, low jitter.

Wu, Cheval, Vaananen                                            [Page 3]

Internet Draft       draft-wu-mpls-diff-ext-00.txt         November 1998

     The aggregate arrival rate that is associated with same egress
     interface in the node  is always less than that interfaces
     configured minimum departure rate for EF PHB.

     Since EF traffic requires absolute bandwidth, when 2 EF traffic
     LSPs are merged using downstream-on-demand ordered mode, it is
     recommended the "brute force" method is used. The "brute force"
     mode means that at the merge point an updated label request message
     is sent all the way from the merge point to the egress LSR. Each
     LSR along the LSP must make sure the incoming EF traffic rate is
     less than the interface's configured EF minimum departure rate.

   -- AF PHB [DIFF_AF]

     As described in [DIFF_AF], 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.

     Two LSPs are allowed to be merged into one LSP only when 2 LSPs
     carry the traffic which has the same AF class.

     Since AF class traffic requires relative bandwidth, when 2 LSPs
     merged there is no need to send a new label request all the way
     down the egress node.

     The subject of AF traffic parameters is for furthur study (FFS).

2.4 Data Transfer in an MPLS LSP

2.4.1 Shim Header Encapsulation

   When MPLS shim header is used, the traffic carried through an MPLS
   LSP is wrapped with at least one MPLS shim header. In the shim
   header, there is a field currently specified as  "Experimental Use".
   We propose to use this field to represent BM field, and specifically
   drop precedence level for AF traffic.

   Mapping from AF codepoints AFij to the BM field are as follows:

Wu, Cheval, Vaananen                                            [Page 4]

Internet Draft       draft-wu-mpls-diff-ext-00.txt         November 1998

     AF Class           BM Fields:

     AFx1    ------------> 001
     AFx2    ------------> 010
     AFx3    ------------> 011

   Traffic from more than one AF class AFij (where i is not equal ) MUST
   NOT be mapped onto same LSP.

2.4.2. ATM header encapsulation

     AF Class: CLP bit:

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

   AF aggregate class selection for ATM is performed by mapping the AFxj
   to desired ATM LSP, with appropriate traffic class and traffic
   parameters. ATM traffic class selection and parameter mapping is not
   discussed in this version of the document.

2.4.3. Frame Relay header encapsulation

     AF Class: DE bit:

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

   AF aggregate class selection for FR is performed by mapping the AFxj
   to desired FR LSP, with appropriate traffic traffic parameters.
   Frame relay parameter mapping is not discussed in this version of the

3. Message Format

   As of today, there are two signalling protocols proposed by MPLS
   working group: RSVP [MPLS_RSVP] and LDP [MPLS_LDP]. The following
   sections proposes the new messages and new objects for differentiated
   service support.

3.1 New RSVP Object Format

   The RSVP SENDER_TSPEC object is expanded to carry the information
   which PHB is used to forward the traffic.

Wu, Cheval, Vaananen                                            [Page 5]

Internet Draft       draft-wu-mpls-diff-ext-00.txt         November 1998

3.1.1 SENDER_TSPEC Object for EF PHB

   DiffServ EF PHB, SENDER_TSPEC object: Class = 12, C-Type = 3

   The format can be

   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 (bytes)        |   Class-Num   |    C-Type     |
   |         The Committed Data Rate                               |
   |                                                               |

     -- The committed Data Rate, the peak rate that  traffic is allowed
     to enter into the network.

3.1.2 SENDER_TSPEC Object for AF PHB

   DiffServ AF PHB, SENDER_TSPEC object: Class = 12, C-Type = 4

   The format can be

   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 (bytes)        |   Class-Num   |    C-Type     |
   |         The AF Class Number                                   |
   |                                                               |

     -- The AF Class Number, which contains the AF class number for the

3.2 New LDP Object Format

3.2.1 The New COS TLV for EF and AF PHBs

   COS TLV is expanded to contain the following values:

Wu, Cheval, Vaananen                                            [Page 6]

Internet Draft       draft-wu-mpls-diff-ext-00.txt         November 1998

     COS Name     Type code    Value

     EF PHB       0x02         4 octet which is the Committed Data Rate

     AF PHB       0x03         1 octet, which can be class1, class2,
     class3, class4

3.2.2 The New LDP Label Re-request Message Format

   A new message, Label Re-request, is defined for renegotiating the
   bandwidth requirement of an established LSP. When 2 LSPs which carry
   the EF traffic merged at one LSR, an Label Re-Request message can be
   sent down from the merged point to the egress LSR. This Label Re-
   Request carries the aggregated Committed Data Rate of the 2 LSPs.

   The format of this Label Re-request is very similar to the Label
   Request message [MPLS_LDP].

       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
      |     Label Re-Request (0x0406) |      Message Length           |
      |                     Message ID                                |
      |                     FEC-Request TLV 1                         |
      |                                                               |
      ~                                                               ~
      |                                                               |
      |                     FEC-Request TLV n                         |
      |                     Optional Parameters                       |

   Message Id

     Four octet integer used to identify this message.

   FEC-Request TLV

     Each specifies an FEC for which a label mapping is requested. A
     FEC-Request TLV is a nested TLV that contains a FEC TLV, an
     optional COS TLV, and an optional Hop Count TLV.

Wu, Cheval, Vaananen                                            [Page 7]

Internet Draft       draft-wu-mpls-diff-ext-00.txt         November 1998

       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
      |   FEC-Request (0x0701)        |      Length                   |
      |                     FEC TLV                                   |
      |                     COS TLV (optional)                        |
      |                     Hop Count TLV (optional)                  |

   The encoding for the FEC, COS, and Hop Count TLVs are specified in
   Section "Commonly Used TLVs".

   Optional Parameters

     No optional parameters are defined for the Label Request message.

4. Security

   The security issues will be discussed in the future version of this

5. Achnowledgments

   Thanks to Michel Henrion, Emmanuel Desmet, Bernard Sales, Christophe
   Boscher, Olivier Duroyon and Sudheer Dharanikota for their helpful
   review and feedback.

6. References

   [MPLSARCH] Rosen et al, "Multiprotocol Label Switching Architecture",
   working in progress, (draft-ietf-mpls-arch-02), July, 1998

   [DIFFARCH] Blake et al, "An Architecture for Differentiated
   Services", working in progress, (draft-ietf-diffserv-arch-02.txt),
   October, 1998

   [DIFF_AF] Heinanen et al, "Assured Forwarding PHB Group", working in
   progress, (draft-ietf-diffserv-af-02.txt), October, 1998

Wu, Cheval, Vaananen                                            [Page 8]

Internet Draft       draft-wu-mpls-diff-ext-00.txt         November 1998

   [DIFF_EF] Jacobson et al, "An Expedited Forwarding PHB", working in
   progress, (draft-ietf-diffserv-phb-ef-00.txt), August, 1998

   [MPLS_LDP] Andersson et al, "LDP Specification", working in progress,
   (draft-ietf-mpls-ldp-00.txt), August, 1998

   [MPLS_RSVP] Swallow et al, "Extensions to RSVP for Traffic
   Engineering", working in progress, (draft-swallow-mpls-rsvp-trafeng-
   00.txt), Auguest, 1998

7. Author Information

   Liwen Wu
   Email: liwen.wu@adn.alcatel.com Tel: 703-724-2619
   44983 Knoll Square, Ashburn, VA 20147, USA

   Pierrick Cheval
   Email: pierrick.cheval@adn.alcatel.com Tel: 703-724-2080
   44983 Knoll Square, Ashburn, VA 20147, USA

   Pasi Vannanen
   Email: pasi.vaananen@ntc.nokia.com Tel:781-238-4981
   3 Burlington Woods Drive, Suite 250, Burlington, MA. 01803

Wu, Cheval, Vaananen                                            [Page 9]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/