Network Working Group Yong Lucy Internet Draft Huawei Intended status: Standard Track October 8, 2010 Expires: April 2011 Flow-Aware Pseudowire for the Virtual Private LAN Service draft-yong-l2vpn-fat-pw-4-vpls-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. Yong Expires April 8, 2011 [Page 1] Internet-Draft FAT-PW-4-VPLS October 2010 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 This Internet-Draft will expire on April 8, 2009. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract A pseudowire (PW) is used in Virtual Private LAN Service (VPLS) solutions to form any-to-any connections and provide service demuliplexing among Provider Edge routers (PEs), and is normally transported over one single network path. Flow-aware PW enable a PW to take advantage of Equal Cost Multipath (ECMP) and/or Link Aggregation Groups (LAG) in a packet switched network (PSN). PW packets with a flow label can be transported over multi-paths. This method can apply to the PWs in a VPLS service. This document describes how VPLS solutions utilize a PW with a flow label, and defines protocol extension for the provisioning of such PWs. Table of Contents 1. Introduction...................................................3 2. Conventions Used in This Document..............................3 3. VPLS Supported by PW with a Flow Label.........................4 3.1. RFC4761 Extension for PW with a Flow Label................4 Yong Expires April 8, 2011 [Page 2] Internet-Draft FAT-PW-4-VPLS October 2010 3.2. RFC4762 Extension for PW with Flow Label..................5 3.3. Virtual Service Instance (VSI) Forwarder..................6 3.4. Flow Identification.......................................6 4. Security Considerations........................................7 5. IANA Considerations............................................7 6. References.....................................................7 6.1. Normative References......................................7 6.2. Informative References....................................7 7. Acknowledgments................................................8 1. Introduction [RFC4664] specifies the Layer 2 virtual private network (L2VPN) framework. The L2VPN framework uses a point-to-point (P2P) pseudowire (PW) between any pair of Provider Edge routers (PEs) to provide connection and service demultiplexing. Each P2P PW is mapped to a traffic engineered (TE) tunnel traversing a packet switched network (PSN). Two popular L2VPN services are Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS). VPWS is a P2P transport service. VPLS is multi-point emulated LAN service. Two standard VPLS solutions are specified in [RFC4761] and [RFC4762]. One is BGP-based auto-discovery and singling; the other is LDP-based signaling. Flow-aware PW [FAT-PW] is developed recently in IETF. It adds a flow label on the label stack and enables the distinction of the flows within a PW being carried over equal cost multipath (ECMP) and/or a link aggregation group (LAG) in a packet switched network (PSN). The target application of a PW with a flow label (i.e., of a PW split across multiple parallel paths) is to transport large volumes of IP traffic between two routers, for example, when providing a VPWS. Service Providers use VPLS to provide an emulated LAN service and to transport customer Layer 2 frames between Customer Edge routers (CEs). Many L2VPN services carry Layer 2 frames that contain IP payloads. There is an incentive for a service provider to use the PW with a flow label in a VPLS service to support large volumes of data between points on the emulated LAN. This document describes a VPLS solution that uses a PW with a flow label and defines protocol extension for provisioning the PW. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Yong Expires April 8, 2011 [Page 3] Internet-Draft FAT-PW-4-VPLS October 2010 3. VPLS Supported by PW with a Flow Label A VPLS is a layer 2 service that emulates an Ethernet LAN across a Wide Area Network (WAN). It is a multipoint service. Although VPLS service frames are Ethernet frames, and frame forwarding is based on the destination MAC address, CE devices may be routers where the frame payload is IP data. [RFC4761] specifies BGP based auto-discovery and signaling for VPLS configuration and operation procedures. [RFC4762] specifies LDP based VPLS configuration and operation procedures. Both configure PWs to support a VPLS instance, and in both cases the PW cannot be split across multiple paths. The extensions in this document are necessary for provisioning the PWs with a flow label that can be split across multiple paths in a VPLS instance. Note: a VPLS service that uses PW with a flow label may have some different service aspects in a PSN from the one that does not. It is outside the scope of this document how a service provider differentiates the service profile between these two cases and how a PE classifies the flows for a PW with a flow label. 3.1. RFC4761 Extension for PW with a Flow Label [RFC4761] uses BGP to discover PEs in a VPLS instance and configure a PW between any pair of PEs in the VPLS instance. [RFC4761] uses VPLS BGP Network Layer Reachability Information (NLRI) to exchange VPLS membership and demultiplexers, and uses the "Layer 2 Info Extended Community" to signal control information about the PW to be setup for a VPLS edge device (VE). In this case, if a flow label is to be used to allow the PW to be carried over ECMP or a LAG, it is necessary to coordinate the use of the flow label between the ingress and egress PE. To signal the presence of the flow label in a PW, this document suggests using two bits in Control Flags. [RFC4761] has specified "Layer 2 Info Extended Community" and Control Flags Bit Vector. This document suggests using two bits in Control Flags Bit Vector to signal flow label present between the ingress and egress PEs. The suggested format is shown below. Yong Expires April 8, 2011 [Page 4] Internet-Draft FAT-PW-4-VPLS October 2010 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |T|R|C|S| (MBZ = MUST Be Zero) +-+-+-+-+-+-+-+-+ Name C and S remain the same meaning as [RFC4761]. Name T and R are defined here. o When T=1 the PE is requesting the ability to send a PW packet that includes a flow label. When T=0, the PE is indicating that it will not send a PW packet containing a flow label. o When R=1 the PE is able to receive a PW packet with a flow label present. When R=0 the PE is unable to receive a PW packet with the flow label present. The two new bits in Control Flags are used to synchronize the flow label state between the ingress and egress PEs. If PE does not support flow label, these two bits MUST be set to zero according to [RFC4761], which preserves backward compatibility. A PE that uses BGP signaling and does not set T bit to 1 MUST NOT include a flow label in the PW packet. This preserves backward compatibility with existing PW specifications. A PE sending a Control Flag with T = 1 to a peer PE and receiving a Flow Label Flag with R = 1 from the peer PE SHOULD include a flow label in the PW packet. Under all other combinations of Flow Label Flag in signaling a PE MUST NOT include a flow label in the PW packet. The signaling process allows that some PWs in a VPLS instance use a flow label on PW packets and other PWs in the same VPLS instance do not use flow labels. This provides the flexibility to support network migration. What is signaled is the desire to include the flow label in the label stack. As [FAT-PW] mentions, the value of the label is a local matter for the ingress PE, and the label value itself is not signaled. 3.2. RFC4762 Extension for PW with Flow Label [RFC4762] uses LDP to provision a VPLS instance and configure an Ethernet PW [RFC4448] between every pair of PEs to form a full mesh topology among PEs. Yong Expires April 8, 2011 [Page 5] Internet-Draft FAT-PW-4-VPLS October 2010 [RFC4762] identified three relevant interface parameters for a VPLS. This document adds the Flow Label Sub-TLV defined in [FAT-PW] as a relevant interface parameter for a VPLS. When Flow Label Sub-TLV is presented in label mapping message, ingress and egress PE MUST perform the same procedures described in section 4 of [FAT-PW]. If LDP signaling [RFC4762] is not in use for PW setup, then whether the flow label is used or not MUST be identically provisioned in both PEs at the PW endpoints. If there is no provisioning support for this option, the default behavior is not to include the flow label. Data forwarding on an Ethernet PW MUST follow the procedures described in [RFC4762]. 3.3. Virtual Service Instance (VSI) Forwarder Each VPLS forms a full mesh among PEs in the VPLS. Every VSI at a PE in a given VPLS has exactly one point-to-point PW to every other VSI in the same VPLS. MAC address learning is done per PW association, i.e., the FIB keeps the mapping of the customer MAC address and PW association.[RFC4664] When a PW in a VPLS is used with a flow label, the PW still appears as one single PW to the VSI. The VSI forwarder function is the same as the PW without flow label.[RFC4762] It is worth mentioning the case that, if ECMP is used at PEs, the ingress PE may distribute PW packets with the flow label to different tunnels; so the egress PE gets the packets from different tunnels and pass them to the same PW forwarder. The distribution method is local and outside the scope of document. Flow recognition is discussed in Section 3.4. The VSI forwarder SHOULD be able to generate a flow label and process PW encapsulation as described in section 3.1 or 3.2. It is possible that a VPLS uses point-to-multipoint (P2MP) PWs for traffic optimization [P2MP-PW-REQ], [BCAST-EXT]. A P2MP PW with a flow label requires that all the egress points can process that flow label, which makes harder to synchronize the decision. The solution for P2MP is for further study. 3.4. Flow Identification A VPLS service transports customer Ethernet frames. When using a PW with a flow label, it requires that ingress PE identifies a flow or a group of flows within the service so that all frames from any one flow are given the same flow label and treated the same way in the Yong Expires April 8, 2011 [Page 6] Internet-Draft FAT-PW-4-VPLS October 2010 network. This can be done by parsing the ingress Ethernet traffic and considering all of the IP traffic. Source and destination IP address, source and destination port, and protocol type may be used to identify the flow. Whether the ingress PE uses a PE bridge element or VSI forwarder to recognize the flow is a local implementation matter and is outside the scope of document. 4. Security Considerations The protocol extension in this draft does not introduce any new security risk to the services and network beyond the analysis in [FAT-PW]. 5. IANA Considerations Not Any. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4761] Kompella, K., Rekhter, Y., "BGP Auto-Discovery and Signaling for VPLS", RFC 4761, January 2007. [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, 6.2. Informative References [RFC4664] Andersson, L., Rosen, E.,"Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, 2006. [FAT-PW] Bryan, S., et. Al, "Flow Aware Transport of Pseudowire over an MPLS PSN", draft-ietf-pwe3-fat-pw-04, Work in progress. [P2MP-PW-REQ] Jounay, F., et. al, "Requirements for Point to Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements- 03.txt, Work in progress. Yong Expires April 8, 2011 [Page 7] Internet-Draft FAT-PW-4-VPLS October 2010 [BCAST-EXT] Delord, S. et. Al, Extension to LDP-VPLS for Ethernet Broadcast and Multicast, draft-delord-l2vpn-ldp-vpls- broadcast-exten-03-txt, work in progress. 7. Acknowledgments Author would like to thank Adrian Farrel, Mach Chen for the review and valuable suggestions. Yong Expires April 8, 2011 [Page 8] Internet-Draft FAT-PW-4-VPLS October 2010 Authors' Addresses Lucy Yong Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 469-229-5387 Email: lucyyong@huawei.com Yong Expires April 8, 2011 [Page 9]