Internet Draft






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