L2VPN Working Group F. Balus Internet Draft M. Bocci Expires: January 2008 M. Aissaoui Alcatel-Lucent John Hoffmans KPN Geraldine Calvignac France Telecom July 2, 2007 VPLS Extensions for Provider Backbone Bridging draft-balus-l2vpn-vpls-802.1ah-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 2008. Abstract IEEE 802.1ah draft standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on Balus, et. al Expires January 2, 2008 [Page 1] Internet-Draft VPLS Extensions for PBB July 2007 multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance, load balancing. As a result the coverage of the solution is limited, service providers avoiding large scale deployments of STP in the core of their network. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution based on superior tunneling capabilities through the use of routed, traffic engineered backbone. As a result VPLS has been deployed on a large scale in service provider networks, providing also for a fully interoperable, extensible model. This draft discusses extensions to VPLS model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1. Terminology....................................................3 2. Introduction...................................................3 3. Architecture...................................................4 4. Deployment Scenarios...........................................6 5. Data Plane.....................................................8 6. Auto-Discovery.................................................8 7. Signaling......................................................8 7.1. MAC Address Withdraw.....................................10 7.2. Flood Containment in the Backbone VPLS...................10 8. Multicast Handling............................................11 9. Resiliency....................................................11 10. OAM..........................................................11 11. Security Considerations......................................11 12. IANA Considerations..........................................11 13. Acknowledgments..............................................12 14. References...................................................13 14.1. Normative References....................................13 14.2. Informative References..................................13 Balus, et al. Expires December 2, 2008 [Page 2] Internet-Draft VPLS Extensions for PBB July 2007 Author's Addresses...............................................13 Intellectual Property Statement..................................14 Disclaimer of Validity.................Error! Bookmark not defined. Copyright Statement..............................................14 Acknowledgment...................................................15 1. Terminology [IEEE802.1ah] provides terminology for Provider Backbone Bridging. This document defines the following additional terms: B-x: a component of the Backbone domain B-VPLS: a VPLS that operates in the Backbone MAC domain B-VSI: A VPLS Service Instance (VSI) that participates in a B-VPLS B-FEC: A FEC associated with a certain B-VSI association B-PW: A PW interconnecting two B-VSI Instances I-x: a component of the customer domain I-VPLS: a VPLS that operates in the customer MAC domain I-VSI: A VPLS Service Instance (VSI) that participates in a I-VPLS I-FEC: A FEC associated with a certain I-VSI association I-PW: A PW interconnecting two I-VSI Instances PBB VPLS: a PBB Service built around a I-VPLS component tunneled potentially through a B-VPLS "tunnel" PBB PE: a PE that contains an I-VSI and a related B-VSI. 2. Introduction The IEEE model for PBB is organized around a B-component handling the provider backbone MAC layer and an I-component concerned with the Customer MAC domain. PBB encapsulates customer payload in a provider Ethernet header, providing for Customer MAC hiding capabilities. Balus, et al. Expires December 2, 2008 [Page 3] Internet-Draft VPLS Extensions for PBB July 2007 PBB requires the use of MSTP as the core control plane (B-domain) for loop avoidance, load balancing. As a result the coverage of the solution is limited, service providers avoiding large scale deployments of STP in the core of their network. VPLS provides a solution based on superior tunneling capabilities through the use of a routed, traffic engineered backbone. VPLS use of the structured FEC 129 [RFC4762] allows for inter-domain, inter- provider connectivity. This is an interoperable model, fully tested in large scale deployments. VPLS creates an emulated LAN Segment using as building blocks a set of Virtual Switch Instances (VSIs) interconnected using Virtual Links - i.e. based on Pseudowires or native Ethernet. In a large scale deployment, there might be a need to split the backbone domain into two or more domains using the Hierarchical VPLS (HVPLS) model described in [RFC4762]. This may be required for administrative reasons or to provide efficient handling of packet replication. In this context VPLS scalability may be improved by hiding the customer MAC addresses at the edge PEs so that the core PEs (e.g. PE- rs) handle just the Provider MAC addresses. Also a "Backbone VPLS" may be used to handle multiple customer VPNs, improving the speed of provisioning and reducing the number of required PWs. This document proposes simple extensions to the VPLS model to allow for selective inclusion of useful PBB capabilities while avoiding the use of MSTP in the backbone. The proposed architecture accommodates though the use of native Ethernet model, MSTP-based for the PBBN [IEEE802.1ah] should a provider choose to deploy it. The basic functions do not require changes to existing PW, MPLS data or control plane. We are proposing some optional extensions to PW signaling to optimize the MAC Withdraw process and to address flood containment in the backbone VPLS. 3. Architecture A PBB VPLS may be represented as one or more I-VPLSes interconnected via a Backbone VPLS (B-VPLS) that may be seen as a multi-point tunnel. Inside a particular PBB PE, a "PBB VPLS VSI" may be modeled as an "I-VSI" mapped to a "B-VSI" operating on Customer MAC layer, respectively on the Backbone MAC layer - see Figure 1 below: Balus, et al. Expires December 2, 2008 [Page 4] Internet-Draft VPLS Extensions for PBB July 2007 ,,.--.,, ,-` `', - ' ' \ | MPLS | | | , / . / /., _./ | | /`''--''` | | | | | | +-\-\--+ +--\-\-+ | B-PW | | B-PW | +-----| |----| |-----+ | +------+ +---.--+ | | `. ,.., ` | | ' `-` | ,.-., | ,. B | | ,' `+-------+ ,-` . / | / | | .'` `/.` | | PBBN | B-ETH | ` | | \ | | ,- | `. ,+-------+ / ` | `'-'` | ' I `. | | ,' . | | --.--.-----' | | .` | `. | | +-----`+ +--\---+ +-'----+ | | | | | | | | | +--| I-PW |-| I-ETH|-| I-Q |--+ | | | | | | +--/---+ +--_---+ +------+ ` / \ `. ` ,.-/, / \ ,.'/, ,' `. - ' ,' `. / , CE CE / , | I-HVPLS | Q-in-Q \ ` \ ` `. ,' `. ,' `'-'` `'-'` Figure 1: "PBB VPLS VSI" architecture** **This representation of PBB VPLS components is a theoretical model to be used to ease the discussion around the solution. It is up to the implementations to optimize the functions described in this document as long as they provide for solution interoperability. The I-VSIs may be mapped 1:1 or many:1 (m:1) to the B-VSIs. PBB MAC hiding, aggregation functions are provided by encapsulating the Balus, et al. Expires December 2, 2008 [Page 5] Internet-Draft VPLS Extensions for PBB July 2007 Customer MAC frame into a Provider Ethernet Header and by mapping, the Customer MACs to Backbone MACs. An I-component Service ID (ISID) may be used to provide additional multiplexing capabilities (m:1 model). PW or native Ethernet virtual ports may be associated with these entities in Backbone and/or Customer domains. In Figure 1 they are tagged with B-PW/B-ETH, respectively I-PW/I-ETH. Each of these domains may use a full mesh, a hub and spoke topology or a combination as described in [RFC4762]. The edge PEs containing both I-VSIs and B-VSIs are equivalent with a PBB IB-BEB - see [IEEE802.1ah]. The core PEs will usually run just the Backbone component (i.e. "B-VSI"), equivalent with a regular VPLS PE operating in the Backbone MAC domain. 4. Deployment Scenarios VPLS is being deployed in the Service Provider networks as a solution for Ethernet Multi-point service spanning multiple network domains: e.g. Metros interconnected via a national/international backbone. Figure 2 shows an example of three VPLS domains where PE 3 and PE4 are the core PEs. For some very large VPNs, it may make sense to use a PBB "VPLS VSI" in the edge PEs (1, 2, 5 and 6) to hide the customer MAC addresses from the core PEs. B-PWs are used to provide B-VSI interconnect over a routed, Traffic Engineered backbone between the core B-VSIs e liminating the need for configuring Backbone VLAN IDs (BVIDs) throughout the core. Carrier of Carrier Services may be sold using this additional hierarchy of services where the a Carrier may sell a L2 Service using its MPLS infrastructure but use PBB to separate the addressing of its Carrier customer from its backbone. IEEE 802.1ah specification allows for 1:1 or m:1 I-component(s) to B- component mapping. The former option (1:1) may be chosen by a service provider who is content with the level of service multiplexing provided by the B-PWs. In this particular scenario there is no need for using an ISID for identifying the service: i.e. the B-PW fully identifies the end customer VSI (I-VSI). A default ISID value may be used instead. Balus, et al. Expires December 2, 2008 [Page 6] Internet-Draft VPLS Extensions for PBB July 2007 _,,..--..,,, ,-'` `'-, .` `' ,' `. / VPLS , | Domain 2 | \ ` `. ` ', _-` +------`-,, _,-`-------+ | ,-, | ``'''--'''`` | ,-, | PE3 | | B | | | | B | | PE4 | | | | | | | | | `'' | | `'' | +-,--,,-+ +--,--,,+ ,' \ ,' \ / \ / \ | VPLS | | VPLS | | Domain 1 | | Domain 2 | | | | | \ / \ / `. / `. / +------`-,,+-------+ +-------+'-'+-------+ | ,-, | | ,-, | | ,-, | | ,-, | | | B | | | | B | | | | B | | | | B | | | | | | | | | | | | | | | | | | | `'' | | `'' | | `'' | | `'' | | I1 I2 | | I1 I3 | | I1 I2 | | I1 I3 | +-------+ +-------+ +-------+ +-------+ PE1 PE2 PE6 PE5 Figure 2 PBB VPLS Topology for m:1 use case Alternatively the ISID may be used to provide an additional level of service multiplexing, on top of the B-PW FEC and service label. There are use cases when the I-VPLS domains that share the same B- VPLS overlap but in most practical scenarios that is not the case. A flood containment solution may be required to address the latter scenario (i.e. I-VPLS domains do not overlap). While this iteration of the document is focused on PBB VPLS solution where B-PWs are used as core infrastructure, the model allows for native Ethernet Access (QinQ and/or PBB based) or even a full PBB solution to be deployed using just the I-ETH or B-ETH interconnects between the related I-VSIs and respectively B-VSIs. Balus, et al. Expires December 2, 2008 [Page 7] Internet-Draft VPLS Extensions for PBB July 2007 Specific service provider requirements define the reach of PBB and VPLS domains within their networks. It is not in the scope of this document to specify how far PBB and VPLS boundaries extend. The PBB VPLS may co-exist in the same PE with non PBB services: i.e. regular VPLS or VLLs using MPLS PW where PBB MAC hiding or aggregation functions are not required. 5. Data Plane The core PEs are not PBB aware. Existing VPLS, PWE3 procedures, including Multi-Segment PWs (MS-PW) apply: i.e. just the regular Backbone Ethernet header is used to forward the frames. At the PBB VPLS PEs (BEBs) additional PBB encapsulation/de-encapsulation is required when passing the frame between the I and B components - see [IEEE802.1ah]. Additional ISID look-up is required whenever m:1 I- VSIs to B-VSI model is used. 6. Auto-Discovery Existing VPLS discovery procedures as per [L2VPN-Sig] may be used in the B-VPLS domain and even inside each local I-VPLS domain. End-to-end auto-discovery of I-VPLS instances coincides with BVPLS discovery for the 1:1 I-VSI to B-VSI model. 7. Signaling The setup of the B-PWs and/or the I-PWs between related VSI entities may be achieved using the existing PWE3 procedures - see [RFC4762]. FEC 128 or FEC 129 may be used to identify each VSI instance accordingly. Lack of congruency between customer VPN domains might determine Service Providers to deploy an 1:1 model (I to B). For this particular scenario, the backbone FEC and related PW Service Labels fully identify the PBB VPLS in the control and data plane. There is no need for the ISID to be configured, signaled or used in the data plane to provide service multiplexing. For the m:1 (I to B) model it is useful to include in the LDP signaling the I-VPLS information associated with the PBB VPLS instances. The ISID information and the associated BMAC on a certain PBB PE (BEB) may be signaled when required using a new LDP TLV, the "PBB TLV". Balus, et al. Expires December 2, 2008 [Page 8] Internet-Draft VPLS Extensions for PBB July 2007 This TLV may be used for the m:1 model in conjunction with the B-VPLS FEC TLV to optimize the MAC Address Withdraw and for flood containment in the related B-VPLS infrastructure as described in section 7.1 and 7.2. A suggested PBB TLV structure is given below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PBB TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PBB sub-TLV type values are TBD. The Lenght field is used to define the length of the PBB sub-TLV including the type and the length itself. Processing of the sub-TLVs should continue when unknown ones are encountered, and they MUST be silently ignored. One or more of the following sub-TLV may be included in the PBB TLV: - I-VPLS ID sub-TLV type A 4 octet value containing the ISID value of the related I-VPLS - B-MAC Address sub-TLV type A 6 octet value containing the BMAC address associated with the I- VPLS ID(s). Usage of this optional new TLV is specified in the following sections. Balus, et al. Expires December 2, 2008 [Page 9] Internet-Draft VPLS Extensions for PBB July 2007 7.1. MAC Address Withdraw The use of Address Withdraw message with MAC List TLV is proposed in [RFC4762] as a way to expedite removal of MAC addresses as the result of a topology change (e.g. failure of a primary link for a dual-homed VPLS capable switch). These existing procedures apply to B-VPLS and I-VPLS domains. When it comes to reflecting access failures across the core (i.e. B- VPLS) domain certain additions should be considered as described below. MAC Switching in PBB is based on the mapping of customer MACs to Provider MAC(s). A topology change in the access (I-domain) should generate just the flushing of Customer MAC entries in the PBB PE (BEB) FIB(s) associated with a certain I-VPLS. Further optimizations may consider flushing just the Customer MACs that are mapped to a specific destination BMAC. These goals may be achieved by adding the PBB TLV associated with the affected I-VPLS(s) in the Address Withdraw message to indicate the particular domain requiring MAC flush. At the other end the receiving PBB PEs may use the ISID(s) and/or the BMAC information to flush only the related FIB entry(entries) (customer/I-domain). 7.2. Flood Containment in the Backbone VPLS PBB is using a special Backbone Group MAC (BMAC) address every time flooding in the B-domain is required. This BMAC is built (see [IEEE802.1ah]) using a group OUI assigned for PBB usage followed by the ISID value in the last 24 bit of the MAC address. As I-VPLS components are added to a certain Backbone VPLS, the new components identifying the PBB Service Instance may be used to advertise the presence of a specific ISID on a certain PBB PE and throughout the BVPLS core. At the Backbone VPLS PEs, the ISID information may be used to build a flooding tree in the data plane that will deliver traffic through the BVPLS structure just to the PBB PEs where the IVPLS endpoints are present. The dissemination of the ISID information is achieved through the use of PBB TLV. The above procedure assumes the same ISID value is used to identify the customer VPN across the BVPLS domain. Inter-provider scenarios will be discussed in a future version of the document. Balus, et al. Expires December 2, 2008 [Page 10] Internet-Draft VPLS Extensions for PBB July 2007 8. Multicast Handling PBB MAC hiding may create difficulties for identifying customer Multicast exchanges. It is important to be able to support both regular and PBB VPLSes. That way the customer VPNs requiring large volume of Multicast may be addressed using regular VPLS, allowing for easy multicast snooping throughout the VPLS infrastructure. Alternatively the optimization for Flood Containment may be expanded to allow for efficient Multicast handling in the BVPLS infrastructure: i.e. Group BMAC addresses may be assigned on a per group of Multicast trees sharing the same ISID endpoints. 9. Resiliency [IEEE802.1ah] recommends the use of Provider MSTP (P-MSTP) to ensure loop free topology for connectionless forwarding through a native PBB core. Using BVPLS infrastructure instead of native Ethernet core eliminates the need for backbone P-MSTP through the use of a full mesh of PWs with split-horizon or via the HVPLS scheme (Primary/Standby PWs) - see [RFC4762]. On the access side, for a PB network or a CE device dually connected to PBB PEs, a loop spanning both I and B domains may occur. An STP- based or a local mechanism may be used to break this loop. A solution that does not imply running MSTP end-to-end in the I domain may involve the MAC Withdraw scheme described in the signaling section to speed up data plane convergence. 10. OAM Existing VPLS OAM tools may be used in each I-VPLS and B-VPLS domain. Details of the required OAM tools and discussion on the correlation between these two domains are out of scope of this draft. 11. Security Considerations This section will be added in a future version. 12. IANA Considerations This document proposes the use of a new LDP TLV and related sub-TLV. Suggested values TBD. Balus, et al. Expires December 2, 2008 [Page 11] Internet-Draft VPLS Extensions for PBB July 2007 13. Acknowledgments The authors gratefully acknowledge the contributions of Nabil Bitar and Wim Henderickx. Balus, et al. Expires December 2, 2008 [Page 12] Internet-Draft VPLS Extensions for PBB July 2007 14. References 14.1. Normative References [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [IEEE802.1ah] IEEE Draft P802.1ah/D3.5 "Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges", Work in Progress, April 19, 2007 14.2. Informative References [L2VPN-Sig] E. Rosen, et Al. "Provisioning, Autodiscovery and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt, May 2006 ( work in progress ) Author's Addresses Florin Balus Alcatel-Lucent 701 E. Middlefield Road Mountain View, CA, USA 94043 Email: florin.balus@alcatel-lucent.com Mustapha Aissaoui Alcatel-Lucent 600 March Road Kanata, ON Canada e-mail: mustapha.aissaoui@alcatel-lucent.com Matthew Bocci Alcatel-Lucent, Voyager Place Shoppenhangers Road Maidenhead Berks, UK e-mail: matthew.bocci@alcatel-lucent.co.uk Balus, et al. Expires December 2, 2008 [Page 13] Internet-Draft VPLS Extensions for PBB July 2007 Geraldine Calvignac France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: geraldine.calvignac@orange-ftgroup.com John Hoffmans KPN 's-Gravenhage, Regulusweg 1 HV IV Regulusweg 1 2516 AC Den Haag Nederland Email: john.hoffmans@kpn.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Balus, et al. Expires December 2, 2008 [Page 14] Internet-Draft VPLS Extensions for PBB July 2007 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Balus, et al. Expires December 2, 2008 [Page 15]