One document matched: draft-sajassi-l2vpn-interworking-01.txt-53764.txt
Differences from 01.txt-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 11:37:06 |