HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 12:13:59 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 26 Feb 1999 15:17:45 GMT ETag: "2e6b5a-48c1-36d6bb19" Accept-Ranges: bytes Content-Length: 18625 Connection: close Content-Type: text/plain 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]