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