L2VPN Working Group F. Balus Internet Draft M. Bocci Intended Status: Proposed Standard M. Aissaoui Expires: August 2008 Alcatel-Lucent John Hoffmans KPN Geraldine Calvignac France Telecom Raymond Zhang British Telecom Nabil Bitar Verizon Olen Stokes Extreme Networks February 24, 2008 VPLS Extensions for Provider Backbone Bridging draft-balus-l2vpn-vpls-802.1ah-02.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 August 24, 2008. Balus, et. al Expires August 24, 2008 [Page 1] Internet-Draft VPLS Extensions for PBB February 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 multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the 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. Balus, et al. Expires August 24, 2008 [Page 2] Internet-Draft VPLS Extensions for PBB February 2008 Table of Contents 1. Introduction...................................................3 2. Terminology....................................................4 3. Reference Model................................................6 3.1. General Description.......................................6 3.2. I-VSI to B-VSI Mapping....................................9 3.3. Interworking with regular VPLS Instances.................11 4. Data Plane....................................................13 5. Auto-Discovery................................................16 6. Signaling.....................................................16 6.1. MAC Address Withdraw.....................................16 7. Multicast Handling............................................18 8. Resiliency....................................................18 9. OAM...........................................................19 10. Security Considerations......................................19 11. IANA Considerations..........................................19 12. Acknowledgments..............................................19 13. References...................................................20 13.1. Normative References....................................20 13.2. Informative References..................................20 Author's Addresses...............................................21 Full Copyright Statement.........................................22 Intellectual Property Statement..................................22 Acknowledgment...................................................23 1. Introduction The IEEE 802.1ah model for PBB is organized around a B-component handling the provider backbone MAC layer and an I-component concerned with the mapping of Customer/Provider Bridge (QinQ) domain (e.g. MACs, VLANs) to the provider backbone (e.g. BMACs, B-VLANs): i.e. the I-component contains the boundary between the Customer and Backbone MAC domains. PBB encapsulates customer frames in a provider backbone Ethernet header, providing for Customer MAC hiding capabilities. PBB requires the use of Multiple Spanning Tree Protocol (MSTP) as the core control plane (B-domain) for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. Virtual Private LAN Service (VPLS) provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without requiring the use of (M)STP across the Balus, et al. Expires August 24, 2008 [Page 3] Internet-Draft VPLS Extensions for PBB February 2008 backbone. VPLS use of the structured FEC 129 [RFC4762] also allows for inter-domain, inter-provider connectivity and enables auto- discovery options across the network improving the service delivery options. 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 Pseudo Wires (PWs) 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 (H-VPLS) 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. This document proposes extensions to the VPLS model to allow for selective inclusion of useful PBB capabilities while continuing to avoid the use of MSTP in the backbone. The proposed solution accommodates though the use of native Ethernet model, MSTP-based for the PBBN [IEEE802.1ah] should a provider choose to deploy it. Description of the framework and requirements for interoperability between the IEEE and VPLS components is given in [PBB-VPLS-Interop]. Specific service provider requirements often define the boundaries of PBB and VPLS domains within their networks. It is not in the scope of this document to specify how far in the Metro Area Network (MAN) or the Wide Area Network (WAN) PBB and VPLS boundaries extend. The PBB VPLS may co-exist in the same PE with non PBB services (i.e., regular VPWS or VPLS using MPLS PW where PBB Customer MAC hiding and aggregation functions are not required). Section 2 defines the terms used to describe the extensions to the regular VPLS Model. Section 3 covers the reference model for PBB VPLS and gives examples of its usage to address the use cases described in [PBB-VPLS-Interop]. Section 4 describes the data plane while section 5 and 6 deal with the auto-discovery and signaling components, including the required MAC Withdraw extension. 2. Terminology [IEEE802.1ah] provides terminology for Provider Backbone Bridging that is briefly described also in [PBB-VPLS-Interop]. This document employs specifically the following abbreviations from [IEEE802.1ah]: Balus, et al. Expires August 24, 2008 [Page 4] Internet-Draft VPLS Extensions for PBB February 2008 CBP: Customer Backbone Port, the B-component port connecting to the I-component. PIP: Provider Instance Port, the I-component port connecting to the B-component. This document defines the following additional terms: B-x: a VPLS component of the switching domain handling Backbone MACs - e.g. B-FEC, B-PW B-VPLS: a collection of VPLS components that operate in the Backbone MAC domain, carrying one or multiple I-VPLS instances B-VSI: A VPLS Service Instance (VSI) that participates in a B-VPLS I-x: a VPLS component of the switching domain handling customer MACs - e.g. I-FEC, I-PW I-VPLS: a collection of VPLS components that participate in the customer MAC layer - i.e. it uses the customer MAC addresses (basically the destination address) to switch Ethernet frames I-VSI: A VPLS Service Instance (VSI) that participates in an I-VPLS PBB VPLS: an extended VPLS Service that includes PBB components IB-PE: a PE that contains both I and B components I-PE: a PE that contains just I component(s) B-PE: a PE that contains just B component(s) and Customer Backbone Ports (I-tagged CBPs - see [IEEE802.1ah]) BC-PE: Backbone Core PE, a PE that contains only B component(s) and Provider Network Port(s) (PNPs - see [IEEE802.1ah]) Balus, et al. Expires August 24, 2008 [Page 5] Internet-Draft VPLS Extensions for PBB February 2008 3. Reference Model VPLS is defined in [RFC4762] as a collection of Virtual Switch Instance(s) (VSIs) interconnected via Pseudo-Wires (PW). The VPLS model described in [RFC4762] is able to accommodate different types of PWs and Ethernet Attachment Circuits (AC) through the use of VPLS Forwarders and bridge module, respectively. PBB Service is defined in [IEEE802.1ah] as a collection of two components: an I-component and a B-component operating on the Customer and the Backbone MAC layer, respectively. 3.1. General Description A PBB VPLS solution may be modeled as an "I-VSI" mapped to a "B-VSI" operating on the Customer and the Backbone MAC layer, respectively, as depicted in Figure 1. The I-VSI and its related B-VSI should be considered as separate modules interconnected through an internal or external link. Each x- VSI will be identified by the same type of components as the regular VPLS VSI: . I-FEC for the I-VSI and B-FEC for the B-VSI in the control plane. The relationship between I-FECs and B-FECs is discussed in the control plane section. . A PW Service Label for B-PW and/or I-PWs. . A B-VID [IEEE802.1ah] for a B-ETH port (Provide Network Port or PNP in [IEEE802.1ah]). . A S-VID and/or a C-VID number and/or the port number for I-ETH generating different type of interfaces - i.e. QinQ, 802.1Q, port mode, same as for regular VPLS. Each VSI is identified in the control plane by a L2 FEC as per [RFC4762]. In the data plane, a PW Service Label or a native Ethernet identifier (e.g. a VLAN ID and/or a port number) play the role of demultiplexor, service delimiter, depending on the type of "interface" that is present. This representation of the PBB VPLS components is an abstract model used in this document to help the solution description. It is up to Balus, et al. Expires August 24, 2008 [Page 6] Internet-Draft VPLS Extensions for PBB February 2008 the implementations to optimize the functions described in this document as long as they provide for solution interoperability. ,,.--.,, ,-` `', - ' ' \ | MPLS | | (B-VPLS) | , / . / /., _./ | | /`''--''` | | | | | | +-\-\--+ +--\-\-+ | B-PW | | B-PW | +-----| |----| |-----+ | +------+ +---.--+ | | `. ,.., ` | | ' `-` | ,.-., | ,.B-VSI | | ,' `+-------+ ,-` . / | / | | .'` `/.` | | PBBN | B-ETH | ` | IB-PE | \ | | ,- | `. ,+-------+ / ` | `'-'` | ' `. | | ,' I-VSI . | | --.--.-----' | | .` | `. | | +-----`+ +--\---+ +-'----+ | | | | | | | | | +--| I-PW |-| I-ETH|-| I-Q |--+ | | | | | | +--/---+ +--_---+ +------+ ` / \ `. ` ,.-/, / \ ,.'/, ,' `. - ' ,' `. / , CE CE / , | I-VPLS | Q-in-Q \ ` \ ` `. ,' `. ,' `'-'` `'-'` Figure 1: "PBB VPLS" reference model, IB-PE Example PBB Customer MAC hiding and aggregation functions are provided by encapsulating the Customer MAC frame into a Provider Ethernet Header and by mapping the Customer MACs to Backbone MACs. An I-component Balus, et al. Expires August 24, 2008 [Page 7] Internet-Draft VPLS Extensions for PBB February 2008 Service ID (ISID) is used in the data plane to provide additional de- multiplexing capabilities. The PBB VPLS Model maintains the flexibility of associating both PWs or native Ethernet ACs with I-VSI and B-VSI. In Figure 1 the associated objects are referred to as I-PW/I-ETH and B-PW/B-ETH, respectively. I-Q represents a QinQ interface [IEEE802.1ad], in fact an instantiation of an I-ETH AC used to connect to a QinQ access network. The I-VPLS and B-VPLS clouds may contain either a VPLS mesh or HVPLS topology as described in [RFC4762]. Two different use cases may be considered based on the location of the I-VSI and its related B-VSI. Case 1: Co-located I-VSI and B-VSI Figure 1 describes the case of a PE that contains both I and B-VSIs. IB-PE terminology is used as the PE performs a similar function with a PBB IB-BEB - see [IEEE802.1ah]. The link between I-VSI and its related B-VSI is internal to the PBB PE. Case 2: Non co-located I-VSI and B-VSI The I-VSI and its associated B-VSI may be also located in different PE devices referred to as I-PE and B-PE, respectively, as depicted in Figure 2. ,,.--.,, ,-` `', - ' ' \ | MPLS | | (B-VPLS) | , / . / /., _./ | | /`''--''` | | | | | | +-\-\--+ +--\-\-+ | B-PW | | B-PW | +-----|(PNP) |----|(PNP) |-----+ | +------+ +---.--+ | | `. ,.., ` | | ' `-` | | ,.B-VSI | | ,'`'-'``+-------+ ,-` . / | / | | .'` `/.` | | PBBN | B-ETH | ` | B-PE | Balus, et al. Expires August 24, 2008 [Page 8] Internet-Draft VPLS Extensions for PBB February 2008 \ | | | | `. ,+-------+ | | `'-'` | | | +------------------------------+ |CBP | | |PIP +------------------------------+ | | | | | | | ,- | | / ` | | ' `. I-PE | | ,' I-VSI . | | --.--.-----' | | .` | `. | | +-----`+ +--\---+ +-'----+ | | | | | | | | | +--| I-PW |-| I-ETH|-| I-Q |--+ | | | | | | +--/---+ +--_---+ +------+ ` / \ `. ` ,.-/, / \ ,.'/, ,' `. - ' ,' `. / , CE CE / , | I-VPLS | Q-in-Q \ ` \ ` `. ,' `. ,' `'-'` `'-'` Figure 2: "PBB VPLS" reference model, I-PE, B-PE Example In this case, the connection between I-PE and B-PE will be an external link, where the PBB Service ID (ISID) is used to determine which particular I-VSI FIB should be used to determine the destination for a frame ingressing the PIP port on the I-PE. 3.2. I-VSI to B-VSI Mapping The I-VSI(s) may be mapped to the B-VSIs using an 1:1 model or many- to-1 (M:1) model. . The 1:1 model, see Figure 1 and 2, may be chosen by a service provider who is content with the level of service multiplexing provided by the B-PWs. Balus, et al. Expires August 24, 2008 [Page 9] Internet-Draft VPLS Extensions for PBB February 2008 . The M:1 model may be used in order to provide an additional layer of aggregation where multiple customer services are transported through a backbone VPLS. Figure 3 shows the M:1 mapping and uses the reference model introduced in this section to address the scenario described in section 4.1 of [PBB-VPLS-Interop]. _,,..--..,,, ,-'` `'-, .` `' ,' `. / IP MPLS Core , | (VPLS Mesh) | \ ` `. ` ', _-` +------`-,, _,-`-------+ | ,-, | ``'''--'''`` | ,-, | N-PE3 | | B | | | | B | | N-PE4 | | | | BC-PEs | | | | | `'' | | `'' | +-,--,,-+ +--,--,,+ ,' \ ,' \ / \ / \ | MPLS | | MPLS | | Access | | Access | | B-PWs | | B-PWs | \ / \ / `. / `. / +------`-,,+-------+ +-------+'-'+-------+ | ,-, | | ,-, | | ,-, | | ,-, | | | B | | | | B | | | | B | | | | B | | | | | | | | | |IB-PEs | | | | | | | | | `'' | | `'' | | `'' | | `'' | | I1 I2 | | I1 I3 | | I1 I2 | | I1 I3 | +-------+ +-------+ +-------+ +-------+ U-PE1 U-PE2 U-PE6 U-PE5 Figure 3 PBB VPLS model for HVPLS with MPLS Access The PBB VPLS is enabled in the U-PEs to hide the customer MACs from the N-PEs. The U-PEs are IB-PEs where multiple I-VSIs are mapped to one B-VSI. The N-PEs may be seen as playing the role of Backbone Core Bridges (BCB - see [IEEE802.1ah]) hence the name of Backbone Core PE (BC-PE). The B-VSI components on the U-PEs are connected to the B- VSIs/Regular VSIs on the N-PEs using B-PWs. Balus, et al. Expires August 24, 2008 [Page 10] Internet-Draft VPLS Extensions for PBB February 2008 In the (M:1) model, there are use cases where the I-VPLS domains that share the same B-VPLS overlap but in most practical scenarios that is not the case. A broadcast and flood containment solution may be provided using [IEEE802.1ak]. The reference model described in this section can be used to address the other scenarios described in [PBB-VPLS-Interop], where an IB-PE structure may be used wherever an IB-BEB function is required, an I- PE for I-BEB and a B-PE for a B-BEB. 3.3. Interworking with regular VPLS Instances The PBB VPLS model described in this section may interoperate with regular VPLS PEs on the I-VSI and/or B-VSI side(s) as long as no PBB functions or optimizations are required on these PEs. Balus, et al. Expires August 24, 2008 [Page 11] Internet-Draft VPLS Extensions for PBB February 2008 _,,..--..,,, ,-'` `'-, .` `' ,' `. / IP MPLS Core , | (VPLS Mesh) | \ ` `. ` ', _-` +------`-,, _,-`-------+ | ,-, | ``'''--'''`` | ,-, | N-PE3 | | V | | | | B | | N-PE4 | | | | BC-PEs | | | | | `'' | | `'' | +-,--,,-+ +--,--,,+ ,' \ ,' \ / \ / \ | MPLS | | MPLS | | Access | | Access | | B-PWs | | B-PWs | \ / \ / `. / `. / +------`-,,+-------+ +-------+'-'- | ,-, | | ,-, | | ,-, | | | B | | | | B | | | | B | | | | | | | | | |IB-PEs | | | | | `'' | | `'' | | `'' | | I1 I2 | | I1 I3 | | I1 I2-|-------| +-------+ +-------+ +-------+ | U-PE1 U-PE2 U-PE5 PE6| +---|---+ | ,-, | | | V'| | | `'' | +-------+ Figure 4 Interworking to regular VPLS Some of the interworking scenarios are depicted in Figure 4 where: . N-PE3 is running a regular VPLS VSI marked with V which operates only on the Backbone MAC header, switching performed by the PBB BCBs. No PBB awareness (e.g. I-component functions) is required on this PE which connects to the B-VSIs in U-PE1, U-PE2 and N- PE4. In both cases a HVPLS spoke or a VPLS Mesh may be used. . PE6 is running a regular VPLS VSI marked with V' which operates only on the Customer MAC header. No PBB awareness (B-component Balus, et al. Expires August 24, 2008 [Page 12] Internet-Draft VPLS Extensions for PBB February 2008 functions, linkage) is required on PE5 which connects to the I- VSI on U-PE5 via an HVPLS spoke PW or a VPLS mesh. 4. Data Plane The data plane for each I-VSI and B-VSI follows the VPLS model described in [RFC4762]. This section will focus on the interaction between the I-VSI and B-VSI Modules. Figure 5 represents a collection of I-VSI and B-VSI components that may be located in the same or different PEs as described in section 3. In order to describe the packet walkthrough, the I-VSIs and B-VSIs should be seen as different switching modules (I and B), each with its own set of VPLS Forwarders, Bridge modules and ACs. | | | | +-\-\--+ +--\-\-+ | B-PW | | B-PW | +-----|(PNP) |----|(PNP) |-----+ | +------+ +---.--+ | | `. ,.., ` | | ' `-` | | ,.B-VSI | | +-------+ ,-` . / | | | .'` `/.` | --| B-ETH | ` | | | | | | +-------+ | | | | | +------------------------------+ |CBP | |PIP +------------------------------+ | | | | ,- | | / ` | | ' `. | | ,' I-VSI . | | --.--.-----' | | .` | `. | | +-----`+ +--\---+ +-'----+ | | | | | | | | | +--| I-PW |-| I-ETH|-| I-Q |--+ | | | | | | +------+ +------+ +------+ Figure 5 Packet Walkthrough for PBB VPLS Balus, et al. Expires August 24, 2008 [Page 13] Internet-Draft VPLS Extensions for PBB February 2008 In order to better understand the data plane walkthrough let us consider the example of a PBB packet arriving on a B-PW link. The MPLS Tunnel is used to carry the PBB encapsulated frame over the MPLS backbone while the B-PW Service Label is used to determine the B-VSI FIB, same as for regular VPLS. The destination BMAC address of the packet is then mapped against the B-VSI FIB to determine the Next Hop (NH) with the following possible results: -NH = B-ETH AC: PW encapsulation is removed but the PBB encapsulation is left untouched. The packet is sent out on the B-ETH AC. Regular AC processing rules apply - e.g. a B-VID may be added to the backbone header. -NH = another B-PW: ingress PW Encapsulation is removed and egress PW encapsulation is added. The packet is sent out on the B-PW (Split Horizon rules apply). -NH = CBP "port" towards the I-VSI: PW Encapsulation is removed and the packet is passed to the I-VSI module for processing. Translation of the PBB header (e.g. ISID) may be performed. -NH = unknown or the destination BMAC is a Group MAC address (Multicast or Broadcast): the packet is flooded to all the virtual ports that are part of the B-VSI. For the packets that arrive at the I-VSI module ingressing the PIP Link the ISID demultiplexor is used to determine the specific I-VSI FIB to which the packet belongs. The PBB header is then removed and the destination Customer MAC (CMAC) address is used to determine the Next Hop for the packet with the following possible results: -NH = I-ETH/I-Q (QinQ AC): the Customer Frame is sent out on the I- ETH. Regular AC processing rules apply - e.g. a C-VID and/or a S-VID may be added to the packet. -NH = I-PW: the frame containing just the Customer MAC and S-VID and/or C-VID tags is encapsulated in the PW header before being sent out on the I-PW. The S-VID and/or C-VID may or may not be included in the actual encapsulated packet as per regular PW processing rules. For a packet ingressing the I-VSI via an I-PW, the I-PW Service Label is used this time to determine the FIB to which the packet belongs. Next the destination CMAC address of the packet is then mapped against the I-VSI FIB to determine the Next Hop (NH) with the following possible results: Balus, et al. Expires August 24, 2008 [Page 14] Internet-Draft VPLS Extensions for PBB February 2008 -NH = I-ETH/I-Q: PW encapsulation is removed and the packet is sent out on the corresponding I-ETH AC. Regular AC processing rules apply - e.g. an S-VID and/or C-VID tag may be added to the packet. There is no need to add PBB encapsulation to the packet. -NH = another I-PW: ingress PW Encapsulation is removed and egress PW encapsulation is added. The packet is sent out on the I-PW (Split Horizon rules apply). -NH = PIP "port" towards the B-VSI: PW Encapsulation is removed, the PBB header (BMACs and the corresponding I-TAG) is added and the packet is passed to the B-VSI module for further processing. This is the case when the destination CMAC is located behind a remote PBB PE identified by a destination BMAC. -NH = unknown or the destination CMAC is a Group MAC (Multicast or Broadcast): the packet is flooded to all the virtual ports that are part of the I-VSI. For the packets that arrive at the B-VSI module ingressing the CBP Link the ISID is used to determine the specific B-VSI FIB to be used to which the packet belongs. Translation of the PBB header (e.g. ISID) may be performed. Next the destination BMAC is used to determine the Next Hop for the packet with the following possible results: -NH = B-ETH: the PBB Frame is sent out on the B-ETH. Regular AC processing rules apply - e.g. a B-VID is added to the packet. -NH = B-PW: the PBB frame is encapsulated in the PW header before being sent out on the B-PW. . NH = B-PW: the PBB frame is encapsulated in the PW header before being sent out on the B-PW. It is important to note in this context that the core PEs (N-PE3 and N-PE4 in Figure 3) do not have to be aware about the PBB encapsulation because just the regular Backbone Ethernet header may be used to forward the Ethernet frames. Existing VPLS and PWE3 procedures, including Multi-Segment PWs (MS-PW) apply for the PW infrastructure between them. Regular Ethernet PW types (Ethernet and Ethernet VLAN) may be also used to signal the B-PWs (Backbone PWs) interconnecting the B-VSIs in the U-PEs and the regular VSIs in the N-PEs or the I-VSIs with other I-VSIs or regular VSIs. Alternatively for the implementations that require a special indication of the PBB payload to perform ISID translation, a new PW Balus, et al. Expires August 24, 2008 [Page 15] Internet-Draft VPLS Extensions for PBB February 2008 type, defined in [802.1ah PW] may be used to interconnect B-VSIs to other B-VSIs or to regular VSI components - see [802.1ah PW]. To make this work the N-PEs located in the core of the network will need to understand and accept the new PW type. 5. Auto-Discovery Existing VPLS discovery procedures as per [L2VPN-Sig] may be used in the B-VPLS domain and/or inside each local I-VPLS domain. Each I-VPLS and B-VPLS domains must be assigned a separate set of identifier and attributes: i.e. VPLS-Id, VSI-Id (RD, Prefix), RT(s) as described in [L2VPN-Sig]). 6. 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]. A separate FEC addressing structure may be used to identify each B-VSI and/or I-VSI instances accordingly. The new PW Type, defined in [802.1ah PW] must be implemented in both IB-PEs, B-PEs or BC-PEs if required - see section 4. 6.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 or of a VPLS PE used as one in a pair of switches in a dual-homing use case). These existing procedures apply to B-VPLS and I-VPLS domains. When it comes to reflecting topology changes in access networks connected to I-VSI across the B-VPLS domain certain additions should be considered as described below. MAC Switching in PBB is based on the mapping of Customer MACs (CNACs) to Backbone MAC(s) (BMACs). A topology change in the access (I- domain) should just invoke the flushing of CMAC entries in PBB PEs' FIB(s) associated with the I-VPLS(s) impacted by the failure. Further optimizations may consider flushing just the CMAC addresses that are mapped to a specific destination BMAC address. These goals may be achieved by adding a PBB TLV in the Address Withdraw message to indicate the particular domain(s) requiring MAC flush. At the other end, the receiving PBB PEs may use the information from the PBB TLV to flush only the related FIB entry/entries in the I-VSI(s). Balus, et al. Expires August 24, 2008 [Page 16] Internet-Draft VPLS Extensions for PBB February 2008 A suggested PBB TLV structure is depicted 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|1| PBB TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The UF bits are set to forward unknown so that the intermediate VPLS PEs that are unaware of PBB can just forward the TLV towards the PBB aware IB-PEs. The PBB TLV type values are TBD. The Length field is used to define the length of the PBB 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: - PBB BMAC List sub-TLV: Type: 0x0001 Length: value length in octets. Zero indicates an empty BMAC list. Value: one or a list of 48 bits MAC address(es). These are the source BMAC addresses associated with the B-VSI(s) that originated the MAC Withdraw message. - PBB ISID List sub-TLV: Type: 0x0002 Length: value length in octets. Zero indicates an empty ISID list. Value: one or a list of 24 bits ISIDs that represent the I-VSIs where the MAC Flush needs to take place. Balus, et al. Expires August 24, 2008 [Page 17] Internet-Draft VPLS Extensions for PBB February 2008 The following steps describe the processing for the related LDP Address Withdraw message: . The LDP MAC Withdraw Message, including the PBB TLV is initiated by the PBB PE(s) experiencing a Topology Change event. . On reception of the LDP message, the B-VSI instances related to the FEC TLV from the LDP Address Withdraw message must interpret the presence of the PBB TLV as an indication of a PBB Flush message. As a result they should not flush their BMAC FIBs. . Next the B-VSI control plane must propagate the MAC Flush indication following the split-horizon grouping and the established B-PW topology. . The receiving IB-PE uses the PBB ISID List from the PBB TLV to determine the particular ISID FIBs that need to be flushed. If the ISID List is empty all the ISID FIBs associated with the receiving B-VSI are flushed. The PBB BMAC List from the PBB TLV is used to flush from the ISID FIBs just the entries that map CMACs to the BMACs that are not listed in the sub-TLV. If the BMAC list is empty then all the entries associated with a remote BMAC must be flushed. 7. Multicast Handling PBB MAC hiding may create difficulties for identifying customer Multicast exchanges in the B-VSIs. 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 IEEE 802.1ak MMRP protocol defined in [IEEE802.1ak] may be used to allow for efficient Multicast handling in the B-VPLS infrastructure: i.e. Group BMAC addresses may be assigned per Customer Multicast tree to ensure efficient Multicast distribution. 8. Resiliency [IEEE802.1ah] recommends the use of Provider MSTP (P-MSTP) to ensure loop free topology for connectionless forwarding throughout PBBN. Using B-VPLS infrastructure instead of native Ethernet core eliminates the need for backbone P-MSTP through the use of a full Balus, et al. Expires August 24, 2008 [Page 18] Internet-Draft VPLS Extensions for PBB February 2008 mesh of PWs with split-horizon and/or via the H-VPLS 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 should involve the MAC Withdraw scheme described in the signaling section to speed- up data plane convergence upon topology changes. 9. OAM Existing VPLS OAM tools may be used in each I-VPLS and B-VPLS domain. Details of the correlation between these two domains are out of scope of this draft. 10. Security Considerations This section will be added in a future version. 11. IANA Considerations This document proposes the use of a new LDP TLV, the PBB TLV and related sub-TLVs. Suggested values TBD. 12. Acknowledgments The authors gratefully acknowledge the contributions of Wim Henderickx, Dimitri Papadimitriou, Dutta Pranjal, Jorge Rabadan and Maarten Vissers. Balus, et al. Expires August 24, 2008 [Page 19] Internet-Draft VPLS Extensions for PBB February 2008 13. References 13.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/D4.0 "Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges", Work in Progress, April 19, 2007 [802.1ah PW] L. Martini and A. Sajassi "802.1ah Ethernet Pseudowire", draft-martini-pwe3-802.1ah-pw-01.txt, November 2007 ( work in progress ). 13.2. Informative References [PBB-VPLS-Interop] A. Sajassi, et Al. "VPLS Interoperability with Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb- interop-02.txt, November 2007 ( work in progress ). [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [L2VPN-Sig] E. Rosen, et Al. "Provisioning, Autodiscovery and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt, May 2006 ( work in progress ) [IEEE802.1ak] IEEE Draft P802.1ak/D8.0 "Virtual Bridged Local Area Networks, Amendment 7: Multiple Registration Protocol", Work in Progress, November 29, 2006 [IEEE802.1ad] IEEE 802.1ad-2005 "Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", December 7, 2005 Balus, et al. Expires August 24, 2008 [Page 20] Internet-Draft VPLS Extensions for PBB February 2008 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 Geraldine Calvignac France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: geraldine.calvignac@orange-ftgroup.com John Hoffmans KPN Regulusweg 1 2516 AC Den Haag Nederland Email: john.hoffmans@kpn.com Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 900245 USA EMail: raymond.zhang@bt.com Balus, et al. Expires August 24, 2008 [Page 21] Internet-Draft VPLS Extensions for PBB February 2008 Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 Email: nabil.bitar@verizon.com Olen Stokes Extreme Networks PO Box 14129 RTP, NC 27709 USA Email: ostokes@extremenetworks.com 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. 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. 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 Balus, et al. Expires August 24, 2008 [Page 22] Internet-Draft VPLS Extensions for PBB February 2008 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 August 24, 2008 [Page 23]