Theoretical foundations and architecture
NG-MVPN (RFC 6513 and RFC 6514) separates signalling from tunnels: BGP carries PE auto-discovery and customer joins, while data is delivered over the tunnel selected by the PMSI Tunnel attribute. The MCAST-VPN family (AFI 1, SAFI 5) defines seven route types: Intra-AS and Inter-AS I-PMSI A-D, S-PMSI A-D, Leaf A-D, Source Active A-D and two C-multicast routes (Shared Tree and Source Tree Join). A PMSI tunnel can be an mLDP P2MP or MP2MP LSP (RFC 6388), P2MP RSVP-TE (RFC 4875), a PIM tree or ingress replication; an inclusive tunnel covers all PEs, a selective one only the interested ones. To deliver a C-multicast route only to the upstream PE, an RT built from the VRF Route Import is used. The lesson builds on your L3VPN and MPLS experience: PE-RR MP-BGP sessions, LDP and the IGP to the root loopback. As a result the core replicates packets by label, without PIM and GRE, and the control plane scales better than Rosen.
What NG-MVPN changed
RFC 6513 and RFC 6514 solve the main problem of Rosen: customer multicast signalling and PE discovery moved from PIM over GRE into BGP, and the core is free to use any tunnel technology. The architecture introduces the PMSI abstraction (Provider Multicast Service Interface): a delivery service from an ingress PE to a set of egress PEs. An Inclusive PMSI (I-PMSI) covers all PEs of the mVPN, a Selective PMSI (S-PMSI) only the PEs interested in a given flow (C-S,C-G) or group. A PMSI is realised by a tunnel: a P2MP or MP2MP LSP of mLDP (RFC 6388), P2MP RSVP-TE (RFC 4875), a PIM tree, ingress replication (a set of unicast tunnels) or something else. BGP only says which tunnel to use.
BGP MVPN routes: seven types
The MCAST-VPN family is defined for this: AFI 1, SAFI 5 for IPv4 (RFC 6514). The NLRI begins with the route type:
| Type | Name | Purpose |
|---|---|---|
| 1 | Intra-AS I-PMSI A-D | PE auto-discovery, I-PMSI announcement and the PMSI Tunnel attribute |
| 2 | Inter-AS I-PMSI A-D | The same between ASes (ASBR boundaries) |
| 3 | S-PMSI A-D | A tunnel announcement for a specific (C-S,C-G) or a wildcard |
| 4 | Leaf A-D | A leaf's reply to Leaf Information Required (RSVP-TE, ingress replication) |
| 5 | Source Active A-D | A PE reports an active source (C-S,C-G) for ASM and SPT-only |
| 6 | C-multicast Shared Tree Join | A customer (*,G) join toward the PE behind the RP |
| 7 | C-multicast Source Tree Join | A customer (S,G) join toward the PE behind the source |
Types 1-5 carry auto-discovery and tunnel information, while types 6 and 7 are called C-multicast routes: they replace customer PIM Join/Prune.
The PMSI Tunnel attribute
Routes of types 1 and 3 (and 2 and 4 for the Inter-AS part) contain the PMSI Tunnel Attribute: flags (including Leaf Information Required), the tunnel type, an MPLS label and the tunnel identifier. Tunnel types: 0 - no tunnel information, 1 - P2MP RSVP-TE, 2 - mLDP P2MP, 3 - PIM-SSM, 4 - PIM-SM, 5 - BIDIR-PIM, 6 - ingress replication, 7 - mLDP MP2MP. For mLDP the identifier is the P2MP FEC element: the root address and an opaque value. A leaf that receives such an attribute starts building the LSP toward the root itself; thus BGP replaces both discovery and the mapping of a group to a tunnel.
Route Targets and VRF Route Import
A-D routes (types 1, 3, 5) are imported by the RTs configured for the mVPN (normally the same as the VRF RTs). C-multicast routes (types 6 and 7) must be received only by the upstream PE. To achieve that, a PE adds the VRF Route Import extended community to the VPNv4 route toward a source or RP: the address of the originating PE and a local VRF number. The receiving PE, when sending a C-multicast route, takes this community from the best unicast route and attaches it as an RT: the route is imported into the VRF of the upstream PE only, not by all PEs. Extended communities are therefore mandatory in BGP for NG-MVPN, and the RR must carry the mvpn family without stripping them.
mLDP: P2MP and MP2MP
mLDP (RFC 6388) extends LDP: P2MP (type 0x06) and MP2MP (up 0x07, down 0x08) FEC elements appear and the P2MP and MP2MP capabilities are negotiated. The LSP is built from the leaves toward the root: a leaf sends a label mapping to the LDP neighbour that is the IGP next hop toward the root address; on each node the labels from downstream are accepted and merged. A branching node replicates the packet to all downstream labels. A P2MP LSP carries traffic from the root to the leaves; MP2MP allows sending from any participant but uses the root node as a rendezvous point. The tree path follows the IGP toward the root, so mLDP requires the root loopback to be reachable with LDP labels at every hop, and the tree is rebuilt when the IGP changes.
P2MP RSVP-TE and ingress replication
P2MP RSVP-TE (RFC 4875) builds the tree by signalling from the root: one P2MP LSP consists of sub-LSPs to every leaf, with explicit paths, bandwidth reservation and FRR possible. For mVPN the PE learns the leaves from Leaf A-D routes and creates the sub-LSPs itself. The price is state and configuration on the root and harder scaling. Ingress replication uses unicast LSPs to each leaf; the core needs no P2MP capability, but the PE makes as many packet copies as there are leaves, which limits it to a small number of receivers or to a core where P2MP is unavailable.
Inclusive and selective tunnels
The I-PMSI is the simplest: one tunnel per mVPN per source PE, and all PEs receive all flows. This is the behaviour of the default MDT, but with an MPLS tunnel and without PIM. An S-PMSI lets a flow move to its own tree: the source PE announces a Type 3 route with (C-S,C-G) and a tunnel, and PEs with receivers reply with Type 4 (if Leaf Information Required is set) and join. A wildcard S-PMSI (RFC 6625) describes a whole set of flows with one route. Often the I-PMSI is used for discovery and small flows and the S-PMSI for heavy flows or broadcast IPTV channels.
