PPVPN Working Group Ali Sajassi Internet Draft Jim Guichard Expiration Date: May 2003 George Wilkie Perry Leung Cisco Systems November 2002 L2VPN Interworking draft-sajassi-l2vpn-interworking-00.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-00.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 L2 service. Based on the application, a given approach/mechanism may be Sajassi, et al Expires May 2003 [Page 2] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 better suited than others as will be described in this document. This document primarily focuses on interworking in the data-plane and provides some discussion on management-plane interworking, such as OAM functionality. 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 May 2003 [Page 3] Internet Draft draft-sajassi-l2vpn-interworking-00.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 that 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 ATM and FR respectively. In this scenario, the FR frames are carried over the network using FRoPW to PE1 and PE1 performs FRF.8 Service Interworking. PE2 is unaware of this interworking functionality and operates as if AC1 is also of type FR. However, a certain amount of burden is placed on PE1, as it needs to perform complete interworking functionality, including the termination of the FR VC even though PE1 may not have any FR interfaces. |<--- Pseudo Wire ---->| AC1 | | AC2 | | |<-- PSN Tunnel -->| | | | v v v v | | +--------+ +--------+ | +----+ v | |==================| | v +----+ | |===| +---+ | | |====| | |CE1 |---|..|IWF|.|......AC2oPW .....|.. |----| CE2| | |=^=| +---+ | | |==^=| | +----+ | | |==================| | | +----+ | +--------+ +--------+ | Sajassi, et al Expires May 2003 [Page 4] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 | 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 ATM and FR respectively, PE1 terminates the ATM VC using [RFC2684] and transports the NS frames (e.g., Ethernet frames in this example) to the other side using EoPW. At the egress PE2, the Ethernet frames are encapsulated using [RFC2427] and are sent over the FR AC. In the reverse direction, PE2 terminates the FR VC using [RFC2427] and transports the Ethernet frames over EoPW to the egress PE1 and PE1 after encapsulating the frames using [RFC2684], sends them over the ATM AC. |<--- Pseudo Wire ---->| AC1 | | AC2 | | |<-- PSN Tunnel -->| | | | v v v v | | +--------+ +--------+ | +----+ v | |==================| | v +----+ | |===| +---+ | | +---+ |====| | |CE1 |---|..|IWF|.|..... NSoPW ......|..|IWF| |----| CE2| | |=^=| +---+ | | +---+ |==^=| | +----+ | | |==================| | | +----+ | +--------+ +--------+ | | PE1 PE2 | | | | | 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 Sajassi, et al Expires May 2003 [Page 5] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 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, the disadvantages of this approach can outweigh the advantages since there is more overhead associated with this approach. For example, performing FRF.8 requires performing both [RFC2684] and [RFC2427] encapsulation in addition to traffic management interworking, PVC management interworking, and congestion interworking at one PE, even though that PE may not support both AC types. 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. 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 Sajassi, et al Expires May 2003 [Page 6] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 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 needs 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 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. Sajassi, et al Expires May 2003 [Page 7] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 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 a configuration. 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 encapsulationThere 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 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. Sajassi, et al Expires May 2003 [Page 8] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 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 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 Sajassi, et al Expires May 2003 [Page 9] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 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, InARP) corresponding to the disparate interfaces. In some cases where a Frame-relay circuit 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 Frame-relay 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 a 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. +---+-----------+------------+--------------+-------------+ | | AC-1 | AC-2 | IWF-1 | IWF-2 | +---+-----------+------------+--------------+-------------+ | 1 | Ethernet | ATM | RFC 894 | RFC 2684-R | | 2 | Ethernet | FR | RFC 894 | RFC 2427-R | Sajassi, et al Expires May 2003 [Page 10] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 | 3 | Ethernet | PPP/HDLC | RFC 894 | RFC 2516 | | 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- 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 Sajassi, et al Expires May 2003 [Page 11] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 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 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. Sajassi, et al Expires May 2003 [Page 12] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 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 a new Multiprotocol (MP) PW. The MP PW 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. As will be seen later, the MP PW has additional overhead in order to identify the encapsulation of each packet, which makes the network BW utilization less efficient than other Interworking mechanisms such as Ethernet, IP, or PPP. 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. 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 Sajassi, et al Expires May 2003 [Page 13] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 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. 6. 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 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). Sajassi, et al Expires May 2003 [Page 14] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 As MP approach is extended to support additional routed and bridged protocols, it can get closer to [FRF.8.1] functionality. 7. Management Interworking The management interworking will be discussed at a later time. 8. Security Considerations The security aspects of this solution will be discussed at a later time. 9. Acknowledgements The authors would like to thank Francois Gagne, Michael Wu, Ian Cox, and Megan Bao for their helpful discussions and feedbacks. 10. 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)ö [RFC2427] ôMultiprotocol Interconnect over Frame Relayö [RFC2684] ôMultiprotocol Encapsulation over ATM Adaptation Layer 5ö [RFC2784] ôGeneric Routing Encapsulation (GRE)ö Sajassi, et al Expires May 2003 [Page 15] Internet Draft draft-sajassi-l2vpn-interworking-00.txt November 2002 [RFC2878] ôPPP Bridging Control Protocol (BCP)ö 11. 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 Sajassi, et al Expires May 2003 [Page 16]