Multicast in an MPLS VPN Environment: Transparency
| A separate function is required to enable IP multicast over an MPLS VPN network, because MPLS has no native ability to support it. (However, it should be noted that native support is a work in progress and will be supported.) This is cause for concern, because the alternative to supporting multicast in such an environment is to employ generic routing encapsulation (GRE) tunneling to all sites connected to the VPN, which creates an O[n]2 (where n is a variable) issue because of the huge amount of complexity in scaling relationships of any-to-any tunnels for the scaling of the implementation for the enterprise. For example, ten sites requiring any-to-any connectivity would require 100 GRE tunnels to deliver multicast over GRE between sites. Now picture the challenges when connectivity is required for 100 sites. Ten thousand tunnels would be required! To get around this issue, multicast VPN (MVPN) was developed to enable the support of multicast in an MPLS environment, thus delivering the much-needed transparency and reduced complexity for the enterprise. The basic concept of MVPN is as follows:
To achieve this, customer traffic (C packets) is encapsulated at the service provider PE inside P packets. The encapsulated P packet is then forwarded to remote PE sites as native multicast inside the P network. During this process, the P network has no knowledge of the C network traffic. The PE is the router that participates in both networks. MVPN IP Multicast support for MPLS VPNs allows service providers to configure and support multicast traffic in an MPLS VPN environment. Because MPLS VPNs support only unicast traffic connectivity, deploying the MVPN feature in conjunction with MPLS VPNs allows service providers to offer both unicast and multicast connectivity to MPLS VPN customers. The MVPN feature supports routing and forwarding of multicast packets for each individual virtual routing/forwarding (VRF) instance. It also provides a mechanism to transport VPN multicast packets across the service provider backbone. The MVPN feature in Cisco IOS Software provides the ability to support the multicast feature over a Layer 3 VPN. As enterprises extend the reach of their multicast applications, service providers can accommodate these enterprise needs over their MPLS core network. IP multicast is used to stream video, voice, and data through an MPLS VPN network core efficiently. The MVPN solution allows Acme to transparently interconnect its private network across a service provider's network backbone. The use of an MVPN to interconnect an enterprise network in this way does not change how that enterprise network is administered, nor does it change general enterprise connectivity. The major benefits of deploying with a service provider that supports MVPN are as follows:
Multicast Routing Inside the VPNA PE router in an MVPN has multiple multicast routing tables, as well as multiple instances of PIM, IGMP, and MSDP. There is one global table and a table per multicast VRF (MVRF). Multicast domains are based on the principle of encapsulating multicast packets from a VPN to be routed in the core. Because multicast is used in the core network, PIM must be configured in the core. PIM-SM, PIM-SSM (source specific multicast), and bidir-PIM are all supported inside the provider core for MVPN. PIM-SM or PIM-SSM is the recommended PIM option in the provider core, because bidir-PIM is not yet supported by all platforms. PIM-SM, PIM-SSM, bidir-PIM, and PIM-DM are supported inside the MVPN. MVPN supports the concept of Multicast Distribution Trees (MDTs). An MDT is sourced by a PE router and has a multicast destination address. PE routers that have sites for the same MVPN all source to a default MDT and also join to receive traffic on it. The distinction between default MDTs and data MDTs is that a default MDT is a tree that is "always on." It transports PIM control traffic, dense-mode traffic, and RP tree (*,G) traffic. All PE routers configured with the same default MDT receive this traffic. On the other hand, data MDTs are trees that are created on demand. They are joined only by the PE routers that have interested receivers for the traffic. They can be created by a traffic rate threshold and/or source-group pair. Default MDTs must have the same group address for all VRFs that comprise an MVPN. Data MDTs may have the same group address if PIM-SSM is used. If PIM-SM is used, they must have a different group address, because providing the same one could cause the PE router to receive unwanted traffic. This is a PIM-SM protocol issue, not an implementation issue. Multicast domains (MDs) are the solution that Cisco Systems has adopted and integrated into Cisco IOS. An MD is essentially a set of VRFs that can send multicast traffic to each other. On the MVPN-enabled PE router, each MVRF has its own multicast routing table. Each PE router runs a number of instances of PIM-SM (as many as one per VRF) and, within each instance of PIM-SM, maintains a PIM adjacency with the CE router. The PE router also runs a "global" instance of PIM-SM, with which it forms adjacencies with each of its IGP neighbors, such as P (backbone SP) routers and/or other PE routers. Each MVRF is assigned to an MD, and each MVRF MD is configured with a multicast group address belonging to the service provider PIM-SM instance. However, note that this MD group address must be unique in the service provider PIM domain, and it can overlap with group addresses in use by VPN customers. Figure 6-6 provides an overview of this concept. Figure 6-6. MVRF MD Overview For a more detailed view of how to build MVPN for MPLS VPN environments, see MPLS and VPN Architectures, Volume II, Chapter 7, "Multicast VPN." Or you can find the information online at http://www.ciscopress.com/title/1587051125. |
EAN: 2147483647
Pages: 136