Provider Provisioned VPN WG Dinesh Mohan [Editor]
Internet Draft Michael Chen
draft-ouldbrahim-l2vpn-lpe-02.txt Vasile Radoaca
Expiration Date: August 2002 Hamid Ould-Brahim
Nortel Networks
Pascal Menezes
Terabeam Networks
March 2002
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
Ould-Brahim, et al. Expires August 2002 [Page 1]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
Service Providers offer Virtual Private LAN Service (VPLS), also
known as Transparent LAN Service (TLS), as part of their Layer 2
VPN offering. VPLS simulates an Ethernet Virtual 802.1d bridge
for given set of customers across metro or wide area networks.
From an end-user's perspective, a VPLS ties geographically
separate customer sites together as if they share a common LAN
segment. A VPLS service 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 metro or wide area network. Such providerÆs edge
devices store information related to customer VPLS domains and
are responsible for making forwarding decisions related to
customers VPLS traffic. A problem arises when there is need to
provide a network-based VPLS solution that scales to a large
number of VPLSs, each with potentially a large number of
customer ports while at the same time providing a solution that
is cost-effective and reliable for the Service ProvidersÆ access
infrastructure. This draft introduces the "Logical PE"
architecture to effectively address the scalability of VPLS
services.
Table of Contents
Abstract
1. Conventions used in this document........................3
2. Introduction.............................................3
2.1 What is VPLS Service?...................................4
2.2 VPLS/L2VPN Reference Model..............................4
2.3 VPLS Functions..........................................4
2.3.1 VPLS Control Plane Functions..........................5
2.3.1.1 VPLS Membership Auto-discovery......................6
2.3.1.2 VPLS Transport Tunnel Signaling.....................6
2.3.1.3 VPLS Topology & Loop Prevention.... ................6
2.3.1.4 Service Label Signaling.............................7
2.3.2 VPLS Forwarding Plane Functions.......................7
2.3.2.1 MAC Learning........................................7
2.3.2.2 Customer VLAN Processing............................7
2.3.2.3 Customer Packet Replication/Flooding................7
2.3.2.4 Virtual Bridging/Switching..........................8
2.3.2.5 Customer Packet Encapsulation.......................8
2.3.2.6 Service Label De-multiplexing.......................8
2.3.2.7 VPLS Resiliency.....................................8
2.3.2.8 VPLS QoS............................................9
2.3.3 VPLS Management Plane & OAM&P Functions..............10
2.3.3.1 VPLS Configurations................................10
2.3.3.2 Operations and Maintenance Functions...............10
3. VPLS Deployment & Scaling Issues........................10
4. Logical PE (LPE) Architecture...........................11
4.1 LPE Definition.........................................11
4.2 LPE Functional Elements................................13
4.2.1 LPE VPLS Configurations..............................13
Ould-Brahim, et al. Expires August 2002 [Page 2]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
4.2.2 LPE VPLS Auto-discovery..............................13
4.2.3 LPE VPLS Topology & Loop Prevention..................14
4.2.4 LPE MPLS MAC Learning................................14
4.2.5 LPE Customer Packet Encapsulation....................14
4.2.6 LPE Service Label De-multiplexing....................15
4.2.7 LPE VPLS Resiliency..................................15
4.2.8 LPE VPLS QoS.........................................15
5. LPE VPLS Reference Model................................16
6. LPE Functional Distribution Example.....................17
6.1 PE-Edge Functions......................................18
6.2 PE-Core Functions......................................18
7. Security Considerations.................................19
8. References..............................................19
9. Acknowledgments.........................................21
10. Intellectual Property Considerations...................21
10. Author's Addresses.....................................21
Full Copyright Statement...................................22
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
Service Providers offer Virtual Private LAN Service (VPLS), also
known as Transparent LAN Service (TLS), as part of their Layer 2
VPN offering. VPLS simulates an Ethernet Virtual 802.1d bridge
for given set of customers across metro or wide area networks.
From an end-user's perspective, a VPLS ties geographically
separate customer sites together as if they share a common LAN
segment. A VPLS service 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 metro or wide area network. Such providerÆs edge
devices store information related to customer VPLS domains and
are responsible for making forwarding decisions related to
customers VPLS traffic. A problem arises when there is need to
provide a network-based VPLS solution that scales to a large
number of VPLSs, each with potentially a large number of
customer ports while at the same time providing a solution that
is cost-effective and reliable for the Service ProvidersÆ access
infrastructure. This draft introduces the "Logical PE"
architecture to effectively address the scalability of VPLS
services.
Ould-Brahim, et al. Expires August 2002 [Page 3]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
2.1 What is VPLS Service?
Initially introduced in [RFC-2764], and adopted in [VPLS-REQ],
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 multi-protocol
transport and for regulatory reasons in the Service Provider
context.
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/L2VPN Reference Model
The VPLS service reference model follows the models 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 (PE). PEs are connected to providerÆs internal devices
(P) which are considered VPLS unaware. P devices participate in
providing tunnels/LSP between PE devices across the providers
packet switched IP/MPLS core network infrastructure. This
reference model is similar to existing layer-3 and point-to-
point reference models.
2.3 VPLS Functions
It is possible to describe the VPLS functions based on a
functional model as shown in Figure 1.
+----------------------+--------------------------------+
| Service Quality | Quality of Service |
|----------------------+--------------------------------|
| | Resiliency |
Ould-Brahim, et al. Expires August 2002 [Page 4]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
|----------------------+--------------------------------|
| Provisioning | Static Configurations |
|----------------------+--------------------------------|
| | Dynamic Configurations |
|----------------------+--------------------------------|
| Auto-Discovery | Node |
|----------------------+--------------------------------|
| | VPLS membership |
|----------------------+--------------------------------|
| Signaling | Transport tunnel |
|----------------------+--------------------------------|
| | Service Multiplexing |
|----------------------+--------------------------------|
| Encapsulation | Tunneling |
|----------------------+--------------------------------|
| | Service Multiplexing |
|----------------------+--------------------------------|
| Reachability | MAC Learning |
|----------------------+--------------------------------|
| | VLAN Processing |
|----------------------+--------------------------------|
| Management | OAM |
+----------------------+--------------------------------+
Figure 1: VPLS/L2VPN Functional Model
This section describes the functional elements based on the
model in Figure 1 for a VPLS solution that can be classified
under control plane, forwarding plane and Management/OAM&P
plane. These functional elements are:
o VPLS membership auto-discovery
o Transport tunnel signaling
o VPLS Topology & Loop Prevention
o Service label signaling
o VPLS Configurations
o MAC learning
o Customer VLAN processing
o Packet Replication/Flooding
o Virtual Bridging/Switching
o Customer packet encapsulation
o Service label de-multiplexing
o Resiliency
o Customer traffic prioritizing, policing, and shaping
o Operations and Maintenance
2.3.1 VPLS Control Plane Functions
2.3.1.1 VPLS Membership Auto-discovery
Ould-Brahim, et al. Expires August 2002 [Page 5]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
Auto-discovery function (e.g., [BGP-AD]) is necessary for any
network-based VPNs in order to meet network scalability
requirements. For VPLS, auto-discovery allows a VPLS aware
device to find all other VPLS aware devices that contain the
same VPLS membership. It may happen that the auto-discovery
mechanism extends to also provide other VPLS information such
as encapsulation/multiplexing scheme to be used to forward
private frames across the tunnels (e.g., [L2VPN-KOMP]). BGP
based auto-discovery mechanism can also be used in the core to
inform each VPLS aware device about VPLS membership information
(e.g., described in [BGP-AD], and [L2VPN-KOMP]).
2.3.1.2 VPLS Transport Tunnel Signaling
VPLS traffic between VPLS aware devices can be tunneled across
Service Provider IP/MPLS packet switched core using tunneling
mechanism such as MPLS, Qtag, GRE, L2TP, and IPSec etc.
In the core network, point-to-point tunnels can be created
using either [L2VPN-KOMP], or [MARTINI-TRANSP] type
architectures (e.g., [L2VPN-ROSEN]). It is possible that the
transport tunnel signaling might be integrated with auto-
discovery mechanism or decoupled with auto-discovery
mechanisms. When using MPLS as the tunneling mechanism, bi-
directional LSPs need to be established between each VPLS
endpoint.
2.3.1.3 VPLS Topology & Loop Prevention
In order to preclude the need for traffic between two VPLS
aware devices to transit through another VPLS VPLS aware
device, which would then require the use of the Spanning Tree
protocol; fully meshed point-to-point VPLS topology between VBs
can be used. 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).
Another topology that can be used is virtual bridge/switch
model that is similar to layer-3 VPN virtual router/VRF models
except that each VPLS edge device 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
Ould-Brahim, et al. Expires August 2002 [Page 6]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
addressing information. Care must be taken to avoid formation
of forwarding loops.
2.3.1.4 Service Label Signaling
Signaling is required to distribute the Service Label in a VPLS
solution. Service Label is used at VPLS aware egress device to
multiplex multiple VPLS services over the VPLS transport
tunnels and at VPLS aware egress device to distinguish
individual emulated VPLS Ethernet frames within a single VPLS
transport tunnel and the source VPLS aware device.
Service Label signaling can be carried out using mechanism
specified in [MARTINI-TRANSP], [L2VPN-KOMP] etc.
2.3.2 VPLS Forwarding Plane Functions
2.3.2.1 VPLS MAC Learning
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 broadcast/multicast flooding can be used to inform every
other PE device in the same VPLS 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 path (i.e., PE/tunnel) at each PE member
of the VPLS. One mechanism is to bind 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 a VC LSP that
can be used to forward the packet to the proper egress PE
device.
2.3.2.2 Customer VLAN Processing
A customer VLAN identification, using some scheme such as IEEE
802.1q tags, customers port configurations or other means,
allow for separate broadcast domain within the same customer
network. A VPLS service can be extended to recognize customer
VLAN identification in context of the VPLS that the VLAN is
part of. Each of these customer domains needs to appear as a
separate broadcast domain within the VPLS solution. However the
VPLS service should not constrain the customerÆs ability to
configure VLAN topologies, VLAN tags etc.
2.3.2.3 Customer Packet Replication/Flooding
Ould-Brahim, et al. Expires August 2002 [Page 7]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
A VPLS needs to have a broadcast capability. This is needed
both for broadcast and multicast frames, and for link layer
packet flooding, where a unicast frame is flooded because the
path to the destination link layer address may be unknown.
2.3.2.4 Virtual Bridging/Switching
The three functions listed under the Sections 2.3.2.1, 2.3.2.2
and 2.3.2.3, essentially allow the VPLS to offer Virtual 802.1d
Bridging/Switching capabilities. It is called Virtual since
bridging/switching occurs on across a core IP/MPLS network
infrastructure.
2.3.2.5 Customer Packet Encapsulation
To forward an Ethernet frame, a VPLS aware device must be able
to associate a destination MAC address with a VPLS emulated
circuit in the transport tunnel. To allow dynamic learning and
association of destination MAC addresses with VPLS emulated
circuits in transport tunnels across the core IP/MPLS network
infrastructure, Ethernet frames need to be encapsulated at the
VPLS aware ingress device.
For example, such encapsulation can be carried out as per
[MARTINI-ENCAPS] that defines a dual label stack. One label is
needed to transport the frame across the IP/MPLS core while the
other contains demultiplexing information about the enclosed
frame that is necessary in order to properly emulate the layer
2 services.
2.3.2.6 Service Label De-multiplexing
Service Label De-multiplexing is required to distinguish
individual emulated VPLS Ethernet frames within a single VPLS
transport tunnel. Such de-multiplexing is to be carried out at
the VPLS aware egress device. The service label de-multiplexing
can be based on VPLS transport tunneling protocol e.g., an MPLS
label (e.g. in [MARTINI-ENCAPS]) or a GRE key field.
2.3.2.7 VPLS Resiliency
VPLS resiliency is an important consideration to ensure service
availability in presence of failures. Indeed, VPLS, like any
other layer-2 scheme is subject to failures like link, trunk
and node failures. Besides the Service Provider core network
infrastructure resiliency, considerations of access network
resiliency are also important. Upon the occurrence of failure,
Ould-Brahim, et al. Expires August 2002 [Page 8]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
it is desirable that the failure be detected immediately and
protection mechanisms allow fast restoration times to make VPLS
service almost transparent to these failures to the extent
possible, based on the level of resiliency.
Essential aspects of providing resiliency are:
- Link/Node failure detection û Mechanisms within the VPLS
service should allow for link or node failures that impact
the Service, and should be detected immediately.
- Resiliency policy û Depending upon the VPLS service
specification in associated SLA, the detected failure be
handled based on restoration policy. It may need to be
handled immediately, or handled only if no other critical
failure needs protection resources or completely ignored if
the VPLS service being offered allows acceptable downtimes.
This could also determine if the resiliency is revertive or
non-revertive.
- Restoration Mechanisms û The VPLS solutions could allow for
physical level protection, logical level protection or both.
For example, through dual homing of customer connections to
provider customer-facing devices, one connection can be
maintained as active while the other could be marked as a
backup and upon the failure detection across the primary
connection, the backup could become active.
2.3.2.8 VPLS QoS
Based on the customer VPLS SLA, traffic from customer can be
prioritized, policed and shaped for Quality of Service
requirements. The queuing and forwarding policies can preserve
the packet order and QoS parameters of customer VPLS traffic.
Combining the bandwidth flexibility of Ethernet with the
sophisticated traffic engineering tools of MPLS enables Service
Providers realistic opportunities to offer differentiated class
of services.
The class of services can be mapped from customer Ethernet
priority information e.g. 802.1p or it can be independent of
it. QoS functions can be listed as follows:
- Customer Traffic Prioritization û VPLS service could be best
effort or QoS guaranteed. Traffic from one customer might
need to be prioritized over others when sharing same network
resources. This requires capabilities within the VPLS
solution to classify and mark priority to QoS guaranteed
customer traffic.
- Policing û This ensures that a user of VPLS service uses VPLS
network resources within the limits of the agreed SLA. Any
excess VPLS traffic can be rejected or handled differently
based on provider policy.
Ould-Brahim, et al. Expires August 2002 [Page 9]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
- Shaping û Under some cases the random nature of VPLS traffic
might lead to sub-optimal utilization of network resources.
Through queuing and forwarding mechanisms the traffic can be
shaped without altering the packet order.
2.3.3 VPLS Management Plane & OAM&P Functions
2.3.3.1 VPLS Configurations
It is desirable that a VPLS is designed to need minimal
configuration when adding or deleting customer-facing ports to,
or from, a given VPLS where several disjoint instances of VPLS
within same network infrastructure could exist.
To associate a PE level customer-facing port to the VPLS, a
common mechanism used is to associate a VPN membership scheme
to the VPLS. Thereby any port member of a given VPLS will be
assigned the same VPN membership ID. A common VPN membership
scheme is to use the VPN-IDs format [RFC-2685].
The topology of the VPLS could be manipulated by controlling
the configuration of peer devices at each VPLS edge device
combined with an auto-discovery mechanism.
2.3.3.2 Operations and Maintenance Functions
A VPLS solution can provide mechanisms to manage and monitor
different VPLS components. From a Service Level Agreement (SLA)
perspective, VPLS solution could allow monitoring of VPLS
service characteristics and offer mechanisms used by Service
Providers to report such monitored statistical data.
Trouble-shooting and verification of operational and
maintenance activities of VPLS service are essential
requirements for Service Providers.
3. VPLS Deployment and Scaling Issues
A Service Provider access/metro network might have small low-
cost provider provisioned devices at the customer premises
connected to a device at the providerÆs central office. The
devices at the central office tend to have more functional
capabilities compared to the low-cost devices at customer
premises. The provider provisioned low-cost devices typically
interface with the customer edge devices.
VPLS Service deployment has operational, cost and scalability
considerations. While cost and operational overhead for a
service needs to be minimal, it should be highly scalable.
Ould-Brahim, et al. Expires August 2002 [Page 10]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
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, VPLS contains some unique
properties.
Layer-2 VPN solutions extend the concept of traditional layer-2
circuits to accommodate VPN constructs like membership, auto-
discovery, tunneling, and topology discovery. VPN Scalability is
addressed mostly through 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).
An Ethernet VPLS solution meets the scaling requirement where
the PEs facing customer devices and attached to a core network
need to perform MAC learning for all VPLS instances. Besides
providing VPLS services, these PEs may also be used to provide
other VPN services e.g. layer-3 VPNs or point to point L2VPNs.
One way of achieving scaling, reliability and cost objectives is
to distribute VPLS and VPN functional elements like MAC
learning, auto-discovery, aggregation etc among multiple
provider devices. This concept is manifested by "Logical PE"
architecture that distributes the functional elements between
providerÆs customer-facing edge devices, called "PE-Edges", and
providerÆs core-attached edge devices, called "PE-Cores".
Another objective of the Logical PE approach besides scaling is
to be able to fit nicely with all existing VPN technologies
supported in the service provider networks e.g. [VPN-VR], [VPN-
RFC2547bis], [L2VPN-KOMP], [L2VPN-ROSEN] and [OVPN], thus
preventing Service Providers from vendor lock-ins.
4. Logical PE (LPE) Architecture
As discussed in Section 3, Logical PE architecture fits nicely
with Service ProviderÆs typical access network. This section
describes the LPE architecture with its related building blocks
and functions.
4.1 LPE Definition
The LPE addresses VPLS scalability and reliability by
distributing VPLS functional elements among providerÆs
customer-facing edge devices, called ôPE-Edgesö and providerÆs
Ould-Brahim, et al. Expires August 2002 [Page 11]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
core-attached edge devices, called ôPE-Coresö, as shown in
Figure 2.
The concept of separate PE-Edge and PE-Core edge devices does
not prevent the distributed VPLS functional elements from being
implemented within the same physical device. PE-Edge devices
are not mandatory for building Service ProviderÆs VPLS access
network. However, the value addition to the VPLS services for a
Service Provider are reasons enough for large scale VPLS
service to be preferably implemented across low-cost Ethernet-
based ôPE-Edgeö devices and high capacity core-attached ôPE-
Coreö edge devices, as explained later in Section 4.2
LOGICAL PE
+-------------------------------------------+
| |
| +---------+ |
| +---------+ | | |
+----+ | | | | | |
|CE-1|-|-| PE-Edge |--{ Distributed }--| PE-Core |-|--{Core}...
+----+ | | (n) | {VPLS Functions} | (m) | |
| +---------+ | | |
| | +----|----+ |
| | | |
+------|-----------------------------|------+
| |
+----+ +----+
|CE-2| |CE-3|
+----+ +----+_
Figure 2: Logical PE with PE-Edges and PE-Cores
PE-Edges and PE-Cores can be interconnected by switched
Ethernet transport network(s) or directly connected links
within a LPE. Note that the PE-Core device might also need to
support PE-Edge functions when some customer sites might be
directly connected to them, for example as shown in Figure 2
where CE-3 is directly connected to a PE-Core.
The customer-facing Ethernet ports on PE-Edge and PE-core, when
connected directly to customer site, are called LPE endpoints.
These LPE endpoints can be logical when LPE supports customer
VLAN processing and represent the customer demarcation point
for VPLS service.
PE-Edges will interoperate with other PE-Edges in the same LPE
or different LPEs. PE-Edges connected to the same Switched
Ethernet Transport can inter-operate without involvement of a
Ould-Brahim, et al. Expires August 2002 [Page 12]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
PE-Core. A network consists of only PE-Edges can deliver a
subset of VPLS services. The PE-Cores provide intermediary
functions to enable PE-Edges to interoperate with PEs outside
their local Switched Ethernet Transport domain. PE-Cores can
also offer VPLS services to CEs directly connected to PE-Core
and can also communicate with conventional PE devices that
implement VPLS functions on a single device. PE-Cores are
connected in a fully mesh topology of transport tunnels across
the core network.
PE-Edges are only aware of PE-Cores and other PE-Edges in the
same-switched Ethernet transport domain; therefore there is no
direct full mesh signaling between PE-Edges across the core
network. Any inter-site connectivity between PE-Edges across
different switched Ethernet transport domains traverses the PE-
Cores.
4.2 LPE Functional Elements
Following sections describe a list of PE functions that can
allow the distribution of functions described in Section 2.3 in
forming a LPE:
4.2.1 LPE VPLS Configurations
An LPE-based VPLS service can be created either at the PE-Edge
or the PE-Core or both. It is also possible to use a service
provider network management system to provide these
configurations. A VPLS solution is a port-based VPN type
architecture. Therefore, configuring LPE endpoints, physical or
logical customer-facing ports defined in Section 4.1, and
associating these LPE endpoints to VPLS membership scheme
accomplishes the VPLS membership.
It may happen that a different membership scheme is used for
intra-LPE than the membership scheme used for inter-LPE. In
this case a mapping function is needed at LPE level to maintain
unique VPLS membership across the service provider network.
4.2.2 LPE VPLS Auto-discovery
A lightweight protocol similar to [LPE-AD] is recommended
between PE-Edge and PE-Core to exchange VPLS related
information e.g. membership, tunneling, encapsulation schemes
etc. for the purpose of auto-discovery of LPE endpoints
belonging to the same VPLS. Example of functions provided by an
[LPE-AD] include:
Ould-Brahim, et al. Expires August 2002 [Page 13]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
o Notification of LPE endpoint Addition, Deletion, and
Modification within any VPLS.
o Service Label/Tunnel information exchange within any LPE.
o Addition/Deletion/Modification of PE-Edge devices.
4.2.3 LPE VPLS Topology and Loop Prevention
LPE is quite flexible and various network configurations can be
implemented, some of them being:
- PE-Edges and PE-Cores implemented within a single device
- PE-Edge connected directly to PE-core devices through
physical links
- PE-Edge connected to PE-Core through virtual point-to-point
link (e.g. FR, ATM).
- Multiple Broadcast/Switched Ethernet Transport domains
When implemented within a single PE device, LPE behaves similar
to conventional VPLS solutions that exhibit scaling and
reliability constraints.
PE-Edges can be directly connected to PE-Cores via Ethernet
trunks. When the same PE-Edge is connected to same PE-Core via
more than one Ethernet trunk, it introduces reliability, as
discussed in Section 4.2.6, and potential for load sharing.
PE-Edges and PE-cores can also be connected via multiple
broadcast or Switched Ethernet Transport domains e.g. Resilient
Packet Rings (RPR). In such cases, Ethernet header can be used
as a form of transport header between PE-Edge and PE-Core
devices. This connectivity offers specific advantages e.g.
provide direct PE-Edge-to-PE-Edge connectivity on the same
Switched Ethernet Transport domain without requiring PE-Core.
Provider VPLS network can participate in customer STP to avoid
loops in the customer network for multi-homed customers or
customers with backdoor connectivity. This is an OPTIONAL
function.
4.2.4 LPE VPLS MAC Learning
The logical PE can be built with a PE-Core with or without
source MAC learning capabilities. A PE-Core needs to perform
source MAC learning in situations where VPLS customer sites are
attached to the PE-Core. However, when no customer sites are
attached to a PE-Core, the LPE will perform MAC learning
function only at the PE-Edge level.
Ould-Brahim, et al. Expires August 2002 [Page 14]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
4.2.5 LPE Customer Packet Encapsulation
Within the LPE, the Ethernet frame encapsulation scheme can be
different than the Ethernet frame encapsulation scheme across
the IP/MPLS core network infrastructure. In such a case, the PE-
Core carries out the translation/mapping between LPE
encapsulation scheme to the core encapsulation scheme.
4.2.6 LPE Service Label De-multiplexing
De-multiplexing header can used to identify the VPLS service
within a transport tunnel. Mechanisms analogous to the "VC
label" stated in [MARTINI-ENCAPS] can be used.
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).
4.2.7 LPE VPLS Resiliency
To be able to offer resiliency along the access of the VPLS
service network, it is preferable to implement the service
using clusters of service elements. This helps to prevent
single failures from disrupting large-scale services. LPE-based
access network are more tightly coupled than PE-based access
networks due to additional signaling required when formulating
the LPE.
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. When using more than one PE-Core,
one will need mechanisms to blend those PE-Cores into LPE.
When PE-Edges are directly connected to PE-Cores via multiple
Ethernet trunks, where the PE-Core connected via multiple
trunks can be used for load sharing and for recovery from link
and device failures.
4.2.8 LPE VPLS QoS
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
Ould-Brahim, et al. Expires August 2002 [Page 15]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
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.
Function includes ingress classification, metering, policing,
and egress shaping of customer traffic at the provider
boundary.
5. LPE VPLS Reference Model
VPLS customers typically connect to providerÆs VPLS aware
devices, which could be fully functional PE devices just like
any other layer 2 scheme, or low-cost edge Ethernet devices.
These edge devices could be themselves attached to either
switched Ethernet networks or through uplinks to other provider
edge devices, which are attached to a packet switched core
IP/MPLS network infrastructure. In the example illustrated in
Figure 3, from a conceptual view, PEs facing customer equipment
(and not attached to the core network) combined with PE
attached to the core network represent a "logical PE" construct
where many VPLSs along with other layer-2 and layer-3 VPN
services can be offered.
+---+
+----+ +---+ +---+ |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 3: Example of VPLS service
Ould-Brahim, et al. Expires August 2002 [Page 16]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
To highlight the case described in Figure 3, 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. Using Figure 3, PE1, PE7, PE5, PE6 can be labeled PE-
Edges while PE2, PE3, PE4, and PE8 are labeled PE-Cores.
Within the LPE reference model, a CE can be attached to one or
more than one PE-Edges. However, connecting to more than one
PE-Edge may require the PE-Edges to participate in customer
spanning tree protocol.
PE-Edges can be connected through the Switched Ethernet
transport network or direct links to one (or more) PE-Core(s).
There can be multiple switched Ethernet transport domains within
a Logical PE. A Switched Ethernet transport domain is equivalent
to a broadcast domain. All the devices within the switched
Ethernet transport domain will receive an Ethernet broadcast
message sent onto the switched Ethernet transport domain. Within
a carrierÆs metro Ethernet network it can contain multiple
Switched Ethernet Transport domains. For example, a particular
802.1q VLAN in a carrierÆs metro Ethernet network is a switched
Ethernet transport domain. 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-Cores are connected to
each other over core network (e.g. MPLS) through P devices as
usual VPN architectures [PPVPN-REQ].
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.
Logical PE also allows a provider to gracefully introduce MPLS
functionality into their existing 802.1q or stacked Q-tag
Ethernet network. One migration path is that the existing
customer facing devices will evolve into PE-Edges devices. These
PE-Edge devices need not be MPLS aware and can remain simple
from the control plane side. PE-Edge-to-PE-Edge communication
can continue to be carried over the existing switched Ethernet
transport network. PE-Core can then be added into the switched
Ethernet transport network to provide connectivity to the
IP/MPLS core. The grouping of PE-Core, PE-Edge, and switched
Ethernet transport devices can give the appearance of a PE from
other PEs across the IP/MPLS core.
Ould-Brahim, et al. Expires August 2002 [Page 17]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
6. LPE Functional Distribution Example
Distribution of Logical PE functions is primarily determined
upon the VPLS architecture model used. This section discusses
one such possible distribution of these LPE functions.
In most cases, the PE-Edges provide such functions as managing
the SLA including bandwidth policing, traffic classification
and QoS, as well as customer Ethernet frame encapsulation, and
MAC and VLAN learning. While, in most cases, the PE-Core
maintains membership information and performs VPN membership
determination and advertisement 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 LPE endpoint related
information to all PEs/LPEs across the core. Such distribution
can be constrained to only the PEs/LPEs that have VPLS
membership in common.
6.1 PE-Edge Functions
Typically a PE-Edge, being a bridge, a routing switch, or a
router, will perform regular Ethernet based functions. These
functions are:
o MAC learning
o Packet Replication/Flooding
o Loop Prevention [e.g. participation in customer SPT](OPTIONAL)
o Transport tunnel within LPE
o Service label de-multiplexing within LPE
o Auto-discovery within LPE [e.g. [LPE-AD]]
o Customer traffic prioritizing, policing, and shaping
o Customer VLAN processing
o Packet Encapsulation
o VPLS configuration (depending on the configuration model)
6.2 PE-Core Functions
A PE-Core being attached to an IP/MPLS network and providing
other VPN service than just VPLS should provide the following
functions:
o Packet Replication/Flooding
o Transport tunnel within LPE
o Service label de-multiplexing within LPE
o Auto-discovery within LPE [e.g. [LPE-AD]]
o VPLS Configuration (depending on the configuration model)
o VPLS Auto-discovery between PEs
Ould-Brahim, et al. Expires August 2002 [Page 18]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
o Transport tunnel signaling
o Service Label signaling between PEs
o Service Label de-multiplexing between PEs
o VPN Membership mapping from within LPE domain to core domain
(OPTIONAL)
7. Security Considerations
VPLS security needs to be considered within the LPE and inter-
LPEs.
Within the LPE, Customer traffic needs to be separated.
Ethernet Qtag, MPLS/IP based tunneling can be used for customer
VPLS traffic separation. The level of data path security is
same as ATM or FR networks. This document does not 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.
8. References
[BGP-AD] Ould-Brahim, H. et al., "Using BGP as an Auto-
discovery Mechanism for network-based VPNs", draft-ietf-
ppvpn-bgpvpn-auto-02.txt, 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., "Layer 2 VPNs Over
Tunnels ", draft-kompella-ppvpn-l2vpn-01.txt,
work in progress.
[MARTINI-ENCAPS] Martini, L., et al. " Encapsulation Methods
for Transport of Layer 2 Frames Over IP and MPLS Networks",
draft-martini-l2circuit-encap-mpls-04.txt, work in progress.
[MARTINI-TRANSP] Martini, L., et al., "Transport of Layer-2
Frames over MPLS", draft-martini-l2circuit-trans-mpls-
08.txt, work in progress.
[PPVPN-REQ] Carugi, M., et al., "Service requirements for
Provider Provisioned Virtual Private Networks", work in
Ould-Brahim, et al. Expires August 2002 [Page 19]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
progress.
[PPVPN-FRAME] Callon, R., et al., "A Framework for Provider
Provisioned Virtual Private Networks", work in progress.
[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.
[VPLS-REQ] Waldemar, A., et al., "Requirements for Virtual
Private LAN Services (VPLS)", draft-augustyn-vpls
requirements-01.txt, work in progress.
[VPN-RFC2547bis] Rosen, E., et al., "BGP/MPLS VPNs", draft-
ietf-ppvpn-rfc2547bis-01.txt, January 2002, work in
progress.
[VPN-VR] Ould-Brahim H., et al., "Network-based IP VPN using
Virtual Routers", draft-ietf-ppvpn-vpn-vr-01.txt, November
2001, work in progress.
[LPE-AD] Knight, P., et al., "Logical PE Auto-Discovery
Mechanism", draft-knight-l2vpn-lpe-ad-00.txt, work in
progress, November 2001.
9. Acknowledgments.
We would like to acknowledge the following individuals for
their constructive comments: Marc Holness, Paul Valentine, Phil
Edholm, Sam Sigarto, Bilel Jamoussi, Frank Neil, Liam Casey,
Wai-Chai Hui, Hesham Elbakoury, Paul Knight and many other
people who contributed to the concept of logical PE.
10. 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.
11. Author's Addresses
Ould-Brahim, et al. Expires August 2002 [Page 20]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
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
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
Dinesh Mohan
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 763 4794
Email: mohand@nortelnetworks.com
Pascal Menezes
Terabeam Networks
www.terabeam.com
Chief Technology Officer IP Internetworking
2300 Seventh Ave
Seattle, WA, USA
98121
Access Line and Fax : 206 686-2001
email: pascal.menezes@terabeam.com
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
Ould-Brahim, et al. Expires August 2002 [Page 21]
draft-ouldbrahim-l2vpn-lpe-02.txt March 2002
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. Expires August 2002 [Page 22]