Internet Draft
Internet Engineering Task Force                           Shahram Davari
INTERNET DRAFT                                           PMC-Sierra Inc.
Expires October 1999
                                                            Ram Krishnan
                                                        Nexabit Networks

                                                           Pasi Vaananen 
                                                                   Nokia

                                                             April, 1999
                                                                 

         MPLS Support of Differentiated Services over PPP links

                 <draft-davari-mpls-diff-ppp-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 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 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 a technique for MPLS to support Differentiated
   Services (Diff-Serv) over PPP links in non-ECN-capable [ECN] networks.

   Briefly, we propose that:

   - Packets belonging to the same PHB forwarding class (PFC), as defined
     in [DIFF_MPLS_EXT], be transported over the same PPP LSP.
 
   - For a given FEC, a separate PPP LSP should be established for each
     PFC, so that multiple PPP LSPs are established in parallel for
     support of Diff-Serv.


Davari, et al.                                                  [Page 1]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  


   - Among a set of PHBs transported over the same PPP LSP, the different
     PHBs' drop Precedence (DP) be mapped into the EXP field (3 bits) of
     the MPLS shim header (note that DP is implicitly a part of DSCP).

   The required updates to the current MPLS LDP and MPLS RSVP messages
   (for LSP establishment in order to support Diff-Serv over PPP LSRs)
   are the same as the ones proposed in [MPLS_DIFF_EXT].
   
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 signaling 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 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 supporting the currently
   defined Diff-Serv PHBs over a non-ECN-capable PPP MPLS network, i.e.,
   an MPLS network implemented using non-ECN-capable PPP routers.

1.1. PHB Forwarding Class

   [MPLS_DIFF_EXT] defines a set of PHBs that require no misordering of
   packets in a microflow (even if the microflow contains packets for
   more than one PHB) as a PHB Forwarding Class (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 in Diff-Serv over PPP MPLS

   Recognizing that:
 
   - MPLS over PPP links requires the use of a Shim Header, which consists
     of a label stack with one or more entries [MPLS_ENCAPS];

   - The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER], which
     can not be copied entirely in to the 3-bit long EXP field of the MPLS
     shim header;

   We propose that:

   - All packets belonging to a single PFC and the same Forwarding

Davari, et al.                                                  [Page 2]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  


     Equivalent 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
     Precedence (DP) values through appropriate coding of the EXP field
     of the top label entry of the shim header.

   MPLS specifies how LSPs can be established via multiple signaling
   protocols. This Internet-Draft assumes the extensions to LDP and
   RSVP are those defined in [MPLS_DIFF_EXT], which allow establishment
   of one LSP per  pair over a PPP link.


1.3. Label Forwarding for Support of Diff-Serv over PPP MPLS

   Label forwarding for support of Diff-Serv over PPP MPLS domain can be
   broken down into three regions:

   - Ingress node
   - Egress node
   - Interior node 
   
   On the other hand the Ingress and Egress links may be one of the
   followings:

   - Non-MPLS link
   - MPLS link of the same hierarchical level 
   - MPLS link of different hierarchical level

   Let us further assume that the upstream and downstream links of an
   Interior node are in the same hierarchical level.
     
1.3.1 Ingress Node Label Forwarding

   At the Ingress edge of a PPP Diff-Serv MPLS cloud, the Edge-LSR should
   identify the PHB of an incoming packet (note that PHB consists of PFC
   and DP). It should then determine the outgoing PHB according to some
   local policy and/or traffic conditioning function and map it to the
   outgoing packet. 

   The following actions are taken by the Ingress-LSR depending on the
   Ingress link type and hierarchical level: 

   - If the incoming packet is coming through a non-MPLS PPP/ATM/FR link
   (unlabeled packet), the Edge-LSR determines the incoming packet's PHB
   by looking at its IP DSCP, according to the mappings defined in
   [DIFF_HEADER], [DIFF_AF], [DIFF_EF]. It then determines the packet's
   outgoing PHB according to some local policy and/or traffic conditioning.
   Based on the FEC and PFC of the outgoing packet, the Edge-LSR selects

Davari, et al.                                                  [Page 3]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  


   the LSP among the set of LSPs established for each  pair. The
   PPP Edge-LSR then inserts a shim header and sets the EXP field of the
   top label entry according to the mapping defined below between the
   outgoing PHBs and the EXP field + PFCs (section 2.1).

   - If the incoming packet is coming through an MPLS PPP link (labeled
   packet), which is in the same hierarchical level as the downstream
   link, then the Ingress LSR should act like an Interior LSR described in
   section 1.3.3.

   - If the incoming packet is coming through an MPLS PPP link (labeled
   packet), and this is the start of a hierarchical tunnel, the Ingress
   Edge-LSR first determines the packet's PFC from the incoming LSP among
   the set of LSPs established for the  pair. It then determines
   the incoming packet's PHB from this PFC and from the EXP field of the
   top label entry of the label stack according to the mapping defined
   below between the EXP fields + PFCs and the PHBs (section 2.2). It then
   deteremines the PHBs for the two levels of hierarchy according to some
   local policy and/or traffic conditioning. At each level, based on the
   FEC and PFC of the outgoing packet, the Edge-LSR selects the LSP among
   the set of LSPs established for each . It then pushes a new
   label entry into the label stack and sets the EXP field of the new
   label entry and the lower label entry (i.e., the incoming label entry)
   according to the mapping defined below between PHBs and the EXP field
   + PFCs (section 2.1). Note that these two labels may have similar or
   different EXP fields.

   - If the incoming packet is coming through an MPLS ATM/FR link (labeled
   packet), which is in the same hierarchical level as the downstream link,
   the Ingress first determines the packet's PFC from the incoming LSP
   among the set of LSPs established for the  pair. It then
   determines the incoming packet's PHB from this PFC and from the CLP/DE
   bit and/or EXP field of the top label entry of the label stack
   according to a mapping between CLP/DE bit and/or EXP field and the PHBs
   , which is outside the scope of this document and is yet to be defined.
   It then determines the packet's outgoing PHB according to some local
   policy and/or traffic conditioning. Based on the FEC and PFC of the
   outgoing packet, the Edge-LSR selects the LSP among the set of LSPs
   established for each . It then sets the EXP field of the top
   label entry, according to the mapping defined below between the outgoing
   PHB and EXP field + PFCs (section 2.1).

   - If the incoming packet is coming through an MPLS ATM/FR link (labeled
   packet) and this is the start of a hierarchical tunnel, the Ingress 
   Edge-LSR first determines the incoming packet's PFC from the incoming
   LSP among the set of LSPs established for the  pair. It then
   determines the incoming packet's PHB from this PFC and from the CLP/DE
   bit and/or EXP field of the top label entry of the label stack
   according to a mapping between CLP/DE bit and/or EXP field and the PHBs
   , which is outside the scope of this document and is yet to be defined.
   It then determines the PHBs for the two levels of hierarchy according
   to some local policy and/or traffic conditioning. At each level, based

Davari, et al.                                                  [Page 4]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  


   on the FEC and PFC of the outgoing packet, the Edge-LSR selects the LSP
   among the set of LSPs established for each . It then pushes a
   new label entry into the label stack and sets the EXP field of the new
   label entry and the lower label entry (i.e., the ATM/FR label entry)
   according to the mapping defined below between PHBs and the EXP field
   + PFCs (section 2.1). Note that these two labels may have similar or
   different EXP fields.

1.3.2 Egress Node Label Forwarding

   At the Egress edge of a PPP Diff-Serv MPLS cloud, the Edge-LSR first
   determines the packet's PFC from the incoming LSP among the set of LSPs
   established for the  pair. It then determines the incoming
   packet's PHB from this PFC and from the EXP field of the top label
   entry of the label stack according to the mapping defined below between
   the EXP fields + PFCs and the PHBs (section 2.2). It then determines
   the packet's outgoing PHB according to some local policy and/or traffic
   conditioning and maps that into the outgoing packet depending on egress
   link type and hierarchical level as explaind below: 

   - If the outgoing link is a non-MPLS PPP/ATM/FR link (unlabeled packet)
   , the Edge-LSR pops the shim header and sets the IP DSCP of the packet
   based on the outgoing PHBs according to the mappings defined in
   [DIFF_HEADER], [DIFF_AF], [DIFF_EF]. 

   - If the outgoing packet is labeled and is going through a PPP egress
   link, which is in the same hierarchical level as the upstream link,
   then the Egress LSR should act as an Interior LSR described in section
   1.3.3.

   - If the outgoing packet is going through an MPLS PPP link (labeled
   packet) and this is the end of a hierarchical tunnel, based on the FEC
   and PFC of the outgoing packet, the Edge-LSR selects the LSP among the
   set of LSPs established for each . It then pops the top label
   entry and sets the EXP field of the lower label entry according the
   mapping defined below between PHBs and EXP field + PFCs (section 2.1).

   - If the outgoing packet is going through an MPLS ATM/FR link (labeled
   packet), which is in the same hierarchical level as the upstream link,
   based on the FEC and PFC of the outgoing packet, the Edge-LSR selects
   the LSP among the set of LSPs established for each . It then
   sets the EXP field of the shim header's top label entry (i.e., ATM/FR
   label entry) according to the mapping defined below between PHBs and the
   EXP field + PFCs (section 2.1). It also sets the CLP/DE bit according to
   the mapping defined in [MPLS_DIFF_EXP] between PHBs and CLP/DE bit.

   - If the outgoing packet is going through an MPLS ATM/FR link (labeled
   packet) and this is the end of a hierarchical tunnel, based on the FEC
   and PFC of the outgoing packet, the Edge-LSR selects the LSP among the
   set of LSPs established for each . It then pops the top label
   entry and sets the EXP field of the lower label entry according to the
   mapping defined below between PHBs and EXP field + PFCs (section 2.1).

Davari, et al.                                                  [Page 5]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  


   It also sets the CLP/DE bit according to the mapping defined in
   [MPLS_DIFF_EXP] between PHBs and CLP/DE bit.


1.3.3 Interior Node Label Forwarding

   At the Interior of a PPP Diff-Serv MPLS cloud, the Interior-LSR, which
   receives and transmits labeled packet on PPP links, which are at the
   same heirarchical level, will perform the following action:

   - The Interior LSR first determines the packet's PFC from the incoming
   LSP among the set of LSPs established for the  pair. It then
   determines the incoming packet's PHB from this PFC and from the EXP
   field of the top label entry of the label stack according to the mapping
   defined below between the EXP fields + PFCs and the PHBs (section 2.2).
   It then determines the packet's outgoing PHB according to some local
   policy and/or traffic conditioning. Based on the FEC and PFC of the
   outgoing packet, the Interior LSR selects the LSP among the set of LSPs
   established for each . The Interior LSR then sets the EXP
   field of the top label entry of the stack according to the mapping
   defined below between the PHBs and the EXP field + PFcs (section 2.1).
  
2. PHB Mapping into PFCs and Selective Discard Mechanism
   
   The mapping from the AF and EF PHBs into the PFCs are the same as
   those defined in [MPLS_DIFF_EXT]. While the mapping from PHBs into the
   EXP field + PFCs and the mapping from EXP field + PFCs into the PHBs are
   described below.

2.1 Mapping PHBs into the EXP Field and PFCs

   This section covers the mapping from AF and EF PHBs into the EXP field
   of the Shim Header and the PFC. 
   
   There are 4 PFCs defined for AF PHBs and within each AF PFC there are
   3 drop precedences, which get mapped into the EXP field. There is only
   one PFC with one drop precedence defined for the EF PHB and the DF PHB
   (Default Forwarding), which gets mapped into the EXP field.

   The mapping from AF, EF and DF PHBs into the EXP field of the shim
   header and the PFCs is as follows:

   PHB             EXP Field     PFC

   AFx1   ----->     000         AFCx
   AFx2   ----->     001         AFCx
   AFx3   ----->     010         AFCx
   EF     ----->     000         EFC
   DF     ----->     000         DFC

   The AFCx and EFC per-hop forwarding classes (PFC) are defined in
   [MPLS_DIFF_EXT]. The DFC (Default Forwarding Class) corresponds to the
   PHB-group Forwarding Class for the DF PHB. 

Davari, et al.                                                  [Page 6]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  


2.2 Mapping EXP field and PFC into the PHBs

   The mapping from EXP field of the shim header and PFC into the AF, EF
   and DF PHBs is as follows:

   EXP Field         PHB       PFC

     000   ----->    AFx1      AFCx        
     001   ----->    AFx2      AFCx
     010   ----->    AFx3      AFCx
     000   ----->    EF        EFC
     000   ----->    DF        DFC

   The AFCx and EFC per-hop forwarding classes (PFC) are defined in
   [MPLS_DIFF_EXT]. The DFC (Default Forwarding Class) corresponds to the
   PHB-group Forwarding Class for the DF PHB. 

3 Examples of Local Policies for Determining PHBs

   This section gives a few examples of the local policies, which might be
   used in determining a packet's PHB.

3.1 Example of Determining an Egress packet's PHB Considering its
      Previous PHB when DP Upgrading is not Permitted

   In this example an egress packet's PHB is determined by examining the
   EXP field of its shim header together with its previous PHB (which
   might be determined from the packet's DSCP in case of non-MPLS egress
   link or the shim header's lower label entry in case of MPLS egress
   link of different hierarchical level), and assuming that no upgrading
   of the DP of a packet is permitted. 

   EXP Field    Previous         New        Comments
                  PHB            PHB

     000         AFx1   ----->   AFx1       No change
     000         AFx2   ----->   AFx2       Impossible      
     000         AFx3   ----->   AFx3       Impossible
     000         EF     ----->   EF         No change
     000         DF     ----->   DF         No change
     001         AFx1   ----->   AFx2       Downgrade
     001         AFx2   ----->   AFx2       No change
     001         AFx3   ----->   AFx3       Impossible
     001         EF     ----->   EF         Impossible
     001         DF     ----->   DF         Impossible      
     010         AFx1   ----->   AFx3       Downgrade
     010         AFx2   ----->   AFx3       Downgrade
     010         AFx3   ----->   AFx3       No change
     010         EF     ----->   EF         Impossible
     010         DF     ----->   DF         Impossible

The following assumptions has been made in the above table:

Davari, et al.                                                  [Page 7]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  


   - The drop precedence of a Marked packet can not be upgraded.
   - the drop precedence of the EF and DF PHB packets can not be
   downgraded.

3.2 Example of Determining an Egress Packet's PHB Considering its
      Previous PHB when DP Upgrading is Permitted

   In this example an egress packet's PHB is determined by examining the
   EXP field of its shim header together with its previous PHB (which
   might be determined from the packet's DSCP in case of non-MPLS egress
   link or the shim header's lower label entry in case of MPLS egress
   link of different hierarchical level), and assuming that upgrading of
   the DP of a packet is permitted.  

   EXP Field    Previous         New        Comments
                  PHB            PHB

     000         AFx1   ----->   AFx1       No change
     000         AFx2   ----->   AFx1       Upgrade      
     000         AFx3   ----->   AFx1       Upgrade
     000         EF     ----->   EF         No change
     000         DF     ----->   DF         No change
     001         AFx1   ----->   AFx2       Downgrade
     001         AFx2   ----->   AFx2       No change
     001         AFx3   ----->   AFx2       Upgrade
     001         EF     ----->   EF         Impossible
     001         DF     ----->   DF         Impossible 
     010         AFx1   ----->   AFx3       Downgrade
     010         AFx2   ----->   AFx3       Downgrade
     010         AFx3   ----->   AFx3       No change
     010         EF     ----->   EF         Impossible
     010         DF     ----->   DF         Impossible

The following assumptions has been made in the above table:

   - The drop precedence of a Marked packet can be upgraded.
   - the drop precedence of the EF and DF PHB packets can not be
   downgraded.    
   
3.3 Example of Determining an Ingress ATM/FR Packet's PHB Considering
    its previous PHB and CLP/DE bit when DP Upgrading is not Permitted
      
   In this example an ingress packet's PHB is determined by examining its
   CLP/DE bit (or in case of fragmented IP packets the logical "OR" of
   CLP/DE bits of all fragments) together with its previous PHB (which
   might be determined from the packet's DSCP in case of non-MPLS ingress
   link or the shim header's top label entry in case of MPLS ingress link)
   , and assuming that no upgrading of DP is permitted.




Davari, et al.                                                  [Page 8]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  


   CLP/DE     Previous             New           
    bit       EXP(PHB)           EXP(PHB)       Comments
   
    0        000 (AFx1)  ----->  000 (AFx1)     No change   
    0        001 (AFx2)  ----->  001 (AFx2)     Impossible
    0        010 (AFx3)  ----->  010 (AFx3)     Impossible
    0        000 (EF)    ----->  000 (EF)       No change
    0        000 (DF)    ----->  000 (DF)       No change
    1        000 (AFx1)  ----->  001 (AFx2)     Downgrade
    1        001 (AFx2)  ----->  001 (AFx2)     No change
    1        010 (AFx3)  ----->  010 (AFx3)     No change
    1        000 (EF)    ----->  000 (EF)       Impossible
    1        000 (DF)    ----->  000 (DF)       Impossible  

   The following assumptions has been made in the above table:

   - The drop precedence of a Marked packet can not be upgraded.
   - ATM/FR links can downgrade the drop precedence of a packet by only
   one level (i.e., AFx1 -> AFx2, not AFx3).
   - the drop precedence of the EF and DF PHB packets can not be
   downgraded.

3.4 Example of Determining an Ingress ATM/FR Packet's PHB Considering
    its previous PHB and CLP/DE bit when DP Upgrading is Permitted

   In this example an ingress packet's PHB is determined by examining its
   CLP/DE bit (or in case of fragmented IP packets the logical "OR" of
   CLP/DE bits of all fragments) together with its previous PHB (which
   might be determined from the packet's DSCP in case of non-MPLS ingress
   link or the shim header's top label entry in case of MPLS ingress link
   ), and assuming that upgrading of DP is permitted. 

   CLP/DE     Previous             New           
    bit       EXP(PHB)           EXP(PHB)       Comments
   
    0        000 (AFx1)  ----->  000 (AFx1)     No change   
    0        001 (AFx2)  ----->  000 (AFx1)     Upgrade
    0        010 (AFx3)  ----->  001 (AFx2)     Upgrade
    0        000 (EF)    ----->  000 (EF)       No change
    0        000 (DF)    ----->  000 (DF)       No change
    1        000 (AFx1)  ----->  001 (AFx2)     Downgrade
    1        001 (AFx2)  ----->  001 (AFx2)     No change
    1        010 (AFx3)  ----->  010 (AFx3)     No change
    1        000 (EF)    ----->  000 (EF)       Impossible
    1        000 (DF)    ----->  000 (DF)       Impossible   

The following assumptions has been made in the above table:

   - The drop precedence of a Marked packet can be upgraded by only one
   level (i.e., AFx3 -> AFx2 not AFx1).
   - ATM/FR links can downgrade the drop precedence of a packet by only
   one level (i.e., AFx1 -> AFx2, not AFx3).
   - the drop precedence of the EF and DF PHB packets can not be
   downgraded.

Davari, et al.                                                  [Page 9]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  


3. References

   [ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion
   Notification (ECN) to IP", RFC-2481, January 1999.

   [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"
   , RFC-2475, December 1998.

   [MPLS_ENCAPS] Rosen et al., "MPLS Label Stack Encoding", work in
   progress, (draft-ietf-mpls-label-encaps-03.txt), September 1998.

   [DIFF_HEADER] Nichols et al., "Definition of the Differentiated
   Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474,
   December 1998.

   [MPLS_DIFF_EXT] Wu et al., "MPLS Support of Differentiated Services
   by ATM LSRs and Frame Relay LSRs", work in progress, February 1999.

   [DIFF_AF] J. Heinanen et al., "Assured Forwarding PHB Group", work in
   progress, (draft-ietf-diffserv-af-06.txt), February 1999.

   [DIFF-EF] V. Jacobson et al., "An Expedited Forwarding PHB", work in
   progress, (draft-ietf-diffserv-phb-ef-02.txt), February 1999.

4. Authors' Addresses

   Shahram Davari
   PMC-Sierra Inc.
   105-8555 Baxter Place
   Burnaby, BC V5A 4V7
   Canada
   E-mail: Shahram_Davari@pmc-sierra.com

   Ram Krishnan
   Nexabit Networks
   200 Nickerson Road,
   Marlboro, MA 01752
   USA
   E-mail: ram@nexabit.com

   Pasi Vanannen
   Nokia
   3 Burlington Woods Drive, Suit 250
   Burlington, MA 01803
   USA
   Email: pasi.vaananen@ntc.nokia.com


Davari, et al.                                                  [Page 10]

Internet Draft      draft-davari-mpls-diff-ppp-00.txt      February 1999  
                                                    
                                                    Expires October 1999