[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01

            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]
          

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/