PPVPN Working Group Arnold Sodder Internet Draft Tenor Networks Document: draft-sodder-ppvpn-vhls-00.txt Expires: April 2003 October 2002 Virtual Hierarchical LAN Services Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 draft describes an Ethernet [IEEE-802.3] L2VPN model that provides point-to-point and point-to-multipoint Layer 2 data communication services using a hierarchical LAN switching architecture. The model is based on a hierarchical MAC frame format. Scalability and manageability is achieved by simplifying the control plane at the cost of adding functionality to the forwarding plane. Summary for Sub-IP related Internet Drafts RELATED DOCUMENTS: See References. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This ID is intended for the PPVPN WG. Sodder Expires - April 2003 [Page 1] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 WHY IS IT TARGETED AT THIS WG(s) This document describes a method for a provider provisioned Layer 2 Ethernet VPN. JUSTIFICATION This document describes mechanisms that can be used to support an Ethernet layer two virtual private network (L2VPN). The document does not limit the mechanism to the emulation of an Ethernet wire but instead describes how an Ethernet LAN supporting point-to-point and point-to-multipoint services can be supported across a wide area network. 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 RFC-2119 [2]. Table of Contents 1. Introduction...................................................2 2. Reference Model................................................3 3. Frame Processing...............................................5 3.1 CE Frame Processing........................................6 3.2 L2PE Frame Processing......................................6 3.3 L2PE Frame Processing for frames with 802.1Q VLAN Tags.....8 3.4 PE Frame Processing........................................8 3.5 PE Frame Processing for MPLS based backbone networks.......9 Security Considerations..........................................10 References.......................................................10 Acknowledgments..................................................11 Intellectual Property Considerations.............................11 Full Copyright Statement.........................................11 Author's Addresses...............................................12 1. Introduction Service Providers require a low-cost, scalable method of providing ubiquitous data services. They have indicated that Ethernet-based services are the interface of choice to provide this service. The service must be "low-cost" in terms of the cost of operations for the Customer and Provider, and the cost of deployment for the Provider. This draft describes a "Virtual Hierarchical LAN Services" model, where each L2VPN is built upon a virtual LAN. This model Sodder Expires - April 2003 [Page 2] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 encapsulates customer frames into a hierarchical encapsulated frame such that many customer MAC addresses are represented by the combination of an L2VPN identifier and a single provider-managed MAC address. When forwarding the frame over a backbone network, each frame includes a VPN identifier as part of the frame header, thus the need for per VPN VC establishment over the backbone network is not required. The model also describes a broadcast and multicast service that limits the replication of frames in the service providers backbone network. 2. Reference Model The following network diagram shows the elements needed to support the Ethernet-based L2VPN service. The reference model presents three logical functions represented by: Customer Edge (CE) devices, Layer 2 Provider Edge (L2PE) devices and Provider Edge (PE) devices. CE devices belong to a customer while the PE and L2PE devices belong to a service provider. The service provider backbone network can be based on any technology such as Bridging, MPLS, L2TP, GRE, IP in IP etc. The diagram shows customers connected to three L2VPNs represented by x, y and z. CE devices connect to L2PE devices, each of which support many L2VPNs. L2PE devices connect to PE devices that support connectivity to a backbone network. In the diagram below the Service Provider Backbone Network is demarked by the ". . .". The backbone network must be able to support point-to-point communication and point-to-multipoint communication. Sodder Expires - April 2003 [Page 3] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 +----+ . . . . . . . . . . . . |CEx1|-+ +-----+ . . +----+ +----+ +-| | +-----+ +-----+ +-|CEx4| |L2PEa|-----| | | | +-----+ | +----+ +----+ +-| | +---| PE1 | | PE2 |--| |-+ |CEy1|-+ +-----+ | +-| | | | | | +----+ +----+ | | +-----+ +-----+ |L2PEd|---|CEy2| | | . . | | +----+ | | . . | |-+ | | . . +-----+ | +----+ +----+ +-----+ | | . . +-|CEy3| |CEz1|---|L2PEb|-+ | . . +----+ +----+ +-----+ | . Service . | . Provider . | . Backbone . | . Network . +----+ | . . |CEx2|-+ | . . +----+ | +-----+ | . +-----+ +-| | | . | | +-----+ +----+ +----+ | | | . | PE3 |--|L2PEe|--|CEx5| |CEz2|-+-|L2PEc|---+ . | | +-----+ +----+ +----+ | | . +-----+ +-| | . . +----+ | +-----+ . . . . . . . . . . . . |CEx3|-+ +----+ CE devices could be hosts, Layer 2 switches or Layer 3 routers. The model REQUIRES that the link that connects the CE devices to the L2PE devices carry Ethernet Frames. Frames with and without VLAN tags [IEEE-802.1Q] are supported. A CE device can connect to many L2PE devices, however the L2PE device MUST ensure that only one of these links is active at a time, with the other links in stand-by mode. L2PE devices are Virtual Hierarchical LAN switches. Typically there are many CE devices that connect to a single L2PE device. L2PE devices provide switching and replication services for the CE devices connected to them. All L2PE interfaces MUST support the transport of Ethernet frames. L2PE devices MUST have at least one active interface that connects to the PE device. When more than one interface connects to one or more PE devices, control mechanisms MUST be used to insure that only one is active and all others are in stand-by mode. Sodder Expires - April 2003 [Page 4] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 L2PE devices are assigned a single MAC address. When an L2PE device has two uplinks to different PE devices the same MAC address is used on both links. This allows redundancy to be implemented in a manner that does not require remote ends to know about a failure. PE devices support interfaces that connect to L2PE devices and interfaces that connect to the backbone network. The interfaces that connect to L2PE devices MUST support Ethernet frames. PE devices MUST be able to address each L2PE device that it is connected to using a unique MAC address. L2PE devices MUST be able to address a single PE device. Any network topologies that prevent this are not supported. Both PE and L2PE devices must support basic Ethernet services such as the frame replication of broadcast and multicast addressed frames. In the network reference diagram above, frame replication services for customer devices CEx2 and CEx3 are provided by L2PEc. Replication services for customer devices CEy2 and CEy3 are provided by L2PEd. All other replication services are provided by PE1, PE2 or PE3. This replication hierarchy minimizes broadcast traffic on the service provider's backbone network. 3. Frame Processing The VHLS model is supported by the L2PE and PE devices. The VHLS model requires special frame formats between these VHLS devices. The frames received from CE devices are encapsulated by L2PE devices into hierarchical MAC frames that have enough information so that PE and L2PE devices can "learn" the source L2PE device of these frames. The frame must also include information that limits the replication of broadcast and multicast frames within the L2VPN. The hierarchical encapsulation frame headers used by the L2PE and PE devices are stripped before transmitting frames to the CE devices. Each L2PE device is assigned a single MAC address, which is used to uniquely identify the L2PE device within the service provider's network. In addition an L2VPN identifier is required. This identifier is used to determine frame handling characteristics, such as broadcast scope, that is particular to the L2VPN. The VHLS model defines a new Ethernet type to support the definition of a VHLS L2VPN identifier and control word (VHLS-ICW). The value of the Ethernet type is TBD and is referred to as VHLS-ICW. The VHLS- ICW is a 32-bit field as described below: Sodder Expires - April 2003 [Page 5] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-----------------------------------------------+ |O|r|r|r|r|Q|Q|Q| 24-bit L2VPN identifier | +-+-+-+-+-+-+-+-+-----------------------------------------------+ The first 8-bits define a VHLS Control Field. The next 24-bits define a VHLS L2VPN identifier that is administered by the Service Provider. This L2VPN identifier is used to separate data between customers, and is globally unique for a service provider's network. The VHLS L2VPN identifiers 0 and 16777215 are reserved. Bit 0 of the 8-bit Control Field (O) is defined as an OAM indicator. Bits 1 through 4 (r) are reserved. Bits 5 through 7 (Q) define the QOS field. The use of the QOS field is dependent on the architecture of the service provider network. Details of the OAM indicator are TBD and must be currently set to zero. All reserved bits must be set to zero. 3.1 CE Frame Processing This model does not require that the CE devices perform any special frame processing in addition to that provided by a typical device attached to an Ethernet LAN. The following frame formats are supported: +-------+-------+-----+-------------------------------------+-------+ | MACDA | MACSA | T/L | Information | CRC32 | +-------+-------+-----+-------------------------------------+-------+ +-------+-------+----+------+-----+-------------------------+-------+ | MACDA | MACSA |8100| VLAN | T/L | Information | CRC32 | +-------+-------+----+------+-----+-------------------------+-------+ These frames are received and transmitted by the L2PE devices on CE facing interfaces and processed as described below. 3.2 L2PE Frame Processing All frames received or transmitted over L2PE to PE interfaces are encapsulated by the L2PE device within a hierarchical MAC frame as described below. Sodder Expires - April 2003 [Page 6] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 +---------+---------+----------+--------+---------------------+-----+ |BCST-ADDR| L2PE-SA |VHLS-ETYPE|VHLS-ICW| CE Frame |CRC32| +---------+---------+----------+--------+---------------------+-----+ +---------+---------+----------+--------+---------------------+-----+ | L2PE-DA | L2PE-SA |VHLS-ETYPE|VHLS-ICW| CE Frame |CRC32| +---------+---------+----------+--------+---------------------+-----+ The first frame, which uses a broadcast MAC address (BCST-ADDR,) is used when the CE frame contains a MAC destination address that is unknown. After a learning process, L2PE devices will map the CE MACDA to a L2PE-DA so using the second frame format. In the above frame formats the CE frame MUST include the original CRC32 to allow detection of bit errors introduced by devices in the service provider network or attached to the service provider network. If the L2PE device needs to modify the CE frame it MUST calculate and add a new CRC32 to the CE frame. The L2PE supports a MAC address table per L2VPN defined. When transmitting a CE frame to a PE device, the L2PE-SA in the frame is the MAC address of the transmitting L2PE device. The L2PE must learn the addresses of remote L2PE devices and map these to the CE MAC addresses within the L2VPN. The L2PE device supports a forwarding data base. The data base is keyed using the CE MACDA and the L2VPN identifier. The data for each keyed entry that belongs to a CE connected interface contains the identity of the CE interface. The data for each keyed entry that belongs to a L2PE interface contains the L2PE-DA MAC address. The L2PE MUST use the configured L2VPN identifier for this interface and perform a lookup of the CE MACDA within the L2VPN forwarding table for the received frame. If the MACDA is unknown the frame is forwarded using an L2PE MACDA of FF-FF-FF-FF-FF-FF to all interfaces that belong to the L2VPN. If the MACDA is known it is forwarded to the appropriate interface. In both cases the interface could be a CE interface or a PE interface, also the appropriate frame format must be used. When forwarding frames to a PE interface it uses the hierarchical frame format. The MACDA in the hierarchical Ethernet header is the learnt L2PE-MACDA or the L2PE-BCST MAC address. The MACSA is the MAC address assigned to the L2PE device. The Ethernet type is set to VHLS-ETYPE and the next 4 bytes are the VHLS-ICW field. The Q bits in the VHLS-ICM field depend on the QOS architecture in use. The information field in this MAC frame is the CE MAC frame. Sodder Expires - April 2003 [Page 7] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 The L2PE will also perform a lookup using the CE MACSA and the configured L2VPN identifier within the L2VPN forwarding table. This is required to learn the source of the CE frame. On receiving frames from the connected PE device, the L2PE will use the CE MACDA and the L2VPN identifier in the received frame to perform a lookup within the forwarding table. If the lookup returns a CE interface as the destination, the CE frame is forwarded to this interface. If the lookup returns a network-facing interface the frame is dropped. If the lookup results in a failure, the CE frame is flooded to all CE interfaces that support traffic to the particular L2VPN. The L2PE will also perform the learning function on the CE MACSA and map it to the L2PE MAC address and L2VPN identifier as learnt from the received frame. The L2PE device performs "aging" on all MAC addresses learnt. 3.3 L2PE Frame Processing for frames with 802.1Q VLAN Tags When L2PE devices are connected to CE devices that support VLAN tags in a non-transparent manner, they must be configured as such and each VLAN tag must be assigned to a unique L2VPN identifier. This ensures that the PE devices can perform forwarding and control functions for both types of Ethernet frames in a similar and consistent manner. 3.4 PE Frame Processing PE devices support the following frame processing methods depending from which interface the frame is received, and the type of frame received. Frames received from PE devices over the backbone network MUST be forwarded to L2PE devices. Frames received from L2PE devices can be forwarded to other L2PE devices and/or remotely connected PE devices using the backbone network. PE frame processing assumes that the service provider's backbone network architecture supports point-to-point and multipoint frame processing. The backbone network architecture must support the ability to link a tunnel in one direction between end-points to a tunnel in another direction between the same end-points so that learning in one direction can be used to forward data in the reverse direction. The PE device is responsible for providing replication services. The L2VPN topology is used to determine the destinations to which broadcast frames must be replicated. PE devices receiving broadcast frames on backbone interfaces will not forward these frames to other PE devices. Sodder Expires - April 2003 [Page 8] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 PE devices maintain a forwarding database that have two types of keys. The first key is used for frames received from backbone interfaces and depends on the architecture of the backbone network. The data associated with this key typically will include information that results in the PE performing an additional lookup based on the second key. The second key is made up of the L2PE-DA address and the L2VPN identifier received in the frame. Frame processing details of the first key is dependent on the backbone network architecture and is thus beyond the scope of this draft, in fact in some architectures it may not be required. The PE device processes frames received from L2PE devices in two different ways depending on the received MACDA in the frame. If the L2PE-MACDA is a Unicast MACDA then it MUST be a known MACDA. If it is unknown the frame is dropped. Known L2PE-MACDA frames are forwarded based on the lookup result. If the frame is forwarded to a backbone interface it is encapsulated if required based on the backbone network architecture. If the frame is forwarded on an L2PE facing interface no additional encapsulation is required. When the received L2PE-MACDA in the frame is a broadcast MAC address the PE device must replicate this frame to all L2PE devices that support connectivity for the L2VPN defined in the VHLS-ICW. Frames received from backbone network interfaces should not be forwarded to other backbone network interfaces. When receiving frames the PE device will perform a lookup of the L2PE-SA address and the L2VPN identifier in order to learn the source interface of the frame. 3.5 PE Frame Processing for MPLS based backbone networks The frame format for an MPLS [MPLS-ARCH] based Service Provider Backbone network is replicated below for completeness. +--------------+------------+----------------+----------------+-----+ |MPLS-L2-header|tunnel-label|L2PE-enet-header| CE Frame |CRC32| +--------------+------------+----------------+----------------+-----+ The format of the MPLS-L2-header [MPLS-ENCAPS] is specific to the protocol used in the PE uplink. The tunnel-label is an LSP label that has been signaled using RSVP-TE [RSVP-MPLS-TE] or any other MPLS signaling protocol in use by the service provider backbone network. The L2PE-enet-header is the L2PE-MACDA, L2PE-MACSA, VHLS-ETYPE and VHLS-ICW. The information field is the original CE frame including Sodder Expires - April 2003 [Page 9] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 its CRC32. The Ethernet CRC32 added by the L2PE device is replaced by the CRC32 used by the tunneling protocol. When using MPLS for the tunneling protocol, the QOS bits in the VHLS L2VPN field are mapped to and from the EXP bits in the E-LSP tunnels as recommended in [MPLS-DIFFSERV]. Security Considerations The security aspects of this model will be discussed at a later time. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [MPLS-DIFFSERV] F. Le Faucheur et al, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002 [RSVP-MPLS-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [PWE3-ENET] "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", Martini, L., et al., draft-ietf-pwe3- ethernet-encap-00.txt, (work in progress), August 2002 [IEEE-802.1Q] "IEEE Standards for Local and Bridged Metropolitan Area Networks, Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 1998 Edition. [IEEE-802.1D] "IEEE Standards, Part 3: Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D, 1998 Edition. Sodder Expires - April 2003 [Page 10] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 [IEEE-802.3] "Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std 802.3, 2000 Edition. Acknowledgments The author would like to thank Tim Mancour and Louie DiDiodato who first presented the idea of using a MAC address to identify an L2PE device. The author would also like to thank many others at Tenor that provided valuable comments. Intellectual Property Considerations Tenor Networks may seek patent or other intellectual property protection for some or 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 Tenor Networks, Tenor Networks intends to disclose those patents and license them on reasonable and non-discriminatory terms. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 Sodder Expires - April 2003 [Page 11] Internet Draft draft-sodder-ppvpn-vhls-00.txt October 2002 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. Author's Addresses Arnold Sodder Tenor Networks, Inc. 100 Nagog Park Acton, MA 01720 Phone: 978-264-4900 Email: asodder@tenornetworks.com Sodder Expires - April 2003 [Page 12]