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]