Multicast in MPLS/BGP IP VPNs
updated by
Extracted elements (28)
BGP is preferred over PIM for PE-PE exchange of C-multicast routing because BGP provides reliable transport with incremental updates; PIM is a soft-state protocol requiring periodic full retransmissions whose overhead grows with the number of MVPNs and C-trees.
Explicit tracking of downstream PEs per C-tree is omitted from default BGP C-multicast routes to reduce state and improve scalability; the upstream PE does not need to know downstream PE identities to construct PIM messages. Leaf A-D routes provide explicit tracking only when needed for P-tree setup or S-PMSI optimization.
Multiple P-tunnel technologies (PIM, mLDP, RSVP-TE, unicast mesh) are all supported because multicast deployment history shows no single option is always acceptable. Segmented inter-AS trees allow each SP to choose the technology that fits its environment without forcing other SPs to adopt it.
Optimal multicast routing requires per-flow state in P routers proportional to the number of VPN multicast flows, which is outside SP control and scales poorly. The framework aggregates customer multicast flows onto shared P-tunnels, trading routing optimality for P-router scalability; SPs configure their own balance between the two.
In the event of any conflict or discrepancy between this document and RFC 6514 (MVPN-BGP) regarding the use of BGP in support of MVPN service, RFC 6514 is authoritative.
PIM Dense Mode (PIM-DM) is explicitly not supported on PE-CE links or for creating P-tunnels; only PIM-SM (ASM and SSM) and BIDIR-PIM are within scope.
A PE MUST select a single route from the UMH Route Candidate Set. The default procedure, which MUST be implemented, selects the candidate whose Upstream PE address is numerically highest (treating the 32-bit IP address as an unsigned integer), ensuring all PEs converge on the same upstream PE given stable routing.
A PE that installs an A-D route with the 'Leaf Information Required' bit set in the PMSI Tunnel attribute MUST respond by generating a Leaf A-D route indicating it needs to join the specified PMSI Tunnel.
Each Intra-AS I-PMSI A-D route MUST carry one or more Route Target Extended Community attributes. Any PE with a matching RT configured for import treats the advertising PE as a member of the corresponding MVPN, realizing BGP-based auto-discovery of MVPN membership.
For a given MVPN, a PE MUST use a single consistent IP address as the source address in all BSR packets it transmits to other PEs, and this same address MUST be used as the Global Administrator field of the VRF Route Import Extended Community in its distributed VPN-IP routes.
If BGP is used for carrying C-multicast routes, OR if segmented inter-AS tunnels are used, then every UMH route MUST also carry a Source AS Extended Community.
If BGP is used to distribute C-multicast routing information, or if the UMH route is from a multi-AS VPN (RFC 4364 option b), every eligible UMH route MUST carry a VRF Route Import Extended Community identifying the PE that originated the route.
P-tunnel construction (via PIM, RSVP-TE, or mLDP) to instantiate an I-PMSI SHOULD occur as soon as the required identification information is known.
PIM Join suppression SHOULD be enabled when PEs form full PIM adjacencies over an MI-PMSI treating it as a LAN interface.
The Global Administrator field of the VRF Route Import Extended Community MUST be set to the same IP address that the PE places in the IP source address field of the PE-PE PIM C-instance control messages it originates from that VRF.
The use of ingress replication by any PE for an MVPN implies that all other PEs MUST use ingress replication for that MVPN.
A P-Multicast Service Interface (PMSI) is a conceptual overlay on the provider network enabling a PE in an MVPN to deliver packets to some or all other PEs in that MVPN, with each receiver able to identify the originating MVPN. PMSIs are instantiated by P-tunnels using PIM trees, mLDP LSPs, RSVP-TE P2MP LSPs, or unicast meshes.
PE Distinguisher Labels are upstream-assigned MPLS labels distributed in Intra-AS I-PMSI A-D routes by the root of a P-tunnel, binding a label value to a specific PE address. They are used for demultiplexing on MP2MP LSPs and for PIM-BIDIR support; label values are unique only in the context of the P-tunnel root's IP address.
PIM C-instances are n independent VPN-specific multicast routing instances running on a PE attached to n MVPNs. Each C-instance is associated with a VRF (extended from RFC 4364 to include multicast routing entries). CE routers become multicast routing adjacencies of their local PE but not of CE routers at other sites.
The Intra-AS I-PMSI Auto-Discovery (A-D) route is a MCAST-VPN BGP NLRI originated by PEs attached to MVPN sites. Its NLRI encodes the route type, originating PE IP address, and a locally configured Route Distinguisher; it carries Route Target Extended Communities for membership discovery, a PMSI Tunnel attribute, and optionally a PE Distinguisher Labels attribute.
The MCAST-VPN address family is a new BGP address family used for MVPN auto-discovery and C-multicast routing. Its NLRI encodes a route-type field distinguishing Intra-AS I-PMSI A-D, S-PMSI A-D, Leaf A-D, Source Active A-D, and C-multicast routing routes (source tree join and shared tree join).
The PMSI Tunnel attribute encodes tunnel technology (one of: BIDIR-PIM, PIM-SM SSM, PIM-SM ASM, RSVP-TE P2MP LSP, mLDP P2MP LSP, mLDP MP2MP LSP, or unicast tunnel), a technology-dependent P-tunnel identifier, and optionally an upstream-assigned MPLS label for multi-MVPN aggregate demultiplexing.
The Upstream Multicast Hop (UMH) is the PE or ASBR at which C-multicast data packets enter the VPN backbone for a given C-root (source address or RP). UMH selection builds a candidate set of eligible VPN-IP routes matching the C-root and selects one deterministically to ensure all egress PEs converge on the same ingress PE.
Three PMSI types are defined: MI-PMSI (Multidirectional Inclusive) enables any PE to reach every other PE in the MVPN; UI-PMSI (Unidirectional Inclusive) enables one PE to reach all others in the MVPN; S-PMSI (Selective) enables a PE to reach a subset. At most one MI-PMSI and one UI-PMSI per PE per MVPN exist; multiple S-PMSIs per PE per MVPN are allowed.
Section 14 requests IANA allocations for the MCAST-VPN address family and its NLRI route-type codes (covering Intra-AS and Inter-AS I-PMSI A-D, S-PMSI A-D, Leaf A-D, Source Active A-D, and C-multicast route types), PMSI Tunnel Attribute type codes, and associated BGP extended community types; detailed assignments are specified in companion document RFC 6514.
Section 13 addresses security for MVPN. The integrity of VPN traffic isolation depends on the security of BGP-based auto-discovery and C-multicast routing; a compromised PE could inject false Intra-AS I-PMSI A-D routes or C-multicast routes, violating MVPN isolation boundaries. Standard BGP security mechanisms from RFC 4364 apply.
For GRE encapsulation with a single PMSI per P-tunnel, C-multicast data are encapsulated in GRE with the outer IP destination set to the P-group address. For aggregate P-tunnels carrying multiple MVPNs, an upstream-assigned MPLS label is prepended before the GRE header to identify the MVPN.
For MPLS encapsulation on P2MP LSPs, C-multicast packets carry an upstream-assigned MPLS label on the label stack when the P-tunnel is aggregated (multiple MVPNs). For non-aggregated tunnels, the LSP label alone identifies the PMSI. Placement in the label stack is specified in Sections 12.1.3 and 12.2.