Provider Provisioned VPN WG Hamid Ould-Brahim
Internet Draft Vasile Radoaca
draft-ouldbrahim-l2vpn-lpe-00.txt Michael Chen
Expiration Date: April 2002 Nortel Networks
November 2001
VPLS/LPE L2VPNs:
Virtual Private LAN Services using
Logical PE Architecture
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 [RFC-2026], except
that the right to produce derivative works is not granted.
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
Consider a common network scenario in the metro area where the
service provider offers Virtual Private LAN services (VPLS)
Ould-Brahim, et. al 1
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
known also as Transparent LAN services (TLS) to a large number
of customers attached to low-cost Ethernet provider devices.
These devices specialized mostly for Ethernet based functions
(e.g., MAC learning, etc) may not have adequate resources and
functions compared to provider devices offering large scale
layer-2 or layer-3 VPN services. Consider also the case where
those devices are themselves attached to either switched
Ethernet networks or through uplinks to other provider edge
devices, which are attached to a core IP/MPLS network
infrastructure. The problem is how to provide a network-based
VPLS solution that scales to a large number of VPLSs, each with
a large number of customer ports while at the same time the
solution should be cost-effective at service provider network-
edges. This draft introduces the "Logical PE" architecture to
effectively address this problem.
TABLE OF CONTENT
Abstract
1. Conventions used in this document......................... 3
2. Introduction.............................................. 3
2.1 What is a VPLS Service?.................................. 4
2.2 VPLS Architecture and Ethernet Scaling Issues............ 4
2.3 Network-based VPNs and VPLS Service...................... 6
2.3.1 L2VPN Architectures.................................... 6
2.3.2 L2VPN Architectures and VPLS........................... 6
2.4 VPLS and Logical PE Approach............................. 7
2.5 VPLS Architecture Functions and VPLS Models.............. 7
2.5.1 VPLS/L2VPN Reference Model............................. 7
2.5.2 VPLS Main Functions.................................... 7
2.5.3 VPLS Model: Full Mesh Point-to-Point Circuits.......... 9
2.5.4 Virtual Switch Model................................... 9
2.5.5 Virtual Switch with Full mesh Point-to-Point Model..... 9
3. Logical PE Architecture................................... 9
3.1 VPLS LPE Reference Model................................. 9
3.2 Logical PE...............................................12
3.3 Network Connectivity within the Logical PE...............13
3.3.1 PE-Edges connected directly to the PE-Core.............13
3.3.2 Multiple Broadcast Domains in Logical PE...............13
3.4 Logical PE Function Distribution.........................14
3.4.1 PE-Edge Functions......................................14
3.4.2 PE-Core Functions......................................14
3.5 Logical PE Auto-Discovery Protocol (LPE-AD)..............15
3.6 VPLS Membership Determination............................15
3.7 Logical PE Forwarding and Auto-discovery.................15
3.7.1 VPN Auto-Discovery on the Core Network.................16
3.7.2 LPE Forwarding Algorithm for [MARTINI-TRANSP]
on the Core..............................................16
3.7.3 LPE Forwarding Algorithm using [L2VPN-KOMP]
on the Core..............................................17
3.7.4 Virtual Switch Proxy (VSP).............................18
Ould-Brahim, et al. May 2002 [Page 2]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
3.8 LPE Configuration Models.................................18
3.9 Quality of Service.......................................19
3.10 LPE Resiliency..........................................19
3.11 Security Considerations.................................19
4. References................................................20
5. Acknowledgments...........................................21
6. Intellectual Property Considerations......................21
7. Author's Addresses........................................22
Full Copyright Statement.....................................23
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC-2119 [2].
2. Introduction
Consider a common network scenario in the metro area where the
service provider offers Virtual Private LAN services (VPLS)
known also as Transparent LAN services (TLS) to a large number
of customers attached to low-cost Ethernet provider devices.
These devices specialized mostly for Ethernet based functions
(e.g., MAC learning, etc) may not have adequate resources and
functions compared to provider devices offering large scale
layer-2 or layer-3 VPN services. Consider also the case where
those devices are themselves attached to either switched
Ethernet networks or through uplinks to other provider edge
devices, which are attached to a core IP/MPLS network
infrastructure. The problem is how to provide a network-based
VPLS solution that scales to a large number of VPLSs each with a
large number of customer ports while at the same time the
solution should be cost-effective at service provider network-
edges. This draft introduces the "Logical PE" architecture to
effectively address this problem.
Architecting a scalable network based VPLS solution faces
challenges related to the nature of the Ethernet technology
itself and the network-based VPN mechanisms used. Most of
existing VPLS solutions attempt to address the VPLS architecture
within a problem space similar to the layer-3 and point-to-point
layer-2 VPNs. Although the layer-3/2 VPN problem space is indeed
part of the VPLS problem space, it doesn't fully meet all the
possible scaling characteristics and common VPLS network
deployment scenarios. This section illustrates the nature of
VPLS service/architecture, network based VPN technologies with
VPLS, VPLS architecture models and functions.
Ould-Brahim, et al. May 2002 [Page 3]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
2.1 What is a VPLS Service?
Initially introduced in [RFC-2764], a Virtual Private LAN
service (VPLS) is a VPN service, which emulates a LAN segment
using IP based facilities. A VPLS can be used to provide what
is known as a Transparent LAN Service (TLS) used to
interconnect multiple customer edge devices (CEs) (e.g.,
bridges, router, routing switch) across a shared Ethernet and
IP/MPLS service provider network infrastructure. The primary
benefits of a VPLS are complete protocol transparency, which
are important both for multiprotocol transport and for
regulatory reasons in particular service provider contexts.
From an end-user's perspective, a VPLS ties geographically
separate sites together as if they share a common LAN segment.
A VPLS network is built by attaching customer LAN equipment
into the provider Ethernet ports, and interconnecting them to
other provider customer facing ports across the service
provider network. The end user does not need to know exactly
how the packets are delivered only that they are delivered
unmodified to the proper sites. Multiple VPLS services can be
provided on a single service provider network. A provider edge
device (PE) can support multiple VPLS services.
2.2 VPLS Architecture and Ethernet Scaling Issues
This sections describes the main issues related to Ethernet
technology in the VPN space:
o Customer Separation on a shared infrastructure
Ethernet was originally designed as an Enterprise Local Area
Network where support for customer separation is not a
requirement. As Ethernet deployment grew Enterprise customers
sought ways of separating different departments traffic on
single Ethernet based infrastructure. An enhancement to the
original standard provided an answer with the addition of
802.1Q VLAN(s) that allow for separate broadcast domains on the
one physical network. In its standard form 802.1Q VLAN(s)
identifiers can provide up to 4,096 unique VLANs and many
vendors have allowed for more than one 802.1Q identifier
(stacked VLANs) in a single packet thus increasing the number
of VLANs supported.
For service providers who may have many thousands of customers
this approach will not meet scaling objectives when used in a
network environment with a large number of VPLSs along with a
large number of other VPN services.
o MAC and VLAN Explosion
Ould-Brahim, et al. May 2002 [Page 4]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
The Ethernet MAC address is the unique global identifier for an
Ethernet device. The MAC address is used to identify a specific
device and is stored in Ethernet switches to identify the
location of a device. In a large network with many devices the
number of MAC addresses that need to be stored in an Ethernet
switch can be in the tens of thousands. The need to store all
device addresses on network nodes is a significant scaling and
reliability issue and is known as the MAC explosion issue.
A MAC "explosion" is a significant scaling issue in a Service
Provider's network. As traffic migrates to the Core of the
network, a large number of MAC addresses need to be learned.
This approach is essentially unmanageable in situations where a
failure of network devices impacts all devices whose addresses
are stored on that device.
A similar problem occurs with 802.1Q VLAN identifiers. Each
customer may have many VLAN identifiers, which can overlap with
other customers. Even with VLAN stacking the number of VLANs
lead to significant complexity in network design and
operational issues that limit the scale of the network.
A VPLS solution must aim towards isolating the MAC and VLAN
relevance to only the provider edge devices. All customer MAC
addresses and VLAN identifiers are stored in edge devices and
have only local significance. The intermediate network elements
are not required to be aware of MAC customer addresses or VLAN.
o Spanning Tree Protocol (STP) Issues
The STP was designed to eliminate loops in Ethernet networks to
ensure that there was always a path to every device on the
network. It creates two major limitations when building a
scalable VPLS solution on conventional PEs. Firstly, the STP
builds a "tree" structure in the network that block the
redundant links that create loops. This passive redundancy
wastes available bandwidth. Second, the STP is a convergence
type algorithm and in most cases requires an amount of time to
re-compute and converge after a network failure. During this
time the STP domain is not operational and no traffic is
forwarded. To overcome this problem, a VPLS solution should aim
towards building a fully redundant active network that utilizes
all available bandwidth and resources and where recovery from
failure occurs in fractions of a second.
o Traffic Engineering
When Ethernet was originally designed and to maintain
simplicity of the technology, traffic engineering was not a
significant requirement in enterprise Ethernet networks. With
the introduction of VLANs it was possible to define multiple
Ould-Brahim, et al. May 2002 [Page 5]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
STP domains in a single network. However, this approach does
not alleviate the fundamental limitations of STP. With Ethernet
and the STP network, traffic tends to migrate toward the core
of the network resulting in hot spots in some parts of the
network and under utilization in others. This is inefficient
and limits network scalability. Using traffic engineering
capabilities of MPLS for example in an IP based network, and
bundling bandwidth reservation to the logical tunnels should be
a design goal for a scalable network-based VPLS solution.
2.3 Network-based VPNs and VPLS Service
2.3.1 L2VPN Architectures
Layer-2 VPN extends the concept of traditional layer-2 circuits
to accommodate VPN constructs like membership, auto-discovery,
tunneling, and topology discovery. Two layer-2 VPN architectures
[L2VPN-ROSEN], [L2VPN-KOMP] are being proposed within provider
provisioned VPNs working group. Both are based on [MARTINI-
ENCAPS] for encapsulating layer-2 frames and they differ in the
way l2vpn services are built and auto-discovered and whether
signaling of l2vpn information (i.e., encapsulation) is
decoupled from the auto-discovery scheme.[L2VPN-ROSEN] is based
on [MARTINI-TRANSP] as a signaling scheme to establish layer-2
circuits. Further improvement to the scheme, [ROSEN-SIG]
introduced the concept of single sided signaling to accommodate
a VPLS service where endpoint need not have apriori knowledge of
each other. [L2VPN-KOMP] build the l2vpn through site indexation
scheme. Although these two architectures are still under
development within PPVPN WG, this document describes how logical
PE architecture can be adapted to a core network running either
[MARTINI-TRANSP] based l2vpn solution, or [L2VPN-KOMP]
architecture or running both types of architectures.
2.3.2 L2VPN Architectures and VPLS
An important objective of existing Provider Provisioned network-
based VPN solutions is to address VPN service and provider
network scalability requirements [PPVPN-REQ], [PPVPN-FRAME]. The
mechanisms developed within these solutions (e.g., [BGP-AD]) can
greatly benefit scaling VPLS architectures. VPN Scalability is
addressed mostly from aggregation and auto-discovery mechanisms.
Aggregation offers the ability to multiplex multiple VPNs over
shared network pipes. Auto-discovery provides the ability to
dynamically discover the VPN members and hence simplifies
service provisioning within the network (e.g., single ended
provisioning).
However, most of these network-based VPNs solutions and
techniques have been applied to a network model with the
assumption that the provider edge devices have all equal weight
Ould-Brahim, et al. May 2002 [Page 6]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
and are assumed to scale to a large number of VPNs. An Ethernet
VPLS based solution is required to meet the scaling requirement
where the PEs facing customer devices need to support a large
number of VPLS services where each VPLS has a large number of
ports attached to it. Furthermore, the PEs may also be used to
provide other VPN services (like layer-3 VPNs or point to point
L2VPNs). Scaling the number of VPLSs and port density on the PE
at the same time balancing the cost across provider edge devices
should be a main design goal for any VPLS solution.
2.4 VPLS and Logical PE Approach
One way of achieving both scaling and cost objectives is to
distribute some of the VPLS and VPN functions like MAC learning,
auto-discovery and aggregation among low-cost Ethernet based
provider edge devices (facing customer devices) and high
capacity core provider edge devices (attached to service
provider core network). A service provider may want to use a
"logical PE" function based on association between PE-facing
customer ports, called "PE-Edges", and core provider edge
devices, labeled as "PE-Core". Another objective of the logical
PE approach besides scaling is to be able to fit nicely with all
existing VPN technologies supported on the service provider
network [VPN-VR], [VPN-RFC2545bis], [L2VPN-KOMP], [L2VPN-ROSEN],
[OVPN].
2.5 VPLS Architecture Functions and VPLS Models
This sections describes the basic functions in a VPLS solution
and describes VPLS architecture models.
2.5.1 VPLS/L2VPN Reference Model
The VPLS network reference model follows the model described in
[PPVPN-REQ] and [VPLS-REQ]. A service provider may offer VPLS
services where a customer edge device (CE), which can be a
layer 2 Ethernet switch, a server, a router, a routing switch
or an Ethernet bridge is attached to a service provider edge
device. PEs are connected to internal provider devices (P)
which are considered VPLS unaware. This reference model is
similar to existing layer-3 and point-to-point reference
models.
2.5.2 VPLS Main Functions
A VPLS service should provide a set of functions, which mostly
are:
o MAC Learning
Ould-Brahim, et al. May 2002 [Page 7]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
MAC learning deals with the case where an Ethernet frame,
received from customer let say CE1, arrives at the ingress PE1
with a source MAC address A and a destination MAC address B. B
is not an entry in PE1 address look-up table. Mechanisms like
multicast, flooding can be used to inform each VPLS member PE
device of the unknown destination address frame, and eventually
the packet is received by B. Source MAC learning will be
accomplished by storing the source information with its route
(i.e., PE/tunnel) at each PE member of the VPLS. One mechanism
is to bound the service tunnel (e.g., VC Label in [MARTINI-
TRANSP]) with the source MAC address. Therefore future lookup
on a packet received by the PE having the learned MAC
destination address will produce the egress tunnels that can be
used to forward the packet to the proper egress PE device.
o Broadcast and Multicast Capability
A VPLS needs to have a broadcast capability. This is needed
both for broadcast frames, and for link layer packet flooding,
where a unicast frame is flooded because the path to the
destination link layer address is unknown.
o Tunneling
Like any VPN technology, VPLS solution has to provide
mechanisms by which customer traffic is separated. VPLS traffic
can be tunneled using tunneling mechanism such as Ethernet, GRE,
L2TP, MPLS, IPSec.
o VPLS Membership Determination
VPLS membership is analogous to that of layer-3 and layer-2
VPNs. It generally requires only knowledge of the local VPN
link assignments at any given VPLS edge node, and the identity
of, or route to, the other edge nodes in the VPLS. A common
mechanism to associate a customer facing port at the PE level
to the VPLS is to associate a VPN membership scheme to the VPLS
and any port member of a given VPLS will be assigned the same
VPN membership ID. Depending on the VPLS architecture, one
common VPN membership scheme is to use the VPN-IDs format [RFC-
2685].
o VPLS Topology and Loop Prevention
The topology of the VPLS could be manipulated by controlling
the configuration of peer nodes at each VPLS edge node combined
with an auto-discovery mechanism. In order to preclude the need
for traffic between two VPLS nodes to transit through another
VPLS node, which would then require the use of the Spanning
Tree protocol, fully mesh VPLS topology between PEs can be
used.
Ould-Brahim, et al. May 2002 [Page 8]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
o VPLS Auto-Discovery
Auto-discovery function (e.g., [BGP-AD]) is necessary for any
network-based VPNs in order to meet network scalability
requirements. VPLS architectures should support an automatic
mechanism that allows a particular VPLS to automatically
discover the VPLS members configured on a given PE. It may
happen that the auto-discovery mechanism extends to also
provide information such as encapsulation scheme to be used to
forward private frames across the tunnels (e.g., [KOMP-L2VPN]).
2.5.3 VPLS Model: Full Mesh Point-to-Point Circuits
The Full Mesh Point-to-Point VPLS model suggests that PE
Ethernet ports member of a VPLS are connected in a fully mesh
topology across the service provider network. The PE has the
functionality to receive frames from the attached CEs and make
a decision to what egress tunnel the frame should be forwarded.
MAC learning is achieved through the data plane through
broadcast/flooding on each per VPLS circuit (within the VPLS
domain). When MPLS is used as the tunneling mechanism, bi-
directional LSPs need to be established between each VPLS
endpoint.
2.5.4 Virtual Bridge/Switch Model
The virtual bridge/switch model is similar to layer-3 VPN
virtual router/VRF models except that each VPLS edge node
implements link layer forwarding rather than network layer
forwarding. Virtual bridge/switches are connected through
point-to-point private tunnels. As such, most of the layer-3
VPN tunneling and configuration mechanisms discussed in [PPVPN-
FRAME] can also be used for virtual switches, with the
appropriate changes to accommodate link layer, rather than
network layer, packets and addressing information.
2.5.5 Virtual Switch with Full Mesh Point-to-Point Model
It is possible to combine a virtual switch model with a full
mesh point-to-point tunnels. One approach is to use virtual
switch model based on VPLS membership for broadcast, user
unknown, and multicast, and full-mesh for known Unicast packet.
3. Logical PE Architecture
This section describes the LPE architecture with its related
building blocks and functions.
3.1 VPLS LPE Reference Model
Ould-Brahim, et al. May 2002 [Page 9]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
The logical PE architecture addresses network scenarios when
PEs facing customer devices is connected to some switched
Ethernet transport networks or uplinks attached to other PEs
which themselves are attached to a core network infrastructure.
In the example illustrated in figure 1, from a conceptual view
PEs facing customer equipment (and not attached to the core
network) combined with PE attached to the core network
represent from a conceptual view a "logical PE" construct where
many VPLSs along with other layer-2 and layer-3 VPN services
are attached to it.
+---+
+----+ +---+ +---+ |CE4|
|CE-2| | P |....| P |\ +---+
+----+ /+---+ +---+ \ |
\ PE2 / \ | +---+
\ +-----+ +-------+ |CE5|
\| | | PE4 | +---+
PE1 | | / +-------+ /
+---+ /+-----+ / | +-/--+
+---+ | | / | | | |
|CE1|-| |-{ uplinks or} CORE |{uplinks or}-| PE5|
+---+ | |{L2 Networks} Networks |{L2 networks}| |
+---+ /\ \ | +----+
/ \ +-----+ +---+ | \\
/ \| | |PE8| | +---+
+---+ | PE3 | +---+ | |CE6|
+---+ | | /+-----+ / | +---+
|CE8|---|PE7| / \ / +---+
+---+ +---+ / +---+ +---+ |PE6|
+---+ | P |....| P | +---+\
|CE3| +---+ +---+ +-/-+ \+---+
+---+ |CE9| |CE7|
+---+ +---+
Figure 1: Example of VPLS service
To highlight the case described in figure 1, we label each PE
within the network as a PE-Edge or PE-Core depending if the PE
is attached to the core network or not (and depending if there
is a functional relationship between the PE-Edge and the PE-
Core). PEs who do not participate in these schemes are not
labeled. This model extends the previous L2VPN model described
in the section 2.5.1. Using figure 1, PE1, PE7, PE5, PE6 can be
labeled PE-Edges while PE2, PE3, PE4, and PE8 are labeled PE-
Cores.
An example of logical PEs is shown in figure 2 and 3.
+---+ +---+
Ould-Brahim, et al. May 2002 [Page 10]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
| P |....| P | +---+
+---+ +---+ /|CE5|
+---+ / \ / +---+
|CE2|\ +-----+ +-----+ +---+
+---+ \| PE1 | | |----| |
/| PE2 | | PE4 | |CE6|
/ +-----+ VPLS/LPE | PE5 |----| |
+---+ | Solution +-----+ +---+
|CE1| +-----+ |
+---+ | PE7&| +-----+ +---+
/| PE3 | |PE8&6|----|CE7|
+---+/ +-----+ +-----+ +---+
|CE3| | \ / \
+---+ | +---+ +---+ +---+
+---+ | P |....| P | |CE9|
|CE8| +---+ +---+ +---+
+---+
Figure 2: Logical Grouping between PE Edges and PE Cores
+---+ +---+
| P |....| P | +---+
+---+ +---+ /|CE5|
+---+ / \ / +---+
|CE2|\ +-----+ +-----+ +---+
+---+ \| LPE1| | |----| |
/| | |LPE3 | |CE6|
/ +-----+ VPLS | |----| |
+---+ | Solution +-----+ +---+
|CE1| +-----+ |
+---+ | LPE2| +-----+ +---+
/| | |LPE4 |----|CE7|
+---+/ +-----+ +-----+ +---+
|CE3| | \ / \
+---+ | +---+ +---+ +---+
+---+ | P |....| P | |CE9|
|CE8| +---+ +---+ +---+
+---+
Figure 3: Network reference using using logical PEs
Within the LPE reference model, a CE can be attached to one or
more than one PE-Edges. Most likely PE-Cores are highly
scalable routers/Ethernet switches (with IP/MPLS based
capabilities). PE-Cores like any other PEs can provide VPLS,
layer-2, and layer-3 VPN services.
PE-Core is associated with only one logical PE. An LPE may
contain more than one method of tunneling or switching
mechanism. A single LPE alone may even implement a separate
Ould-Brahim, et al. May 2002 [Page 11]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
low-scale L2VPN. PE-Edge is associated with only one logical
PE. Logical PE expresses the relationship between PE-Edge
devices and PE-Core devices. Note that a PE core can act as any
conventional PE providing VPN services.
Logical PE concept can be used in situations requiring high
scalability in terms of number of VPLSs and port density while
aiming towards reusing low-cost PE devices. LPE can also be
used in situations where the provider PEs don't have equal
weight with respect to resource availability and full VPN
functionality supported.
3.2 Logical PE
A logical PE (LPE) is a PE constructed by distributing VPLS
functions across PE-Edges and PE-Cores interconnected by
switched Ethernet transport network(s) or one or more than one
uplink.
LOGICAL PE
+-------------------------------------------+
| |
| +---------+ |
| +---------+ | | |
+----+ | | | | | |
|CE-1|-|-| PE-Edge |--{ Distributed }--| PE-Core |-|--{Core}...
+----+ | | (n) | {VPLS Functions} | (m) | |
| +---------+ | | |
| | +----|----+ |
| | | |
+------|-----------------------------|------+
| |
+----+ +----+
|CE-2| |CE-3|
+----+ +----+_
Figure 4: Logical PE with PE-Edges and PE-Cores
Within the Logical PE concept, the PE-Edge is connected to the
CE through Ethernet ports (which can be logical ports) called
LPE endpoints. An LPE endpoint can be defined on the PE-Core or
the PE-Edge. An LPE endpoint where the CE is attached to is the
demarcation point between the customer and the VPLS service.
The PE Core device is connected to the Core network. Multiple
PE-Edges can be connected to one or more PE-core.
Ould-Brahim, et al. May 2002 [Page 12]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
PE-Edges interoperate with other PE-Edges between different
Logical PEs and within the same Logical PE. PE-Edges
interconnected through a switched Ethernet transport domain can
inter-operate without involvement of PE-Cores. A network
consists of only PE-Edges can also deliver low-scale VPLS
services. The PE-Cores provide intermediary functions to enable
PE-Edges to interoperate with PEs outside their local Switched
Ethernet Transport domain. This may be with another PE or with
PE-Edges in other Logical PEs, with PE-Edges in the same LPE
but belonging to different switched Ethernet transport domain.
Each PE-Edge/PE-Core is associated with a set of VPLS services.
PE-Core implements a layer-2 VPN/VPLS solution and can offer
layer-3 VPNs. PE-Cores can also offer VPLS services for
directly connected CEs. Finally, when LPEs are used they can
communicate with conventional PE devices that are not
associated with any PE-Edges.
PE-Cores are connected in a fully mesh topology. PE-Edges sees
only PE-Cores and other PE-Edges in the same switched Ethernet
transport domain, therefore there is no direct full meshing
between PE-Edges across the core network, and any inter-site
connectivity between PE-Edges across the core network will
traverse the PE-Cores. However, any inter-site connectivity
within the logical PE need not involve other PEs.
3.3 Network Connectivity within the Logical PE
Various network configurations can be implemented within the
Logical PE. This section describes some of these configurations
(the LPE scheme is flexible enough to support many other
configurations).
3.3.1 PE-Edges connected directly to the PE-Core
In this configuration the PE-Edges are connected directly to
the PE-Cores using single line Ethernet trunks. For enhanced
reliability the PE-Edges can be connected to the PE-Core via
two Ethernet trunks where the PE-Core which can be used for
load sharing and for recovery from link and device failures.
3.3.2 Multiple Broadcast Domains in Logical PE
In this case, a single PE-Core can be connected to PE-Edges via
multiple Switched Ethernet Transport domains. An implementation
example of Switched Ethernet Transport domain is Resilient
Packet Rings (RPR).
3.4 Logical PE Function Distribution
Ould-Brahim, et al. May 2002 [Page 13]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
Logical PE function distribution depends on the VPLS
architecture model used. In most cases, the PE-Edge manages the
SLA including bandwidth policing, traffic classification and,
QoS, customer Ethernet frame encapsulation and MAC and VLAN
learning. The PE-Core maintains membership information and
performs VPN membership determination and dissemination to all
the PE-Cores members of the same VPLS. By using a signaling
and/or an auto-discovery mechanism, the PE-Core distributes the
VPN and/or endpoint related information to all LPEs. Such
distribution can be constrained to only the LPEs that have VPLS
membership in common.
Following are a list of PE functions that can be distributed in
forming a LPE:
o MAC learning
o Participation in customer Spanning Tree Protocol
(if needed).
o Tunneling within LPE.
o Service label de-multiplexing within LPE.
o PE-Edge/PE-Core auto-discovery protocol (LPE-AD).
o Customer traffic policing and shaping (if necessary)
o Customer VLAN processing.
o Customer traffic priority handling.
o VPLS configuration
o VPLS membership determination
o Tunneling between PEs (MPLS/IP based)
o Service label de-multiplexing between PEs.
o VPLS auto-discovery between PEs.
o VPLS signaling between PEs (when required).
3.4.1 PE-Edge Functions
Typically a PE-Edge being a bridge, a routing switch, or a
router will perform regular Ethernet based functions. Among
these functions:
o MAC learning
o Participation in customer Spanning Tree Protocol (if needed).
o VPLS membership determination
o PE-Edge/PE-Core auto-Discovery protocol (LPE-AD).
o Tunneling within the LPE.
o Service label de-multiplexing within LPE.
o Customer traffic policing and shaping (if necessary)
o Customer VLAN processing.
o Customer traffic priority handling.
o VPLS configuration (depending on the configuration model).
3.4.2 PE-Core Functions
Ould-Brahim, et al. May 2002 [Page 14]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
A PE-Core being attached to an IP/MPLS network and providing
other VPN service than just VPLS should provide the following
functions:
o VPLS membership determination.
o Tunneling between PEs (MPLS/IP based).
o Service label de-multiplexing between PEs.
o VPLS Configuration.
o VPLS auto-discovery between PEs.
o VPLS signaling between PEs (when required).
o PE-Edge/PE-Core auto-discovery protocol (LPE-AD).
3.5 Logical PE Auto-Discovery Protocol (LPE-AD)
A lightweight protocol needs to be established between the PE-
Edge and PE-Core for VPLS information exchange (e.g.,
membership, tunneling, etc). An example of functions provided
by an LPE-AD:
o Notification of endpoint Addition/Deletion/Modification of
VPLSs.
o Service Label/Tunnel information exchange at the LPE level.
o Addition/Deletion/Modification of PE-Edges.
3.6 VPLS Membership Determination
A VPLS service visible at the LPE level can be created either
at the PE-Edge or the PE-Core or both. A VPLS solution is a
port-based VPN type architecture. Therefore, the VPN membership
is accomplished by configuring customer facing ports and
associating the port/endpoints to the VPLS VPN membership
scheme. Typically a VPLS is associated with a VPN-ID, which
uniquely identifies the VPLS across the service provider
network. An example of VPN-ID format can be found in [RFC-
2685]. This draft doesn't preclude the use of other schemes for
VPLS membership as those used in layer-3 and optical VPNs
(e.g., route-target schemes).
It may happen that a VPLS has dual membership schemes within
the LPE and inter-LPE on the core network. In this case, a VPN
membership mapping function is needed at the LPE level.
3.7 Logical PE Forwarding and Auto-Discovery
A Logical PE can be applied to a fully meshed point-to-point,
virtual switching model, or a hybrid VPLS models. VPLS or VPLS
endpoints can be reflected on the PE-Core. For a full mesh
point to point, VPLS endpoints defined on each PE-Edge will
have a logical representation "virtual endpoint" within the PE-
Core. Therefore a given PE-Core will reflect multiple VPLS
services where each service has multiple endpoints configured
on multiple PE-Edges. Each virtual endpoint on the PE-Core is
Ould-Brahim, et al. May 2002 [Page 15]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
fully meshed with other virtual endpoints on the remote PE-
Cores. Another approach similar to [KOMP-DTLS]is to
consider the PE-Edge connectivity as site connectivity and the
endpoint is associasted with the site (PE-Edge) connectivity.
3.7.1 VPN Auto-Discovery on the Core Network
On the core network, point-to-point circuits can be created
using either [L2VPN-KOMP], or [Martini-TRANSP] type
architectures (e.g., [L2VPN-ROSEN]). For example, [MARTINI-
TRANSP] can be used to create VC LSPs between virtual
endpoints. In this scheme, the auto-discovery mechanism is
decoupled from signaling. LDP-DU can be used where the VFEC
will carry VPLS membership scheme (e.g., VPN-ID) and relevant
information about VPLS endpoints (new VFEC parameter IDs can be
defined for carrying such information).
BGP based auto-discovery mechanism can also be used in the core
to inform each PE about VPLS membership information (e.g.,
described in [BGP-AD], and [L2VPN-KOMP]). This draft doesn't
preclude other VPN auto-discovery mechanisms (e.g., LDP based).
3.7.2 LPE Forwarding Algorithm for [MARTINI-TRANSP] on the Core
The following algorithm can be used to forward Unicast Ethernet
frames to the remote PE-Edges. It is assumed that MPLS labels
are used as de-multiplexing scheme at the PE-Edge and PE-Core.
Tunneling is used on the PE-Core (can be IP or MPLS based).
Ethernet/MPLS optionally be used between PE-Edge and PE-Core.
The LPEs are connected through a full mesh of tunnels (e.g.,
traffic engineered tunnels, RSVP-TE/CR-LDP traffic engineered
tunnels).
1. A VPLS is created on the PE-Edge.
2. Each VPLS endpoint is mapped to a virtual endpoint on the
PE-Core.
3. Each PE-Core VPLS virtual endpoint is associated with its
membership scheme.
4. LPE-AD mechanism is run between the PE-Edge
and PE-Core.
5. LDP-DU signaling is used by PE_Cores to establish VC LSP
between VPLS virtual endpoints across the core.
6. A customer frame is received on a given VPLS port on
the PE-Edge.
7. The packet is labeled to reach the virtual endpoint on the
PE-Core.
8. The local PE-Core received the packet swap the service
label with the remote egress VC LSP label.
9. The labeled packet is then tunneled to the remote PE-Core.
10. The remote PE-Core performs a lookup on the service label,
Ould-Brahim, et al. May 2002 [Page 16]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
identifies the egress port where the PE-Edge is attached
11. The PE-Core swaps the corresponding PE-Edge service label
and forward the packet.
12. Once the packet is received by the PE-Edge it will then be
forwarded to the egress port.
3.7.3 LPE Forwarding Algorithm using [L2VPN-KOMP] on the Core
The following algorithm can be used to forward unicast Ethernet
frames to the remote PE-Edges when [KOMP-L2VPN] solution is
used in the core network (PE-Cores). The LPEs are connected
through a full mesh of point to point tunnels (e.g., traffic
engineered tunnels using RSVP-TE/CR-LDP).
1. A VPLS is created on the PE-Edge.
2. Each VPLS endpoint is mapped to a virtual endpoint on the
PE-Core.
3. The virtual endpoint is considered private site attachment
to the logical PE.
4. An auto-discovery mechanism is run between the PE-Edge
and PE-Core.
5. Each PE-Core VPLS virtual endpoint is associated with its
[KOMP-L2VPN] configuration information (e.g., CE_ID,
CE_range, label_base, route-target export and import list
for the VPLS virtual forwarding table.
5. BGP auto-discovery is used on the core network informing
all the PE-Core about the virtual endpoints.
6. A customer frame is received on a given VPLS port on
the local PE-Edge.
7. The packet is labeled with a VPLS service label to reach
the virtual endpoint on the PE-Core.
8. The local PE-Core look up the label, identify the virtual
endpoint, lookup the virtual forwarding table and push the
two labels onto the packet (the top label for the LSP to
reach the egress PE-Core and the inner label is for
reaching the virtual endpoint interface).
10. The remote PE-Core performs a lookup on the service label,
and identify the egress virtual endpoint. If the endpoint is
located on the PE-Edge, the PE-Core swaps the service
label with the remote PE-Edge VPLS service label.
11. The labeled packet is then tunneled to the remote PE-Edge.
12. Once the packet is received by the PE-Edge it will then be
forwarded to the egress port.
Another approach with [KOMP-L2VPN] is to consider the PE-
Edge/PE-Core connectivity as a site connectivity. This approach
avoids configuring/learning about virtual endpoints (assuming
only Ethernet frames are traversing this link). Example of such
scheme can be found in [KOMP-DTLS]. Decouple Transparent LAN
model (DTLS) extends the [KOMP-L2VPN] architecture to
Ould-Brahim, et al. May 2002 [Page 17]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
accommodate a VPLS service using the LPE network reference
model.
3.7.4 Virtual Switch Proxy (VSP)
A virtual switch proxy can be created on the PE-Core for each
VPLS defined on the PE-Edge. Virtual switch proxies are fully
meshed within the core network. Traffic destined to sites
across the core network will traverse the virtual switch proxy.
VSP LSPs can be established based on the VPLS/VS membership.
MAC learning is still achieved at the PE-Edge level. The model
can also extend to create virtual switches at the granularity
of PE-Edge connectivity, and treats each PE-Edge connectivity
as site connectivity.
LPE Forwarding for user Unknown Unicast, Broadcast, and
Multicast Packets using VSP type approach (with no link layer
forwarding):
In the case of unknown unicast, broadcast and multicast packet
a VSP type approach can be used as described below:
1. PE-Edge forward the packet to the PE-Core.
2. The PE-Core identifies the VPLS membership of the packet,
and finds that it needs to identify the set of PE-Cores
members of the same VPLS (i.e., having at least one port
member of that VPLS).
3. Pe-Core broadcast/multicast the packet to this set of
PE-Cores.
4. PE Core then appends the service label associated with the
membership scheme (i.e., VC GROUP) and tunnel the packet to
the far end LPEs.
5. When the egress PE-Core receives the MPLS encapsulated
packet, it will examine the service label and since it is
related to a set of VPLS members, it will map the service
label to a set of destination PE-Edges/PE-Edge endpoints.
6. When the packet reaches the egress PE-Edge, the PE-Edge
learns the binding between source MAC address and the
PE-Core within the LPE.
3.8 LPE Configuration Models
A VPLS service can be configured on the PE-Edge or PE-Core or
using a service provider network management system to configure
both PE-Edge and PE-Core. The LPE-AD auto-discovery conveys
configuration data between PE-Edge and PE-Core. The information
needed on the PE-Edge/PE-Core relates to the VPLS membership
scheme, the port/endpoint configuration. It may happen that the
a different membership scheme is used intra-LPE than the
membership used inter-LPE, in this case a mapping function is
Ould-Brahim, et al. May 2002 [Page 18]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
used to maintain unique VPLS membership across the service
provider network.
3.9 Quality of Service
Intra-LPE or inter PE-Core connectivity can be traffic
engineered. RSVP-TE/CR-LDP can be used at the core and/or
switched Ethernet transport. Customer traffic can be policed
and shaped at the access port on the PE-Edge. The customer
traffic is classified on the PE-Edge, and is mapped onto the
endpoints VC-Labels. Most generally priority configured per
access port (at the PE-Edge level) maps the customer 802.1p
traffic to the network priority tunneling. This mapping is
based on customer VPLS SLA.
3.10 LPE Resiliency
VPLS/L2VPN architecture resiliency is key to ensure service
availability in presence of failures. Indeed, VPLS, like any
layer-2 scheme is subject to failures like link, trunk, node
failures.
Within the logical PE, failures can appear at the PE-Edge, PE-
Core, the PE-Edge/PE-Core interconnecting link or switched
Ethernet network. Dual PE-Cores can be used to protect the LPE
failure and VPLS failures. Although using two dual PE-Cores,
the LPE appears to the network as a single LPE.
3.11 Security Considerations
VPLS security needs to be considered within the LPE and inter-
LPEs.
Within the LPE Customer traffic needs to be separated within
the LPE. Ethernet Qtag, MPLS/IP based tunneling can be used.
The level of data path security is same as ATM or FR networks.
This document doesn't preclude the use of encryption mechanisms
within the LPE (although not recommended, particularly if
Ethernet switched transport is used).
Inter-LPE security is provided within the layer-2 VPN
architecture. A range of security parameters can be used, from
using link layer type security to full encryption and
authentication. An inter-domain solution usually requires some
security mechanism across provider boundaries. For full inter-
provider security (only when needed), IPSec tunneling mechanism
is recommended.
4. References
Ould-Brahim, et al. May 2002 [Page 19]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
[BGP-AD] Ould-Brahim, H,. et al., "Using BGP as an Auto-
discovery Mechanism for network-based VPNs", draft-ietf-
ppvpn-bgpvpn-auto-00.txt, work in progress.
[ETHER-REQ] Ould-Brahim, H., et al, "Service Requirements for
Ethernet based L2VPNs", draft-ouldbrahim-ethernet-l2vpn
requirements-00.txt, work in progress, July 2001.
[KOMP-DTLS] Kompella, K., et. al., "Decoupled Transparent LAN
Services", draft-kompella-ppvpn-dtls-00.txt,
October 2001, work in progress.
[L2VPN-ROSEN] Rosen, E., et al., "An Architecture for L2VPNs",
draft-ietf-ppvpn-l2vpn-00.txt, July 2001,
work in progress.
[L2VPN-KOMP] Kompella, K., et al., "MPSL based Layer-2 VPNs",
draft-kompella-ppvpn-l2vpn-00.txt, June 2001,
work in progress..
[MARTINI-ENCAPS] Martini, L., et al. "Encapsulation Methods for
Transport of Layer 2 Frames Over MPLS", draft-martini-
l2circuit-encap-mpls-03.txt, work in progress.
[MARTINI-TRANSP] Martini, L., et al., "Transport of Layer-2
Frames over MPLS", draft-martini-l2circuit-trans-mpls-
07.txt, work in progress, July 2001.
[PPVPN-REQ] Carugi, M., et al., "Service requirements for
Provider Provisioned Virtual Private Networks", work in
progress.
[PPVPN-FRAME] Callon, R., et al., "A Framework for Provider
Provisioned Virtual Private Networks", July 2001, work in
progress.
[PWE3-REQ] Xiao, X., et al., "Requirements for Pseudo-Wire
Emulation Edge-to-Edge (PWE3)", draft-ietf-pwe3-
requirements-01.txt, July 2001.
[OVPN] Ould-Brahim, H., Rekhter, Y. et al., "BGP/GMPLS Optical
VPNs", draft-ouldbrahim-bgpgmpls-ovpn-02.txt, work in
progress.
[RFC-2685] Fox B., et al, "Virtual Private Networks
Identifier", RFC 2685, September 1999.
[RFC-2764] Gleeson, B., et al., "A Framework for IP Based
Virtual Private Networks", February 2000.
[ROSEN-SIG] Rosen, E., "Single Sided Signaling for L2VPN",
Ould-Brahim, et al. May 2002 [Page 20]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
draft-rosen-ppvpn-l2-signaling-00.txt, October 2001,
work in progress.
[VPLS-LASS] Lasserre, M., et al., "Transparent VLAN Services
over MPLS", draft-lasserre-tls-mpls-00.txt, August 2001.
[VPLS-REQ] Waldemar, A., et al., "Requirements for Virtual
Private LAN Services (VPLS)", draft-augustyn-vpls
requirements-00.txt, October 2001.
[VPLS-VPSN] Virtual Private Switched Network Services over MPLS
Network", draft-vkompella-ppvpn-vpsn-mpls-00.txt, July 2001.
[VPN-RFC2547bis] Rosen, E., et al., "BGP/MPLS VPNs", draft-
draft-ietf-ppvpn-rfc2547bis-00.txt, July 2001, work in
progress.
[VPN-VR] Ould-Brahim H., et al., "Network-based IP VPN using
Virtual Routers", draft-ietf-ppvpn-vr-00.txt, July 2001,
work in progress.
[802-P] IEEE Std 802.1Q-1998
5. Acknowledgments.
6. Intellectual Property Considerations
Nortel Networks may seek patent or other intellectual property
protection for some of all of the technologies disclosed in
this document. If any standards arising from this document are
or become protected by one or more patents assigned to Nortel
Networks, Nortel Networks intends to disclose those patents and
license them on reasonable and non-discriminatory terms.
7. Author's Addresses
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
Email: hbrahim@nortelnetworks.com
Vasile Radoaca
Nortel Networks
600 Technology Park
Billerica, MA 01821
vasile@nortelnetworks.com
978-288-6097
Ould-Brahim, et al. May 2002 [Page 21]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
Michael Chen
Nortel Networks
4010 E Chapel Hill-Nelson Hwy
Research Triangle Park, NC 27709 USA
Phone: +1 (919) 997 3840
Email: mchen@nortelnetworks.com
Ould-Brahim, et al. May 2002 [Page 22]
draft-ouldbrahim-l2vpn-lpe-00.txt November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
Ould-Brahim, et al. May 2002 [Page 23]