Internet Working Group David Allan Internet Draft Nigel Bragg Date Created: July 7, 2008 Dinesh Mohan Expiration Date: January 7, 2009 Nortel Intended Status: Standards Track Simplified VPLS-PBB interworking via MMRP draft-allan-mmrp-for-mac-in-mac-00 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. This Internet-Draft will expire in January 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Allan et al. [Page 1] Internet Draft draft-allan-mmrp-for-mac-in-mac February 2008 Abstract This document describes how MAC filtering programmed by the IEEE multiple MAC registration protocol (MMRP or 802.1ak) can be employed by VPLS-PE devices as the exclusive mechanism for interworking with 802.1ah PBBNs. No new protocol standardization is required to do this, however there are small procedural changes associated with the interworking of protocols. Conventions used in this document 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 [RFC2119]. 1. Terminology In addition to well understood VPLS terms, this memo uses terminology from IEEE 802.1 and introduces a few new terms: 802.1ah Provider Backbone Bridges (Mac-in-Mac encapsulation) 802.1ak Multiple Registration Protocol 802.1aq Shortest Path Bridging (SPB) B-DA Backbone Destination Address 802.1ah Mac-in-Mac header B-MAC Backbone MAC Address B-SA Backbone Source address in 802.1ah Mac-in-Mac header B-VID Backbone VLAN ID in 802.1ah Mac-in-Mac header B-VLAN Backbone Virtual LAN BCB Backbone Core Bridge BEB Backbone Edge Bridge C-MAC Customer MAC. Inner MAC in 802.1ah Mac-in-Mac header CPB Customer Backbone Port C-VID Customer VLAN ID C-VLAN Customer Virtual LAN DA Destination Address FDB (MAC) Filtering Database in an 802.1Q bridge FIB Forwarding information base (B-DA/B-VID to next hop(s)) ISID 802.1ah: I component service instance identifier IVL Independent VLAN learning MAC Media Access Control Mac-in-Mac Basically Ethernet in Ethernet as specified in 802.1ah MMRP Multiple MAC Registration Protocol MSTI Multiple spanning tree instance PBB Provider Backbone Bridge PBBN Provider Backbone Bridged Network SA Source Address VID VLAN ID Allan et al. [Page 2] Internet Draft draft-allan-mmrp-for-mac-in-mac February 2008 2. Introduction The interworking of 802.1ah PBB with VPLS is considered desirable for a number of reasons, primarily that of significantly reducing the number of MAC addresses VPLS-PEs need to support. The challenge with such interworking is achieving efficient multicast while bounding the amount of state required at the interworking function. A PBBN can in theory support up to 2**24 communities of interest, therefore there is significant impetus for bounding the impact of overlaying a PBBN on VPLS. MMRP driven filtering of multicast MAC replication in VPLS-PEs shifts the peering of VPLS and PBB to the B-component level from the I- component level. This substantially enhances the scalability, of the overall solution, and operationally decouples PBB and VPLS. VPLS support of the PBBN can simply be pre-provisioned. 3. MMRP Overview It is specifically the programming of MAC filtering with MMRP that is of interest for this memo, so this description will concentrate on that aspect of 802.1ak. MMRP provides a mechanism to allow end stations and MAC bridges to dynamically register and deregister attributes, where these attributes are either multicast MAC addresses or group service requirements. In a practical sense this manifests itself as transaction exchanges to program MAC filtering, where the chain of MMRP PDU transaction exchanges follows the spanning tree active topology. A topology change requires re-registration of the attributes. Filtering is programmed by registration exchange in a fairly straightforward way. Registration is of the form of full participant (both transit and receive interest) or application participant (receive interest only). A bridge receiving registrations for a common MAC address of interest on multiple ports can resolve registrations with respect to transmission and reception requirements for the multicast group address and set up the appropriate filtering. 4. Discussion We will only consider the basic case of PBB-VPLS interworking, which is that one or more VPLS TLS instances appear as topological components in the PBBN. Whatever combinations and permutations of the locations of I-Component and S-component functionality around the edges are secondary implementation considerations and well understood. Allan et al. [Page 3] Internet Draft draft-allan-mmrp-for-mac-in-mac February 2008 The simplest instantiation is that a single VPLS TLS service instance per PBBN MSTP instance (manifested as one or more B-components) is employed, tagged UNI being the service mapping mechanism used by VPLS-PEs. By itself it will be non optimal as the set of VPLS-PEs participating in the single TLS instance will be a superset of that of the community of interest for any individual I-SID. Therefore the handling of per I-SID multicast, broadcast and flooding of unknowns by VPLS will involve significant discard as the set of receivers is the superset of that required. It would be possible to dynamically manipulate the set of VPLS-PEs associated with B-tag specific TLS instances to try to reduce this inefficiency, but this requires continual remapping of the B-VID/VPLS community of interest driven by adds/moves and changes to the component I-SID communities of interest. Further, this overloads the B-tag, because the motivation for specifying tagged UNI was not for multicast optimization, but to allow the use of MSTP or 802.1aq SPB which requires IVL behavior at the VPLS-PEs. Proposals have suggested I-component awareness in VPLS-PEs to address multicast inefficiency, however this significantly complicates the VPLS interworking function and has implications on the amount of state VPLS requires simply to function as an NNI for the PBBN. Without the MMRP driven multicast MAC filtering at VPLS-PEs, the VPLS core must be configured with per service state undermining much of the potential scalability benefit of combining 802.1ah with VPLS. MMRP driven multicast MAC filtering must be used at VPLS-PEs to get a truly scalable solution from PBB and VPLS/H-VPLS combined. 5. Use of MMRP The use of MMRP and MAC filtering at the VPLS-PEs provides a simpler way to achieve the equivalent level of I-component awareness which is aligned with the normal operation of a PBBN, and which avoids complex frame inspection and possibly per-I-SID PW meshes. The successful operation of 802.1ah over a PBBN only requires B- component unicast and multicast connectivity, with I-component functionality being confined to BEBs at the edge of the PBBN. Overlaying of PBB on VPLS does not change this. 802.1ah maps all per I-component C-MAC layer broadcast, multicast and flooding to well known B-MAC multicast addresses. The construction of the multicast MAC address is the concatenation of a well known OUI with the I-component I-SID value. This suggests that simply filtering on the B-component MAC can replace I-component awareness in a VPLS network. If the VPLS-PE is capable of MAC filtering at the ingress to each PW in the TLS instance AND that filtering can be programmed by MMRP exchange then a different mode of operation to support PBBNs emerges. Allan et al. [Page 4] Internet Draft draft-allan-mmrp-for-mac-in-mac February 2008 When a port interconnecting a VPLS-PE to a PBBN is turned up, it can be pre-provisioned as a member in a TLS instance for each PBBN B- component and therefore be PW mesh connected with the other PEs connected to the PBBN. This could be via simple association of the B- VID with a well known AGI. When the VPLS-PE receives an MMRP frame from the peer BCB it uses the frame information as an input to the local MMRP filtering state machine, and replicates that frame onto the set of PWs for the PBBN B-component TLS instance. When the VPLS-PE receives an MMRP frame over a PW, it again uses the frame information as an input to the local MMRP filtering state machine and relays that frame over the port to the peer BEB/BCBs. What will emerge is pruned per I-component multicast over a single pre-provisioned TLS instance. This obviates the need for service end point auto-discovery or other E-LDP/BGP interactions. PW set up is a pre-provisioning exercise only and is decoupled from PBBN service changes. 6. Resiliency It is expected that when performing PBBN/VPLS interworking it will be found desirable to isolate the PBBN (M)STP instances (MSTIs) into distinct domains subtending the VPLS core, as opposed to running one or more large (M)STP domains by tunneling of BPDUs through VPLS. Further it is expected there will only be a small number of PBBN MSTP instances attached to any individual gateway device. This argues in favor of providing a VPLS TLS termination per gateway device per subtending MSTP/RSTP instance. This may require unique IP addressing of each TLS VSI in the case where a PE hosts attachment to multiple non overlapping MSTP domains within a single PBBN. MMRP and MAC learning require coordination with STP state. However given the small number of STP domains considered, the simplest mechanism for coordination would be the proposed "active/standby" bits used in independent mode as described in [BIT]. A PBBN/VPLS interworking node can use "active/standby" semaphoring to advise its set of remote peer VPLS_PEs to flush their MAC tables, reset MMRP filtering and re-initiate MMRP PDU generation across the PWs as if there had been an active topology change. If this semaphoring results in a change of status of a PBBN facing port, then Topology Change Notification BPDUs should be injected into the PBBN from affected VPLS ports, as described below. This is an alternative to the use of "MAC withdraw" transactions and the possible requirement for VPLS-PE to proxy large numbers of MMRP "leave" transactions. Allan et al. [Page 5] Internet Draft draft-allan-mmrp-for-mac-in-mac February 2008 For fully resilient interworking across the PBBN - VPLS boundary (i.e. "4 box handoff"), the "active/standby" PW state in VPLS must be synchronized with the STP state in the PBBN. A standard mechanism to achieve this would be to run MSTP locally on all of the VPLS-PE ports connected to a specific PBBN. The VPLS domain can be modeled as a single virtual bridge, with a very high Bridge ID such that it will never become the root bridge whilst any PBBN bridge is connected, to avoid transit of on-PBBN traffic through VPLS. This further makes all PBBN-facing VPLS ports "root ports" in STP parlance, and the VPLS-facing PBBN ports "designated ports", thus putting VPLS in control of which link is used. When VPLS changes "active/standby" PW state, and hence its "root port" states, it should inject Topology Change Notification BPDUs into the PBBN, to force the rapid aging of PBBN B-MACs. It may also be possible to filter the number of MMRP registration messages that are flooded into an individual PBB MSTI by VPLS by only issuing MMRP registrations for multicast MAC addresses for which a registration was been received from the PBB MSTI by the VPLS-PE. 7. 802.1aq considerations 802.1aq is shortest path bridging. Unlike 802.1ah, current proposals for 802.1aq in a PBB context use multicast MAC addresses that identify (S,G) vs. (*,G). This scenario is already addressed by MMRP as it is possible to advertise interest in receiving MAC addressed multicast flows with no intention of originating them. Hence an egress BCB for a tree can register receive only interest, while an ingress can advertise send/receive. This has the effect of bounding the amount of filtering state that needs to be installed. This memo will expand upon 802.1aq as more details emerge from IEEE 802. 8. OAM Considerations The operation of a PBBN over VPLS does not introduce any new OAM considerations, other than those addressed in [VPLS-OAM]. The VPLS PE would need to support MIPs on a per B-VID basis which equate to per VPLS VSI MIPs. However, inline with the earlier stated objectives, this does not require per service state on the VPLS PE and therefore, the per I-SID OAM flows will have no visibility on VPLS PE nodes and will be handled in the same manner as regular data frames. A single PW mesh per PBBN B-component will dramatically reduce the telemetry generated by VPLS when compared to a per-I-component PW mesh. As the PW offers only a portion of overall BEB to BEB connectivity the reduction in telemetry would not be expected to have any operational impacts. 9. Security Considerations Allan et al. [Page 6] Internet Draft draft-allan-mmrp-for-mac-in-mac February 2008 The operation of a PBBN over VPLS does not introduce any new security concerns to VPLS or H-VPLS beyond that documented in [RFC4762] and may address concerns documented in said RFC. 10. IANA Considerations / ISO Considerations There are no implications for IANA specified or implied by this document. 11. References 11.1 Normative References None 11.2 Informative References [BIT] "Preferential Forwarding Status bit definition", IETF Internet Draft, draft-ietf-pwe3-redundancy-bit-00.txt, February 2008 [MACMAC] "IEEE draft Standard for Local and Metropolitan Networks, Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges", IEEE 802.1ah D4.1, February 2008 [MMRP] "IEEE draft Standard for Local and Metropolitan Networks, Virtual Bridged Local Area Networks, Amendment 7: Multiple Registration Protocol", IEEE 802.1ak D8.0 [RFC4762] "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", IETF RFC 4762, January 2007 [SPB] "IEEE draft Standard for Local and Metropolitan Networks, Virtual Bridged Local Area Networks, Amendment 9: Shortest Path Bridging", IEEE 802.1aq D0.4, February 2008 [VPLS-OAM] "VPLS OAM", IETF Internet Draft, draft-mohan-l2vpn-vpls- oam-00.txt, November 2007 12. Acknowledgments 13. Author's Addresses David Allan Nortel Networks Allan et al. [Page 7] Internet Draft draft-allan-mmrp-for-mac-in-mac February 2008 3500 Carling Ave. Ottawa, Ontario, CANADA Phone: 1-613-763-6362 dallan@nortel.com Nigel Bragg Nortel Networks UK Limited London Road, Harlow, Essex, CM17 9NA, UK Phone +44 (0) 1279 40 2052 nbragg@nortel.com Dinesh Mohan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA Phone: 1-613-763-4794 mohand@nortel.com 14. 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 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 Allan et al. [Page 8] Internet Draft draft-allan-mmrp-for-mac-in-mac February 2008 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. 15. Disclaimer of Validity "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. 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. Allan et al. [Page 9]