Theoretical foundations and architecture

Rosen mVPN (RFC 6037, draft-rosen) is the first solution for multicast inside an L3VPN, built on the MDT concept. Each PE creates a multicast VRF and a tunnel interface (MTI) for the customer VRF, and all PEs of one mVPN subscribe to the default MDT group address in the global table. Customer packets and PIM messages are packed into GRE with the MDT group as the outer destination, so the core needs only ordinary PIM, while the PEs of one VPN see each other as neighbours on a LAN-like interface. Heavy flows are moved to a data MDT: the PE announces the group with an MDT Data TLV and only PEs with receivers join it. PE discovery uses ASM or the MDT SAFI in BGP. The lesson explains the mechanics and shows why Rosen scales poorly: core state, default MDT flooding to all PEs, customer PIM load, GRE overhead and Inter-AS complexity. These limits lead to NG-MVPN in the next lesson.

The Rosen idea: a multicast VRF and a tunnel across the core

Cisco's solution described in RFC 6037 (draft-rosen) rests on a simple thought: the provider core knows nothing about VRFs, so customer multicast is encapsulated in the provider's own multicast. On each PE the VRF gets an mVRF - the multicast routing table of that VRF (separate PIM neighbours, mroute and RPF). All PEs of one mVPN are connected by a multicast tunnel, the MDT (Multicast Distribution Tree): the customer packet is wrapped in GRE, the outer IP header has the PE loopback (the BGP peering address) as source and an MDT group address from the provider's global space as destination. The core replicates such a packet with ordinary PIM without knowing what is inside. MPLS labels are not involved here: core forwarding is IP multicast, while MPLS remains for unicast VPN traffic.

The default MDT and the MTI

The default MDT is the group configured in the VRF with mdt default; every PE of that mVPN joins it, and each PE is the root of its own (PE,G) tree and a leaf of the others. For an mVPN with N PEs the core holds up to N (S,G) entries on every P router along the way. For the default MDT the PE creates a virtual Multicast Tunnel Interface (MTI): for the VRF it is an ordinary multi-access interface that carries customer PIM messages and data in and out. For the RPF check the MTI is an acceptable incoming interface when the unicast (VPNv4) route to the customer source points to a remote PE and that PE is a PIM neighbour on the MTI. That is why the next hop of the VPNv4 route must match the address from which the tunnel is built.

Customer PIM over the MDT

Customer PIM runs in the VRF as in any network: Hello every 30 seconds, Join/Prune every 60 seconds, DR election on the MTI. To customer PIM the MTI looks like a LAN holding all PEs. Therefore a Join is sent on the MTI and received by all PEs, and Join suppression/override and the Assert winner election apply when a flow arrives from several PEs. Customer PIM control messages also travel through the default MDT and reach all PEs, including those with no receivers.

The data MDT

The default MDT delivers every customer multicast packet to all PEs of the mVPN, even when a receiver sits behind only one of them. To avoid wasting bandwidth, heavy flows are moved to a data MDT. The mdt data command defines a pool of groups and a threshold in kbps. When a customer flow (C-S,C-G) exceeds the threshold, the source PE picks a free group from the pool and announces it with an MDT Data TLV in a UDP packet (port 3232, to 224.0.0.13) over the default MDT. PEs with receivers of this (C-S,C-G) join the data MDT group, the others do not. The flow is then moved to the data MDT and returns to the default MDT when traffic falls. The pool must be sized: the number of simultaneous data MDTs is bounded by the pool size, and the remaining flows stay on the default MDT.

PE discovery: ASM or MDT SAFI

A PE must know the addresses of the other PEs of the same mVPN to join (PE,G). With ASM in the core (PIM-SM with an RP) sources find each other through the shared tree: all PEs send to the group and the RP connects sources with receivers. With PIM-SSM in the core the source addresses must be known in advance, and RFC 6037 introduces the MDT SAFI (AFI 1, SAFI 66): the PE sends a BGP update with the RD, the PE address and the MDT group address, and a receiver with a matching RT joins (PE,G) using ip pim ssm default. MDT-SAFI addresses make SSM (simpler, no RP) possible and limit the scope with RTs. The RR must carry the mdt address family.

Rosen limitations

First, PIM is mandatory in the core (and an RP with ASM); P-router state grows: for each mVPN at least N default MDT entries plus the data MDTs. Second, the default MDT delivers data to all PEs until a flow moves to a data MDT. Third, customer PIM exchanges periodic messages between all PE pairs, which loads the control plane. Fourth, GRE adds 24 bytes (20 bytes of outer IP and 4 bytes of GRE), and a customer packet sized to an MTU of 1500 may not fit. Fifth, Inter-AS needs extra mechanisms (the BGP connector, RPF vector). Finally, the core uses IP multicast rather than labels, so there is no common model with LDP/RSVP-TE and FRR. These limits led to NG-MVPN: BGP instead of PIM for customer signalling and P2MP tunnels instead of mGRE (next lesson).