Internet Engineering Task Force CY Lee INTERNET DRAFT S Cirkovic Informational March 2003 Hybrid Virtual Private LAN Service 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. Abstract This draft describes a solution to enable an emulated LAN Service or Virtual Private LAN Service (VPLS) by decoupling the bridging and tunneling of Ethernet traffic into Customer Located Equipment (CLE) or Customer Edge (CE) and Provider Edge (PE), respectively. This decoupling of functions allows an operator to provision point-to- point transport of Ethernet services for customer on PEs, while leveraging bridging functions at CLEs to forward traffic towards the appropriate point-to-point Ethernet service leading to the destination node. This decoupling of functions also allow providers to leverage existing network infrastructures to enable VPLS while easing migration to new network infrastructures. This approach scales as the number of customers and sites increases, and as customers' emulated LAN sites span over a large wide area network. It is also the intention to show that an interface like Ethernet can be offered to customers and emulated LAN services can be enabled, but it is not mandatory to introduce VLAN like technologies (or PE-based type of Expires Sept 2003 Informational [Page 1] Internet Draft Hybrid VPLS March 2003 VPLS) in the provider's network. In addition, existing and heterogeneous access technologies can be supported in a common network infrastructure. Abbreviations AC Attachment Circuit [L2VPN-FW] CE Customer Edge CLE Customer Located Equipment DLCI Data Link Connection Identifier FR Frame Relay p2p point-to-point PE Provider Edge PSN Packet Switched Network PW Pseudo-Wire VPL Virtual Private LAN 1. Introduction This draft describes a solution to enable Virtual Private LAN Service (VPLS) by decoupling the bridging and tunneling of Ethernet traffic into CLEs/CLEs and PEs, respectively. This decoupling of functions allows an operator to provision point to point transport of Ethernet services for customer on PEs, while leveraging bridging functions at CLE to figure out which point to point Ethernet connection to forward Ethernet traffic (destined to a node in a VPL) to. In the case where the CEs are routers, the proposal also allows a CE with point-to-point links such as Frame Relay or ATM access to appear as a node on the emulated LAN, thereby allowing a CE to peer with other CE routers as if it is connected to the same LAN as the other CE routers. Only one DLCI is required at a CE router with Frame Relay access to allow it to peer with other CE routers. In the case where the CEs are bridges, a CE with FR access shall be visible to other CE bridges of the emulated LAN. The implication of decoupling the bridging and tunneling of Ethernet traffic is a PE need not learn and store customers' Ethernet addresses and switch customers' Ethernet traffic (as in PE-based solutions such as [VPLS]), and on the other hand, a CLE need not be configured with addresses of other CLEs to enable the CLE to tunnel traffic to other CLEs of a VPL (as in a CE-based VPL [CE-VPL]). 2. Reference Model The following diagram show a Hybrid VPLS reference model, PE devices transporting customer's traffic over PWs and CLE devices bridging traffic over the PWs. A CE and CLE may be collapsed in one device. Expires Sept 2003 Informational [Page 2] Internet Draft Hybrid VPLS March 2003 CLE1, CLE2 and CLE3 belong to one VPLS instance. A PE, PE2 maps an attachment circuit AC2a to a PW setup between PE2 and PE1, to transport frames received on AC2a to CLE1 via the single attachment circuit of PE1 to CLE1. Similarly, PE2 maps AC2b to another PW setup between PE2 and PE3, which in turn is mapped to the single attachment circuit of PE3 to CE3. A Hybrid VPLS can contain a single IEEE [802.1q] VLAN or multiple VLANs. PEs are concerned with switching p2p Ethernet PWs. CLEs bridge traffic over different attachment circuits. The attachment circuits may be on different physical interface or/and multiplex over a physical interface. If the Ethernet traffic is encapsulated or tagged over the attachment circuit, the encapsulation or tagging should be terminated at the PE. The PE encapsulates the Ethernet frame in a p2p PW to a remote PE. The remote PE decapsulates the Ethernet frame as specified for PW and send it out the appropriate attachment circuit (encapsulating or tagging the Ethernet frame as required). If attachment circuits are multiplexed over a physical interface, service multiplexing may use : a) VLAN tag b) Stacked VLAN tag c) MPLS VC label (FFS) Expires Sept 2003 Informational [Page 3] Internet Draft Hybrid VPLS March 2003 In the example below, since there is no service multiplexing from CLE1, traffic from CLE1 whether tagged or untagged is not of concern to PE1. PE1 simply maps it to one PW. Similarly for traffic from CE3. On CLE2, there is service multiplexing (i.e. more than one ACs). If the customer's (CE) traffic is already VLAN tagged then Stacked VLAN tagged should be used to multiplex the different ACs at CLE2. If the customer's traffic is not already VLAN tagged, then VLAN tagged may be used instead by CLE2. The tagged traffic from CLE2 is mapped to the appropriate PWs, setup towards remote sites. CLE2 performs the bridging of traffic across the different ACs. The next section outlines a pragmatic migration strategy for CLE2. ................................................... . . . . . +-----+ +-----+ . CE1----+ CLE1+--+ |CLE2 |----CE2 . +-----+ | <---EthoPSN PW-----> +-----+ . . | +----+ +----+ AC2a| | . . | | | | |------+ | . . +--| PE1|--Routed---| PE2|--------+ . . +----+ Backbone +----+ AC2b . . | ^ . . | |EthoPSN . . | |PW . . +----+ | . . | |<------+ . . | PE3| . . +----+ . . | . . | . . | . . | . . | . .......................|........................... | Emulated LAN CE3 Figure 1 Expires Sept 2003 Informational [Page 4] Internet Draft Hybrid VPLS March 2003 CLE1 PE1 PE2 CLE2 +-----------+ +------+ +------+ +-----------+ |\ /| | | | | |\ /| | \ Relay / | | | | | | \ Relay / | | \ / | | | | | | \ / | | \ / | | | | | | \ / | | \ / | | | | | | \ / | | V | | | | | | V | | MAC | MAC | | E| |E | | VP | MAC | +--+--+--+--+ +------+ +------+ +--+--+--+--+ | | | | | | | |LAN | | | | | | | |port | | | | PSN | | | | | +----------+ +------------+ +----------+ | | AC |<-----PW------>| AC | | | | | ...|........................................................|.... . | | . . | | . ...|........................................................|.... | Emulated LAN | | | Figure 2 The above figure shows an AC on CLE2 as a Virtual Port(VP) of CLE2. An AC is service multiplexed over the access link (CLE-PE), as described before. The Encapsulation (E) Entity, is responsible for encapsulating frames to be transported over the PSN. The Virtual Port (VP) provides MAC service support similar to the MAC entity. The Internal Sublayer Service (ISS) and Enhanced Internal Sublayer Service (E-ISS), i.e. the indication and request primitives provided by a MAC entity to the MAC Relay Entity within a CLE is as defined in 802.1d and 802.1q. The Relay is a bridge as defined in 802.1d and optionally 802.1q (the use of a modified bridge is described below). CLEs process BPDUs, as defined in 802.1d and optionally 802.1q, and MAC control frames as defined in IEEE specifications. If a modified bridge (performing reverse split horizon forwarding on a full-meshed of PWs, I.e. traffic received on a PW is not forwarded to other PWs) is used, the modified bridge would reside between the Relay and the VP. The use of a modified bridge in a CLE is being reviewed. [Note: Peering CE routers over an emulated LAN using a Expires Sept 2003 Informational [Page 5] Internet Draft Hybrid VPLS March 2003 full-meshed of PWs and reverse split horizon forwarding may introduced the following issues. For instance, if a PW between Router A and Router C is down, Router A can see Router B and Router B can see Router C, and vice-versa, but Router A cannot see Router C (and vice-versa), and this may affect the operation of routing protocols (and bridging as well). In contrast, when using 802.1d bridging, and a tree is partitioned, if Router A cannot see Router C, neither can Router B. The problem with using a modified bridge could be reduced by using protected PWs or tunnels.] 2.2 Pragmatic migration steps for CLE2 In the case where a CLE is not capable of bridging to the different ACs (VLAN tags), a CLE which maps customer's Ethernet traffic coming from different ports to different VLAN tags (corresponding to remote CEs) may be used. For e.g. : customer's +-----+ traffic | | -----CE--------| | VLAN/Stacked VLAN tagged traffic | | | | | +-------| CLE |---------------- to provider's network | | | +---------| | | | +-----+ Figure 3 CE may be a bridge with multiple ports. The number of remote CEs that can be connected shall be limited by the number of ports available on the CE and CLE. In this example, the CE bridges traffic to different remote CEs, the CLE merely tags traffic coming in from the different ports. 2.3 Major technical differences from PE-based VPLS or Provider Bridges [802.1ad] - PEs or Ps are not bridging customers' (internal) MAC addresses - one level of Spanning Tree - a CLE processes the customer's BPDUs 3. Deployment Scenarios 3.1 Point-to-Point Ethernet Service The provider provides and provision point-to-point Ethernet service between CEs. [Note: CEs and CLEs functions described above may be Expires Sept 2003 Informational [Page 6] Internet Draft Hybrid VPLS March 2003 collapsed into CE devices]. The different sites requiring the service are specified by customers. Both ends of the PW may be connected to CEs with Ethernet access or one end of the PW may be connected to a CE with Ethernet access and the other end the PW may be connected to a CE with FR/ATM access. The former PW is referred to as a homogeneous p2p Ethernet PW, while the latter is referred to as a heterogeneous p2p Ethernet PW. [A special heterogeneous p2p PW with IP payload is described later]. In both cases, at the ingress PE, the service multiplexing tag or encapsulation of an Ethernet frame is removed, the Ethernet frame is encapsulated at the ingress PE using the appropriate tunneling technology, decapsulated at the egress, the Ethernet frame is tagged or encapsulated, and forwarded to the appropriate AC. The customer provisions the number of remote CEs, and the set of multiplexing IDs (e.g. VLAN ID/DLCI) to be used. To reduce provisioning, a provider and the customer may agree apriori the set of multiplexing IDs range to be used for the p2p services. The Section "Discovery" below, describes different means for a provider to reduce the provisioning required by the provider and the customer. The customer manages the bridging aspects of the emulated LAN on CEs, while the provider manages the point-to-point Ethernet service. 3.2 Emulated LAN Service The provider provides Emulated LAN service. P2P Ethernet service (both homogeneous and heterogeneous) is provisioned in the provider network. CLEs perform the bridging among different sites. The provider pre-provisions the set of multiplexing IDs (e.g VLAN ID/DLCI) that can be used for the p2p Ethernet service. The Section "Discovery" below describes different ways to reduce provisioning on CLEs and PEs. The number of remote CLEs to connect to at each CLE may be updated by the provider using an out-of-band method or using an LMI method. 3.3 Point-to-Point Heterogeneous PW with IP Payload This service transport IP packets from an access link such as Frame Relay or ATM, over the PSN, to an Ethernet access link. This service is further described in the sections below. 3.4 Router Peering Service Expires Sept 2003 Informational [Page 7] Internet Draft Hybrid VPLS March 2003 A provider may offer part of the service which enables CE routers to peer : i) over an emulated LAN ii) with other CE routers on different "subnets" iii) with routers connected to different access links (e.g. a CE router may be connected to Ethernet and peers with another router connected to to Frame Relay (FR)) (i) is the basic service described in the Reference Model. (iii) is described below. (ii) is not within the scope of this draft (as it is not related to emulated LAN) Expires Sept 2003 Informational [Page 8] Internet Draft Hybrid VPLS March 2003 3.4.1 Peering CEs with heterogeneous access links over an emulated LAN In some L2VPN deployment, a customer may have some sites with Ethernet access and some with FR interfaces to the provider. For e.g. in the figure below, a CE4 with an FR access is connected to PE3. If the CEs are routers, CE1, CE2 and CE3 may peer over the emulated LAN - discovering the IP addresses of each via a routing protocol and the corresponding MAC addresses using ARP over the emulated LAN. .................................................... . . . . Eth +-----+ Eth +------+ Eth CE1-----+ CLE1+--+ | CLE2 |-----CE2 . +-----+ | <----EthoPSN-----> +------+ . . | +----+ +----+ | | |Eth. . | | | | |-AC2a-+ | | . . +--| PE1|----PSN----| PE2|-AC2b---+ | . . +----+ Backbone +----+-AC2c-----+ . . | ^ ^ . . | EthoPSN| |IPoPSN . . | | | . . +----+ | | . . | |<-----+ | . . | PE3|<-------+ . . +----+ . . | | . . Eth| +------+ . . +-----+ | . . | CLE3| | . . +-----+ | . . Eth| |FR . ......................|........|.................... | | Broadcast network CE3 CE4 Figure 4 - Peering CE Routers over a Broadcast network In the above example, it would be useful to allow a CE4 with FR access to the provider to peer with the other routers (CE1,CE2,CE3) in the (emulated) LAN. All IP multicast/broadcast traffic on emulated LAN will be transported to the CE router with FR access. All IP multicast/broadcast traffic from CE4 will be seen on the emulated LAN. Essentially, CE4 appears as a station/node on a LAN to other CE routers. Although CE4 has an FR access link, CE4 is able discover Expires Sept 2003 Informational [Page 9] Internet Draft Hybrid VPLS March 2003 other routers on the emulated LAN if the OSPF Interace Type of the FR link is set to broadcast type. Note that CE4 is a router and need not have bridging functions. From the L2 perspective, CE1, CE2 and CE3 see a (emulated) LAN and CE4 has a FR access link. From the IP layer perspective in CE1, CE2, CE3 and CE4, all these CE routers appear to be connected on a broadcast network, and hence all the routers can peer with each other. 3.4.1.1 Heterogeneous PW with IP payload To allow a CE with FR interface to peer with other routers on an emulated LAN, a mechanism which allows IP packets to be transported from an FR interface to an Ethernet interface is required, called a heterogeneous PW with IP payload. [ARP-MEDIATION] describes the interworking procedures between CEs using different address learning techniques, for instance, one using ARP on Ethernet and the other using Inverse ARP on Frame Relay. In this proposal, a CE with FR interface is allowed to peer and discover other routers on an emulated LAN, and CEs on the emulated LAN can discover a CE with FR interface as if it is on the same LAN. The features offered by this proposal are : - many routers with FR links could peer on a broadcast network (instead of configuring meshed of p2p links on different subnets, which requires more configuration on the CE routers) - using a broadcast network to peer routers reduces the number of adjacencies required. This in turn reduces the amount of routing protocol traffic and the size of the link-state database - on a CE, only one FR DLCI is required, to peer with other routers on the broadcast network. The heterogeneous PW service, transports IP traffic to a CLE performing bridging for the emulated LAN, CLE2 in the above example. CLE3 has a VLAN tag (or stacked VLAN tag) assigned for this heterogeneous PW service. CE4 has a DLCI assigned for this heterogeneous PW. When the IP traffic encapsulated over FR is received at PE3, PE3 decapsulates the frame, and tunnel the IP packet over the PSN as described for the appropriate tunneling technology. Since both ends use different link layer technology, it is not useful to include the link layer header and the heterogeneous PW is concerned with tunneling higher layer, i.e. IP traffic, only the IP packet is transported over the PSN. When PE2 receives a frame over the heterogeneous PW, PE2 decapsulates the frame, to obtain the IP packet. PE2 knows the AC it should forward packets to, i.e. AC2c and the service multiplexing ID Expires Sept 2003 Informational [Page 10] Internet Draft Hybrid VPLS March 2003 (VLAN/Stacked VLAN tag) to use. The IP destination address of the packet is known, but the corresponding link layer or MAC address is not known. The next section describes how the MAC address is resolved. 3.4.1.2 Resolving the link layer/MAC address for a node connected to Ethernet Note that for a homogeneous Ethernet PW, the link layer technology is the same at both ends of the PW. The link layer header is transported from ingress to egress. When the egress decapsulates the frame, it forwards the frame to the appropriate AC. Since the MAC destination address is known, the frame can be delivered to its destination. With heterogeneous PW, the MAC destination address corresponding to the IP address is not available at the egress, since only the IP packet is transported. A functional element, to figure out the corresponding link layer address (MAC address) of the IP address is required. If the IP packet is multicast, the corresponding MAC address can be derived from the IP multicast address. A reserved (broadcast) MAC address corresponds to the IP broadcast address. This function is referred to as IP multicast to MAC address derivation. If the IP packet is unicast, a functional element called Proxy ARP client, finds out about the corresponding MAC address via ARP. The Proxy ARP client (and IP multicast to MAC address) functions may be located at PE2 or CLE2. Each CE with FR/ATM access is assigned a unique virtual MAC address and this address may be provisioned on the Proxy ARP Client for the CE. 3.4.1.2.1 Proxy ARP Client at PE If the MAC address corresponding to the IP destination of the packet decapsulated at PE2 is already resolved, PE2 may append an Ethernet header to the packet and forward it over AC2c. Otherwise, PE2 shall send an ARP for the MAC address of the IP destination address over AC2c. The ARP message is tagged appropriately for AC2c and is broadcasted on the emulated LAN. When PE2 receives an ARP response from the corresponding IP node, PE2 caches the MAC address learn for the IP address in a table. PE2 now knows the MAC DA (Destination Address) to use for the IP address. The Ethernet header fields for packets destined to the IP node are set as follows: - Source Address is set to the virtual MAC address of CE4. - Destination Address is set to the MAC address resolved, corresponding to the IP address - VLAN ID is set the value assigned for this (Heterogeneous) PW service (corresponding to AC2c) Expires Sept 2003 Informational [Page 11] Internet Draft Hybrid VPLS March 2003 - length is set to the length of the payload and the (sub) EtherType is set to IP. When CLE2 receives the frame, it shall bridge it like any other Ethernet frames, towards the destination node. 3.4.1.2.2 Proxy ARP Client at CLE When PE2 receives a frame over the heterogeneous PW, PE2 decapsulates the frame, to obtain the IP packet. PE2 knows the AC it should forward packets to, i.e. AC2c and the service multiplexing ID (VLAN/Stacked VLAN tag) to use. PE2 shall forward the IP packet to the AC. The Ethernet header fields are set as follows: - Source Address is set to the MAC address of PE2 - Destination Address is set to the MAC address of CLE2 - VLAN ID is set the value assigned for this (Heterogeneous) PW service (corresponding to AC2c) - length is set to the length of the payload and the (sub) EtherType is set to IP. When CLE2 receives the frame destined to it, it inspects it. If the corresponding MAC address is not resolved, CLE2 shall ARP for the MAC address corresponding to the IP destination address on the emulated LAN. When the MAC address is resolved, the Ethernet header fields of the corresponding IP packet are set as follows: - Source Address is set to the virtual MAC address of CE4 - Destination Address is set to the MAC address corresponding to the IP address - length is set to the length of the payload and the EtherType is set to IP. CLE2 shall bridge the Ethernet frame appropriately, adding any VLAN tag as required. Note that a Proxy ARP Server (described in the next section), prevents ARP messages from being sent over the PW to the Frame Relay end of the PW. The advantages of having a Proxy ARP client at CLEs are: - the mapping of customer's MAC address to customer's IP address is not cached in PEs - no ARP messages from provider's network to customer site and vice- versa - no need to manage virtual MAC addresses for CEs in PEs 3.4.1.3 Resolving virtual MAC address for a node connected to Frame Relay/ATM 3.4.1.3.1 Proxy ARP Server Expires Sept 2003 Informational [Page 12] Internet Draft Hybrid VPLS March 2003 The Proxy ARP Server may reside on CLE2 or PE2. If PE2 is a Proxy ARP Client, then PE2 must be a Proxy ARP Server, similarly for CLE2. CE2 and other routers on the emulated LAN discover the IP address of CE4 via a routing protocol on the emulated LAN. When CE2 or other routers ARP for the MAC address of CE4, Proxy ARP Server(s) shall intercept the broadcast ARP message. The Proxy ARP Server on CLE2 or PE2 shall respond with the virtual MAC address of CE4. Other Proxy ARP Servers shall ignore the ARP message. The bridging function in the emulated LAN shall be able to learn CE4 (virtual) MAC address in the same way as it does for the MAC addresses of any other nodes on the emulated LAN. 3.4.1.4 Routing Protocol Interface Types 3.4.1.4.1 OSPF A routing protocol like OSPF on CE4 should be configured with Interface Type broadcast mode to allow OSPF to learn the other CE routers on the emulated LAN. OSPF on CE2 and other CEs should also be configured to be of Interface Type broadcast, if they are connected to the emulated LAN. 3.4.1.4.2 RIP RIP routers shall be able to discover neighbors on an emulated LAN, including the virtual MAC nodes (CEs with FR/ATM access). No additional configuration is required. 3.4.1.4.3 IS-IS FFS 4. Control Plane 4.1 Signaling (optional) To setup PWs, [MARTINI-CTL] or/and [ETH-L2TP] may be used. For e.g. PWs used for a VPLS may be setup using [MARTINI-CTL] within a domain and using [ETH-L2TP] to a different domain which may not support MPLS. Heterogeneous PW with IP payload is signaled using a new PW Type. This PW Type indicates one end of the PW is a point-to-point access link (e.g. ATM or Frame Relay) and the other end is Ethernet (LAN). When a PW is signal across domains, it is more likely that the "PE" Expires Sept 2003 Informational [Page 13] Internet Draft Hybrid VPLS March 2003 in another domain would be a border Network Element (NE) and the border NE setup another PW to a PE (facing customers' CEs) independently. The VPL ID and provider ID, e.g. Avpl.providerY.com may be included in the signaling from a PE in Provider X to a border NE/"PE" in Provider Y network. That way the border NE in Provider Y network can identify which Provider Y internal PW (belonging to Avpl) at the border NE, the external PW should be cross-connected with. Further details shall be specified if there is interest in this area. 4.2 Discovery (optional) The purpose of the mechanisms described here is to reduce the provisioning required to enable VPLS. 4.2.1 Reducing Provisioning at CLEs 4.2.1.1 Using a convention of consecutive VLAN tags or multiplexing IDs A convention of assigning multiplexing ID (VLAN tag values) at a CLE and PE and the mapping of an AC to the appropriate PW can be used to reduce the provisioning required on CLEs/CEs and PEs. CLEs/CEs can be pre-provisioned with a range of reserved VLAN tag values or multiplexing IDs, used to multiplex traffic to different remote CEs. For e.g. the CLEs/CEs in Figure 1 have reserved 100 VLAN tags, 2001-2100 each for this purpose. The customer wants to have two p2p Ethernet service from CLE2 to CLE1 and CE3. The provider may use LMI or other means to provision CLE2 or have the customer configure CLE2 via a web interface to connect to two remote CLEs. This is the only configuration required at the CLE when remote CLE(s) that this CLE should connect to, are added or removed. CLE2 may then allocate VLAN tag 2001 and 2002 for these two connections. PE2 expects CLE2 to use VLAN tag 2001 and 2002 and shall map VLAN tag 2001 to the first PW and 2002 to the second PW, the mapping of VLAN tags to PWs can be arbitrary if there is no specific requirements for the PWs e.g. different SLAs requirements. If a new CLE4 is added, the number of remote CLEs to connect to at CLE2 shall be configured to 3 and VLAN tag 2003 shall be allocated for the new p2p connection to the CLE4. If CLE3 is removed, the number of remote CEs to connect to at CLE2 shall be changed to two, and the virtual port association (VLAN 2003) for the third p2p connection shall be changed to VLAN 2002. Note that this change of VLAN tag to virtual port association should not affect the status of the virtual port. Using the above convention it is not necessary to use specific protocols to reduce the provisioning of CLEs. 4.2.1.2 LMI Expires Sept 2003 Informational [Page 14] Internet Draft Hybrid VPLS March 2003 The number of remote CLEs to connect to at each CLE may be updated by an LMI approach. After provisioning the required PWs, LMI may be used to inform CLE2 that the PWs are up. When a CLE is added or removed, and the corresponding PW is established or removed, LMI may be used to inform the remote CLE(s) that the p2p connection is up or down, respectively. 4.2.2 Reducing Provisioning at PEs To reduce provisioning at PEs, network management tools which reduces provisioning steps or the BGP mechanism described in [L2VPN-KOMPELLA] may be used. DNS [DNS-VPLS] or the BGP mechanism described in [L2VPN-KOMPELLA] may be used to discover the remote PEs and cross-connect information to setup the PWs. 5. Forwarding 5.1 PE Point-to-point Ethernet connections are forwarded as described in [MARTINI-ENCAP] and [ETH-L2TP]. When a PW terminates at a border Network Element, the payload of the PW, i.e. Ethernet frame shall be forwarded based on the PW ID to another PW within the domain instead of being sent out an AC. 5.2 CLE VLAN service multiplexing is being defined in IEEE 802.1. If necessary bridging over different virtual ports corresponding to different VLAN IDs may be specified in IEEE 802.1. 5.3 Heterogeneous PW Heterogeneous PW forwarding is described in Section 3. 6. Security Considerations Homogeneous Pseudo-Wires as used in this draft do not introduce any new security issues. Heterogeneous PWs with IP payload introduces new security issues, if the Proxy ARP Client and Proxy ARP Server reside on a PE. Hence it may be better to consider specifying the Proxy ARP Client and Server functions on a CLE only. Expires Sept 2003 Informational [Page 15] Internet Draft Hybrid VPLS March 2003 7. IANA Considerations A new PW Type for transporting IP traffic from an AC with Ethernet access to an AC with Frame Relay or ATM access is required. 8. Acknowledgments This draft benefited from discussions with Arnold Jansen, Plavin D'Souza, Raymond Chang, Roy Nighswander, Pierre Bolduc, Steve Buchko, Chris Bachalo, Alex Zinin, Zlatko Krstulich, Dimitri Papadimitriou, Hansen Chan and Italo Busi. Thanks to Radia Perlman for writing Interconnections. 9. Intellectual Property Considerations The IETF is being notified of intellectual property rights claimed in regard to some of the specification contained in this document. For more information consult the online list of claimed rights. 10. References 10.1 Normative References [MARTINI-ENCAP] Martini et al, "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", work in progress, Feb 2003 [ETH-L2TP], Aggarwal et al, "Transport of Ethernet Frames over L2TPv3", work in progess, work in progess, Oct 2002 [802.1D] IEEE, "ISO/IEC 15802-3:1998,(802.1D, 1998 Edition), Information technology --Telecommunications and information exchange between systems --IEEE standard for local and metropolitan area networks --Common specifications-Media access control (MAC) Bridges", June, 1998. [802.1Q] IEEE, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998 . [802.3] IEEE, "ISO/IEC 8802-3: 2000 (E), Information technology--Telecommunications and information exchange between systems --Local and metropolitan area networks --Specific requirements --Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", 2000. [802.1ad], "Provider Bridges", Tony Jeffree, work in progess, Dec 31 2002 Expires Sept 2003 Informational [Page 16] Internet Draft Hybrid VPLS March 2003 10.2 Informative References [Perlman] R. Perlman, "Interconnections, Bridges and Routers", 1997, Addison-Wesley. [L2VPN-KOMPELLA] K. Kompella et al, "MPLS-based Layer 2 VPNs", work in progress, July 2001. [L2VPN-FW] L. Andersson, E. Rosen, "L2VPN Framework", work in progress, Jan 2003 [VPLS] Lasserre, M, Kompella, V, et al, "Virtual Private LAN Services over MPLS", work in progress, March 2002 [ARP-MEDIATION] H. Shah et al, "ARP Mediation for IP Interworking of Layer 2 VPN", work in progress, October 2002 [MARTINI-CTL], Martini et al, "Transport of Layer 2 Frames over MPLS", work in progress, Aug 2002 [VPLS-DNS] J. Heinanen, "DNS/LDP Based VPLS", work in progess, January 2002. [CE-VPL] CY Lee, M Higashiyama, "CE-based VPL", work in progress, Nov 2002 [RFC3439], R. Bush, D. Meyer, "Some Internet Architectural Guidelines and Philosophy", Informational, December 2002 [MULTIPROT-FR] C. Brown, A. MALIS, "Multiprotocol Interconnect over Frame Relay", Standards Track, Sept 1998 [MULTIPROT-ATM] D. Grossman, J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", Standards Track, Sept 1998 Authors' Addresses Cheng-Yin Lee Cheng-Yin.Lee@alcatel.com Sasha Cirkovic Sasha.Cirkovic@alcatel.com Expires Sept 2003 Informational [Page 17]