Like many network engineers I have had difficulties with multicast, the logic is all messed up right!? The only implementation of mVPN I had seen in test or production was Draft Rosen (RFC6037). Now I know Draft Rosen works well but it does have its limitations and I’m a firm believer in getting unnecessary junk out of the core, I’m looking at you PIM! Draft Rosen requires that you run PIM in your core and it must maintain state for, at a minimum, one MDT per mVPN. The amount of state is proportional to the number of VPNs. We are also limited to using GRE to interconnect our PE routers together and cannot therefore leverage MPLS technologies in the same way our unicast traffic can. The next evolution in multicast VPN aims to address these limitations.
Before we get in to the nitty gritty I need to introduce some concepts that you may not be familiar with, especially if you come from a Cisco background. Draft Rosen uses the concept of default and data MDTs. The default tree uses GRE to build tunnels between all PEs participating in the mVPN. This is called the MI-PMSI (Multidirectional Inclusive Provider Multicast Service Interface, a.k.a I-PMSI). In its capacity as an overlay broadcast network it is responsible for distributing multicast traffic to all VPN endpoints to ensure any interested receivers will get the traffic flow. The downside of this is disinterested PEs will receive traffic and simply discard it, an uncool use of resources. To optimize forwarding we use the data tree so that only PEs with interested receivers get the traffic with the switchover process typically triggered by traffic rates breaching a threshold on the root PE. This is the S-PMSI (Selective PMSI). These concepts are present in both Draft Rosen and the NG mVPN implementations (RFC6513, RFC6514).
NG mVPN removes the dependency on PIM in the core allowing us to use mLDP or RSVP-TE for transport. As we already use MPLS and MP-BGP to distribute unicast VPN routing information then why don’t we reuse that functionality here, and that’s pretty much what this is all about. You can still use PIM for transport but that is more of a transitional technology. For example I work on Alcatel-Lucent kit a lot and mLDP needs SR-OS mode D. If you can’t run your router in that mode PIM would be the way to go for your service transport until you can enable mode D. This will still allow you to maintain BGP and service configuration consistency between transport protocols. The remainder of this post will focus on the BGP elements with subsequent posts looking at transport using mLDP, RSVP and actual implementation.
RFC6514 introduces an MP-BGP NRLI called called MCAST-VPN (SAFI 5) which defines 7 route types. The most pertinent route types are 1 and 3, the Intra-AS I-PMSI and the S-PMSI A-D respectively. Each one has a primary role in the foundation of the build of our mVPN, they are used for auto-discovery within the service.
The Intra-AS I-PMSI A-D route is 12 octets in length and carries a route distinguisher (the same as RFC4364) and the originating routers IP address.
This route type is carried by BGP instead of an MDT-SAFI route and is use to discover all other PEs within the mVPN. When a PE is activated in the mVPN it originates this route and advertises it in to MP-BGP with the no-export community set.
The S-PMSI A-D route is used by the ingress PE to signal other mVPN PEs of an S-PMSI instance, such as when the threshold for the I-PMSI has been exceeded. This allows traffic to flow over our optimal path (from a service perspective) to PEs with interested receivers connected. The data threshold could be set to 1kbps to trigger an almost immediate transition from I-PMSI to S-PMSI and to keep the core and flows as optimal as possible.
The S-PMSI route adds in the customers source and group (C-S, C-G) on top of the I-PMSI contents. The length field changes depending on if the address is IPv4 or IPv6.
There are two other route types of particular note and they concern the end users network specifically. The first is the Source-Active A-D route (type 5) which is used to notify other PEs when there is an active multicast source in the customers network.
The source active route specifies the (C-S, C-G) pair.
The final route type of significant importance is the C-multicast route which is used by PEs to either join the shared or source trees. If the message relates to a shared tree join (type 6) the multicast source address field will contain the customer RP (C-RP). If the message is a source tree join (type 7) then the multicast source address will be the stream source host address (C-S). This will also contain the source ASN.
There are other route types for things like Inter AS VPN but I won’t cover them as they’re more advanced and I haven’t done any lab testing on them. I may come back to them in another post but for now that’s it for this post, the next one will cover mLDP and RSVP-TE uses for transport before finishing with implementation and behaviours.