Internet Working Group Ali Sajassi Internet Draft Luyuan Fang Pradosh Mohapatra Cisco Nabil Bitar Verizon Raymond Zhang British Telecom Expires: January 2009 July 2008 Multicast Pruning in Provider Backbone Bridged VPLS draft-sajassi-l2vpn-pbb-vpls-multicast-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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The scalability of H-VPLS (either with MPLS or Ethernet access network) can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. Sajassi, et. al. [Page 1] draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 2008 The ingress replication of PBB multicast traffic can be further improved by replicating such traffic over a subset of PWs for which there are receivers interested in that PBB multicast group. This document discusses the use of BGP for distribution of PBB multicast addresses (e.g., auto-discovery of these addresses) and applying multicast pruning to a VPLS instance for efficient ingress replication. Conventions 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. Introduction....................................................2 2. Terminology.....................................................3 3. Multicast Pruning in Native PBBN................................5 4. Multicast Pruning in H-VPLS with PBB Components.................6 5. BGP Extensions..................................................7 5.1. Tunnel Identifier..................Error! Bookmark not defined. 5.2. PBB-VPLS NLRI.................................................7 6. Security Considerations.........................................8 7. IANA Considerations.............................................8 8. Intellectual Property Considerations............................8 9. Full Copyright Statement........................................8 10. IPR Notice.....................................................8 11. Normative References...........................................9 12. Informative References.........................................9 13. Authors' Addresses.............................................9 1. Introduction [VPLS-PBB] introduces the use of Provider Backbone Bridge (PBB) encapsulation in H-VPLS for providing better scalability of Customer MAC addresses (C-MACs) and Pseudowires. PBB encapsulation provides a hierarchical MAC-address scheme where customer MAC frames are encapsulated in "backbone" MAC frames before being forwarded in the Provider Network. C-MAC learning is performed only at the edge of the network (by I-Components) whereas all forwarding and learning in the core of the network is performed on Backbone MAC addresses (B- MACs). This gives rise to two independent MAC address spaces: the C- Sajassi, et al. [Page 2] draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 2008 MAC address space and the B-MAC address space; where, the latter one is administered and controlled by the Service Provider. This document describes how BGP can be used to distribute the provider administered B-MAC multicast addresses among different PE devices so that ingress replication can be restricted to those PE devices interested in receiving these B-MAC multicast groups. In other words, BGP is used as an auto-discovery mechanism for B-MAC multicast groups among PE devices. The mapping of one or more customer multicast addresses (either C-MAC or IP multicast group addresses) to a provider B-MAC multicast address (either statically or dynamically) is outside of the scope of this document. [VPLS-PBB] covers a number of interoperability scenarios where one of the prominent one is the mapping of bridge domain in B-MAC space (e.g., B-VLAN) to a VPLS instance (after encapsulating a customer frame inside a PBB frame); therefore, achieving both C-MAC and PW scalabilities. In [VPLS-PBB], this scenario is described for both H- VPLS with PBBN as native Ethernet access network (in context of type-I interface) and H-VPLS with MPLS access network using PBB encapsulation at u-PE devices. In these scenarios, the intermediate PE devices (n-PEs) require no additional functionality beyond existing H-VPLS functions (e.g., no visibility into I-SIDs). However, the main drawback of this scheme is the inefficient operation of provider multicast traffic where it is flooded over the corresponding VPLS instance even if some of the PE devices have no interest in that multicast traffic (e.g., ingress replication is performed over all Pseudowires for that VPLS instance rather than only a subset). This document describes how to improve ingress replication for provider multicast traffic (e.g., B-MAC multicast groups) by distributing these locally administered addresses using BGP and then limit the ingress replication for a given B-MAC multicast group to only those PEs that have interest in that group. It should be noted that one of the main advantage of mapping a bridge domain in B-space (e.g., B-VLAN) to a VPLS instance is that it not only provides C-MAC scalability via hierarchical MAC encapsulation but also it reduces the number of VPLS instances substantially, therefore, reducing operational overhead for configuring and monitoring these VPLS instances. Thus, by providing an efficient ingress replication mechanism for provider multicast traffic, this scheme becomes more preferable over other schemes specified in [VPLS-PBB] for a single I-SID domain. Section 2 provides a summary of the terminology used throughout the document. Section 3 discusses the procedure for multicast pruning in PBB-HVPLS. Section 4 captures the message formats. Finally, section 6 summarizes the advantages of the solution. 2. Terminology Sajassi, et al. [Page 3] draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 2008 802.1ad: IEEE specification for "Q-in-Q" encapsulation and bridging of Ethernet frames. 802.1ah: IEEE specification for "MAC tunneling" encapsulation and bridging of frames across a provider backbone bridged network. B-BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It contains a B-component that supports bridging in the provider backbone based on B-MAC and B-TAG information. B-MAC: The backbone source and destination MAC address fields defined in the 802.1ah provider MAC encapsulation header. BCB: A backbone core bridge running in the core of a provider backbone bridged network. It bridges frames based on B-TAG information just as an 802.1ad provider bridge will bridge frames based on a VLAN identifier (S-VLAN) BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It can contain an I-component, B-component or both I and B components. B-TAG: field defined in the 802.1ah provider MAC encapsulation header that conveys the backbone VLAN identifier information. The format of the B-TAG field is the same as that of an 802.1ad S-TAG field. B-VID: The specific VLAN identifier carried inside a B-TAG C-MAC: Customer source or destination address used in a customer MAC frame. I-Component: A bridging component contained in a backbone edge bridge that bridges in the customer space (customer MAC addresses, S-VLAN) IB-BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It contains an I-component for bridging in the customer space (customer MAC addresses, service VLAN IDs) and a B-component for bridging the provider's backbone space (B-MAC, B- TAG). I-BEB: A backbone edge bridged positioned at the edge of a provider backbone bridged network. It contains an I-component for bridging in the customer space (customer MAC addresses, service VLAN IDs). I-SID: The 24-bit service instance field carried inside the I-TAG. The I-SID defines the service instance that the frame should be "mapped to". Sajassi, et al. [Page 4] draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 2008 I-TAG: A field defined in the 802.1ah provider MAC encapsulation header that conveys the service instance information (I-SID) associated with the frame. PBB: Provider Backbone Bridge PBBN: Provider Backbone Bridged Network S-TAG: A field defined in the 802.1ad QinQ encapsulation header that conveys the service VLAN identifier information (S-VLAN). S-VLAN: The specific service VLAN identifier carried inside an S-TAG 3. Multicast Pruning in Native PBBN In order to get a better feel for multicast pruning operation in H- VPLS with PBB components, it is helpful to first understand how multicast pruning works in a native PBBN. When a customer frame is encapsulated in a PBB frame represented by a service instance ID (I-SID), then all the broadcast, multicast, and unknown unicast frames for that customer can be mapped onto a default multicast "Backbone Service Instance Group Address" as defined in [P802.1ah] section 26.4. This default B-MAC multicast address is formed simply by OUI + I-SID (e.g., there is 1:1 mapping between I-SID and its corresponding default multicast address). If the service provider doesn't want to use the default multicast address per I-SID and instead assigns a single multicast B-MAC address for a group of I-SIDs, then that can also be administered accordingly. As mentioned previously, the encapsulation of customer frames into PBB frames is performed only at the edge of the network by backbone edge bridges (BEBs) and the core bridges are transparent to customer MAC addresses. In other words, core bridges only operate on provider B-MACs and backbone VLANs (B-VLANs). Therefore, multicast pruning in a PBBN is provided by backbone bridges (both edge and core bridges) operating on multicast B-MAC addresses within a B-VLAN and limiting the replication of the frames to only those interfaces that are of interest for that multicast group address (e.g., registered for that multicast B-MAC address). If multicast pruning is not enabled in a PBBN, then multicast B-MAC traffic is flooded to the entire B-VLAN. An analogy can be drawn for multicast pruning between native PBBN and H-VPLS with PBB components. If a VPLS instance is set up for a B-VLAN, then the multicast pruning for a given B-MAC multicast address in this scenario corresponds to pruning the VPLS instance to only those PE devices that are interested in that multicast address Sajassi, et al. [Page 5] draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 2008 - e.g., limiting multicast ingress replication to a subset of PWs in that VPLS instance. In a native PBBN, Multi-protocol Multicast Registration Protocol [802.1ak] is used for distribution of multicast B-MAC addresses among backbone bridges; whereas, in case of H-VPLS with PBB component, BGP can be used for distribution of these addresses among PE devices. A PE device can then formulate its OIF list for a given B-MAC multicast address based on these BGP messages. 4. Multicast Pruning in H-VPLS with PBB Components As described in [VPLS-PBB], there are two main types of H-VPLS with PBB components - one with an Ethernet access network (PBBN) and the other with an MPLS access network (and PBB-capable u-PEs). In both case, customer MAC frames are encapsulated using PBB frames and each backbone bridge domain (B-VLAN) can be mapped onto a single VPLS instance. A provider VPLS network can consist of one or more backbone bridge domains and each bridge domain can support many multicast groups (limited by the size of memory in the bridge). Since each B-MAC multicast group can represent one or more customers and since each bridge domain is mapped to a single VPLS instance, a single VPLS instance can represent a very large number of customers and the scope of broadcast domain for each customer is represented by a B-MAC multicast address. For each B-MAC multicast address, a PE device (n-PE) needs to know over what subset of Pseudowires for that VPLS instance, to perform ingress replication. The PE device discovers what other PE devices are interested in a given B-MAC multicast address via BGP auto- discovery and then adds the Pseudowires associated with those PE devices to the OIF list for that B-MAC multicast address - e.g., the ingress replication for that B-MAC address is limited to a subset of Pseudowire for that VPLS instance. As a customer (I-SID) is provisioned on a PE device, its associated B-MAC multicast address is administered accordingly (either automatically via default backbone I-SID group address or manually via provisioned multicast group address). When a PE device is administered by a B-MAC multicast address, it will advertise this multicast address as a PBB-VPLS route in BGP. The route carries a single L2VPN NLRI with the RD set to the RD of the VSI, the VE-ID set to the VE-ID of the VSI (e.g., IPv4 address), and the B-MAC multicast address. When a PE is administered for a B-MAC multicast address and it receives a BGP PBB-VPLS route with this multicast address, it will add the Pseudowire corresponding to that PE to its OIF list for that B-MAC multicast address. Sajassi, et al. [Page 6] draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 2008 5. BGP Extensions This section describes the encoding of BGP extensions. 5.1. PBB-VPLS NLRI A new BGP NRLI, called PBB-VPLS NLRI, is defined in this document as follow: +--------------------------------+ | RD (8 octets) | +--------------------------------+ | VE-ID of VSI (4 octets) | +--------------------------------+ | B-MAC address (6 octets) | +--------------------------------+ Figure 1: PBB-VPLS NLRI Format RD: Route Distinguisher encoded as described in [RFC4364] VE-ID: The VE-ID of the VSI on this PE as specified in [L2VPN-SIG]. B-MAC: The backbone multicast address in which this PE is interested. The PBB-VPLS NLRI is carried in BGP using BGP Multiprotocol Extensions [RFC4760] with an AFI of 25 (L2VPN AFI), and an SAFI of PBB-VPLS (pending IANA assignment). The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the PBB-VPLS NLRI encoded as specified in the above. In order for two BGP speakers to exchange PBB-VPLS NLRI, they must use BGP Capabilities Advertisement to ensure that they both are capable of properly processing such NLRI. This is done as specified in [RFC4760], by using capability code 1 (multiprotocol BGP) with an AFI of 25 and an SAFI of PBB-VPLS. 5.2. BGP Attribute This document uses a new BGP attribute, called PMSI Tunnel Attribute, as defined in [MVPN-BGP-ENCODE] and [L2VPN-MCAST]. This is an optional transitive BGP attribute. The format of this attribute is defined in [MVPN-BGP-ENCODE] and [L2VPN-MCAST]. Sajassi, et al. [Page 7] draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 2008 The purpose of this attribute is, to indicate what type of tunnel to be used with PBB-VPLS A-D routes. The applicable type for this draft is "ingress replication". 6. Security Considerations There are no additional security aspects beyond those of VPLS/H-VPLS that need to be discussed here. 7. IANA Considerations None. 8. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. 9. Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 10. IPR Notice 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. Copies of IPR disclosures made to the IETF Secretariat and any Sajassi, et al. [Page 8] draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 2008 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. 11. Normative References [P802.1ah] IEEE P802.1ah/D4.2, "Draft Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges", IEEE 802.1 Interworking Task Group, March, 2008. [RFC4762] "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC4762, January 2007 [802.1ad] IEEE Std. 802.1ad-2005, "IEEE Standard for Local and metropolitan area networks - virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", IEEE Computer Society, May, 2006. [802.1ak] IEEE Std. 802.1ak-2007, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks - Amendment 7: Multiple Registration Protocol", IEEE Computer Society, June, 2007. 12. Informative References [VPLS-PBB] Sajassi et al., "VPLS Interoperability with Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-interop-02.txt, work in progress, November, 2007. 13. Authors' Addresses Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: sajassi@cisco.com Sajassi, et al. [Page 9] draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 2008 Luyuan Fang Cisco 300 Beaver Brook Road Boxborough, MA 01719, US Email: lufang@cisco.com Pradosh Mohapatra Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: pmohapat@cisco.com Nabil Bitar Verizon Communications Email : nabil.n.bitar@verizon.com Raymond Zhang British Telecom 2160 E. Grand Avenue El Segundo, CA 90245 Email: raymond.zhang@bt.com Sajassi, et al. [Page 10]