Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Multicast VPNs Overview

    JunosE Software provides the ability to create multicast VPNs by using GRE tunnels. This implementation is based on Multicast in MPLS/BGP VPNs (draft-rosen-vpn-mcast-06.txt and draft-rosen-vpn-mcast-08.txt) and further defined by Base Specification for Multicast in MPLS/BGP VPNs (draft-raggarwa-13vpn-2547-mvpn-00.txt).

    Note: Although you can configure PIM sparse mode remote neighbors, you can no longer use these remote neighbors for BGP/MPLS VPNs. For multicast VPNs, use the functionality described in this section.

    The JunosE Software supports default Multicast Distribution Trees (MDTs) and data MDTs. The following topics explain how to create multicast VPNs using the default MDTs and the data MDTs:

    Creating Multicast VPNs Using the Default MDT

    The JunosE Software does not support a single MDT command. Instead, you must configure the multicast tunnel interfaces (MTIs) explicitly. The MTI is an IP interface that is stacked on a GRE tunnel interface. The destination address of the GRE tunnel is the multicast VPN (MVPN) group address of the MDT.

    A tunnel mdt command specifies that the tunnel is the MTI for the default MDT, enabling the creation of a second, layer 2 interface (interface tunnel gre:name.mdt) on which an unnumbered IP interface (tied to the provider edge loopback interface) is stacked in the context of the parent virtual router.

    Creating Multicast VPNs Using the Data MDT

    A data multicast distribution tree (MDT), based on section 8 of Internet draft draft-rosen-vpn-mcast-08.txt, Multicast in MPLS/BGP IP VPNs, solves the problem of P routers flooding unnecessary multicast information to PE routers that have no interested receivers for a particular VPN multicast group. The data MDT solution requires the creation of a new tunnel by the PE router if the source exceeds a configured rate threshold parameter. All other PE routers join the new tunnel only if the PE router has receivers in the VPN for that multicast group.

    The JunosE Software uses dynamic point-to-multipoint GRE tunnels to configure data MDTs. In the current release, IPv6 transport over GRE (unicast or multicast) is not supported. For more information, see Configuring Dynamic IP Tunnels in the JunosE IP Services Configuration Guide.

    Data MDTs are established using PIM-SM (shared RP Trees) and PIM-SSM (Source Trees). Profiles for dynamic interfaces in the VRF are restricted to sparse-mode only.

    Data MDT Sources

    A C-SG flow arriving in the source VRF is a candidate for a data MDT if the system matches the C-SG in the route map that you specify for the data MDT using the ip pim data-mdt command. The C-SG flow is initially forwarded on the default MDT. The system creates the data MDT when the flow rate exceeds a value you configure in the route map using the set threshold command.

    When the Source C-PIM-SM first creates a data MDT for a C-SG flow, it sends a <C-SG, P-G> MDT join message with type, length, value (TLV) format to the default MDT. This message invites peer PE routers to join the new data MDT. It starts a timer that you can configure using the mdt-data-delay command to track the number of seconds before switching to the data MDT. When that timer expires, C-PIM-SM switches from sending C-SG data on the default MDT to sending data on the data MDT.

    When the C-SG flow is switched to the data MDT, the Source C-PIM-SM starts a timer that you can configure using the mdt-data-holddown command to track the number of seconds before switching to the default MDT. When the timer expires, the data MDT is deleted and the C-SG flow switched back to the default MDT if the flow rate drops back below the threshold. If the flow rate exceeds the threshold, the timer restarts. If the timer expires and the flow rate is below the threshold, the data MDT is removed.

    The Source C-PIM-SM maintains sent MDT Join TLV messages in its database as long as they are active. While the data MDT is active, C-PIM-SM resends that MLD Join TLV message using a setting that you can configure using the mdt-interval command to measure time in seconds between successive MLD join TLV messages.

    Data MDT Receivers

    When the Receiver C-PIM-SM receives a <C-SG, P-G> MDT Join TLV message from the default MDT, it extracts the C-SG and the data MDT P-Group address from the TLV and queries the route map that you specified for the data MDT to determine whether the C-SG is a candidate for a data MDT. If it matches, the C-PIM-SM adds the MDT Join TLV to its database and records the time.

    If the Receiver C-PIM-SM does not receive an MDT Join TLV<C-SG, P-G> to refresh its database within the amount of time specified for the timeout in the mdt-data-timeout command, the MDT Join TLV<C-SG> is removed from the database and the associated data MDT is removed.

    When a new MDT Join TLV<C-SG, P-G> is added to the database, the Receiver C-PIM-SM determines whether it has an SG, SPT state. If it has an SG state, and the incoming interface (IIF) is the default MDT, then C-PIM-SM creates the data MDT and deletes the corresponding forwarding entry. C-PIM-SM waits for the source to transmit data on the data MDT. During this period, data can continue to be received on the default MDT. C-PIM-SM fails the reverse-path forwarding (RPF) check, which results in a forwarding entry with a discarded IIF.

    If the C-SG,SPT state is created (either as a result of a C-SSM join or switch from RPT to SPT), and it is the default MDT, the Receiver C-PIM-SM determines whether an MDT Join TLV<C-SG> is active. If it is, C-PIM-SM creates the data MDT.

    Establishing a Data MDT Using ASM or SSM

    A data MDT carries one C-SG flow. If the data MDTs are established using any-source multicast (ASM), then the P-Group address selected by a PE for the data MDT must be unique to that PE in the MDT (that is, the range of MDT P-Group addresses available in the core must be administratively divided among all the PEs that will source VPN multicasts). The VRFs in a PE must share the P-Group addresses in the assigned range for the PE.

    If the data MDTs are established using single-source multicast (SSM), you must configure VRFs to transmit on a tunnel using the same MDT P-Group address. Each VRF transmits using a unique P-Source address; however, each data MDT created by the VRF must use a different P-Group address. There might be one sender data MDT and possibly many receiver data MDTs sharing an IP tunnel. Each PE can assign MDT P-Groups from the same range, but the P-Group addresses must be administratively divided among the VPNs.

    For a receiver on the data MDT, P-PIM-SM joins the data MDT by propagating join state into the core. The P-Group for that join is extracted from the MDT Join TLV. If SSM is not activated or the P-Group is not in the SSM group range, P-PIM-SM performs a <*, G> join towards the RP for that P-Group.

    If SSM is activated and the P-Group is in the SSM group range, P-PIM-SM performs an <S, G> join towards the P-Source, where the P-Source address is the SA of the MDT Join TLV.

    Published: 2014-08-19