Service Provider Multicast
Service provider multicast message transport falls into two categories: infrastructure multicast, used for delivering services, and customer multicast packet transport. Multicast that supports the provider infrastructure enables the provider to offer services to customers—such as multicast VPNs (MVPNs) (discussed in Chapter 3) and multitenant data center services (discussed earlier in this chapter and in Chapter 4). The provider infrastructure may also use multicast for content services. Internet multicast services is one example. In addition, many providers use multicast to deliver television content over their networks, where the set-top box is a multicast client, and channel content is delivered over specific groups.
Today, relatively few multicast applications are transported across the Internet natively. Most service providers have yet to embrace the benefits of transporting multicast, primarily due to the complexity and the ability to charge for multicast services. For SPs that have enabled and are using multicast, kudos to you! Chapters 1, 3, and 4 are very helpful for creating multicast-enabled provider infrastructure. In addition, there are a few design elements to consider when deploying multicast services in a provider network, as discussed in the following sections.
Service Provider PIM-Type Selection and RP Placement
The most important decisions that service providers have to make are similar to the decisions required for multitenant data centers: What mode of PIM needs to be selected, and where should RPs be placed? Chapter 3 discusses the numerous options that service providers use to transport multicast messages using MPLS, since using MPLS is currently the preferred method of moving both unicast and multicast messages across a shared service cloud. Remember that to deploy an MPLS service that supports multicast, the provider network needs a multicast-enabled core network that supports multicast data trees (MDTs).
The provider multicast domain that services the MDTs is completely isolated from any customer domains. This means the provider network needs to choose a PIM method (ASM or SSM) and, if necessary, configure RPs for the network. Service provider network architects should consider using SSM as the infrastructure delivery method. It greatly simplifies the multicast deployment at scale. SSM does not require an RP and has a separate and specific multicast range, 232.0.0.0/8, that is easy to scope and manage. Examine the network diagram in Figure 5-23. This network provides an MPLS MVPN service to the customer between Site 1 and Site 2. The customer is using PIM-SM and is providing its own RP on the customer premises equipment router at Site 1. The provider network is using SSM to transport the MDT for the customer VPN with route distinguisher (RD) 100:2.
)
Figure 5-23 SSM Provider Infrastructure Domain
Using SSM also simplifies scaling across global networks and eases the burden of converting merged autonomous systems from network acquisitions, as interdomain routing is a natural amenity of SSM. In addition, the same SSM domain can be used to provide content services within the infrastructure. Or, if needed, the SSM domain can coexist with a PIM-SM domain when required.
Remember that to implement SSM, any clients need to support IGMPv3. Cisco IOS-XR service provider software supports SSM delivery for MPLS MVPNs natively. The MVPN configuration requires a specific source and group for MDT. Simply use an SSM group range for MDT configurations and enable the transport interfaces with PIM-SM. Example 5-2 shows the relevant configuration of PE1 from Figure 5-23 to enable SSM and the MDT in IOS-XR.
Example 5-2 MDT SSM Configuration Using IOS-XR
RP/0/RP0/CPU0:PE1# configure RP/0/RP0/CPU0:PE1(config)# multicast-routing RP/0/RP0/CPU0:PE1(config-mcast-ipv4)# interface all enable RP/0/RP0/CPU0:PE1(config-mcast-ipv4)# mdt source Loopback 0 RP/0/RP0/CPU0:PE1(config-mcast-default-)# vrf Customer RP/0/RP0/CPU0:PE1(config-mcast-vrf_A-ipv4)# mdt default 232.10.1.1 RP/0/RP0/CPU0:PE1(config-mcast-vrf_A-ipv4)# mdt data 232.10.1.0/24 threshold 1200 RP/0/RP0/CPU0:PE1(config-mcast-ipv4)# exit RP/0/RP0/CPU0:PE1(config)# router igmp RP/0/RP0/CPU0:PE1(config-igmp)# version 3 RP/0/RP0/CPU0:PE1(config)# commit
For customers interested in these services, purchasing multicast transport from an SP is something of a premium service—that is, service providers usually charge an additional fee. If you are purchasing L2 VPN services that a service provider offers using Virtual Private LAN Service (VPLS), Provider Backbone Bridging combined with Ethernet VPN (PBB-EVPN), or a Pseudowire service, there is a better chance that multicast transport services are offered. The transport of multicast messages is often limited to a certain rate. If more bandwidth is required, you can overcome the limitation by purchasing additional bandwidth or encapsulating multicast messages using some sort of overlay technology, such as MVPN, GRE, and so on.
Service provider networks that want to also provide content services over the same infrastructure may not be able to choose SSM if the set-top box or other clients do not support IGMPv3. In such cases, PIM-SM is the preferred alternative for the provider infrastructure, and the provider network should either use static RP mappings or redundant Anycast RP for added reliability. Figure 5-24 shows the same provider network as Figure 5-23, but this time using PIM-SM.
)
Figure 5-24 PIM-SM Provider Domain
When a provider grows beyond the ability to support every customer in a single routed domain, BGP confederations or even multiple public domains are often used to carry traffic. Remember from Chapter 1 that using multiple IGP and BGP domains for unicast requires corresponding multicast domains, with interdomain routing, to complete multicast transport across the network. In such situations, providers should consider nesting RPs, using anycast for redundancy, and building a mesh of MSDP peerings between them. This completes the transport across the provider domain. Figure 5-25 shows a very high-level diagram of this type of provider multicast domain design.
)
Figure 5-25 Interdomain Infrastructure Transport
For networks that also provide multicast services to customers, there are other considerations. In particular, IP Television (IPTV) delivery requires some unique design elements, which are discussed next.
IPTV Delivery over Multicast
Figure 5-26 provides a 10,000-foot view of the components of multicast in the cable environment.
)
Figure 5-26 High-Level Cable TV Multicast Network
There are three main architectural components in an IPTV multicast delivery service:
Service plane: Consists of the IPTV source, IPTV multicast service gateway, and IP Multicast receiver
Service interface: Consists of the signaling mode between the service plane and the network plane
Network plane: Consists of IP network configuration to support multicast (control and data plane), resiliency, and high availability of the network transport
The network consists of a shared platform needed for all services, like QoS (DiffServ or RSVP based on applicability) or QoS-based Call Admission Control (CAC) systems for transport of multiple types of content. IP Multicast gateways consists of ad splicers, converters, and so on.
The choice of multicast transport protocols should determine the service plane communication needs of connected devices. Based on protocol requirements for the content providers, such as CAC, IGMPv3 or v2 support, and application redundancy, the multicast network technology selected for the transport layer should be able to support all required application services. The WAN technology generally consists of an MPLS L3 VPN or L2 VPN solution that connects to the end host access technology. Layer 2 Pseudowire could also be considered using a protected Pseudowire deployment. This provides subsecond convergence by leveraging features such as Fast Reroute (FRR) with RSVP-TE LSPs. It also provides the network operators service level agreement (SLA) guidelines for multicast transport. The items to consider in the design are as follows:
The need for global, national, or regional content sources
Fast convergence and availability
Requirements for different media content
Other factors to keep in mind during the design stage relate to the type of feed. The feed could be any or all of the following:
Broadcast feed: Including static forwarding to a DSLAM
Switched digital video: Static PIM tree to the PE-AGG router
Multicast based video: Dynamic path creation to the end receiver
These three types of video feed are illustrated in Figure 5-27.
)
Figure 5-27 Three Types of Video Feed
The service interface consideration in this section includes multicast signaling support with IGMPv3, applications built to SLA requirements, and applications built using CAC methods. The PIM-SSM model generally fits this design, with one-to-many communication building on any individual sources. This method is best suited to handling join/prune latency requirements. PIM-SSM will also help with the localization of services based on unicast IP addresses of different host servers using the same multicast group. Techniques using different masks for source IP addresses can be used for redundancy for the source of the multicast service. SSM multicast technology can be aligned with channel feeds, and source IP address spoofing is mitigated based on built-in application support for IGMPv3. The transport design also covers path separation across the WAN transport segment.
It is critical to understand multicast VLAN registration (MVR) and the features in the cable environments. MVR is designed for multicast applications deployed in Ethernet ring-based service provider networks. The broadcast of multiple television channels over a service provider network is one typical example. MVR allows a subscriber on a port to subscribe and unsubscribe to a multicast stream on the networkwide multicast VLAN, thereby enabling a single multicast VLAN to be shared in the network while subscribers (receivers) remain in separate VLANs. It also optimizes stream delivery by providing the ability to send continuous multicast streams in the multicast VLAN rather than send separate streams from the subscriber VLANs.
MVR assumes that subscriber ports subscribe and unsubscribe to these multicast streams by sending IGMPv2 join and leave messages on the VLAN. MVR uses IGMP snooping, but MVR and IGMP snooping can be enabled or disabled without impacting each other. The MVR feature only intercepts the IGMP join and leave messages from multicast groups configured under MVR. The MVR feature has the following functions:
Categorizes the multicast streams configured under the MVR feature and ties the associated IP Multicast group in the Layer 2 forwarding table
Modifies the Layer 2 forwarding table to include or exclude the receiver of the multicast stream (not constrained by VLAN boundaries)
The MVR has two port types:
Source: Configures a port that receives and sends multicast data as source ports. Subscribers cannot be directly connected to source ports; all source ports on a switch belong to the single multicast VLAN.
Receiver: Configures a port as a receiver port and only receives multicast data.