PPVPN Working Group Ali Sajassi
Internet Draft Dan Lee
Expiration Date: September 2002 Jim Guichard
Cisco Systems
February 20, 2002
VPLS Architectures
draft-sajassi-vpls-architectures-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines a reference architecture for a VPLS system. It
describes possible VPLS architectures based on this reference
architecture and the merits of each. Each VPLS architecture is
described in terms of its logical components and their relationship to
each other, as well as the mapping of these logical components to
physical network elements. By understanding these logical components,
which are fundamental building blocks for any VPLS system, one can
easily compare different VPLS architectures and understand the pros and
cons of each. A VPLS system may support one or more of these
architectures simultaneously.
[Page 1]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
Having described each VPLS architecture, we explore the different
logical components of the reference architecture, and describe how they
relate to a Service Provider backbone (whether MPLS enabled or not).
Finally, we examine the operation of each VPLS architecture.
Table of Contents
1. Boilerplate for Sub-IP Area Drafts.................................2
2. Introduction.......................................................3
2.1. Reference Architecture...........................................6
2.2. Single-PE Model..................................................9
2.3. Distributed-PE Model:...........................................10
2.3.1. Ethernet-based PE-CLE.........................................12
2.3.2. MPLS/IP-based PE-CLE..........................................14
3. Emulated VCs......................................................15
4. Emulated Tunnels..................................................17
5. Attachment Tunnels................................................17
5.1. Encapsulation...................................................18
5.2. Signaling.......................................................18
6. Extension VCs.....................................................19
6.1. Encapsulation...................................................19
6.2. Signaling.......................................................19
7. Virtual Switch Instance...........................................20
8. Auto Discovery....................................................21
9. Auto Configuration................................................21
10. System Operation.................................................22
10.1. Single-PE......................................................23
10.2. Distributed-PE with Ethernet-based PE-CLE......................23
10.3. Distributed-PE with MPLS/IP-based PE-CLE.......................25
11. Security Considerations..........................................25
12. Acknowledgements.................................................26
13. References.......................................................26
14. Authors' Addresses...............................................27
15. Intellectual Property Considerations.............................27
16. Full Copyright Statement.........................................27
1. Boilerplate for Sub-IP Area Drafts
This draft is targeted at the PPVPN WG, as it defines a reference
architecture for a VPLS system in terms of its logical components, and
describes possible VPLS architectures that can co-exist simultaneously
in a VPLS system.
The set of related documents may be found in the "References" section.
Sajassi, et al Expires September 2002 [Page 2]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
2. Introduction
The primary motivation behind Virtual Private LAN Services (VPLS) is to
provide connectivity between geographically dispersed customer sites
across MAN/WAN network(s), as if they were connected through a Local
Area Network. Furthermore, the intended application for the end-user
can be divided into the following two categories:
. Connectivity between site routers û LAN routing application
. Connectivity between site Ethernet switches û LAN switching
application
The LAN routing application is intended for the interconnection of
routers via a metro or wide area network, and for providing a broadcast
domain among these routers. Traditionally, the interconnection of VPN
sites over a MAN/WAN has required a mesh of overlay virtual circuits
between routers. Adding a new router to the interconnection mesh
potentially requires significant reconfiguration. The VPLS service is
intended to mitigate this interconnection problem by leveraging native
broadcast capabilities for router discovery, along with a simple point-
to-cloud service model. This service model simplifies the task of
configuration and provisioning for the end customer routers by
providing a virtual LAN/bridge system. Therefore, to the routers it
looks as if they are connected via a local LAN switch even though they
are located in different sites.
The LAN switching application as its name implies provides a virtual
LAN switching service to its end users and it is used for
interconnecting customer switches across a MAN/WAN network. Therefore,
if several sites within a VPN subscribe to this service, it looks as if
these sites are co-located within a campus, and are connected via a
local Ethernet switch providing bridging services for them. This
service is not anticipated to be widely deployed in large-scale
networks because of limited scalability and lower network efficiency.
However, for small/medium business customers, this service can be very
viable to extend the bridging domain between VPN sites across a MAN/WAN
network. By extending the bridging domain, the customer only needs to
use low-cost Ethernet switches as CPEs.
The underlying VPLS service for supporting these two types of
applications is fundamentally the same. However, each application has
different requirements in terms of control frame processing, MAC
address usage, BPDUs handling, and so on.
Sajassi, et al Expires September 2002 [Page 3]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
The following figure shows a VPLS system with two VPLS instances û one
for each customer, referred to as ôVPLS Aö and ôVPLS Bö. This figure
shows that each customer CPE device (whether router or switch) connects
to a PE device within the Service Provider POP. It should be noted that
when the term ôa VPLSö is used by itself, it refers to a VPLS instance
and not a VPLS system.
+----+ +-----+
+CE1 +--+ +---| CE2Æ|
+----+ | ........................ | +-----+
VPLS A | +------+ +-----+ | VPLS B
+--| PE |-- Service ----| PE |--+
+------+ Provider +-----+
/ . Backbone .
/ . | .
+----+ / . | .
+CE1Æ+--+ . | .
+----+ . +----+ .
VPLS B .........| PE |.........
+----+
|
|
+----+
|CE2 |
+----+
VPLS A
One of the main scenarios for the VPLS service is the delivery of an
Ethernet service to multiple customers co-located in one or more MxUs
over the Metro Area. MxUs can be apartments or multi-dwelling units
(MDUs), office buildings or multi-tenant units (MTUs), and hotels or
multi-hospitality units (MHUs). In such cases, it would be much more
cost effective to place an aggregation device at the co-location site,
rather than connecting each CPE directly to a PE within the Service
Provider POP. This device would be used to aggregate all customersÆ
traffic and carry it via an uplink to the Service ProviderÆs POP as
opposed to having a separate uplink for each customer. Because of a
large number of co-location sites and thus large number of aggregation
devices in a Metro area, it is important for the aggregation device to
be truly low cost. In such cases, the VPLS functionality is distributed
between the aggregation device in the co-location site and the PE
sitting in the Service Provider POP. Apart from the obvious cost
reductions, a VPLS system based on a distributed-PE model is also able
to provide access bandwidth efficiency and system scalability. These
additional benefits will be described in more detail in section 2.3.
Sajassi, et al Expires September 2002 [Page 4]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
The following figure extends the VPLS system architecture to include
distributed-PE functionality. As can be seen in the figure, the VPLS
system can have a mix of distributed and non-distributed (single) PEs.
In the case of a non-distributed PE, we refer to it simply as PE and it
is typically located in the Service ProviderÆs central office or POP.
In the case of a distributed PE, we refer to the PE located at the
customer site as PE-CLE and the PE located in the Service ProviderÆs
POP as PE-POP. The Service ProviderÆs Backbone network connecting
PEs/PE-POPs can be based on either MPLS or IP.
As shown in the figure, there are several different ways for CEs and
PE-CLEs to connect to the Service ProviderÆs network. CEs and PE-CLEs
can be either connected directly to PE-POPs via a given transport
mechanism such as SONET, Fiber, CWDM/DWDM, and so on, or they can be
connected via an Ethernet access network. In the later case, care must
be taken to avoid loops in the access network using standard mechanisms
such as STP. Furthermore, there may be cases (although not typical)
where several customer sites are connected to the same PE-CLE. This may
imply certain restrictions on the customerÆs network based on the
capability of the PE-CLE as will be elaborated upon in section 10.2.
Sajassi, et al Expires September 2002 [Page 5]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
+----+ +------+ +----+
+CE1 +--+ +---|PE-CLE|----|CE2 |
+----+ | ........................ | +------+ +----+
VPLS A | +------+ +------+ | | VPLS A
+--| PE |-- Service ----|PE-POP|-+ | +----+
+------+ Provider +------+ +-------|CE2Æ|
/ . Backbone . \ +----+
/ . | . \ +-----+ VPLS B
+----+ / . | . \ / \
+CE1Æ+--+ . | . +--|L2 Access|
+----+ . +----+ . | Network |
VPLS B .........| PE |......... \ /
+----+ +-----+
| |
| |
+----+ +------+ +----+
|CE3 | |PE-CLE|---|CE3Æ|
+----+ +------+ +----+
VPLS A | VPLS B
|
| +----+
+------|CE4Æ|
+----+
VPLS B
2.1. Reference Architecture
The reference architecture described in this section is based on the
model defined in [L2ARCH] with several extensions. The model defined in
[L2ARCH] is primarily intended for non-VPLS systems with non-
distributed PEs (e.g., a single PE is used to connect a CE device to
the Service ProviderÆs network).
A non-VPLS L2VPN can be described in terms of its components as defined
in [L2ARCH]. These components are:
. Attachment VCs
. Emulated VCs
. Emulated Tunnels
. Auto Discovery
. Auto Configuration
Sajassi, et al Expires September 2002 [Page 6]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
We introduce three additional components as follows for a VPLS system
that will be described in subsequent sections of this draft. The first
component is mandatory for a VPLS system (along with the first three
non-VPLS components described above) and the other two components are
needed for a distributed-PE model (and more specifically for a
particular distributed-PE model).
. Virtual Switch Instances (VSI)
. Attachment Tunnels
. Extension VCs
The only components that are dependent on network type (MPLS vs. IP)
are Emulated VCs and Emulated Tunnels. In [L2ARCH] an Attachment VC is
defined as the virtual circuit between a CE and its associated PE, and
an Emulated VC is defined as the virtual circuit between two PEs.
Therefore, an end-to-end virtual circuit between two CEs can be defined
as an ordered triple <Attachment VC, Emulated VC, Attachment VC>. The
mapping between Attachment VC and its corresponding Emulated VC is one-
to-one and is performed on each side by its associated PE. Furthermore,
the mapping between the Attachment VC and its corresponding Emulated VC
is fixed and is established at the time of end-to-end circuit
establishment. The Attachment and Emulated VCs are always terminated in
the PEs and thus L2VPN processing is only limited to PE nodes and
transparent to P nodes.
In a VPLS system, the Attachment VCs can be considered as connected to
a Virtual Switch (referred to as a Virtual Switch Instance û VSI)
corresponding to that VPLS instance at each PE. Furthermore, the
Emulated circuits can be considered as the virtual circuits connecting
these Virtual Switches located at each PE.
A VPLS for a given customer can be defined as a set of Virtual Switches
(one in each PE that is part of the VPLS) connected to each other via
Emulated VCs and to CEs via Attachment VCs. This means that for a VPLS
system, the relationship between the Attachment and Emulated VCs is no
longer fixed. The dynamic mapping of these entities (which is sometimes
one-to-one for unicast and sometimes one-to-many for multicast or
broadcast) is provided by each Virtual Switch through the use of the
destination MAC address, and is performed on a frame-by-frame basis.
Given the above description of a VPLS system, a customer VPLS instance
can be defined in terms of its Attachment VCs, its Emulated VCs, and
its set of Virtual Switches as follows: < Ingress Attachment VCs,
Ingress VSIs, Emulated VCs, Egress VSIs, Egress Attachment VCs>. The
following figure depicts the Attachment and the Emulated VCs and their
Sajassi, et al Expires September 2002 [Page 7]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
relationship for a given L2VPN with three sites via a) non-VPLS network
and b) VPLS network.
PE1 PE2
+----+ +-----+ +-----+ +----+
|CE1 |------+--X--+-----------------------+--X--+------+ CE2|
| |------+--X--+-----------------------+--X | | |
+----+ +-----+ +--|--+ +----+
|
| +----+
+---------+ CE3|
| |
+----+
<Attachment VCs> <Emulated VCs> <Attachment VCs>
PE1 PE2
+----+ +-------+ +-------+ +----+
|CE1 | | +---+ | | +---+ | | CE2|
| |------+-|VSI+-+----------------------+-|VSI+-+-----+ |
+----+ | +---+ | | +|--+ | +----+
+-------+ +--|----+
| +----+
+----------+ CE3|
| |
+----+
<Attachment VCs> <Emulated VCs> <Attachment VCs>
What differentiates the VSI from a typical Ethernet switch is its
ability to do MAC address learning, flooding, forwarding, and so on,
based on virtual circuits (e.g., based on Emulated VCs) per broadcast
domain. For example, if a physical port of a PE carries several
Emulated VCs, then the VSI can replicate packets (for flooding or
broadcasting) across these Emulated VCs over the same physical port.
This is in contrast to a typical switch that may only perform packet
replication across physical ports for a given broadcast domain.
A VPLS-capable PE shall have one VSI per VPLS instance and it can
either be transparent to a customerÆs VLANs or it can recognize the
customerÆs VLANs. If the PE is transparent to the customer VLANs, then
the associated VSI will handle customerÆs VLANs transparently; however,
if the PE needs to recognize customersÆ VLANs and to provide isolation
among them, then separate VSIs for each customer VLAN should be
maintained. Each VSI corresponds to a separate broadcast domain and may
Sajassi, et al Expires September 2002 [Page 8]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
be shared between customer sites for the creation of Extranet or
Internet connectivity. The requirement for maintaining a separate
broadcast domain per VPLS instance is identified in [VPLS-REQ].
Since customersÆ VLANs can be overlapping, the PE should have the
capability of associating customers VLANs with a unique identifier for
identification of the VSIs. Therefore, the ability to a) map customers
VLANs into unique identifiers (for VLAN-aware PE) and b) to perform VSI
functionality with Emulated VCs, constitutes major data-plane
requirements for a VPLS capable PE.
For a PE that needs to recognize customersÆ VLANs and to maintain
isolation among them, if each customer assigns their VLANs
independently, then overlapping VLANs can occur within that PE.
Therefore, the PE is required to provide additional capability so as to
map customersÆ VLANs into unique VSI identifiers. However, if the
Service Provider assigns the VLANs to its customers, then assignment
can be done such that customersÆ VLANs are unique within a PE and thus
the VLAN-id itself can be used as the VSI identifier thus simplifying
the requirement for the PE or the PE-CLE (in the case of the
distributed-PE model). However, this simplification at the PE comes at
the expense of the customer loosing the flexibility of assigning his or
her own VLANs (which maybe acceptable for certain deployment models).
The next few sections describe different VPLS architectures. A VPLS
system may support one or more of these architectures simultaneously.
2.2. Single-PE Model
In the single-PE model, each PE is capable of performing the full set
of VPLS functions and it can be either located in a customer premise or
at the Service Provider POP. If the PE is located in the customer
premise, then the link between the CE and the PE is local and many CEs
can be aggregated via the upstream Service Provider link. However, it
may cost too much to place a PE in the customer premise or the number
of customer located PEs may present some system scalability issues. If
the PE is located in the Service Provider POP, then one MAN link is
required per customer which may in turn result in an increase cost of
facilities and thus an increase in operational costs. Section 2.3 shows
how the use of a distributed-PE can address these issues effectively
when a single-PE environment is not desirable.
In a single-PE model, all VPLS functionality is performed within a
single PE. In terms of the data-plane operation, these functions
constitute:
Sajassi, et al Expires September 2002 [Page 9]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
. Attachment VCs termination
. Emulated VCs termination
. Tunneling of Emulated VCs
. Maintaining a VSI per VPLS instance (for bridging among
Attachment and Emulated VCs)
In terms of the control-plane operation, these functions constitute:
. Signaling of Emulated Tunnels (if needed)
. Signaling of Emulated VCs
. Auto-discovery of peer PEs per VPLS instance
. Auto-configuration of a VPLS instance
As mentioned previously the PE needs to perform VSI functionality (such
as MAC address learning, flooding, and unicasting/broadcasting on a per
Emulated VC basis). In addition to this, if the PE is required to
recognize customerÆs VLANs and to provide isolation among these
different VLANs (by using a separate broadcast domain per VLAN), then
it also needs to have the capability of mapping customersÆ VLANs into
unique VSI identifiers if each customer assigns his or her VLANs
independently.
2.3. Distributed-PE Model:
Some of the main motivations behind a distributed-PE model include:
. The ability to deploy a low-cost edge device at the customer
premise
. Improving access bandwidth efficiency by multiplexing different
customer traffic (in contrast to a single-PE model located at the
Service ProviderÆs POP)
. Improving access bandwidth efficiency by avoiding packet
replication on the access uplink for multicast/broadcast traffic
. Improving system scalability Vs. single-PE functionality within
the customer premise in terms of a) number of BGP peers, b)
number of IGP peers, c) number of routes in the edge device, d)
number of MPLS labels in the edge device, e) number of MPLS or IP
tunnels among PEs (only a subset of routes and MPLS labels need
to installed in PE-CLEs; whereas, in a single-PE model all routes
and MPLS labels are installed in PEs û whether located at
customer sites or Service Provider POP)
As mentioned previously, the most important data-plane functionality of
a VPLS-capable PE is the ability to perform VSI functionality. In the
case of the distribute-PE model, there are two cases that should be
Sajassi, et al Expires September 2002 [Page 10]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
considered - either the PE-POP is capable of performing such
functionality or it is not. If the PE-POP is capable of such
functionality, then a true low-cost Ethernet switch based PE-CLE can be
used.
If the PE-POP doesnÆt have the ability to perform VSI functionality
(e.g., it is a router), then this functionality needs to be performed
by the PE-CLE. It should be noted that if a PE-CLE needs to perform
such functionality, then it must have similar capability as MPLS/IP
switches so as to support multiple virtual circuits per physical
interface, and to treat these VCs as logical ports of a VSI, so that it
can do flooding and broadcasting across these VCs per broadcast domain.
As mentioned before, existing Ethernet switches may not perform these
functions on a per VC basis. If their data-planes need to be modified
for such functionality, then one can easily extend them to use MPLS
labels or IP information as well.
Based on the above discussion, we define two types of PE-CLE. The first
type is an Ethernet-based PE-CLE which requires the PE-POP to perform
VSI functionality. The second type is an MPLS/IP-based PE-CLE, which
does VSI functionality and thus the PE-POP can be just an MPLS or an IP
router.
Based on which type of PE-CLE is used in a distributed-PE model,
different sets of data-plane and control-plane functions are required
at the PE-CLE and PE-POP. Another way of categorizing a distributed-PE
model, is based on control plane functionality û more specifically in
terms of Emulated signaling and auto-discovery. Based on these two
functions, there can be four categories of distributed-PE models as
follows:
1. Emulated signaling and auto-discovery are both performed at the
PE-POP
2. Emulated signaling at PE-CLE and auto-discovery at PE-POP
3. Emulated signaling at PE-POP and auto-discovery at PE-CLE
4. Emulated signaling and auto-discovery are both performed at the
PE-CLE
The third category does not offer any real benefits in terms of system
scalability and thus is not considered further. The fourth option can
be considered as a degenerate case for a single-PE model since the PE-
CLE is capable of terminating and signaling Emulated VCs and performing
auto-discovery, it can basically perform all other functions required
for a VPLS service. Therefore, only the first two options are examined
further.
Sajassi, et al Expires September 2002 [Page 11]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
As one might have guessed, a distributed-PE model based on Ethernet-
based PE-CLE uses the first control-plane category (e.g., both Emulated
signaling and auto-discovery are performed at the PE-POP). In contrast,
a distributed model based on an MPLS/IP-based PE-CLE can use either the
first or second control-plane category. As will be shown later in
section 2.3.2, for an MPLS/IP-based PE-CLE, the second control-plane
category offers additional benefits over the first one. An example of a
distributed-PE model using an MPLS-based PE-CLE and the first control-
plane category (e.g., Emulated signaling and auto-discovery both
performed at the PE-POP) is described in [DTLS].
In the following two sections, reference architectures for Ethernet-
based and MPLS/IP-based PE-CLE are described and their relationship in
terms of signaling/auto-discovery categorization is further examined.
2.3.1. Ethernet-based PE-CLE
A distributed-PE model with Ethernet-based PE-CLE provides a true low-
cost edge device and at the same time it provides all the benefits of a
distributed model in terms of motivational factors considered above.
This model provides a natural migration in offering VPLS services for
carriers with an existing Ethernet access network. An Ethernet-based
PE-CLE not only provides access bandwidth efficiency by multiplexing
different customers traffic but also it provides bandwidth efficiency
by not replicating frames over its access uplink connected to the PE-
POP (which is not the case for MPLS/IP-based PE-CLEs). Also, since in
this model, the PE-POP performs both Emulated VC signaling and auto-
discovery, all the signaling and routing scalability issues are
addressed as well.
Now lets examine the reference architecture for this model with respect
to its components. Since Ethernet-based PE-CLEs donÆt support VSI
functionality (e.g., MAC address learning, flooding, forwarding, etc.)
based on virtual connections per broadcast domain, Emulated VCs must be
terminated in the PE-POP. Also, since Emulated VCs signaling is
performed at the PE-POP, the auto-discovery should also be performed
there as well (auto-discovery is used for end-point identification in
setting up Emulated VCs). This means that the Ethernet-based PE-CLE
model fits very naturally into the first control-plane categorization
of Emulated signaling and auto-discovery being performed at the PE-POP.
Now that the Emulated VCs are terminated at the PE-POP and the VSIs are
also located at the PE-POP, the question is how to get to the
Attachment VCs that come into the PE-CLE (it should be noted that
Emulated VCs are always terminated at the node that has the VSI
functionality). There are two possible options:
Sajassi, et al Expires September 2002 [Page 12]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
1. To tunnel the Attachment VCs from the PE-CLE to the PE-POP and do
further processing of the Attachment VCs at the PE-POP
2. To extend the Attachment VCs from the PE-CLE into the PE-POP
using Extension VCs (e.g., by mapping Attachments VCs into
Extension VCs at the PE-CLE)
The tunneling of the Attachment VCs can be performed by placing an
outer .1q tag over a given customer traffic. This is also referred to
as .1q-in-.1q encapsulation or for short QinQ. The provision of an
Ethernet switch for this functionality is rather simple and a number of
vendors currently provide such functionality in their Ethernet
switches. The main advantage of this approach is that it requires no
modifications to Ethernet switches that can support QinQ encapsulation
and so these switches can be readily used as PE-CLEs. If the Service
Provider is required to recognize customersÆ VLANs, then the PE-POP
requires the capability of creating a unique VSI identifier per
customerÆs VLAN by looking at both the outer and the inner .1q tags
which is referred to as double-tag lookup. However, if the Service
Provider is not required to recognize customersÆ VLANs, then no double-
tag lookup functionality is needed at the PE-POP and the PE-POP can
simply use the outer .1q tag as the VSI identifier since the outer tag
has been assigned to ensure uniqueness at each PE-POP.
The second option of extending the Attachment VCs into the PE-POP
requires additional functionality in the PE-CLE that may not be
currently available in Ethernet-based switches. This functionality
allows the mapping of a customer VLAN (e.g., Attachment VC) into an
internal VLAN (Extension VC), which is unique within the PE-CLE. This
mapping is needed when separate VPLS instances need to be maintained
per customer VLANs in order to provide isolation among customerÆs VLANs
(e.g., customersÆ VLANs can overlap with each other and the Service
Provider does not impose any restriction in customersÆ VLAN assignment
per [VPLS-REQ]). It should be noted that this option is not needed if
the Service Provider doesnÆt need to recognize customersÆ VLANs and
thus the first option without double-tag lookup at the PE-POP is
sufficient.
In summary, in a distributed-PE model based on Ethernet-based PE-CLE,
the VPLS functions are distributed between the PE-CLE and the PE-POP,
with the following functions being performed at the PE-CLE:
. Tunneling of Attachment VCs to the PE-POP OR;
. Attachment VC termination and origination of Extension VCs toward
the PE-POP
Sajassi, et al Expires September 2002 [Page 13]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
And the following VPLS functions are performed in the PE-POP:
. Attachment Tunnels termination (if used)
. Attachment VC termination OR Extension VC termination
. Emulated VCs - signaling and termination
. Emulated Tunnels û signaling and termination
. Maintaining a VSI per VPLS instance
. Auto-discovery
. Auto-configuration
2.3.2. MPLS/IP-based PE-CLE
In cases where the PE-POP is an MPLS or an IP router without switching
capability, the task of performing VSI functionality reside in the PE-
CLE. The Emulated VCs can be setup at the PE-CLE using either MPLS or
IP encapsulation - thus the name MPLS/IP-based PE-CLE.
In this distributed-PE model, the Emulated VCs are terminated at the
PE-CLE and the bridging functionality between a customerÆs Attachment
VCs and the corresponding Emulated VCs are provided using a VSI per
VPLS at the PE-CLE. Unlike the Ethernet-based PE-CLE, there is no need
for Attachment tunnels or Extension VCs since the VSIs are located in
the PE-CLEs.
As mentioned previously, there are two types of control-plane options
for this distributed-PE model: a) to have both Emulated signaling and
Auto-discovery performed at the PE-POP and b) to have Emulated
signaling at the PE-CLE and Auto-discovery at the PE-POP. It should be
noted that in both options, the termination of the Emulated VCs is
performed at the PE-CLE (Emulated VCs are terminated in the same node
that has the VSI functionality). However, in the first option, the
signaling of Emulated VCs is done among the PE-POPs and then the
relevant information is conveyed to the PE-CLEs; whereas, in the second
option, the signaling of Emulated VCs is done directly between the PE-
CLEs (e.g., using directed LDP).
The advantage of performing the signaling for Emulated VCs at the PE-
CLE is that the Emulated VC gets setup as a single segment VC between
the two PE-CLEs and furthermore, the Emulated VC is transparent to the
PE-POP (e.g., only Emulated Tunnels would be visible to the PE-POPs and
therefore, there is less overhead in terms of configuration, state
information and processing for the PE-POP). However, if the signaling
of Emulated VCs is performed at the PE-POP, then the Emulated VC will
have multiple segments and multiple sets of labels (e.g., one set for
each segment) need to be assigned as suggested by [DTLS] û one set of
Sajassi, et al Expires September 2002 [Page 14]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
labels for the customer-facing segment at each PE and another set for
the WAN/MAN segment.
In addition to the configuration burden of maintaining multiple sets of
labels, there is additional overhead for coordinating and installing
routes among these different label sets. Because of the drawbacks of
signaling of Emulated VCs at the PE-POP, this option is not considered
any further and instead in section 10.3, the operational scenario for a
single-segment Emulated VC (e.g., signaling of Emulated VCs at the PE-
CLE) will be elaborated upon further.
Based on the single-segment Emulated VC model (e.g., signaling of
Emulated VCs to be done at the PE-CLE), the VPLS functions can be
partitioned as follow with the following functions residing at the PE-
CLE:
. Attachment VCs termination
. Emulated VCs û termination and signaling
. Emulated Tunnels û signaling and termination
. Maintaining a VSI per VPLS instance
And the following functions residing at the PE-POP:
. Auto-discovery
. Auto-configuration
3. Emulated VCs
For a VPLS system, a set of Emulated VCs is used to connect different
VSIs belonging to the same VPLS instance. Therefore, Emulated VCs are
terminated at the nodes with VSI functionality.
For a VPLS system over an MPLS network, the encapsulation of Emulated
VCs are performed based on [L2ENCAP] and the corresponding signaling is
performed based on [L2SIG].
For a VPLS system over an IP network, the encapsulation and the
signaling of the Emulated VCs can be performed based on [L2TPv3].
We define two additional types of Emulated VCs for a VPLS system that
are the counterparts of the Ethernet VCs defined in [L2SIG] for non-
VPLS L2VPN:
VC Type Description
Sajassi, et al Expires September 2002 [Page 15]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
0x000C VLAN VPLS
0x000D Ethernet VPLS
The reason for the definition of these two types of VCs is that the
system operation with respect to transport of VLAN tagged and untagged
frames, as well as handling of control packets and BPDUs, differs for
each of these VC types.
An Emulated VC, which is of type VLAN VPLS, corresponds to a single
customerÆs VLAN. Therefore, for scenarios where the Service Provider
needs to recognize customersÆ VLANs and provide a separate broadcast
domain for different VLANs, then this Emulated VC type is used.
Furthermore, only the frames with the specified tag are allowed to be
transported over this Emulated VC. The Emulated VC of type VLAN VPLS
corresponds to customersÆ UNI ports that are multiplexed (e.g., each
UNI ports carries multiple Attachment VCs). A customer UNI port is a
physical port between the customerÆs CE and the Service ProviderÆs PE.
However, an Emulated VC of type Ethernet VPLS corresponds to all the
traffic that comes through a customer UNI port û both VLAN tagged and
untagged traffic including BPDUs. In other words, the Emulated VC acts
as a pseudo wire corresponding to the customerÆs Ethernet port. This
type of Emulated VC is used in applications where the Service Provider
doesnÆt need to recognize customersÆ VLANs and thus it only provides a
single broadcast domain (e.g., single VPLS) per customer or set of
customerÆs ports. This type of Emulated VC can be also viewed as
corresponding to customersÆ UNI ports that are not multiplexed (e.g.,
each UNI ports corresponds to a single Attachment VC).
In multiplex UNI scenarios for LAN bridging applications, not only
isolation of customersÆ VLANs are needed (and different VLANs can go to
different switches (CEs)) but also BPDUs packets need to be transported
among these switches. For these applications, besides having a separate
set of Emulated VCs of type VLAN VPLS for each customerÆs VLAN, another
set of Emulated VCs of the same type is used for untagged frames
including BPDUs. Therefore, in multiplex UNI applications, the untagged
frames are transported over the Emulated VCs of type VLAN VPLS (e.g.,
untagged frames can be considered as frames with special tags).
It is important that these two types of Emulated VCs be differentiated
and processed accordingly by the PEs involved in setting up a VPLS
instance, since during the auto-configuration it provides a
compatibility check between Attachment VCs and their corresponding
Emulated VCs.
Sajassi, et al Expires September 2002 [Page 16]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
4. Emulated Tunnels
An Emulated Tunnel is used to carry Emulated VCs between two PEs and to
make them transparent to the P nodes within the network. The general
requirements for these tunnels are given in [L2ARCH]. The Emulated
Tunnels are setup based on one of the existing methods specified for
L3VPNs [L3ARCH] and are independent from L2VPN applications (e.g., if
MPLS is used then tunnels can be either MPLS-TE using RSVP signaling or
can be regular MPLS LSP using LDP signaling).
In the reference architectures that we have defined for the single-PE
and both of the distributed-PE models, the Emulated Tunnels are
terminated at the same node where the Emulated VCs themselves are
terminated. This means in the case of the distributed-PE model with
Ethernet-based PE-CLE, the tunnels are terminated at the PE-POP; and in
the case of the distributed-PE model with MPLS/IP-based PE-CLE, the
tunnels are terminated at the PE-CLE.
5. Attachment Tunnels
The Attachment tunnels are used only for the distributed-PE model and
more specifically with Ethernet-based PE-CLEs. Attachment tunnels can
be between PE-CLEs and PE-POPs that are either directly connected or
via a .1q access network. In the later case, these tunnels are
transparent to the .1q access network and are treated just as regular
VLANs with slightly larger payloads.
Attachment tunnels are formed by placing an outer .1q tag in front of
the frames (either tagged or untagged) entering a PE-CLE via a customer
UNI port. This outer tag is referred to as a PE-VLAN (Provider Edge
VLAN). In the case of a non-multiplexed UNI, the PE-VLAN is the same
for all the ports of a customer belonging to the same VPLS instance,
and in the case of a multiplexed UNI, the PE-VLAN is the same for all
the ports of a customer that share one or more VPLS instances.
The uniqueness of the PE-VLAN needs to be guaranteed within a PE-POP
domain since there are multiple PE-CLEs per PE-POP and PE-VLANs are
used to differentiate between different customers. In other words, PE-
VLAN is a local parameter that gets shared between PE-POP and its
associated PE-CLEs and it is not transported over the Emulated VCs û
instead it can be derived from the Emulated VCs associated with that
VPLS instance.
In the case of a multiplexed UNI, an Attachment tunnel is used to
transport all the customerÆs VLANs (e.g., Attachment VCs) to the PE-POP
and at the PE-POP both the PE-VLAN and CE-VLAN are used together as a
Sajassi, et al Expires September 2002 [Page 17]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
VSI identifier (e.g., the double-tag lookup mechanism described
previously). However, for a non-multiplex UNI, the Attachment tunnel
degenerates into carrying only a single Attachment VC associated with
that UNI and at the PE-POP only the PE-VLAN is used as a VSI
identifier.
5.1. Encapsulation
The following shows the encapsulation format for customer tagged frames
as they are carried between PE-CLE and PE-POP. The encapsulation format
for customer untagged frames is the same as with 802.1q.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Dest. Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC DA cont. | MAC Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC SA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ether Type = 0x8100 | PE-VLAN |PE .1p |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ether Type = 0x8100 | CE-VLAN |CE .1p |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ether Type / Length | Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Signaling
To configure an Attachment tunnel between the PE-CLE and the PE-POP,
the minimum piece of information that needs to be passed to the PE-CLE
is a) Attachment tunnel ID or PE-VLAN and b) customer-ID/VPN-ID
associated with the Attachment tunnel ID or PE-VLAN. The PE-CLE, upon
receiving the message that contains the association between PE-VLAN and
customer-ID/VPN-ID, looks for which of its ports are configured for
that customer-ID/VPN-ID and then applies the PE-VLAN ID to the
respective port(s).
Sajassi, et al Expires September 2002 [Page 18]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
If in addition to the Attachment tunnel configuration, the PE-CLEÆs
port(s) configuration is also done through the PE-POP, then the PE-POP
can resolve the association between PE-VLAN and the associated port and
thus sending the PE-VLAN + port-ID information along with port
configuration information to the PE-CLE (e.g., PE-CLE does not need to
receive customer-ID/VPN-ID info). It should be noted that if the PE-
CLEÆs port configuration is done via the PE-POP, then this shall
include all relevant configuration information including QoS parameters
and thus the signaling protocol shall support it as well.
Signaling of the Attachment Tunnels can be accomplished through
extensions to an existing protocol (e.g., VLAN Trunking Protocol) and
these extensions would only require software changes to the Ethernet-
based PE-CLE (no hardware/ASIC changes are required). This signaling
protocol along with its extensions will be specified in the future.
6. Extension VCs
Extension VCs are used in conjunction with Ethernet-based PE-CLE in the
distributed-PE model for multiplexed UNI ports and they are used in
lieu of the Attachment tunnels. Since Extension VCs are only used for
multiplexed UNI ports, the PE-CLE is required to have VLAN-mapping
capability, which may not be currently available in standard Ethernet
switches. This capability is needed in order to map overlapping VLANs
of different customers into unique internal VLANs (PE-VLANs) so that at
the PE-POP, these PE-VLANs can be used as a VSI identifier.
6.1. Encapsulation
Encapsulation format for Extension VCs is exactly the same as 802.1q
since only customersÆ VLANs are mapped to PE-VLANs and everything else
remains the same.
6.2. Signaling
Similar to the Attachment tunnels, a signaling protocol can be used to
configure the Extension VCs between the PE-CLE and the PE-POP. At the
minimum, the signaling protocol needs to convey the PE-VLAN and the
associated VPN-ID to the PE-CLE. The PE-CLE uses the VPN-ID to identify
which VLAN under which port needs to be mapped to a given PE-VLAN.
Again similar to the Attachment tunnels, if besides configuration of
the Extension VCs, PE-CLEÆs ports and VLANs also need to be configured
Sajassi, et al Expires September 2002 [Page 19]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
via the PE-POP, then only PE-VLAN information needs to be passed to PE-
CLE along with customer port and VLAN configuration (e.g., no need to
pass VPN-ID information to the PE-CLE since the PE-POP can already
resolve the association between PE-VLAN and customer port-ID + VLAN).
Signaling of the Extension VCs can also be accomplished through
extensions to an existing protocol (e.g., VLAN Trunking Protocol) and
these extensions would only require software changes to the Ethernet-
based PE-CLE. This signaling protocol along with its extensions will be
specified in the future.
7. Virtual Switch Instance
As mentioned previously, for a customerÆs VPLS, there exist a VSI in
each PE associated with that VPLS. The VSI, as its name implies, is a
virtual switch that can have logical ports (e.g., virtual circuits) as
its interfaces. Therefore, it has the ability to do regular
bridge/switch functionality such as MAC address learning/aging,
flooding, forwarding (unicasting, multicasting/broadcasting), and
running STP (if needed) per broadcast domain but based on its logical
ports (regular Ethernet switches may only perform these functions on
their physical ports).
In the case of distributed-PE models, VSIs can be located either in PE-
CLEs or PE-POPs based on their capabilities as described previously.
VSIs of a VPLS are connected to each other through Emulated VCs, which
act as pseudo wires. If all the VSIs are connected directly with each
other through a full mesh of Emulated VCs, then one can avoid running
STP in the PEs by disabling packet forwarding between any two Emulated
VCs in a VSI (e.g., packets arriving from Emulated VCs have to go out
on Attachment VCs). This is referred to as Split Horizon in [TLS].
However, if the VSIs are not directly connected with each other, then
loops can exist and other means for loop prevention shall be devised.
The use of STP in such scenarios is for further study. It should be
noted that if STP were used for loop prevention between the PEs, then
it would be different from the customersÆ STPs (e.g., customersÆ BPDUs
are tunneled transparently through the network).
Although, customersÆ BPDUs are passed transparently through the
providerÆs network, there can exist certain scenarios that would
require monitoring of the customerÆs BPDUs and taking the appropriate
action. For example, if a customer is running 802.1w and there is a
change in their network topology, then the corresponding VSI upon
receiving a Topology Change Notification (TCN) shall flush the MAC
addresses learned from all other ports except the one on which it
received the TCN. This processing is needed in order to achieve
Sajassi, et al Expires September 2002 [Page 20]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
convergence time in the order of milliseconds provided by 802.1w. Also,
in some other scenarios where 802.1w is not used, monitoring of
customersÆ BPDUs may be needed for accelerating aging timeouts of all
portsÆ MAC addresses upon receiving a TCN.
8. Auto Discovery
Auto-discovery is used to discover all the PEs associated with a VPLS
instance for setting up Emulated VCs among the corresponding VSIs.
There are two basic mechanisms for auto-discovery. One is based on
Directory Services and it is described in [DIR-AUTO] and the other is
base on BGP that is first described as part of [L3ARCH] and has been
extended and generalized in [BGP-AUTO].
In Directory-based auto-discovery, IP addresses of all participating
PEs for a VPLS are added as records under the VPN-ID (e.g., domain
name) in the directory. When a new Attachment VC is configured, it is
configured with a VPN-ID and the PE queries the directory for the IP
addresses of all other PEs for that VPLS and then tries to establish an
Emulated VC (if one doesnÆt already exist) between its VSI and other
VSIs within the VPLS system.
In BGP-based auto-discovery, similar to the Directory-based scheme, the
VPN-ID is associated with Attachment VCs when they are configured;
however, in contrast with the Directory-based approach, the IP
addresses of the member PEs need not to be entered in another server.
Instead, each PE running the BGP protocol distributes its VPN-ID
information along with its IP address to all other PEs through MP-BGP
Network Layer Reachability Information (NLRI).
In the case of the distributed-PE model (either Ethernet-based or
MPLS/IP-based), the Directory query or BGP protocol is performed by the
PE-POP. Furthermore, if the distributed-PE model is MPLS/IP-based, then
the discovered information (e.g., IP addresses of the peer PEs) for a
VPLS need to be conveyed to the PE-CLE since Emulated VCs are set up
from there (e.g., single-segment Emulated VC between two PE-CLEs).
9. Auto Configuration
Auto-configuration is used to tie all the pieces of a VPLS together.
Sometimes auto-discovery and auto-configuration are used loosely and in
lieu of each other; however, we make a clear distinction between them
in order to clearly define the functionality of each. Auto-discovery is
only limited to member discovery of a VPLS instance (e.g., IP addresses
Sajassi, et al Expires September 2002 [Page 21]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
of all the PEs participating in a VPLS). However, auto-configuration
uses some components of a VPLS (including auto-discovery) as a
triggering mechanism for configuring other components of that VPLS.
As mentioned previously a VPLS can be defined by a quintuple set as
follows: <ingress Attachment VCs, ingress VSIs, Emulated VCs, egress
VSIs, and egress Attachment VCs>. When an Attachment VC is configured
and becomes active, auto-configuration associates the Attachment VC to
a VSI for that VPLS, and uses it to trigger auto-discovery for finding
member PEs. Upon discovery of the member PEs, the auto-configuration
uses the information to trigger configuration of Emulated VCs if they
are not already setup by previous triggers.
Since an Emulated VC is a full-duplex circuit and it consists of two
uni-directional circuits, when configuring an Emulated VC, both
circuits need to be configured. We use the single-sided signaling
mechanism for L2VPNs as described in [SS-SIG] for this purpose, which
basically means the setup of the return leg is triggered by the setup
of the forward leg. The signaling of the Emulated VC also triggers the
activation of the egress Attachment VC if it is not already activated.
Auto-discovery in conjunction with single-sided signaling helps to
confine the configuration changes for adding a new customer site to a
single PE. Therefore, upon configuring the Attachment VC associated
with the new customer site on the corresponding PE, the configuration
of all other pieces is done automatically as described above. It should
be noted that in the case of Directory-based auto-discovery, the
Directory server might also need to be configured (for adding the IP
address of the PE associated with the new site as a new record under
the domain name if it doesnÆt exist).
In the case of a distributed-PE model where the configuration of
Attachment VCs is performed at the PE-POP, then auto-configuration
causes the configuration of an Attachment VC to also trigger the
signaling to the PE-CLE. In the case of an Ethernet-based PE-CLE, the
signaling is for configuring Attachment tunnels or Extension VCs at the
PE-CLE as well as configuring the Attachment VCs at the PE-CLE. In the
case of an MPLS/IP-based PE-CLE, the signaling is for conveying the
VPLS membership information (e.g., IP addresses of associated PEs) to
the PE-CLE as well as configuring the Attachment VCs at the PE-CLE.
10. System Operation
In the following sections, we describe the system operation for
different VPLS system architectures in terms of control and data plane
operation.
Sajassi, et al Expires September 2002 [Page 22]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
10.1. Single-PE
In setting up a VPLS for a customer, first different components of the
VPLS (Attachment VCs, Emulated VCs, and VSIs) need to be configured and
hooked up to each other and next forwarding information needs to be
installed in the VSIs. The former task is done within the domain of the
control plane by use of different signaling protocols and auto-
configuration. The later task of installing forwarding information is
done solely in the data plane by use of MAC address learning and
flooding (this is in contrast to L3VPN where control plane is used for
installing prefix information).
Thus, a VPLS can be considered a collection of virtual switches
connected with each other and to customersÆ devices via logical ports
and the control plane is used for setting up these virtual switches and
connecting them with each other and the customersÆ devices.
Lets look at the control plane operation for a VPLS in more details.
Upon configuring an Attachment circuit at a PE (for connection to a new
customerÆs site), the auto-configuration mechanism on that PE triggers
auto-discovery (either using BGP or DNS) to discover other PEs
participating in this VPLS. Then the PE tries to setup an Emulated VC
between its VSI and every other VSI of the discovered PEs if one
already doesnÆt exist. Once the setup of the Emulated VCs is completed,
then the new Attachment VC is connected to the VPLS and the new CE can
participate in data plane functionality.
The operation of the data plane is the same as for regular Ethernet
switches except that the VSIs have the capability to perform Ethernet
functionality (MAC address learning, flooding, forwarding, and so on)
based on logical ports as mentioned previously. Once the VSIs learn the
MAC addresses of the new CE and associated them with the logical ports
over which they come from, then they perform Layer-2 forwarding based
on these MAC addresses.
10.2. Distributed-PE with Ethernet-based PE-CLE
A VPLS in this model can be considered as a collection of virtual
switches connected with each other via Emulated VCs and connected to
customersÆ devices via Attachment VCs and either Attachment Tunnels or
Extension VCs. Therefore, the network-side of the VSI in this case is
the same as the one for single-PE model, and configuration and
operation of Emulated VCs are the same as the single-PE model and are
not considered further.
Sajassi, et al Expires September 2002 [Page 23]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
The customer-facing side of the VSI is different and it is connected to
customersÆ devices via Attachment VCs in conjunction with Extension VCs
or Attachment tunnels. As described previously, when configuring
Attachment VCs via the PE-POP, the IDs for Attachment Tunnels or
Extension VCs are allocated by the PE-POP and conveyed to the PE-CLEs
via the appropriate signaling along with Attachment VCs configuration
information. The PE-CLE in turn uses this information to setup its end
of the Attachment Tunnels or Extension VCs as well as setting up the
Attachment VCs to the CEs. Once all the pieces are setup, the VPLS is
ready for data-plane operation.
In case of the Attachment Tunnels for non-multiplexed UNI ports, all
the customerÆs traffic on a port (either tagged or untagged) gets sent
through the Attachment tunnel to the PE-POP and at the PE-POP based on
the tunnel ID, the corresponding VSI associated with that VPLS is
selected and the traffic is switched through. It should be noted that
in the case of a non-multiplexed UNI port, the VPLS and in turn the
associated VSIs are transparent to customerÆs VLANs. However, for the
multiplexed UNI ports, the VPLS is associated with a given customerÆs
VLAN and thus it is important to examine the customerÆs VLANs (e.g.,
Attachment VCs) at the PE-POP. Since customersÆ VLANs can overlap with
each other, in order to uniquely identify them, both Attachment Tunnel
ID and Attachment VC ID needs to be looked at together (e.g., double-
tag lookup) to identify the corresponding VSI. After VSI
identification, the packets are forwarded to their destinations based
on their destination MAC address. It should be noted that when
Attachment Tunnels are used for multiplexed ports, the PE-CLE is
oblivious to the Attachment VCs carried inside these tunnels.
Therefore, if there are more than one customer site connected to the
same PE-CLE and these sites use overlapping MAC addresses across
different VLANs, then these VLANs are not isolated from one another at
the PE-CLE. Although such situations are rare, itÆs worth mentioning
that there are solutions for this scenario such as the use of sticky
MAC addresses; however, because of the rarity of this scenario, they
will not be discussed here.
If Extension VCs are used in lieu of Attachment tunnels for multiplexed
UNI ports, then the Extension VC ID can be used directly to identify
the corresponding VSI. However, as mentioned previously, in order to
use the Extension VCs, the PE-CLE must have the ability to map between
the Attachment VCs and the Extension VCs at the ingress port. This
mapping is needed in order to map overlapping customersÆ VLAN IDs into
unique Extension VCs for proper identification of the VSIs. Once a VSI
is selected, then packet forwarding is performed as before.
Sajassi, et al Expires September 2002 [Page 24]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
10.3. Distributed-PE with MPLS/IP-based PE-CLE
In this model virtual switches can be considered connected with each
other via longer logical ports (Emulated VCs) that span across multiple
Service Provider devices (PE-CLEs and PE-POPs). In the previous cases,
an Emulated VC was either between two PEs or between two PE-POPs.
However, in this case an Emulated VC is between two PE-CLEs and it
passes through the PE-POPs transparently. The difference between this
distributed-PE model and the single-PE model is primarily in the
control plane and once the Emulated VCs are setup among the VSIs, then
the data-plane operation is identical to the one for the single-PE
model (whereas, the same thing can not be said for the distributed-PE
model with Ethernet-based PE-CLE).
Since Emulated VCsÆ setup is originated from the PE-CLE, the tunneling
of these VCs also needs to be originated from the PE-CLE. As discussed
before, a signaling protocol is used to pass the IP addresses of other
PE-CLEs discovered via the auto-discovery mechanism from the PE-POP to
the PE-CLE. Upon receiving the IP addresses, the PE-CLE installs them
in its routing table and then uses them as /32 prefixes to establish
the tunnels (for Emulated VCs). The tunnel establishment is done
through one of the existing methods (e.g., downstream unsolicited LDP,
RSVP-TE, and so on). When tunnels are established, then a directed LDP
session is setup for Emulated VC signaling between this PE-CLE and the
other discovered PE-CLEs for that VPLS. It should also be noted that if
the configuration of the PE-CLE is done through the PE-POP, then the
PE-POP can also be configured with the IP address of the PE-CLE and
convey this IP address to the PE-CLE via the signaling protocol;
however, if the Attachment VCs in the PE-CLE are not configured through
the PE-POP, then a simple IGP protocol such as RIP can be used to pass
the IP address of the PE-CLE to the PE-POP.
Once the Attachment VCs are configured and the Emulated VCs are setup
at the PE-CLE to connect the VSI to other VSIs, then the VPLS is ready
for its data-plane operation and furthermore its data-plane operates
exactly as the one for the single-PE model.
11. Security Considerations
The security aspects of each VPLS architecture will be discussed at a
later time.
Sajassi, et al Expires September 2002 [Page 25]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
12. Acknowledgements
The authors would like to thank Michael Wu, Norm Finn, Eric Rosen, Eric
Voit, Suran DeSilva, and Anush Elangovan for their helpful discussions
and feedbacks.
13. References
[L2ARCH] "An Architecture for L2VPNs", Eric Rosen, draft-rosen-ppvpn-
l2vpn-00.txt, May 2001
[VPLS-REQ] ôRequirements for Virtual Private LAN Services (VPLS)ö,
Waldemar Augustyn, draft-augustyn-vpls-requirements-00.txt, April 2002
[L3ARCH] ôBGP/MPLS VPNsö, Rosen, et. al., RFC2547
[PPVPN-FRWK] "A Framework for Provider Provisioned Virtual Private
Networks", R. Callon, draft-ietf-ppvpn-frammework-03.txt, January 2002
[DTLS] "Decoupled Virtual Private LAN Services", K. Kompella, draft-
kompella-ppvpn-dtls-01.txt, May 2002
[L2ENCAPS] "Encapsulation Methods for Transport of Layer 2 Frames
Over MPLS", Martini, et. al., draft-martini-l2circuit-encap-mpls-
01.txt, 2/01.
[L2SIG] "Transport of Layer 2 Frames Over MPLS", Martini, et. al.,
draft-martini-l2circuit-trans-mpls-05.txt, 2/01.
[L2TPv3] ôLayer Two Tunneling Protocol æL2TPÆ, draft-ietf-l2tpext-l2tp-
base-01.txt
[TLS] "Transparent LAN Service over MPLS", M. Lasserre, et. al., draft-
lasserre-vkompella-ppvpn-tls-00.txt, November 2001
[DIR-AUTO] " DNS/LDP Based VPLS", Juha Heinanen, draft-heinanen-dns-
ldp-vpls-00.txt, January 2002
[AUTO] "Using BGP as an Auto-Discovery Mechanism for Network-based
VPNs", Ould-Brahim, et. al., draft-ouldbrahim-bgpvpn-auto-01.txt, 3/01
[SS-SIG] "Single-sided Signaling for L2VPNs", Eric Rosen, draft-rosen-
ppvpn-l2-signaling-00.txt, 3/01
Sajassi, et al Expires September 2002 [Page 26]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
14. Authors' Addresses
Ali Sajassi
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: sajassi@cisco.com
Dan Lee
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Jim Guichard
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Email: jguichar@cisco.com
15. Intellectual Property Considerations
Cisco Systems may seek patent or other intellectual property protection
for some or 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 Cisco Systems, Cisco Systems intends to
disclose those patents and license them on non-discriminatory terms.
16. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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
Sajassi, et al Expires September 2002 [Page 27]
Internet Draft draft-sajassi-vpls-architectures-00.txt February 2002
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.
This document and the information contained herein is provided on an
ôAS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Sajassi, et al Expires September 2002 [Page 28]