MPLS Multicast VPN Overview


MVPN enables a service provider to transport his multicast traffic across MPLS packet-based core networks for IP VPN customers and to implement the "ships in the night" approach with MPLSthat is, the coexistence of separate routing constructs. The SP does not participate in customer multicast routing, and the MVPN configuration is performed only on the PEs, allowing for transparency of the SP network.

Some key components of MVPN include:

  • Multicast domain (MD) A domain that consists of a set of VRFs capable of transmitting multicast to each other.

  • Multicast VRF (MVRF) A VRF that supports both unicast and multicast forwarding tables.

  • Multicast distribution tunnel (MDT) Used to carry multicast C-packets between PEs in a common MVPN. It takes the form of a multicast tree in the core network.

The two additional components used in a Cisco implementation are as follows:

  • Default-MDT The Default-Multicast Distribution Tunnel (Default-MDT) group is used for control traffic, and to flood the multicast channel for dense mode and low-bandwidth groups.

  • Data-MDT The MDT group is created on demand for MVPN (S,G) pairs, usually high-bandwidth traffic. Every PE router has one or more multicast routing tables and has at least one default table for the provider network. In addition, a multicast routing table exists for each VPN to which the PE is attached.

    A CE router interacts with a PE router in exactly the same way as it does with any other neighboring C routers. A PE router can also have directly connected hosts or Layer 2 switches.

    An interface type called multicast tunnel is dynamically created by PIM to build point-to-multipoint tunnels on the backbone network. The delivery (outer) IP header is a multicast group, called the MDT group for the VPN, and is statically configured.

    The source address in the delivery header is usually a loopback address on the PE router that is the root of the multicast distribution tree. For every VPN the PE router is connected to, there is one multicast tunnel using the PE router as the root. The PE router also becomes the leaves of multicast tunnels rooted at other PE routers connected to the same VPN. A PE's participation in a VPN is distributed to other PEs by MBGP. PE routers use GRE encapsulation to send packets to other PE routers, and these appear as regular multicast packets to P routers. When a PE router receives these packets, the outer delivery header is stripped and the packet is routed using the MVRF identified by the MDT group in the delivery header.

So, an operation of MVPN can be summarized as follows.

An MVRF is assigned to an MD, and a P-group address is defined for each MD. This P-group address must be unique, and C-packets are encapsulated on the PE routers and sent on to the MDT as P-packets. The encapsulation can be GRE/IPinIP/MPLS. An IP source address is the address of the MBGP update, whereas the group destination address is the P-group address. One state exists in the core for all multicast states within a VPN, therein providing core stability. PIM is a soft-state protocol, so a limited number of states can be supported. However, traffic replication is not optimal because the PE routers without interested receivers still receive all multicast traffic per VPN. This architecture solution does not depend on MPLS as the delivery vehicle, and the current solution permits multicast VPNs within one BGP domain. This architecture also depends on stable multicast routing being enabled in the provider core, which is beyond the scope of this chapter.

Therefore, from a functional standpoint, IP Multicast can be packaged into three solutions. The first of these solutions is Campus multicast or Intradomain Multicast where there is an end station management, or host to router protocols (IGMP), which requests admission to join or leave multicast groups. The second component of this solution is switch membership management via CGMP or IGMP snooping. This ensures that the switch intelligently handles multicast forwarding without flooding the network. The third component is PIM Sparse Mode, which ensures that the network has appropriate information necessary to forward multicast packets down a multicast distribution tree from source to destination. Note also that an Internet Multicast tree includes MBGP for AS to AS multicast routing information and MSDP for third party source discovery across PIM Sparse Mode clouds as shown in Figure 10-3.

Figure 10-3. End-to-End Architecture


Multicast VPN Operational Details

In MVPN, the P routers form a PIM adjacency with each other; this is a global adjacency. The CE router forms a PIM adjacency with the VRF instance on the PE router. A per-VPN multicast distribution tunnel is established between PE routers in a provider network, and the PE routers form PIM adjacency with other PE routers over a tunnel. This is a VRF-specific adjacency. Multicast packets from CE routers are forwarded over the multicast tunnel, and the PE is always a root (source) of the MDT. The PE is also a leaf (receiver) to the MDT rooted on the remote PEs. The MDT creates an any-to-any distribution tree.

Figure 10-4 summarizes the MVPN concept.

Figure 10-4. Multicast VPN Solution Concept


For PIM requirements, the service provider might have a preference for a particular PIM mode or already have multicast deployed in the core. Additionally, a VPN customer might have a preference for a PIM mode or already have deployed multicast in its network. Therefore, the customer-facing solution must support all PIM modes.

Available PIM modes are as follows:

  • PIM bidirectional (PIM-BIDIR)

  • PIM source specific multicast (PIM-SSM)

  • PIM sparse-mode (PIM-SM)

  • PIM dense-mode (PIM-DM)

PIM-DM is not suitable for service provider core usage because of its scalability limitations and is therefore not supported as a protocol in the core; neither is any other protocol that is not based on PIM (such as dvmrp, mospf, and so on). For a multicast VRF (MVRF) configuration, the MVRF is created when multicast routing is enabled for that VRF. Multicast protocols such as IGMP and PIM are configured and operate in the context of an MVRF. In fact, PIM-SM is favored by most SPs today for the core.

The MVRF contains the multicast routing information only for the VRFs that comprise a multicast domain. Figure 10-5 depicts the PIM adjacency relationships for the deployment of MVPN.

Figure 10-5. Multicast: PIM Instances and Adjacencies


For reverse path forwarding (RPF) considerations, no unicast routing protocol runs over the MDT; therefore, RPF checks need to use other means. For example, the RPF neighbor is determined by checking the BGP next-hop (PE) address to the customer source and the PIM adjacency with the next-hop customer (C) addresses is conveyed by the VPNv4 BGP updates between PEs. For the RPF interface check to succeed, a packet must come in over the RPF interface to the source. One of two scenarios is possible:

  • RPF interface is in the VRF and is no different from classical RPF interface behavior.

  • The RPF interface is the MD tunnel; that is, the RPF interface check for packets is received over the tunnel interface.

When the PE router receives an MDT packet, it performs an RPF check. During the transmission of the packet through the provider network, the normal RPF rules apply. However, at the remote's PE, the router needs to ensure that the originating PE router was the correct one for that CE. It does this by checking the BGP next-hop address of the customer's packet's source address. This next-hop address should be the source address of the MDT packet. The PE also checks that a PIM neighborship with the remote PE exists. A unique group address is required to be used as the MDT for each customer. A unique source address for the multicast packet in the provider network is also required. This source address is recommended to be the address of the loopback interface, which is used as the source for the IBGP, because this address is used for the RPF check at the remote PE.

If the provider uses MDT-data groups, these also need to be configured. These MDT-data groups must be unique for each customer.

The PE routers must have a PIM adjacency to each other. No other routing protocols can use these MTIs. PE routers are the only routers that need to be MVPN-aware and able to signal information to remote PEs regarding the MVPN. It is therefore fundamental that all PE routers have a BGP relationship with each other or directly or via a route reflector.

The source address of the default-MDT is the same address used to source the IBGP sessions with the remote PE routers that belong to the same VPN and MVRF. When PIM-SSM is used for transport inside the provider core, the PEs indicate that they are MVPN-capable and provide for source discovery via this BGP relationship. This capability is indicated by the updated BGP message.

When a PE receives a BGP update, which includes the RD and group information, it joins the root of that tree, thereby joining the MDT.

The RPF check on the PE is satisfied when the following conditions are met:

  • The next hop for the source of the CE data is the BGP neighbor, which is the source of the MDT.

  • The source of the MDT is a PIM neighbor.

In summary, while preserving state inside the core network, no upgrade of the core routers is necessarythus facilitating the deployment of MVPN. However, multicast does need to be deployed in the core. You need to remember that the customer's IP multicast network has no relationship to the provider's multicast network. From the perspective of the provider, the customer's IP multicast packets are merely data to the provider's distinct IP multicast network.




MPLS and Next-Generation Networks(c) Foundations for NGN and Enterprise Virtualization
MPLS and Next-Generation Networks: Foundations for NGN and Enterprise Virtualization
ISBN: 1587201208
EAN: 2147483647
Year: 2006
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net