MBGP-Based Multicast VPNs

MBGP-based MVPNs (next generation MVPNs) are based on Internet drafts and extend unicast VPNs based on RFC 2547 to include support for IP multicast traffic. These MVPNs follow the same architectural model as the unicast VPNs and use BGP as the PE-to-PE control plane to exchange information. The next generation MVPN approach is based on Internet drafts draft-ietf-l3vpn-2547bis-mcast.txt, draft-ietf-l3vpn-2547bis-mcast-bgp.txt, and draft-morin-l3vpn-mvpn-considerations.txt.

In addition, MBGP-based MVPNs:

• Do not require a virtual router as in dual PIM MVPNs.
• Extend RFC 2547 unicast VPN mechanisms for intra- and extra-AS environments.
• Retain the scalability and flexibility of RFC 2547 unicast VPNs as much as possible.

MBGP-based MVPNs introduce two new types of tree:

By default, traffic from most multicast groups can be carried by an inclusive tree, while traffic from some groups (for example, high bandwidth groups) can be carried by one of the selective trees. Selective trees, if they contain only those PEs that need to receive multicast data from one or more groups assigned to the tree, can provide more optimal routing than inclusive tress alone, although this requires more state information in the P routers.

An MPLS-based VPN running BGP with autodiscovery is used as the basis for a next-generation MVPN. The autodiscovered route information is carried in MBGP network layer reachability information (NLRI) updates for multicast VPNs (MCAST-VPNs). These MCAST-VPN NLRIs are handled in the same way as IPv4 routes: route distinguishers are used to distinguish between different VPNs in the network. These NLRIs are imported and exported based on the route target extended communities, just as IPv4 unicast routes. In other words, existing BGP mechanisms are used to distribute multicast information on the provider backbone without requiring multicast directly.

For example, consider a customer running PIM sparse mode in SSM mode. Only source tree join customer multicast (c-multicast) routes are required. (PIM sparse mode in ASM mode can be supported with a few enhancements to SMM mode.)

The customer multicast route carrying a particular multicast source S should be imported only into the VRF table on the PE router connected to the site that contains the source S and not into any other VRF, even for the same MVPN. To do this, each VRF on a particular PE has a distinct VRF route import extended community associated with it. This community consists of the PE router's IP address and local PE number. Different MVPNs on a particular PE have different route imports, and for a particular MVPN the VRFs on different PE routers have different route imports. This VRF route import is auto-configured and not controlled by the user.

Also, all the VRFs within a particular MVPN will have information about VRF route imports for each VRF. This is accomplished by “piggybacking” the VRF route import extended community onto the unicast VPN IPv4 routes. In order to make sure a customer multicast route carrying multicast source S is imported only into the VRF on the PE router connected to the site contained the source S, it is necessary to find the unicast VPN IPv4 route to S and set the route target of the customer multicast route to the VRF import route carried by the VPN IPv4 route just found.

The process of originating customer multicast routes in a MBGP-based MVPN is shown in Figure 30.

In the figure, an MVPN has three receiver sites (R1, R2, and R3) and one source site (S). The site routers are connected to four PE routers and PIM is running between the PE routers and the site routers. However, only BGP runs between the PE routers on the provider's network.

When router PE–1 receives a PIM join message for (S,G) from the site router R1, this means that site R1 has one or more receivers for a given source and multicast group (S,G) combination. In that case, router PE-1 constructs and originates a customer multicast route after doing three things:

1. Finding the unicast VPN IPv4 router to source S.
2. Extracting the route distinguisher and VRF route import form this route.
3. Putting the (S,G) information form the PIM join, the router distinguisher from the VPN IPv4 route and the route target from the VRF route import of the VPN IPv4 route into a MBGP update.

The update is distributed around the VPN through normal BGP mechanisms such as router reflectors.

Figure 30: Source and Receiver Sites in an MVPN

What happens when the source site S receives the MBGP information is shown in Figure 31. In the figure, the customer multicast route information is distributed by the BGP route reflector as an MBGP update.

The provider router PE-4 will then:

1. Receive the customer multicast route originated by the PE routers and aggregated by the route reflector.
2. Accepts the customer multicast route into the VRF for the correct MVPN (because the VRF route import matches the route target carried in the customer multicast route information).
3. Creates the proper (S,G) state in the VRF and propagates the information to the customer routers of source site S using PIM.

Figure 31: Adding a Receiver to an MVPN Source Site Using MBGP

For more information about configuring multicast for Layer 3 VPNs using MBGP, see Configuring Any-Source Multicast for Draft-Rosen VPNs. For multicast Layer 3 VPN examples, see Example: Configuring PIM Sparse Mode over Layer 3 VPNs Using Multiprotocol BGP.

Copyright © 2009, Juniper Networks, Inc. All rights reserved. Trademark Notice.