Internet DRAFT - draft-allan-mmrp-for-mac-in-mac

draft-allan-mmrp-for-mac-in-mac





   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]