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]
