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