RFC 7117
Multicast in Virtual Private LAN Service (VPLS)
9. BGP Extensions
This section describes the encoding of the BGP extensions required by this document.9.1. Inclusive Tree/Selective Tree Identifier
Inclusive P-multicast tree and Selective P-multicast tree advertisements carry the P-multicast tree identifier. For the purpose of carrying this identifier, this document reuses the BGP attribute, called "PMSI_TUNNEL" that is defined in [RFC6514]. This document supports only the following Tunnel Types when the PMSI Tunnel attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes: + 0 - No tunnel information present + 1 - RSVP-TE P2MP LSP + 2 - LDP P2MP LSP + 6 - Ingress Replication
9.2. MCAST-VPLS NLRI
This document defines a new BGP NLRI, called the "MCAST-VPLS NLRI". Following is the format of the MCAST-VPLS NLRI: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ The Route Type field defines encoding of the Route Type specific field of MCAST-VPLS NLRI. The Length field indicates the length in octets of the Route Type specific field of MCAST-VPLS NLRI. This document defines the following route types for A-D routes: + 3 - Selective Tree A-D route; + 4 - Leaf A-D route. The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol Extensions [RFC4760] with an Address Family Identifier (AFI) of 25 (L2VPN AFI), and a Subsequent Address Family Identifier (SAFI) of MCAST-VPLS. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the MCAST-VPLS NLRI (encoded as specified above). In order for two BGP speakers to exchange labeled MCAST-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 a SAFI of MCAST-VPLS. The following describes the format of the Route Type specific field of MCAST-VPLS NLRI for various route types defined in this document.
9.2.1. S-PMSI A-D Route
The Route Type specific field of MCAST-VPLS NLRI of an S-PMSI A-D route consists of the following: +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Multicast Source Length (1 octet) | +-----------------------------------+ | Multicast Source (Variable) | +-----------------------------------+ | Multicast Group Length (1 octet) | +-----------------------------------+ | Multicast Group (Variable) | +-----------------------------------+ | Originating Router's IP Addr | +-----------------------------------+ The RD is encoded as described in [RFC4364]. The Multicast Source field contains the C-S address, i.e., the address of the multicast source. If the Multicast Source field contains an IPv4 address, then the value of the Multicast Source Length field is 32. If the Multicast Source field contains an IPv6 address, then the value of the Multicast Source Length field is 128. The value of the Multicast Source Length field may be set to 0 to indicate a wildcard. The Multicast Group field contains the C-G address, i.e., the address of the multicast group. If the Multicast Group field contains an IPv4 address, then the value of the Multicast Group Length field is 32. If the Multicast Group field contains an IPv6 address, then the value of the Multicast Group Length field is 128. The Multicast Group Length field may be set to 0 to indicate a wildcard. Whether the Originating Router's IP Address field carries an IPv4 or IPv6 address is determined by the value of the Length field of the MCAST-VPLS NLRI. If the Multicast Source field contains an IPv4 address and the Multicast Group field contains an IPv4 address, then the value of the Length field is 22 bytes if the Originating Router's IP Address carries an IPv4 address and 34 bytes if it is an IPv6 address. If the Multicast Source and Multicast Group fields contain IPv6 addresses, then the value of the Length field is 46 bytes if the Originating Router's IP Address carries an IPv4 address and 58 bytes if it is an IPv6 address. The following table summarizes the above.
Multicast Multicast Originating Router's Length
Source Group IP Address
IPv4 IPv4 IPv4 22
IPv4 IPv4 IPv6 34
IPv6 IPv6 IPv4 46
IPv6 IPv6 IPv6 58
Usage of Selective Tree A-D routes is described in the "Optimizing
Multicast Distribution via Selective Trees" section.
9.2.2. Leaf A-D Route
The Route Type specific field of MCAST-VPLS NLRI of a leaf A-D route
consists of the following:
+-----------------------------------+
| Route Key (variable) |
+-----------------------------------+
| Originating Router's IP Addr |
+-----------------------------------+
Whether the Originating Router's IP Address field carries an IPv4 or
IPv6 address is determined by the Length field of the MCAST-VPLS NLRI
and the length of the Route Key field. From these two length fields,
one can compute the length of the Originating Router's IP Address.
If this computed length is 4, then the address is an IPv4 address; if
its 16, then the address is an IPv6 address.
Usage of leaf A-D routes is described in the "Inter-AS Inclusive
P-Multicast Tree A-D/Binding" and "Optimizing Multicast Distribution
via Selective Trees" sections.
10. Aggregation Considerations
This document does not specify the mandatory implementation of any
particular set of rules for determining whether or not the Inclusive
or Selective trees of two particular VPLS instances are to be
instantiated by the same Aggregate Inclusive/Selective tree. This
determination can be made by implementation-specific heuristics, by
configuration, or even perhaps by the use of offline tools.
This section discusses potential methodologies with respect to
aggregation.
In general, the heuristic used to decide which VPLS instances or <C-S, C-G> entries to aggregate is implementation dependent. It is also conceivable that offline tools can be used for this purpose. This section discusses some trade-offs with respect to aggregation. The "congruency" of aggregation is defined by the amount of overlap in the leaves of the client trees that are aggregated on an SP tree. For Aggregate Inclusive trees, the congruency depends on the overlap in the membership of the VPLS instances that are aggregated on the Aggregate Inclusive tree. If there is complete overlap, aggregation is perfectly congruent. As the overlap between the VPLS instances that are aggregated reduces, the congruency reduces. From the above definition of "congruency", it follows that in order for a given PE to determine the congruency of the client trees that this PE could aggregate, the PE has to know the leaves of these client trees. This is irrespective of whether the aggregated SP tree is established using mLDP or RSVP-TE. If aggregation is done such that it is not perfectly congruent, a PE may receive traffic for VPLS instances to which it doesn't belong. As the amount of multicast traffic in these unwanted VPLS instances increases, aggregation becomes less optimal with respect to delivered traffic. Hence, there is a trade-off between reducing multicast state in the core and delivering unwanted traffic. An implementation should provide knobs to control aggregation based on the congruency of the tree to be aggregated. This will allow an SP to deploy aggregation depending on the VPLS membership and traffic profiles in its network. If different PEs are setting up Aggregate Inclusive trees, this will also allow an SP to engineer the maximum amount of unwanted VPLS instances for which a particular PE may receive traffic. The state/bandwidth optimality trade-off can be further improved by having a versatile many-to-many association between client trees and provider trees. Thus, a VPLS instance can be mapped to multiple Aggregate trees. The mechanisms for achieving this are for further study. Also, it may be possible to use both ingress replication and an Aggregate tree for a particular VPLS. Mechanisms for achieving this are also for further study.
11. Data Forwarding
11.1. MPLS Tree Encapsulation
11.1.1. Mapping Multiple VPLS Instances to a P2MP LSP
The following diagram shows the progression of the VPLS multicast packet as it enters and leaves the SP network when MPLS trees are being used for multiple VPLS instances. RSVP-TE P2MP LSPs are examples of such trees. Packets received Packets in transit Packets forwarded at ingress PE in the service by egress PEs provider network +---------------+ |MPLS Tree Label| +---------------+ | VPLS Label | ++=============++ ++=============++ ++=============++ ||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-IP Header || || C-IP Header || || C-IP Header || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ ++=============++ ++=============++ When an ingress PE receives a packet, the ingress PE using the procedures defined in [RFC4761] and [RFC4762] determines the VPLS instance associated with the packet. If the packet is an IP multicast packet, and the ingress PE uses an Aggregate Selective tree for the (C-S, C-G) carried in the packet, then the ingress PE pushes the VPLS Label associated with the VPLS instance on the ingress PE and the MPLS Tree Label associated with the Aggregate Selective tree, and it sends the packet over the P2MP LSP associated with the Aggregate Selective tree. Otherwise, if the ingress PE does not use an Aggregate Selective tree for the (C-S, C-G), or the packet is either non-IP multicast or broadcast, the ingress PE pushes the VPLS label associated with the VPLS instance on the ingress PE and the MPLS Tree Label associated with the Aggregate Inclusive tree, and it sends the packet over the P2MP LSP associated with the Aggregate Inclusive tree. The egress PE does a lookup on the outer MPLS tree label, and determines the MPLS forwarding table in which to look up the inner MPLS label (VPLS label). This table is specific to the tree label space (as identified by the MPLS Tree Label). The inner label (VPLS label) is unique within the context of the root of the tree (as it is
assigned by the root of the tree, without any coordination with any other nodes). Thus, it is not unique across multiple roots. So, to unambiguously identify a particular VPLS, one has to know the VPLS label, and the context within which that label is unique. The context is provided by the outer MPLS label (MPLS Tree Label) [RFC5331]. The outer MPLS label is popped. The lookup of the resulting MPLS label determines the VSI in which the egress PE needs to do the C-multicast data packet lookup. It then pops the inner MPLS label and sends the packet to the VSI for multicast data forwarding.11.1.2. Mapping One VPLS Instance to a P2MP LSP
The following diagram shows the progression of the VPLS multicast packet as it enters and leaves the SP network when a given MPLS tree is being used for a single VPLS instance. RSVP-TE P2MP LSPs are examples of such trees. Packets received Packets in transit Packets forwarded at ingress PE in the service by egress PEs provider network +---------------+ |MPLS Tree Label| ++=============++ ++=============++ ++=============++ ||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-IP Header || || C-IP Header || || C-IP Header || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ ++=============++ ++=============++ When an ingress PE receives a packet, the ingress PE using the procedures defined in [RFC4761] and [RFC4762] determines the VPLS instance associated with the packet. If the packet is an IP multicast packet, and the ingress PE uses a Selective tree for the (C-S, C-G) carried in the packet, then the ingress PE pushes the MPLS Tree Label associated with the Selective tree, and it sends the packet over the P2MP LSP associated with the Selective tree. Otherwise, if the ingress PE does not use a Selective tree for the (C-S, C-G), or the packet is either non-IP multicast or broadcast, the ingress PE pushes the MPLS Tree Label associated with the Inclusive tree, and it sends the packet over the P2MP LSP associated with the Inclusive tree.
The egress PE does a lookup on the MPLS tree label and determines the VSI in which the receiver PE needs to do the C-multicast data packet lookup. It then pops the MPLS label and sends the packet to the VSI for multicast data forwarding.12. VPLS Data Packet Treatment
If the destination MAC address of a VPLS packet received by an ingress PE from a VPLS site is a multicast address, a P-multicast tree SHOULD be used to transport the packet, if possible. If the packet is an IP multicast packet and a Selective tree exists for that multicast stream, the Selective tree MUST be used. Else, if a (C-*, C-*) Selective tree exists for the VPLS it SHOULD be used. Else, if an Inclusive tree exists for the VPLS, it SHOULD be used. If the destination MAC address of a VPLS packet is a broadcast address, it is flooded. If a (C-*, C-*) Selective tree exists for the VPLS, the PE SHOULD flood over it. Else, if an Inclusive tree exists for the VPLS, the PE SHOULD flood over it. Else, the PE MUST flood the packet using the procedures in [RFC4761] or [RFC4762]. If the destination MAC address of a packet is a unicast address and it has not been learned, the packet MUST be sent to all PEs in the VPLS. Inclusive P-multicast trees or a Selective P-multicast tree bound to (C-*, C-*) SHOULD be used for sending unknown unicast MAC packets to all PEs. When this is the case, the receiving PEs MUST support the ability to perform MAC address learning for packets received on a multicast tree. In order to perform such learning, the receiver PE MUST be able to determine the sender PE when a VPLS packet is received on a P-multicast tree. This further implies that the MPLS P-multicast tree technology MUST allow the egress PE to determine the sender PE from the received MPLS packet. When a receiver PE receives a VPLS packet with a source MAC address, which has not yet been learned, on a P-multicast tree, the receiver PE determines the PW to the sender PE. The receiver PE then creates forwarding state in the VPLS instance with a destination MAC address being the same as the source MAC address being learned, and the PW being the PW to the sender PE. It should be noted that when a sender PE that is sending packets destined to an unknown unicast MAC address over a P-multicast tree learns the PW to use for forwarding packets destined to this unicast MAC address, it might immediately switch to transport such packets over this particular PW. Since the packets were initially being forwarded using a P-multicast tree, this could lead to packet
reordering. This constraint should be taken into consideration if unknown unicast frames are forwarded using a P-multicast tree, instead of multiple PWs based on [RFC4761] or [RFC4762]. An implementation SHOULD support the ability to transport unknown unicast traffic over Inclusive P-multicast trees. Furthermore, an implementation MUST support the ability to perform MAC address learning for packets received on a P-multicast tree.13. Security Considerations
Security considerations discussed in [RFC4761] and [RFC4762] apply to this document. This section describes additional considerations. As mentioned in [RFC4761], there are two aspects to achieving data privacy and protecting against denial-of-service attacks in a VPLS: securing the control plane and protecting the forwarding path. Compromise of the control plane could result in a PE sending multicast data belonging to some VPLS to another VPLS, or black- holing VPLS multicast data, or even sending it to an eavesdropper; none of which are acceptable from a data privacy point of view. In addition, compromise of the control plane could result in black- holing VPLS multicast data and could provide opportunities for unauthorized VPLS multicast usage (e.g., exploiting traffic replication within a multicast tree to amplify a denial-of-service attack based on sending large amounts of traffic). The mechanisms in this document use BGP for the control plane. Hence, techniques such as in [RFC5925] help authenticate BGP messages, making it harder to spoof updates (which can be used to divert VPLS traffic to the wrong VPLS) or withdrawals (denial-of- service attacks). In the multi-AS methods (b) and (c) described in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section, this also means protecting the inter-AS BGP sessions, between the ASBRs, the PEs, or the Route Reflectors. Note that [RFC5925] will not help in keeping MPLS labels, associated with P2MP LSPs or the upstream MPLS labels used for aggregation, private -- knowing the labels, one can eavesdrop on VPLS traffic. However, this requires access to the data path within an SP network, which is assumed to be composed of trusted nodes/links. One of the requirements for protecting the data plane is that the MPLS labels be accepted only from valid interfaces. This applies both to MPLS labels associated with P2MP LSPs and to the upstream- assigned MPLS labels. For a PE, valid interfaces comprise links from other routers in the PE's own AS. For an ASBR, valid interfaces comprise links from other routers in the ASBR's own AS, and links
from other ASBRs in ASes that have instances of a given VPLS. It is especially important in the case of multi-AS VPLS instances that one accept VPLS packets only from valid interfaces.14. IANA Considerations
This document defines a new NLRI, called "MCAST-VPLS", to be carried in BGP using multiprotocol extensions. IANA has assigned it a SAFI value of 8. This document defines a BGP-optional transitive attribute called "PMSI_TUNNEL". This is the same attribute as the one defined in [RFC6514] and the code point for this attribute has already been assigned by IANA as 22 [BGP-IANA]. Hence, no further action is required from IANA regarding this attribute.15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths", RFC 6511, February 2012. [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, February 2012.15.2. Informative References
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012. [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011. [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. [RFC5501] Kamite, Y., Ed., Wada, Y., Serbest, Y., Morin, T., and L. Fang, "Requirements for Multicast Support in Virtual Private LAN Services", RFC 5501, March 2009. [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [MULTI-HOMING] Kothari, B., Kompella, K., Henderickx, W., Balus, F., Uttaro, J., Palislamovic, S., and W. Lin, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, July 2013. [BGP-IANA] IANA, "Border Gateway Protocol (BGP) Parameters", <http://www.iana.org/assignments/bgp-parameters>.
16. Acknowledgments
Many thanks to Thomas Morin for his support of this work. We would also like to thank authors of [RFC6514] and [RFC6513], as the details of the inter-AS segmented tree procedures in this document, as well as some text that describes these procedures have benefited from those in [RFC6514] and [RFC6513]. The same applies to the notion of Inclusive and Selective trees, as well as the procedures for switching from Inclusive to Selective trees. We would also like to thank Nabil Bitar, Stewart Bryant, Wim Henderickx, and Eric Rosen for their review and comments.Authors' Addresses
Rahul Aggarwal 998 Lucky Avenue Menlo Park, CA 94025 USA Phone: +1-415-806-5527 EMail: raggarwa_1@yahoo.com Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: y.kamite@ntt.com Luyuan Fang Microsoft EMail: lufang@microsoft.com Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 USA EMail: yakov@juniper.net Chaitanya Kodeboniya EMail: chaitk@yahoo.com