PPVPN Working Group Arnold Sodder Internet Draft Tenor Networks K.K. Ramakrishnan Charles Kalmanek AT&T Labs-Research Christopher N. DelRegno Scott Kotrla WorldCom Document: draft-sodder-ppvpn-vhls-01.txt Expires: May 2003 November 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 MAC-in-MAC frame format. Scalability and manageability is achieved by simplifying the control plane at the cost of adding functionality to the forwarding plane. Sodder Expires - May 2003 [Page 1] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 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. 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...................................................3 2. Reference Model................................................4 3. Backbone Network...............................................5 3.1 LDP Based Signaling........................................6 3.2 QOS........................................................7 4. Frame Processing...............................................8 4.1 CE Frame Processing........................................9 4.2 L2PE Frame Processing......................................9 4.3 L2PE Frame Processing for frames with 802.1Q VLAN Tags....11 4.4 PE Frame Processing.......................................11 4.5 PE Frame Processing for MPLS based backbone networks......12 Security Considerations..........................................12 References.......................................................13 Acknowledgments..................................................14 Intellectual Property Considerations.............................14 Full Copyright Statement.........................................14 Author's Addresses...............................................14 Sodder Expires - May 2003 [Page 2] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 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. In this model an Ethernet L2VPN is supported by building the network using a hierarchical architecture. At the lowest level of hierarchy, customer edge devices (CE) communicate with service provider devices (L2PE) using standard Ethernet frames. This is also the service demark point. The second level of hierarchy is added by the service provider device (L2PE) which encapsulates the customer frame with an additional MAC header. As part of this additional MAC header a VPN identifier is also added to the frame encapsulation. This encapsulated frame can then be forwarded over a backbone network by a provider edge device (PE). In its simplest form the backbone network can be an Ethernet bridge. The backbone network can also be based on an MPLS architecture, made up of a mesh of pseudo wires that connect the set of provider edge devices in a split horizon manner. The pseudo wires can be MPLS tunnels or VC labels as defined in [PWE3-CTRL]. Since each frame includes the VPN identifier a fully connected mesh of VC's must be established to all PE devices. Per VPN per PE VC establishment over the backbone network is not required. Thus the hierarchical approach provides the following advantage: 1) Many customer MAC addresses are represented by the combination of an L2VPN identifier and a single provider-managed MAC address. This reduces the number of MAC addresses that need to be managed by the core network devices. 2) Simplification of the core network operation by reducing the number of pseudo-wires required for the L2VPN service. The model also describes a broadcast and multicast service that limits the replication of frames in the service providers backbone network. This draft describes extensions to [PWE3-CTRL] to support the setup of the VC mesh between the PE devices. Sodder Expires - May 2003 [Page 3] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 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 at a minimum. Support for point-to-multipoint communication is desirable but not required. +----+ . . . . . . . . . . . . |CEx1|-+ +-----+ . . +----+ +----+ +-| | +-----+ +-----+ +-|CEx4| |L2PEa|-----| | | | +-----+ | +----+ +----+ +-| | +---| PE1 | | PE2 |--| |-+ |CEy1|-+ +-----+ | +-| | | | | | +----+ +----+ | | +-----+ +-----+ |L2PEd|---|CEy2| | | . . | | +----+ | | . . | |-+ | | . . +-----+ | +----+ +----+ +-----+ | | . . +-|CEy3| |CEz1|---|L2PEb|-+ | . . +----+ +----+ +-----+ | . Service . | . Provider . | . Backbone . | . Network . +----+ | . . |CEx2|-+ | . . +----+ | +-----+ | . +-----+ +-| | | . | | +-----+ +----+ +----+ | | | . | PE3 |--|L2PEe|--|CEx5| |CEz2|-+-|L2PEc|---+ . | | +-----+ +----+ +----+ | | . +-----+ +-| | . . +----+ | +-----+ . . . . . . . . . . . . |CEx3|-+ +----+ Sodder Expires - May 2003 [Page 4] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 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. 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. Backbone Network The draft describes requirements for an MPLS based backbone network. As earlier mentioned other backbone architectures are also supported Sodder Expires - May 2003 [Page 5] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 and details of these architectures will be described in a later version of this draft. The L2VPN backbone network is configured by defining the VPNs that are supported by each PE device. The PE device then uses an auto- discover procedure to determine the other PE devices in the backbone network that it must communicate with. Many of these methods are already discussed in the PPVPN working group, however details will be provided in a later revision of this draft. 3.1 LDP Based Signaling In order to establish a full mesh of pseudo-wires, all PEs in an L2VPN network must have a full mesh of LDP sessions. Once an LDP session has been formed between two PEs, pseudo-wires are signaled over this session. In [PWE3-CTRL], the L2 VPN information is carried in a Label Mapping message sent in downstream unsolicited mode, which contains the following VC FEC TLV. VC TLV, C, VC Info Length, Group ID, VC-ID and Interface parameters are as defined in [PWE3-CTRL]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC TLV |C| VC Type |VC Info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document defines a new VC type value in addition to the following values already defined: VC Type Description 0x0001 Frame Relay DLCI 0x0002 ATM AAL5 VCC transport 0x0003 ATM transparent cell transport 0x0004 Ethernet VLAN 0x0005 Ethernet 0x0006 HDLC 0x0007 PPP Sodder Expires - May 2003 [Page 6] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 0x8008 CEM [8] 0x0009 ATM VCC cell transport 0x000A ATM VPC cell transport 0x000B Ethernet VPLS 0x000C IP L2 Interworking 0x000D IPLS 0x000E Ethernet VHLS VC types 0x0004 and 0x0005 identify VC LSPs that carry VLAN tagged and untagged Ethernet traffic respectively, for point-to-point connectivity. We define a new VC type, Ethernet VHLS, with code-point 0x000E to identify VC LSPs that carry Ethernet traffic for multipoint connectivity. For VC types 0x0001 to 0x000A, the VC ID identifies a particular VC. For the VHLS VC type, the VC ID identifies a particular pseudo-wire (VC-LSP) that supports the VHLS application. Note the contrast between VPLS, as defined in [VPLS], and VHLS in how the VC-ID is interpreted. In VPLS the VC-ID identifies the VPLS instance while in VHLS the VC-ID identifies the VHLS service. The VHLS instance is derived from the VPN identifier present in the VHLS header of the data packet. This distinction is key in reducing the number of pseudo-wires required for the multi-point Ethernet service. When setting up LSPs the PE device must connect to Npe(vpn) PE devices that support the particular VPN. In VPLS the number of pseudo-wires required for a PE device is (Npe(vpn1) - 1) + (Npe(vpn2) - 1) + ... (Npe(vpnm) - 1) for m number of VPNs that this particular PE device supports. In VHLS the number of pseudo-wires required per PE device is (Npe - 1), where Npe is the number of PE devices that support the common VPNs supported by the connected PE devices. Thus the VHLS model simplifies the signaling overhead and management of pseudo-wires. 3.2 QOS It is desirable to offer multi-tiered QOS as part of the L2VPN service. It is especially useful to provide preferential treatment of control frames such as OAM and Spanning Tree Bridge PDUs at each intermediary node as well as within the core network. In some cases a service provider may want an altogether different path to carry certain packets, for example broadcast data. In all such cases, a different set of pseudo-wires is required to be signaled over the new LSP tunnel. The VHLS architecture offers a more scalable solution than the VPLS architecture when additional pseudo-wires are needed. In VHLS, a PE Sodder Expires - May 2003 [Page 7] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 node may signal a pseudo-wire to carry broadcasts of all VPNs as compared to VPLS where a PE node must signal a separate pseudo-wire to carry broadcast data for each VPN. 4. Frame Processing The following sections describe the frame encapsulations used by the VHLS model and how each intermediary device process such encapsulated frames for database maintenance and frame forwarding functions. 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 (VIC). The value of the Ethernet type is TBD and is referred to as VHLS ether-type (VET). The VIC is a 32-bit field as described below: 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|C|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. Bit 1 is defined as a CRC indicator. Bits 2 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 Sodder Expires - May 2003 [Page 8] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 network. Details of the OAM indicator are TBD and the bit must be currently set to zero. Details of the CRC indicator are described in section 4.2. All reserved bits must be set to zero. 4.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. 4.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. +---------+---------+-----+-----+-----------------------------+-----+ |BCST-ADDR| L2PE-SA | VET | VIC | CE Frame |CRC32| +---------+---------+-----+-----+-----------------------------+-----+ +---------+---------+-----+-----+-----------------------------+-----+ | L2PE-DA | L2PE-SA | VET | VIC | 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 SHOULD include the original CRC32 to allow detection of bit errors introduced by devices in the service provider network or devices attached to the service provider network. When the CRC32 of the CE frame is included the CRC indicator bit in the VIC must be set. If the L2PE device needs to Sodder Expires - May 2003 [Page 9] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 modify the CE frame it MAY calculate and add a new CRC32 to the CE frame or it MAY strip the CRC32 of the CE frame and clear the CRC indicator bit in the VIC. The L2PE maintains 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 VET and the next 4 bytes are the VIC field. The Q bits in the VIC field depend on the QOS architecture in use. The information field in this MAC frame is the CE MAC frame. 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. Sodder Expires - May 2003 [Page 10] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 4.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. 4.4 PE Frame Processing PE devices support the following frame processing methods depending on 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 the reverse 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. 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 Sodder Expires - May 2003 [Page 11] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 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 VIC. 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. 4.5 PE Frame Processing for MPLS based backbone networks The frame format for an MPLS [MPLS-ARCH] based Service Provider Backbone network is as defined in [PWE3-ENET] and is replicated below for completeness. +--------------+------------+----------------+----------------+-----+ |MPLS-L2-header|PWE3-Header |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 PWE3-Header includes a tunnel-label, 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 PWE3- Header also includes a VC-Label that is signaled using the extensions to [PWE3-CTRL] as specified earlier in this draft. The L2PE-enet- header is the L2PE-MACDA, L2PE-MACSA, VET and VIC. The information field is the original CE frame. 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. Sodder Expires - May 2003 [Page 12] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 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] Martini, L., et al., "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", draft-ietf-pwe3- ethernet-encap-00.txt, (work in progress), August 2002 [PWE3-CTRL] Martini, L. et al., "Transport of Layer 2 Frames Over MPLS", draft-ietf-pwe3-control-protocol-00.txt, (work in progress), August 2002 [VPLS] Lasserre, Kompella et al., "Virtual Private LAN Services over MPLS", draft-lasserre-vkompella-ppvpn-vpls-02.txt, (work in progress), June 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. [IEEE-802.3] "Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std 802.3, 2000 Edition. Sodder Expires - May 2003 [Page 13] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 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 Himanshu Shah and 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 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 Sodder Expires - May 2003 [Page 14] Internet Draft draft-sodder-ppvpn-vhls-01.txt November 2002 Arnold Sodder Tenor Networks, Inc. 100 Nagog Park Acton, MA 01720 Phone: 978-264-4900 Email: asodder@tenornetworks.com K.K. Ramakrishnan AT&T Labs-Research, Room A117 180 Park Avenue Florham Park, NJ 07932 Phone: 973-360-8764 Email: kkrama@research.att.com Charles Kalmanek AT&T Labs-Research 180 Park Avenue Florham Park, NJ 07932 Phone: 973-360-???? Email: crk@research.att.com Christopher N. DelRegno WorldCom, Global Access Technology Development 400 International Pkwy, 1010/041 Richardson, TX 75081-2886 Phone: 972-729-3411 Email: Nick.DelRegno@wcom.com Scott Kotrla WorldCom, Global Access Technology Development 400 International Pkwy, 1010/041 Richardson, TX 75081-2886 Phone: 972-729-3407 Email: scott.kotrla@wcom.com Sodder Expires - May 2003 [Page 15]