PPVPN Working Group Ali Sajassi Internet Draft Jim Guichard Expiration Date: October 2003 George Wilkie Perry Leung Michael Wu Cisco Systems March 2003 L2VPN Interworking draft-sajassi-l2vpn-interworking-01.txt 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 obsolete 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 The need to support L2VPN services with disparate Attachment Circuits (heterogeneous transport) is becoming as important as the support of L2VPN services with the same type of Attachment Circuits (homogenous transport). To support L2VPN services with heterogeneous transport, some means of interworking is needed. The requirement to support L2VPN interworking is stated in [PPVPN-L2FRWK]. This document describes different approaches and mechanisms that can be used to provide L2VPN interworking among disparate interfaces. [Page 1] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 1. Boilerplate for Sub-IP Area Drafts RELATED DOCUMENTS draft-ietf-ppvpn-l2-framework-01.txt draft-ietf-pwe3-framework-01.txt WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK Belongs in PPVPN WHY IS IT TARGETED AT THIS WG This document describes different interworking approaches and mechanisms for Provider Provisioned L2VPN. JUSTIFICATION This document addresses interworking between disparate interfaces for L2VPN whose requirements are also stated in [PPVPN-FRWK]. 2. Introduction The advantages of providing different types of L2 circuits (e.g. ATM, FR, Ethernet, and so on) over a common infrastructure (either IP or MPLS) are well understood and are described in [PWE3-FRWK] and [PPVPN- L2FRWK]. The primary focus in both frameworks has been the support of like-to-like services (e.g. the same type of ACs at both ends of a Pseudo-Wire). The importance of supporting disparate ACs (heterogeneous transport) is becoming more evident. For example, as VPN users expand their L2VPNs over MPLS or IP, they wish to leverage their existing CE devices that may have legacy interfaces such as ATM or Frame-relay, and they would like to be able to add new CE devices with FE or GE interfaces to their L2VPN. This means that Service Providers not only need to provide L2VPN services (such as VPWS and VPLS) to customers with uniform ACs but they also need to provide these services to customers with disparate ACs. To support L2VPN services with heterogeneous transport, some means of interworking is clearly needed. The requirement to support L2VPN interworking is stated in [PPVPN- L2FRWK]. This document covers different approaches to facilitate this interworking and presents some mechanisms that can be used to provide L2VPN interworking among disparate interfaces depending on the intended Sajassi, et al Expires October 2003 [Page 2] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 L2 service. Based on the application, a given approach/mechanism may be better suited than others as will be described in this document. This document primarily focuses on interworking in the data-plane. Control- plane interworking (signaling/routing between different protocols) is outside the scope of this document. 2.1. Interworking Reference Model Figure 1 below shows the network reference model used for L2VPN Interworking. This model is the same as the one described in [PWE3- FRWK], with the exception that the Native Service (NS) that is carried across the AC, has been added to the model. CE1 Attachment |<--- Pseudo Wire ---->| CE2 Attachment Circuit | | Circuit | | |<-- PSN Tunnel -->| | | | v v v v | | +--------+ +--------+ | +----+ v | |==================| | v +----+ | |===| | | |====| | |CE1 |---| ..|....... PW .......|.. |----| CE2| | |=^=| | | |==^=| | +----+ | | |==================| | | +----+ | +--------+ +--------+ | | PE1 PE2 | | | | | Native Native Service Service Figure 1: L2VPN Interworking Network Reference Model CE, PE, Pseudo-wire, and PSN tunnel are as defined in [PWE3-FRWK] and the Attachment Circuits (ACs) are as defined in [PPVPN-FRWK]. In the context of L2VPN Interworking, we define the Native Service as the common end-to-end service that is carried over the ACs between the two CEs. With respect to L2VPN Interworking, it is important to differentiate between an AC and the Native Service (NS) that runs over that AC. The AC is a physical or virtual circuit connection between a CE and a PE. However, the Native Service in this reference model is the common L2 application service that runs between a pair of CEs and is carried over Sajassi, et al Expires October 2003 [Page 3] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 the two disparate ACs. For example, an AC between a CE and a PE can be ATM or FR but the Native Service can be Ethernet (EoATM, EoFR). Sometimes, the AC and the NS are of the same type (e.g., both are of type Ethernet), in which case it simplifies the interworking task on the corresponding PE. 3. General Approaches There are two general approaches for interworking – the first is to extend the AC from one side of the connection to the other side and perform the interworking only on one side (on one PE). The second approach is to terminate each AC locally and to transport the NS frames across the network. In the first approach, the PW type is the same as the AC that gets extended over the network; whereas, in the later approach, the PW type is independent of the AC type and instead it is of the same type as the NS. If the NS is the same as one of the ACs, then local interworking is not required for that PE (whose AC is the same as the NS) and the two approaches become the same. The following figure depicts the interworking model for the extended AC approach. In this figure, the AC between CE2 and the PE2 (AC2) is extended over the network to PE1 (through the use of AC2-over-PW), and the Interworking Function (IWF) between the two disparate ACs is performed in PE1. In this interworking model, PE2 is completely oblivious to the NS and only deals with processing the frames from AC2 (e.g. NS frames pass transparently through PE2). For example, consider AC1 and AC2 are of type FR and PPP respectively. In this scenario, the PPP frames are carried over the network using PPPoPW to PE1 and PE1 performs the Interworking. PE2 is unaware of this interworking functionality and operates as if AC1 is also of type PPP. However, a certain amount of burden is placed on PE1, as it needs to perform complete interworking functionality, including the termination of the PPP sessions even though PE1 may not have any local PPP interfaces. Sajassi, et al Expires October 2003 [Page 4] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 |<--- Pseudo Wire ---->| AC1 | | AC2 | | |<-- PSN Tunnel -->| | | | v v v v | | +--------+ +--------+ | +----+ v | |==================| | v +----+ | |===| +---+ | | |====| | |CE1 |---|..|IWF|.|......AC2oPW .....|.. |----| CE2| | |=^=| +---+ | | |==^=| | +----+ | | |==================| | | +----+ | +--------+ +--------+ | | PE1 PE2 | | | | | Native Native Service Service Figure 2: Extended-AC L2VPN Interworking Model Figure 3 depicts the interworking model for local termination of ACs. In this model each PE terminates its corresponding AC and after extracting the NS frames, it transports them to the other side using the PW that is of the same type as the NS (NSoPW). If we consider the previous example where AC1 and AC2 are of type FR and PPP respectively, PE1 terminates the FR VC using [RFC2427] and transports the NS frames (e.g., IP packets in this example) to the other side using IPoPW. At the egress PE2, the IP packets are encapsulated using [RFC1661] and are sent over the PPP AC. |<--- Pseudo Wire ---->| AC1 | | AC2 | | |<-- PSN Tunnel -->| | | | v v v v | | +--------+ +--------+ | +----+ v | |==================| | v +----+ | |===| +---+ | | +---+ |====| | |CE1 |---|..|IWF|.|..... NSoPW ......|..|IWF| |----| CE2| | |=^=| +---+ | | +---+ |==^=| | +----+ | | |==================| | | +----+ | +--------+ +--------+ | | PE1 PE2 | | | Sajassi, et al Expires October 2003 [Page 5] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 | | Native Native Service Service Figure 3: Local-AC Termination L2VPN Interworking Model The advantage of the Extended-AC interworking approach is that one of the existing PW types is used for carrying the frames from one side of the connection to the other. Furthermore, in the case of ATM-FR interworking, a well-defined Service Interworking function is used for the interoperability between the two disparate ACs. However, in general the disadvantages of this approach can outweigh the advantages since there is more overhead associated with this approach. In comparison, there are several advantages to the Local-AC-Termination interworking approach: * Each PE is only required to support the interworking for the interfaces that it supports. For example, a PE with ATM interfaces is only required to support [RFC2684] and not [RFC2427], [RFC 1661], or other functionality that is not pertinent to that interface. * Each PE is only required to support a common PW for its interworking. For example, a PE with ATM interfaces that needs to do Ethernet encapsulation over its ATM interface is only required to support a single common PW that carries the Ethernet payload. This means that the ATM PE need not terminate different types of PW such as PPP, HDLC, FR, and so on, and be required to run different procedures such as [RFC2427], [RFC1661], [RFC2878], etc. to extract the Ethernet payload from these PWs. * Configuration of each interface or VC type is limited to the PE that supports that interface. * Better scalability. Since each PE terminates the ACs locally and performs the corresponding interworking to/from a common PW locally, the interworking task is load balanced across the two legs of the connection and thus better system scalability is achieved. Because of the above advantages of the Local-AC-Termination approach over the Extended-AC, it is recommended as the preferred approach for interworking between disparate ACs. Sajassi, et al Expires October 2003 [Page 6] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 The Local-AC-Termination approach can be considered as a subset of the service-interworking function, which is optimized for Ethernet, PPP, and IP services (specifically this is true for ATM-FR service interworking). However, in the case of ATM-FR interworking where full service-interworking functionality is required and the approximation is not sufficient, one may have to use the Extended-AC approach and perform the IWF (e.g., FRF.8.1) at a single PE. 4. Interworking Mechanisms In general, there are four main NS types – namely: * Ethernet * IP * PPP * Multiprotocol In the following, we define four interworking mechanisms corresponding to these four service types. As discussed previously, in the Local-AC-Termination interworking approach, the PW type is the same as the NS type. This means that if there are four NS types, then there need to be four PW types to transport the corresponding NS frames. The PW type and encapsulation to carry Ethernet and PPP frames have already been defined for both MPLS and IP; however, new Pseudowire types for IP & Multiprotocol PDUs needs to be defined. In some interworking scenarios as described later, there may be a need to carry both Ethernet and IP services simultaneously over a single AC between the CE and its corresponding PE. There may also be a need to carry several different L3 protocols over the same AC. In such cases, a new Multi-Protocol (MP) Pseudowire is needed to carry these different multiple protocols simultaneously. The following sub-sections describe each of the above interworking mechanisms (Ethernet, IP, PPP, and MP) and their corresponding applications in greater details. 4.1. Interworking w/ Ethernet Encapsulation Ethernet encapsulation is the only interworking mechanism that is applicable to both VPWS and VPLS services. The other interworking mechanisms are only applicable to VPWS service. One of the most common Sajassi, et al Expires October 2003 [Page 7] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 applications for Ethernet encapsulation is to provide ubiquitous Ethernet service across different customer sites and over different AC types so that IGP routing protocols such as OSPF, RIP, and IS-IS can run among customer CE routers without the need for any special procedures in the Service Provider’s PEs. Some of the procedures used in IGP routing protocols depend on the underlying L2 protocol and these procedures are different for a point- to-point connection (e.g., an ATM VC) versus a multi-access connection (e.g., Ethernet). Therefore, it cannot be expected that these protocols will operate correctly between two CEs with disparate ACs, without some special procedures to accommodate such heterogeneous transport. The use of Ethernet encapsulation provides homogenous Ethernet connectivity end-to-end among CEs and thus simplifies the operation of the routing protocols over disparate ACs to a uniform L2 media access. If the AC is of type Ethernet (e.g., AC and NS are of the same type), then no Interworking Function is needed on that PE and Ethernet frames are transported over the PW (which is of type Ethernet [PWE3-ETH- ENCP]). However, if Ethernet frames are carried over a non-Ethernet AC (e.g., ATM, FR, PPP), then the task of IWF on that PE is to terminate the AC based on already defined RFC procedures, and extract the Ethernet frames and transport them over the Ethernet PW. If the AC is of type ATM, FR, or PPP, then [RFC2684], [RFC2427], or [RFC2878] are used respectively for encapsulation/de-encapsulation of the Ethernet frames. In this interworking scenario, the non-Ethernet ACs of the CE routers need to be configured to use Ethernet encapsulation. There are currently two common ways of configuring the CE routers for such operations and they are: * Configure the CE router interface as a bridged interface * Configure the CE router interface as a routed interface with bridged encapsulation The first method requires that the CE router interface be configured for bridging operation, and be connected to routed interfaces by way of a virtual interface. Routed packets for a given protocol can be exchanged between routed and bridged interfaces via this virtual interface. This virtual interface acts like a normal routed interface and represents the corresponding bridge group to routed interfaces within the CE router. The second method requires that the CE interface be configured for routed operation, but provide bridged encapsulation via the interface. Using this method, the interface looks and behaves like a routed Sajassi, et al Expires October 2003 [Page 8] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 interface to all other routed interfaces although packets that are sent out of this interface are encapsulated in a bridged format. In the case of an ATM/FR interface, this would require specific IGP configuration to force the router to see the interface as multi-access. The interworking with Ethernet encapsulation also simplifies the job of PE devices and the IWF on the PEs is limited to the termination of the ACs and encapsulation/de-encapsulation of Ethernet frames based on already defined RFC mechanisms such as [RFC2684], [RFC2427], and [RFC2878]. No additional procedures such as ARP mediation [ARP- Mediation] are required. The following table lists all possible combinations of ACs that can exist for interworking w/ Ethernet encapsulation and the applicable RFC procedures that need to be performed by IWF. +---+-----------+------------+--------------+-------------+ | | AC-1 | AC-2 | IWF-1 | IWF-2 | +---+-----------+------------+--------------+-------------+ | 1 | Ethernet | ATM | NULL | RFC 2684-B | | 2 | Ethernet | FR | NULL | RFC 2427-B | | 3 | Ethernet | PPP/HDLC | NULL | RFC 2878 | | 4 | FR | ATM | RFC 2427-B | RFC 2684-B | | 5 | FR | PPP/HDLC | RFC 2427-B | RFC 2878 | | 6 | ATM | PPP/HDLC | RFC 2684-B | RFC 2878 | +---+-----------+------------+--------------+-------------+ 4.1.1. BPDUs processing In most applications where CEs with non-Ethernet interfaces are either routers or hosts, there is no need to handle BPDUs at the PEs and therefore they can be dropped. This can occur either at the Ethernet PE (when the BPDU first comes over the Ethernet AC) or at the ATM/FR/PPP PE before being delivered over the non-Ethernet AC. However, in applications where the non-Ethernet AC on a CE router is configured as a bridged interface, then BPDUs need to be properly encapsulated/de- encapsulated by the corresponding PE and sent/received over the non- Ethernet AC. 4.2. Interworking w/ IP Encapsulation IP encapsulation is used in applications where IP routing among different customer sites is desired. In such cases, the Service Sajassi, et al Expires October 2003 [Page 9] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 Provider doesn’t participate in the customer’s layer-3 network, but simply provides a L2 circuit over which L3 PDUs may be carried. However, due to the disparate ACs at both ends of the PW, certain issues may arise with the routing protocol such as the mismatch of procedures for point-to-point and multi-access media, and this may necessitate configuration changes at the CE. Such configuration changes may not be available for all routing protocols and in such cases, the Ethernet encapsulation method described earlier may be used. Although the overhead of IP encapsulation on the CEs may be relatively small (e.g., no configurations changes where both ACs are PtP, no requirement for routed/bridged interaction and so on), the overhead on the PEs is more significant as they need to provide mediation between different address resolution mechanisms (such as ARP and InARP) corresponding to the disparate interfaces. In some cases where an ATM or FR AC is configured as point-to-point or with static IP/circuit mapping (instead of a multi-access interface), this mediation is not required at the FR/ATM side of the PW. [ARP-Mediation] describes a three-step process for performing this mediation function for IP only protocols. The three steps are: 1. The PE discovers the attached CEs IP address 2. The PE distributes the CEs IP address to a remote PE 3. The remote PE notifies its attached CE about the far-end CE’s IP address If one of the ACs is of type Ethernet, then the corresponding PE also needs to learn the MAC address of that CE. Based on the AC type, there are several different ways of discovering the attached CE’s IP address and as the result, there are different special cases that need to be handled. For example, if the AC is Ethernet, in order to learn the IP address of the attached CE, the PE device must execute a router discovery protocol or it must glean source address fields from any broadcast messages, or it must wait for the CE to generate an ARP request. The PE also needs to have a mechanism to verify the existence of the CE’s IP address and it’s binding to the MAC address, and to resolve situations where more than one IP address is received over the Ethernet AC. The handling for some of these special cases is described in the [ARP-Mediation] draft. The following table lists all the possible combinations of ACs that can exist for interworking w/ IP encapsulation and the applicable RFC procedures that need to be performed by IWF. Sajassi, et al Expires October 2003 [Page 10] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 +---+-----------+------------+--------------+-------------+ | | AC-1 | AC-2 | IWF-1 | IWF-2 | +---+-----------+------------+--------------+-------------+ | 1 | Ethernet | ATM | RFC 894 | RFC 2684-R | | 2 | Ethernet | FR | RFC 894 | RFC 2427-R | | 3 | Ethernet | PPP/HDLC | RFC 894 | RFC 1661 | | 4 | FR | ATM | RFC 2427-R | RFC 2684-R | | 5 | FR | PPP/HDLC | RFC 2427-R | RFC 1661 | | 6 | ATM | PPP/HDLC | RFC 2684-R | RFC 1661 | +---+-----------+------------+--------------+-------------+ In all these scenarios, the Local-AC-Termination approach is used and after terminating the local AC in the IWF, the L3 PDU is extracted and transported over the PW. In the case of IP encapsulation where one AC is ATM or FR, then the ATM/FR AC may be configured for point-to-point operation, or the circuit-to-IP mapping may be set manually. In this case, Inverse-ARP is not required at the FR or ATM end of the circuit. In such scenarios, the procedure for ARP mediation can be simplified considerably, and ARP proxy may be used at the Ethernet AC side of the circuit. In this case, the PE with the Ethernet AC only need to respond to ARP requests using its own MAC address and there is no need to exchange the CEs’ IP addresses between the two PEs over the network. 4.3. Interworking w/ PPP Encapsulation This type of Interworking may be used for applications that desire an end-to-end PPP connection between a pair of CEs. An example of such an application is where a CE with a low speed (e.g., T1/E1) ATM/FR interface on one side of the PW (e.g., access GWs) needs to carry compressed voice (using cRTP) to a Trunking-GW CE with an Ethernet interface. Such applications require end-to-end PPP connections between the access-GW CEs and the trunking-GW CEs. Also for applications where L3 protocol transparency is needed or peer-to-peer authentication between the CEs is needed, then PPP interworking can come in handy. The impact of the PPP Interworking on CE and PE devices are as follow. If the CE is a router, then it shall support PPP protocol and it needs to terminate both PPP session and the AC; however, if the CE is an Ethernet switch/bridge, then the PPP frames are carried transparently over Ethernet/VLAN (PPPoE) and the PPP session is terminated at a far- Sajassi, et al Expires October 2003 [Page 11] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 end host/router. Therefore, the support for PPP protocol on the CE is not always needed and it depends on the application. If the PE needs to support PPP sessions over an Ethernet interface (e.g., PPPoE), then the PE needs to perform session negotiation therefore it needs to run PPPoE software. However, if the PE needs to support PPP sessions over an ATM interface (e.g., PPPoA), then no session negotiation is required. The following table lists all possible pair of ACs that can exist for interworking w/ PPP encapsulation and the applicable RFC procedures that need to be performed by IWF. +---+-----------+------------+--------------+-------------+ | | AC-1 | AC-2 | IWF-1 | IWF-2 | +---+-----------+------------+--------------+-------------+ | 1 | Ethernet | ATM | RFC 2516 | RFC 2364 | | 2 | Ethernet | FR | RFC 2516 | RFC 1973 | | 3 | Ethernet | PPP/HDLC | RFC 2516 | NULL | | 4 | FR | ATM | RFC 1973 | RFC 2364 | | 5 | FR | PPP/HDLC | RFC 1973 | NULL | | 6 | ATM | PPP/HDLC | RFC 2364 | NULL | +---+-----------+------------+--------------+-------------+ In scenarios 3, 5, and 6 of the previous table, the AC at one side is the same type as the NS (both are PPP) and as mentioned earlier this would result in simplification of the IWF to NULL for that side. Also as mentioned previously, for such scenarios the Local-AC-termination and Extended-AC approaches map into the same thing. However, in scenarios 1, 2, and 4, each side terminates its local AC based on the corresponding RFC and after extraction of the PPP frames, transports them over the PW using [PWE3-PPP]. 4.4. Interworking w/ Multi-Protocol Encapsulation In applications where several different protocol types need to be supported over the same AC simultaneously, the interworking w/ Multi- Protocol encapsulation can be used. An example of this application is where several different protocols (such as IP, IPX, AppleTalk, and so on), run between a pair of CEs with different AC types, and all of these protocols need to be transported over a single AC. In such a scenario, the end-user may want to configure its CEs to run IP as routed encapsulation and all other non-IP traffic as bridged Sajassi, et al Expires October 2003 [Page 12] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 encapsulation. This would require that the PW be able to transport both routed and bridged encapsulated packets over the same AC. Alternatively, the end-user may want to route all of these protocols across the same AC, and this would require the PW to be able to carry multiple L3 protocols simultaneously. Given that some of the routing protocols such as OSPF and IS-IS have dependencies on the underlying L2 circuit type (e.g., PtP versus multi- access link), one cannot assume that the MP PW can work with all different AC types. Therefore, the combination of IP and Ethernet is considered first and any other non-IP routing protocol that needs to be transported over the MP PW should be considered on a case-by-case basis. If MP applications need to be supported then as with other interworking mechanisms, the Local-AC-Termination approach should be used, and all packets should be transported over the network using the Multiprotocol (MP) PW that will be described in the next section. The support of MP PW imposes additional work on the PE, as it is required to select the proper PW or AC encapsulation on a packet-by- packet basis. The advantages of using the MP PW as opposed to extending one of the AC and performing the service interworking on one side are the same as the ones listed for the Local-AC-Termination approach. Primarily by using a MP PW, a common mechanism for Multiprotocol encapsulation is used across different types of ACs. 4.5. IP and MP Pseudowire types In the previous sections, four interworking mechanisms and their corresponding PW types were discussed. Ethernet and PPP PWs have currently been defined for MPLS and IP networks in [PWE3-Ethernet] and [PWE3-PPP] respectively. In this section we define the format for two new PW types for IP and MP encapsulation. We first define two new VC types as follow: VC Type Description 0x000C IP transport 0x000D Multiprotocol transport These VC types are signaled between the PEs using directed LDP for MPLS or L2TPv3 for IP networks. Sajassi, et al Expires October 2003 [Page 13] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 For the IP PW type, the payload field of the PW contains the IP PDU including the IP header. When the IP PW is setup, only IP packets get transported over this PW and non-IP packets will be discarded. However, for the MP PW type, the payload field of the PW contains a shim header of four octets as shown below to identify the Multiprotocol PDU type. 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 2 +-------------------------------------------------------------+ | Reserved | Protocol Type | +-------------------------------------------------------------+ | | | | | Layer-3 Packet Data Unit | | | | | +-------------------------------------------------------------+ The protocol type field is borrowed from GRE [RFC 2784] and it is a two-byte field that can be used to identify all relevant protocols. When the MP PW is setup, the ingress PE after terminating the corresponding AC, examines the protocol type of each packet and uses the corresponding Protocol Type for the shim header in the payload field of the PW. The egress PE uses the Protocol Type of the shim header to do proper encapsulation over the corresponding AC. If the ingress PE receives a packet for which the corresponding Pseudowire Protocol Type (in the shim header) is not defined, then it should discard the packet. The Interworking w/ multi-protocol encapsulation can also be supported using a set of individual PWs instead of MP PW. This is analogous to ATM multi-protocol encapsulation using VC Muxed as opposed to LLC SNAP. For example, if an AC carries both IP and non-IP traffic, then IP traffic can be transported using IP PW and non-IP traffic can be transported using Ethernet PW. The advantage of this approach besides having less payload overheads is that on the egress PE, proper encapsulation of the frames can be performed based on the receiving PW type without looking inside the payload (e.g., without looking at the protocol type). The disadvantage of this approach is that multiple PWs need to be setup ahead of time. 5. ATM/FR Service Interworking [FRF.8.1] is the standard for service interworking between ATM and FR PVCs. It assumes that the ATM service user (e.g., ATM CE) performs no Sajassi, et al Expires October 2003 [Page 14] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 frame relaying service-specific functions, and the frame relaying service user (e.g., FR CE) performs no ATM service specific functions. [FRF.8.1] deals with more than just upper layer protocol encapsulation. It deals with traffic management, PVC management, and congestion management interworking. It also supports a suite of routing and bridge protocols. To support this interworking, the Extended-AC approach is used where either the FR or the ATM AC is extended to the other side (through the use of FRoPW or ATMoPW) and the interworking function is performed only in one PE. However, if the protocols on the CEs can be limited to IP and Ethernet, then Local-AC-Termination approach can be used which provides the advantages mentioned previously (the PW is of type MP in this case). As MP approach is extended to support additional routed and bridged protocols, it can get closer to [FRF.8.1] functionality. 6. Interworking between L2 and L3 VPN There are scenarios where a service provider needs to provide VPLS service to a customer, which has sites with different AC types – e.g., some sites with ATM ACs, some sites with FR ACs and many sites with Ethernet ACs. One easy way for the service provider to deliver such service is to mandate that the NS be of type Ethernet end-to-end as discussed previously. In other words, the customer’s CEs with ATM or FR ACs need to be configured for bridged encapsulation (by configuring its AC as a bridged interface or as routed interface with bridged encapsulation – refer to section 4.1). However, what if the customer’s CEs don’t have such capability and cannot be configured easily for such operation or the SP want to offer the service without requiring configuration changes to its customers’ CEs. In such scenarios, the SP can offer L3VPN service toward the customer’s CEs with routed interfaces and can offer VPLS service toward the CEs with Ethernet interfaces and provide interworking between them. The interworking between L3VPN and VPLS is achieved by having VSI (Virtual Switch Instance) not only on the PEs providing VPLS functionality but also on the PEs providing L3VPN functionality. The VSI interfaces with the L3VPN forwarder (e.g., VRF as defined in [RFC2547]) through provider’s VLAN (P-VLAN). Each VPLS instance at a PE can be locally represented by a P-VLAN and this P-VLAN can be viewed as a routed interface with respect to the customer L3VPN VRF. Furthermore, the interface between the customer’s VRF and its corresponding VPLS is through this P-VLAN interface. Sajassi, et al Expires October 2003 [Page 15] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 It should be noted that such interworking model is viable when a customer has only a few sites with routed interfaces and majority of his sites have Ethernet/bridged-encapsulation interfaces. If converse is true, then the customer might be better off with pure L3VPN service [RFC2547], instead of a hybrid of VPLS and L3VPN. ATM (routed) Ethernet | | | PE1 PE2 | | +---------------+ +--------+ | +----+ | | | | | v +----+ | | V | +---+ +---+ | | +---+ | | | |CE1 |---|-|VRF|---|VSI|-|-------EoPW-------|--|VSI| |----| CE2| | | | +---+ ^ +---+ \ | +---+ | | | +----+ | | |\ | | | +----+ +-------|-------+ \ +----|---+ | \ | | \ | P-VLAN \ +----|---+ \ | | | +----+ \ | +---+ | | | ---EoPW----|--|VSI|-|----| CE3| | +---+ | ^ | | | | | +----+ +--------+ | PE3 | Ethernet Figure 4: VPLS/L3VPN Interworking Model Figure 4 depicts the interworking between VPLS and L3VPN. The figure shows a SP network providing VPN service to a customer with three sites/CEs. Site-1/CE1 is connected via ATM routed interface; whereas, CE2 and CE3 have Ethernet interfaces. The SP is providing VPLS service to CE2 and CE3, and L3VPN service to CE3. The VRF at the PE1 can be viewed as a virtual router peering with CE1 at one end and with CE2 and CE3 at the other end. The collection of VSIs and PWs connecting them together can be viewed as a logical LAN segment between the VRF, CE2, and CE3. Since the VRF is peering with CE1, CE2, and CE3, it is involved in the ARP and the required routing protocol with these CEs. Sajassi, et al Expires October 2003 [Page 16] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 As it can be recalled from previous sections, the interworking with Ethernet encapsulation did require configuration changes to CEs and the interworking with IP encapsulation required not only required configuration changes to CEs but also it posed some restrictions on the type of L3 routing protocols that could be run (it was also limited to VPWS services only). However, the primary advantage of this L2/L3 interworking mechanism is that it removes the shortcomings of the other interworking mechanisms such that it requires no configuration changes at the customer’s CEs and there are no restrictions on the type of L3 routing protocols that can be run on the CEs. However, the cost of this interworking mechanism is for the PEs (with non-Ethernet ACs) to provide the L3VPN service in addition to the VPLS service. 7. Security Considerations The security aspects of this solution will be discussed at a later time. 8. Acknowledgements The authors would like to thank Francois Gagne, Ian Cox, and Megan Bao for their helpful discussions and feedbacks. 9. References [PWE3-FRWK] "Framework for Pseudo Wire Emulation Edge-to-Edge", Prayson Pate, draft-ietf-pwe3-framework-01.txt [PPVPN-FRWK] “PPVPN L2 Framework”, Loa Anderson, draft-ietf-ppvpn-l2- framework-01.txt [PWE3-Ether] “Encapsulation Methods for Transport of Ethernet Frames over IP/MPLS Networks”, Luca Martini, draft-ietf-pwe3-ethernet-encap- 00.txt [ARP-Mediation] “ARP Mediation for IP interworking of Layer 2 VPN”, Himanshu Shah, draft-shah-ppvpn-arp-mediation-00.txt [FRF.8.1] “Frame Relay / ATM PVC Service Interworking Implementation Agreement” [RFC1661] “The Point-to-point Protocol (PPP)” Sajassi, et al Expires October 2003 [Page 17] Internet Draft draft-sajassi-l2vpn-interworking-01.txt November 2002 [RFC2427] “Multiprotocol Interconnect over Frame Relay” [RFC2684] “Multiprotocol Encapsulation over ATM Adaptation Layer 5” [RFC2784] “Generic Routing Encapsulation (GRE)” [RFC2878] “PPP Bridging Control Protocol (BCP)” [RFC2547] “BGP/MPLS VPNs. E. Rosen, Y. Rekhter. March 1999” 10. Authors' Addresses Ali Sajassi Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com Jim Guichard Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Email: jguichar@cisco.com George Wilkie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: gwilkie@cisco.com Perry Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: perryl@cisco.com Michael Wu Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: mwu@cisco.com Sajassi, et al Expires October 2003 [Page 18]