Provider Provisioned VPN Working Group Sunil Khandekar
Internet Draft Vach Kompella
Expiration Date: June 2002 Joe Regan
Nick Tingle
TiMetra Inc
Tom Soon Pascal Menezes
SBC Communications Terabeam Networks
Giles Heron Marc Lassere
PacketExchange Ltd. Riverstone Networks
Ron Haberman Kireeti Kompella
Rick Wilder Juniper Networks
Masergy Communications
Marty Borden
Atrica Inc
Hierarchical Virtual Private LAN Service
draft-khandekar-ppvpn-hvpls-mpls-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document proposes scalable extensions to the Virtual Private
LAN Segment (VPLS) solution described in [VPLS], by introducing
hierarchical connectivity. This document also describes support
for participation of non-bridging PE devices in a VPLS solution.
Khandekar, et al Expires June 2002 [Page 1]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
1. Placement of this Memo in Sub-IP Area
RELATED DOCUMENTS
draft-vkompella-ppvpn-vpsn-mpls-00.txt
draft-heron-ppvpn-vpsn-reqmts-00.txt
draft-lasserre-tls-mpls-00.txt
WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK
This fits in the PPVPN box.
WHY IS IT TARGETED AT THIS WG
This work fits in the PPVPN working group charter. It describes
scalable extensions to a service that uses an emulation of a Layer
2 medium to create a provider provisioned virtual private network
0, specifically, a Transparent LAN service.
JUSTIFICATION
We believe the WG should consider this draft because it specifies
extensions for a class of layer 2 VPN
2. Introduction
The solution described in [VPLS] requires a full mesh of tunnel
LSPs between all the PE routers that participate in the VPLS
service. For each VPLS service, n*(n-1) VCs must be setup between
the PE routers. While this creates signaling overhead, the real
detriment to large-scale deployment is the packet replication
requirements for each provisioned VCs on a PE router. Hierarchical
connectivity, described in this document reduces signaling and
replication overhead to allow large-scale deployment.
In many cases, service providers place smaller edge devices in
multi-tenant buildings and aggregate them into a PE device in a
large Central Office (CO) facility. In some instances, standard
IEEE 802.1q (Dot 1Q) tagging techniques may be used to facilitate
mapping CE interfaces to PE VPLS access points. When this is done,
a hierarchical architecture is created outside the context of VPLS;
no service level signaling is present between the PE router and the
MTU bridge.
To avoid issues with Spanning Tree Protocol (STP), 'VLAN' tag
provisioning and non-Ethernet access networks, it is beneficial to
extend VPLS service tunneling techniques into the MTU domain. This
Khandekar, et al Expires June 2002 [Page 2]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
can be accomplished by treating the MTU device as a PE device and
provision VCs between it and every other edge, as described in
[VPLS]. An alternative is to utilize [MARTINI-ENCAP] VCs between
the MTU and selected VPLS enabled PE routers. This document
focuses on this alternative approach. The [VPLS] mesh core tier
VCs (Hub) are augmented with access tier VCs (Spoke) to form a two
tier hierarchical VPLS (H-VPLS).
Spoke VCs may be expanded to include any L2 tunneling mechanism,
expanding the scope of the first tier to include non-bridging VPLS
PE routers. The non-bridging PE router would extend a Spoke VC from
a Layer-2 switch or Router that connects to it, through the service
core network, to a bridging VPLS PE router supporting Hub VCs.
This document also describes support for participation of non-
bridging devices (routers) in a VPLS solution.
3. Hierarchical connectivity
This section describes the hub and spoke connectivity model and
describes the requirements of the bridging capable and non-bridging
devices for supporting the spoke connections.
For rest of this discussion we will refer to a bridging capable MTU
device as MTU-s and a non-bridging capable PE device as PE-r. A
routing and bridging capable device will be referred to as PE-rs.
3.1. Spoke connectivity for bridging-capable devices
As shown in figure-1, consider the case where an MTU-s device has a
single connection to the PE-rs device placed in the CO. The PE-rs
devices are connected in a full mesh. To participate in the VPLS
service, MTU-s device creates a single point-to-point tunnel LSP to
the PE-rs device in the CO. We will call this the spoke
connection. For each VPLS service, a single spoke VC is setup
between an MTU-s and the PE-rs based on [MARTINI-SIG] and [MARTINI-
ENCAP]. Unlike traditional [MARTINI-ENCAP] VCs that terminate on a
physical port at each end, the spoke VC terminates on a virtual
bridge instance on the MTU-s and the PE-rs devices. The MTU-s
device and the PE-rs device treat each spoke connection like an
access port of the VPLS service. On access ports, the combination
of the physical port and the vlan tag is used to associate the
traffic to a VPLS instance while the combination of vc-id and vc-
labels (ingress and egress) are used to associate the traffic on
the virtual spoke port with a VPLS instance.
The signaling and association of the spoke connection to the VPLS
service may be done by introducing extensions to the LDP signaling
as specified in [MARTINI-SIG]. This will be specified in a future
version of this document.
Khandekar, et al Expires June 2002 [Page 3]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
PE2-rs
------
/ \
| -- |
| / \ |
CE-1 | \B / |
\ \ -- /
\ /------
\ MTU-s PE1-rs / |
\ ------ ------ / |
/ \ / \ / |
| \ -- | VC-1 | -- |---/ |
| / \--|- - - - - - - - - - - |--/ \ | |
| \B / | | \B / | |
\ /-- / \ -- / ---\ |
/----- ------ \ |
/ \ |
---- \ ------
|Agg | / \
---- | -- |
/ \ | / \ |
CE-2 CE-3 | \B / |
\ -- /
MTU-s = Bridging capable MTU ------
PE-rs = VPLS capable PE PE3-rs
--
/ \
\B / = Virtual VPLS(Bridge)Instance
--
Agg = Layer-2 Aggregation
3.1.1. MTU-s Operation
The MTU-s device is defined as a device that supports layer-2
switching functionality and does all the normal bridging functions
of learning and replication on all its ports, including the virtual
spoke port. Packets to unknown destination are replicated to all
ports in the service including the virtual spoke port. Once the
MAC address is learned, traffic between CE1 and CE2 will be
switched locally by the MTU-s device conserving the link capacity
of the connection to the PE-rs. Similarly traffic between CE1 or
CE2 and any remote destination is switched directly on to the spoke
connection and sent to the PE-rs over the point-to-point VC LSP.
Since the MTU-s is bridging capable, only a single VC is required
per VPLS instance for any number of access connections in the same
VPLS service. This further reduces the signaling overhead between
the MTU-s and PE-rs.
3.1.2. PE-rs Operation
Khandekar, et al Expires June 2002 [Page 4]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
The PE-rs device is a device that supports all the bridging
functions for VPLS service and supports the routing and MPLS
encapsulation, i.e. it supports all the functions described in
[VPLS]. The operation on the PE-rs node is identical to that
described in [VPLS] with one addition. A point-to-point VC
associated with the VPLS is regarded as a virtual port. The
operation on the virtual spoke port is identical to the operation
on an access port as described in the earlier section. As shown in
figure-1, each PE-rs device switches traffic between aggregated
[MARTINI-ENCAP] VCs that look like virtual ports and the network
side VPLS VCs.
3.2. Advantages of spoke connectivity
Spoke connectivity offers several scaling and operational
advantages for creating large scale VPLS implementations, while
retaining the ability to offer all the functionality of the VPLS
service.
- Eliminates the need for a full mesh of tunnels and full mesh of
VCs per service between all devices participating in the VPLS
service.
- Minimizes signaling overhead since fewer VC-LSPs are required
for the VPLS service.
- Segments VPLS nodal discovery. MTU-s needs to be aware of only
the PE-rs node although it is participating in the VPLS service
that spans multiple devices. On the other hand, every VPLS PE-
rs must be aware of every other VPLS PE-rs device and all of
it's locally connected MTU-s and PE-r devices.
- Addition of other sites requires configuration of the new MTU-s
device but does not require any provisioning of the existing
MTU-s devices on that service.
- Hierarchical connections can be used to create VPLS service
that spans multiple service provider domains. This is explained
in a later section.
3.3. Spoke connectivity for non-bridging devices
In some cases, a bridging PE-rs device may not be deployed in some
CO while a PE-r might already be deployed. If there is a need to
provide VPLS service from the CO where the PE-rs device is not
available, the service provider may prefer to use the PE-r device
in the interim. In this section, we explain how a PE-r device that
does not support any of the bridging functionality as described in
[VPLS] can participate in the VPLS service.
Khandekar, et al Expires June 2002 [Page 5]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
PE2-rs
------
/ \
| -- |
| / \ |
CE-1 | \B / |
\ \ -- /
\ /------
\ PE-r PE1-rs / |
\ ------ ------ / |
/ \ / \ / |
| \ | VC-1 | -- |---/ |
| ------|- - - - - - - - - - - |--/ \ | |
| -----|- - - - - - - - - - - |--\B / | |
\ / / \ -- / ---\ |
------ ------ \ |
/ \ |
---- \------
| Agg| / \
---- | -- |
/ \ | / \ |
CE-2 CE-3 | \B / |
\ -- /
PE-r = Non-Bridging PE (router) ------
PE-rs = VPLS capable PE PE3-rs
--
/ \
\B / = Virtual VPLS(Bridge)Instance
--
Agg = Layer-2 Aggregation
As shown in figure-2, the PE-r device creates a point-to-point
tunnel LSP to a PE-rs device. Then for every access port that
needs to participate in a VPLS service, the PE-r device creates a
point-to-point [MARTINI-SIG] VC that terminates on the physical
port at the PE-r and terminates on the virtual bridge instance of
the VPLS service at the PE-rs.
3.3.1. PE-r Operation
The PE-r device is defined as a device that supports routing but
does not support any bridging functions. However, it is capable of
setting up [MARTINI-SIG] VCs between itself and the PE-rs. For
every port that is supported in the VPLS service, a [MARTINI-SIG]
VC is setup from the PE-r to the PE-rs. Once the VCs are setup,
there is no learning or replication function required on part of
the PE-r. All traffic received on an access port is transmitted on
the VC associated with that access port. Similarly all traffic
received on a VC is transmitted to the access port where the VC
terminates. Thus traffic from CE1 destined for CE2 is switched at
PE-rs and not at PE-r.
Khandekar, et al Expires June 2002 [Page 6]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
This approach adds more overhead than the bridging capable (MTU-s)
spoke approach since a VC is required for every access port that
participates in the service versus a single VC required per service
(regardless of access ports) when a MTU-s type device is used.
However, this approach offers the advantage of offering a VPLS
service in conjunction with a routed internet service from CO where
the PE-rs device is not yet deployed while the PE-r device is
deployed.
3.3.2. PE-rs Operation
The operation of PE-rs is independent of the type of device at the
other end of the spoke connection. Whether there is a bridging
capable device (MTU-s) at the other end of the spoke connection or
there is a non-bridging device (PE-r) at the other end of the spoke
connection, the operation of PE-rs is exactly the same. Thus, the
spoke connection from the PE-r is treated as a virtual port and the
PE-rs device switches traffic between the virtual port, access
ports and the network side VPLS VCs once it has learned the MAC
addresses.
4. Redundant Spoke Connections
An obvious weakness of the hub and spoke approach described thus
far is that the MTU device has a single connection to the PE-rs
device. In case of failure of the connection or the PE-rs device,
the MTU device suffers total loss of connectivity.
In this section, we describe how redundant connections can be
provided to avoid total loss of connectivity from the MTU device.
The mechanism described is identical for both, MTU-s and PE-r type
of devices
4.1. Dual-homed MTU-s OR PE-r device
To protect from connection failure of the VC or the failure of the
PE-rs device, the MTU-s device or the PE-r device is dual-homed
into two PE-rs devices, as shown in figure-3. The PE-rs devices
must be part of the same VPLS service instance.
An MTU-s device will setup two [MARTINI-ENCAP] VCs (one each to
PE1-rs and PE3-rs) for each VPLS instances. One of the two VC is
designated as primary and is the one that is actively used under
normal conditions, while the second VC is designated as secondary
and is held in a standby state. The MTU-s device or the PE-r
device negotiates the VC-labels for both the primary and secondary
VC, but does not use the secondary VC unless the primary VC fails.
Since only one link is active at a given time, a loop does not
exist and hence 802.1D spanning tree is not required.
Khandekar, et al Expires June 2002 [Page 7]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
PE2-rs
------
/ \
| -- |
| / \ |
CE-1 | \B / |
\ \ -- /
\ /------
\ MTU-s PE1-rs / |
\------ ------ / |
/ \ / \ / |
| -- | Primary VC | -- |---/ |
| / \--|- - - - - - - - - - - |--/ \ | |
| \B / | | \B / | |
\ -- \/ \ -- / ---\ |
------\ ------ \ |
/ \ \ |
/ \ \ ------
/ \ / \
CE-2 \ | -- |
\ Secondary VC | / \ |
- - - - - - - - - - - - - - - - - |-\B / |
\ -- /
MTU-s = Bridging capable MTU ------
PE-rs = VPLS capable PE PE3-rs
--
/ \
\B / = Virtual VPLS(Bridge)Instance
--
4.2. Failure detection and recovery
The MTU-s device controls the usage of the VC links to the PE-rs
nodes. Since LDP signaling is used to negotiate the VC-labels, the
keepalive messages used for the LDP session are used to detect
failure of the primary VC.
Upon failure of the primary VC, the MTU-s device immediately
switches to the secondary VC. At this point, the PE3-rs device
that terminates the secondary VC starts learning MAC addresses on
the spoke VC. All other PE-rs nodes in the network think that CE-1
and CE-2 are behind PE1-rs and may continue to send traffic to PE1-
rs until they learn that the devices are now behind PE3-rs. The
relearning process can take a long time and may adversely affect
the connectivity of higher level protocols from CE1 and CE2. To
enable faster convergence, the PE1-rs device where the primary VC
failed SHOULD send out a flush message, using the MAC TLV as
defined in [VPLS], to all other PE-rs devices participating in the
VPLS service. Upon receiving the message, all PE-rs flush the MAC
addresses learned from PE1-rs. This creates more traffic
Khandekar, et al Expires June 2002 [Page 8]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
temporarily, since the remote PE-rs device that is transmitting to
the CE1 and CE2 must replicate the traffic until it learns that the
devices are now behind PE3-rs. This approach, however, speeds upon
the convergence times when devices move from PE-rs to PE-rs.
5. Multi-domain VPLS service
Hierarchy can also be used to create a large scale VPLS service
within a single domain or a service that spans multiple domains
without requiring full mesh connectivity between all VPLS capable
devices. Two fully meshed VPLS networks are connected together
using a single LSP tunnel between the VPLS gateway devices. A
single VC is setup per VPLS service to connect the two domains
together. The VPLS gateway device joins two VPLS services together
to form a single multi-domain VPLS service. The requirements and
functionality required from a VPLS gateway device will be explained
in a future version of this document.
6. Security Considerations
No new security issues result from this draft. It is recommended
in that LDP security (authentication) methods be applied. This
would prevent unauthorized participation by a PE in a VPLS.
Traffic separation for VPLS is maintained using VC labels or IEEE
802.1q VLAN tags. However, for additional levels of security, the
customer MAY deploy end-to-end security, which is out of the scope
of this draft.
7. References
IETF Drafts
[VPSN-REQ] Heron et al, "Requirements for Virtual Private
Switched Networks", (draft-heron-ppvpn-vpsn-reqmts-
00.txt), work in progress, July 2001.
[PPVPN-REQ] "Service Requirements for Provider Provisioned
Virtual Private Networks", M. Carugi, et al. August
2001. draft-ietf-ppvpn-requirements-02.txt. Work
in progress.
[VPSN] VKompella et al, "Virtual Private Switched Network
Services over an MPLS Network" , (draft-vkompella-
ppvpn-vpsn-mpls-00.txt), work in progress, July
2001.
Khandekar, et al Expires June 2002 [Page 9]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
[TLS] Lasserre et al, "Transparent VLAN Services over
MPLS". (draft-lasserre-tls-mpls-00.txt), work in
progress, August 2001.
[VPLS] Vkompella Lasserre et al, "Signaling Virtual Private
LAN Segments", work in progress, November 2001.
[MARTINI-ENCAP]
Martini et al, "Encapsulation Methods for
Transport of Layer 2 Frames Over IP and MPLS
Networks", (draft-martini-l2circuit-encap-mpls-
04txt), work in progress, November 2001.
[MARTINI-SIG]
Martini et al, "Transport of Layer 2 Frames
Over MPLS", (draft-martini-l2circuit-trans-mpls-
08.txt), work in progress, November 2001.
[LDP] "LDP Specification", L. Andersson, et al. RFC
3036.January 2001.
8. Authors' Addresses
10. Author Information
Sunil Khandekar
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Tel.: +1 (650) 237-5105
Email: sunil@timetra.com
Vach Kompella
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Tel.: +1 (650) 237-5152
Email: vkompella@timetra.com
Joe Regan
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Tel.: +1 (650) 237-5103
Email: jregan@timetra.com
Nick Tingle
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Tel.: +1 (650) 237-5105
Khandekar, et al Expires June 2002 [Page 10]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
Email: sunil@timetra.com
Pascal Menezes
Terabeam
14833 NE 87th St.
Redmond, WA, USA
Email: Pascal.Menezes@Terabeam.com
Phone: +1 (206) 686-2001
Tom S. C. Soon
SBC Technology Resources Inc.
4698 Willow Road
Pleasanton, CA 94588
Tel.: +1 (925) 598-1227
Email: sxsoon@tri.sbc.com
Marc Lasserre
Riverstone Networks
5200 Great America Pkwy
Santa Clara, CA 95054
Tel.: +1 (408) 878-6550
Email: marc@riverstonenet.com
Giles Heron
PacketExchange Ltd.
The Truman Brewery
91 Brick Lane
LONDON E1 6QL
United Kingdom
Tel.: +44 7880 506185
Email: giles@packetexchange.net
Ron Haberman
Masergy Communications
2901 Telestar Ct.
Falls Church, VA 22042
Tel.: +1 (703) 846-0159
Email: ronh@masergy.com
Rick Wilder
Masergy Communications
2901 Telestar Ct.
Falls Church, VA 22042
Tel.: +1 (703) 846-0529
Email: rwilder@masergy.com
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
kireeti@juniper.net
Khandekar, et al Expires June 2002 [Page 11]
Internet Draft draft-khandekar-ppvpn-hvpls-mpls-00.txt November 2001
Marty Borden
Atrica, Inc.
30 Shaker Lane
Littleton, MA 01460
mborden@atrica.com
Khandekar, et al Expires June 2002 [Page 12]