PPVPN Working Group K. Kompella (Juniper) Internet Draft Y. Rekhter (Juniper) Expiration Date: May 2002 V. Kompella (TiMetra) J. Achirica (Telefonica) L. Andersson (Utfors) G. Heron (PacketExchange) S. Khandekar (TiMetra) M. Lasserre (Riverstone) P. Lin (Yipes) P. Menezes (Terabeam) A. Moranganti (Appian) H. Ould-Brahim (Nortel) S. Yeong-il (Korea Tel) Virtual Private LAN Service draft-kompella-ppvpn-vpls-00.txt 1. 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. K. Kompella (editor) Expires May 2002 [Page 1] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 2. Abstract Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offered is a Layer 2 VPN; however, in the case of VPLS, the customers in the VPN are connected by a multipoint network; this is in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions needed to offer VPLS, and goes on to propose a mechanism for signaling a VPLS, as well as a mechanism for transport of VPLS frames over tunnels across a packet switched network. 3. Introduction Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service offering. A Virtual Private LAN appears in (almost) all respects as a LAN to the Service Provider customer. However, in a VPLS, the customers are not all connected to a single LAN; the customers may be spread across a metro or wide area. In essence, a VPLS glues several individual LANs across a metro area to appear and function as a single LAN [VPLS-REQ]. This document describes the functions needed to offer VPLS, and goes on to propose a mechanism for signaling a VPLS, as well as a mechanism for transport of VPLS frames over tunnels across a packet switched network. The basic framework is taken from [L2VPN]. Section 3 describes the functions needed to offer a VPLS, and several deployment scenarios. Section 4 describes a common mechanism for VPLS discovery and signaling, as well as transport of frames. Section 5 depicts an example where the VPLS functions are split across two types of devices. It is important to point out that [L2VPN] allows one to build a Layer 2 VPN with Ethernet as the interconnect; and [MART-SIG] allows one to signal an Ethernet connection across a packet switched network. Both of these, however, offer point-to-point Ethernet services. What distinguishes VPLS from the above two is that VPLS offers a multipoint service. Furthermore, it is useful to note that LDP signaling for a VPLS is defined in [VPLS-LDP]; however, LDP does not offer a scalable VPN discovery mechanism. K. Kompella (editor) Expires May 2002 [Page 2] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 4. VPLS functional architecture This will be described with reference to Figure 1. Figure 1: Example of a VPLS ----- / A1 \ ---- ____CE1 | / \ -------- -------- / | | | A2 CE2- / \ / PE1 \ / \ / \ / \___/ | \ ----- ---- ---PE2 | \ | | \ ----- | Service Provider Network | \ / \ | | CE5 A5 | | ___ | / \ / |----| \ / \ PE4_/ ----- |L2PE|--PE3 / \ / |----| -------- ------- ---- / | ---- / \/ \ / \ CE = Customer Edge Device | A3 CE3 --CE4 A4 | PE = Provider Edge Router \ / \ / L2PE = Layer 2 Aggregation ---- ---- The terminology of [L2VPN] is used, with the addition of "L2PE", a Layer 2 PE device used for Layer 2 aggregation. An L2PE is owned and operated by the Service Provider (as is the PE). PE and L2PE devices are "VPLS-aware", which means that they know that a VPLS service is being offered. We will call these VPLS edge devices, which could be either a PE or an L2PE, a VE. In contrast, the CE device (which may be owned and operated by either the SP or the customer) is VPLS-unaware; as far as the CE is concerned, it is connected to the other CEs in the VPLS via a Layer 2 switched network. This means that there should be no changes to a CE device, either to the hardware or the software, in order to offer VPLS. Note that a CE device may be connected to a PE or an L2PE via Layer 2 switches that are VPLS-unaware. From a VPLS point of view, such Layer 2 switches are invisible, and hence will not be discussed further. Furthermore, an L2PE may be connected to a PE via Layer 2 and Layer 3 devices; this will be discussed further in a later section. The Service Provider Network is a packet switched network. It is desirable that the links in this network are independent of the K. Kompella (editor) Expires May 2002 [Page 3] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 services (in particular, VPLS) being offered. The PEs are assumed to be full meshed with tunnels; these tunnels can be GRE, RSVP-TE or LDP tunnels. The signaling and establishment of these tunnels is not discussed in this document. 4.1. VPLS functions A VPLS offers a multipoint Layer 2 service over tunnels across a common packet switched network. This requires the following functional elements: 1) Endpoint discovery 2) Signaling for tunnel multiplexing 3) MAC address learning 4) Flooding 5) Spanning tree 4.1.1. VPLS endpoint discovery Endpoint discovery is the process by which the VPLS-aware devices find all the customers' ports that belong to the same VPLS. More specifically, a given PE that has one or more (customers') ports that belong to a particular VPLS needs to know all other PEs that have one or more ports that belong to the same VPLS. In the example given above, this means that PE1, PE2, PE3 and PE4 find out that CE1-5 all belong to one VPLS, and that each PE knows to which PE CEx is attached. L2PE devices also need to know what constitutes a given VPLS; however, they don't need the same level of detail. The PE (or PEs) to which an L2PE is connected gives the L2PE an abstraction of the VPLS; this is accomplished by means of the protocol described in [DTLS]. Note that an endpoint in a VPLS is a VE. 4.1.2. Signaling for tunnel multiplexing For reasons of scalability, both of network state as well as SP manageability, there is a single mesh of PE-to-PE tunnels. This means that each tunnel may have multiple services running over it. In order to multiplex these services over a given tunnel (and to know which service a packet belongs to at the egress), one must signal a tunnel multiplexor. K. Kompella (editor) Expires May 2002 [Page 4] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 As in [L2VPN] and [L2SIG], the multiplexor proposed here is a 32 bit cookie formatted as an MPLS label. At the egress, this label captures both the VPLS to which the packet belongs, as well as the source VE. 4.1.3. MAC address learning As was mentioned earlier, the key distinguishing feature of VPLS is that it is a multipoint service. This means that the entire Service Provider network should appear as a single logical learning bridge for each VPLS that the SP network supports. The logical ports for the SP "bridge" are the connections from the SP edge, be it a PE or an L2PE, to the CE. Just as a learning bridge learns MAC addresses on its ports, the SP bridge must learn MAC addresses at its VEs [VPLS]. Learning consists of associating source MAC addresses of packets with the ports on which they arrive; call this association the Forwaring Information Base (FIB). The FIB is used for forwarding packets. For example, suppose the bridge receives a packet with source MAC address S on port P. If subsequently, the bridge receives a packet with destination MAC address S, it knows that it should send the packet out on port P. There are two modes of learning: qualified and unqualified learning. In qualified learning, the learning decisions at the VE are based on the customer ethernet packet's MAC address and VLAN tag, if one exists. If no VLAN tag exists, the default VLAN is assumed. Effectively, within one VPLS, there are multiple logical FIBs, one for each customer VLAN tag identified in a customer packet. In unqualified learning, learning is based on a customer ethernet packet's MAC address only. In other words, at any VE, there is only one FIB per VPLS. Every VE must have at least one FIB for each VPLS that it participates in. 4.1.4. Flooding When a bridge receives a packet to a destination that is not in its FIB, it floods the packet on all the other ports. Similarly, a VE will flood packets to an unknown destination to all other VEs in the VPLS. K. Kompella (editor) Expires May 2002 [Page 5] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 In the example above (Figure 1), if CE2 sent an Ethernet frame to PE2, and the destination MAC address on the frame was not in PE2's FIB (for that VPLS), then PE2 would be responsible for flooding that frame to every other PE in the same VPLS. On receiving that frame, PE1 would be responsible for further flooding the frame to CE1 and CE5 (unless PE1 knew which CE "owned" that MAC address). On the other hand, if PE3 received the frame, it could delegate further flooding of the frame to its L2PE. If PE3 was connected to 2 L2PEs, it would announce that it has two L2PEs. PE3 could either announce that it is incapable of flooding, in which case it would receive two frames, one for each L2PE, or it could announce that it is capable of flooding, in which case it would receive one copy of the frame, which it would then send to both L2PEs. 4.1.5. Spanning tree Learning bridges typically run STP to avoid flooding loops. However, running an instance of STP for each VPLS doesn't scale. By mandating a full mesh of PE-to-PE tunnels, we obviate the need for STP across the Service Provider network. If one considers a VPLS as a "VPLS bridge", then care must be taken to avoid formation of forwarding loops if such VPLS bridges are directly interconnected (with no STP-running bridges in between). 4.2. Functional decomposition The above functions needed to implement a VPLS can be broadly divided into Layer 3 functions (discovery and signaling) and Layer 2 functions (MAC learning, flooding and (if needed) spanning tree. These functions need not all run on the same box. The terminology of PE and L2PE was introduced to allow for a decomposition of VPLS functions. A PE does discovery and signaling. The VE does learning and flooding. If the VE is a PE, then all the above functions reside on a single box. If the VE is an L2PE, then there is a decoupling of the functions along the lines described above. For a more detailed description of the latter case, see [DTLS]. It might be possible in some cases where the VE is an L2PE to have the L2PE do just the MAC learning, and have the PE do the flooding, if the PE is capable of packet replication. This allows the L2PE to send a single packet to the PE, conserving the L2PE-PE link bandwidth. K. Kompella (editor) Expires May 2002 [Page 6] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 This document proposes that the mechanisms of [L2VPN] be used for discovery and signaling, with minor modifications described in the next section. Furthermore, the operation of discovery and signaling should be independent of whether the VPLS functions run on the same box or different boxes. This allows an SP to "mix and match" PEs and PE-L2PE combinations as needed at each site. 5. Discovery and signaling As mentioned above, the mechanism for discovery and signaling is based on [L2VPN]. The modification needed to support VPLS are: 1) re-interpretation of the "CE ID" field 2) new Encaps Types to support VPLS 3) a new control flag for "Flooding capable" PEs 4) a new sub-TLV for Relearning Sequence Numbers 5.1. VE ID A PE advertises a VPLS NLRI for each VPLS that it participates in. If the PE is doing learning and flooding, i.e., it is the VE, it announces a single VPLS NLRI for each VPLS that it is in. If the PE is connected to several L2PEs, it announces one VPLS NLRI for each L2PE. A hybrid scheme is also possible, where the PE learns MAC addresses on some interfaces (over which it is directly connected to CEs) and delegates learning on other interfaces (over which it is connected to L2PEs). In this case, the PE would announce one VPLS NLRI for each L2PE that has customer ports in a given VPLS, and one for itself, if it has customer ports in that VPLS. The format of the VPLS NLRI is given below; it is essentially identical to the L2 VPN NLRI. The AFI and SAFI are the same as for the L2 VPN NLRI. 5.2. Relearn Sequence Number Once a MAC address has been learned by VE A, VE A no longer needs to flood packets destined to that MAC address; instead VE A can send those packets directly to the VE "owning" that MAC address, VE B. However, it is possible that a CE "move" from VE B to VE C; one example scenario is that the CE is dual-homed to VE B and C, and the link over which it is attached to VE B goes down. In this case, VE B may want to signal to other VEs in the VPLS that MAC addresses that they learned from VE B (for the given VPLS) are no longer valid. While aging timers will eventually enforce this, they may often be K. Kompella (editor) Expires May 2002 [Page 7] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 Figure 2: BGP NLRI for VPLS Information +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | VE ID (2 octets) | +------------------------------------+ | Label-block Offset (2 octets) | +------------------------------------+ | Label Base (3 octets) | +------------------------------------+ | Variable TLVs (0 to N octets) | | ... | +------------------------------------+ too slow. The Relearn Sequence Number (RSN) TLV will help speed up relearning. 5.2.1. RSN TLV This is an optional TLV with Type TBD, Length 4 and Value a 32 bit RSN, is a monotonically increasing unsigned number. When an RSN TLV is received, the RSN number is compared against the existing one for that VPLS and PE. If the new number is higher than the previous one, or no previous RSN exists, the PE SHOULD flush all existing MAC address to VC bindings for that VPLS and PE. 5.3. Encaps Type and Control Flags The Encaps Type and Control Flags are encoded in an extended attribute, just as in [L2VPN]. The community type remains the same. There is a new Encaps Type for VPLS (TBD). There are two new control flags, Q and F defined for VPLS. Q says whether qualified learning occurs (1) or not (0); F which says whether the PE is capable of flooding (1) or not (0). K. Kompella (editor) Expires May 2002 [Page 8] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 Figure 3: layer2-info extended community +------------------------------------+ | Extended community type (2 octets) | +------------------------------------+ | Encaps Type (1 octet) | +------------------------------------+ | Control Flags (1 octet) | +------------------------------------+ | Layer-2 MTU (2 octet) | +------------------------------------+ | Reserved (2 octets) | +------------------------------------+ Figure 4: Control Flags Bit Vector 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |Q|F|C|S| (MBZ = MUST Be Zero) +-+-+-+-+-+-+-+-+ 6. VPLS encapsulation Ethernet frames received from a CE are encapsulated as in [MART-ENC] with the following changes: - if the packet, as it arrives at the PE, has a "service tag", e.g., a VLAN tag that is used by the local PE as a service delimiter, then that tag is stripped before the packet is sent into the VPLS. As the packet exits the VPLS, the packet may have a new service tag inserted; this is a local decision on the egress PE. - if the packet, as it arrives at the PE, has an encapsulation that is not service-delimiting (i.e., it has no VLAN that was imposed by the SP to distinguish services, then it is a customer packet whose encapsulation should not be modified by the VPLS. This covers, for example, a packet that carries customer specific tags that the service provider neither knows about nor wants to modify. The egress PE should likewise send the packet to the CE unmodified. By following the above rules, the ethernet packet that traverses a VPLS is always a customer ethernet packet. Note that the two actions, at ingress and egress, of dealing with service delimiters are local actions that neither PE has to signal to the other. They allow, for example, a mix-and-match of tagged and untagged services at either end, and do not carry across a VPLS a tag that may have K. Kompella (editor) Expires May 2002 [Page 9] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 only local significance. The service delimiter may be a VC label also, whereby an ethernet VC given by [MART-ENC] can serve as the access side connection into a PE. An RFC1483 PVC encapsulation could be another service delimiter. 7. Security Considerations The security aspects of this solution will be discussed at a later time. 8. IANA Considerations (To be filled in in a later revision.) 9. Acknowledgments Thanks to Joe Regan and Alfred Nothaft for their contributions. 10. References [DTLS] Kompella, K., et al, "Decoupled TLS", work in progress. [L2VPN] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in progress. [MART-ENC] Martini, L., et al, "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", work in progress. [MART-SIG] Martini, L., et al, "Transport of Layer 2 Frames Over MPLS", work in progress. [VPLS-LDP] Kompella, V., et al, "Virtual Private Switched Network Services over an MPLS Network", work in progress. [VPLS-REQ] Augustyn et al, "Requirements for Virtual Private LAN Services (VPLS)", work in progress. K. Kompella (editor) Expires May 2002 [Page 10] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 11. Intellectual Property Considerations Juniper Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Juniper Networks, Juniper intends to disclose those patents and license them on reasonable and non-discriminatory terms. 12. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. K. Kompella (editor) Expires May 2002 [Page 11] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 13. Author Information Yeong-il,Seo Korea Telecom Telecommunication Network Laboratory Member of Technical Staff 463-1 Junmin-dong, Yusung-gu, Taejeon, Korea Tel : +82-42-870-8333 / FAX : +82-42-870-8339 Mobile : 016-235-0135 / E-mail : syi@hana.ne.kr Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Email: hbrahim@nortelnetworks.com Ashwin Moranganti Appian Communications email: amoranganti@appiancom.com phone: 978 206-7248 Pascal Menezes Terabeam Networks, Inc. 14833 NE 87th St. Redmond, WA, USA phone: (206) 686-2001 email: Pascal.Menezes@Terabeam.com Pierre Lin Yipes Communications, Inc. 114 Sansome St. San Francisco CA 94104 email: pierre.lin@yipes.com Marc Lasserre Riverstone Networks 5200 Great America Parkway Santa Clara CA 95054 marc@riverstonenet.com Sunil Khandekar TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043 Giles Heron PacketExchange Ltd. K. Kompella (editor) Expires May 2002 [Page 12] Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001 The Truman Brewery 91 Brick Lane LONDON E1 6QL United Kingdom Email: giles@packetexchange.net Loa Andersson Utfors AB Box 525, 169 29 Solna Sweden phone: +46 8 5270 5038 email: loa.andersson@utfors.se Javier Achirica Telefonica Data javier.achirica@telefonica-data.com Vach Kompella TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043 Email: vkompella@timetra.com Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 yakov@juniper.net Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 kireeti@juniper.net K. Kompella (editor) Expires May 2002 [Page 13]