One document matched: draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 00:22:28 |