Multicast Deployment Models

This section describes the multicast deployment and operation models available to the enterprisethe Any Source Multicast (ASM) solution and the SSM service.

Any-Source Multicast

The ASM solution is the most commonly deployed model for the IP Multicast infrastructure. The Acme case study predominantly uses this model, too. The Acme IPTV application uses it to deliver live content. A user's workstation sends a request (via the IPTV viewer software) to become a member of a specific multicast group address, which is learned from the scheduled programs listed in a content manager. The DR builds the shared tree toward the RP in an effort to pull content from the source server.

Meanwhile, the source server sends content to the DR on its local subnet, which is forwarded to the RP. The RP then sends the multicast traffic from the source server down the shared tree toward the user's workstation. As soon as the DR receives the content, it can determine the server's source IP address. These multicast packets arriving at the receiver's DR prompt the DR to cut over from the shared tree to the SPT. The DR can build an SPT toward the source now because it has the source server's IP address. As soon as this SPT is complete, content flows from the source server to the receivers. Figure 6-5 provides an overview of the global multicast domains employed by Acme.

Figure 6-5. Global Deployment Model for Acme, Inc.

Source-Specific Multicast

SSM is a technology step that enhances the existing ASM routing solution. ASM will continue to be offered and supported while, in most cases, the transition to SSM support continues. This approach ensures support for all current applications and for new applications developed to take advantage of SSM. It is important to remember that the final goal of SSM is the same as the ASM model: to build a shortest-path distribution tree for content to flow from the source server to the receivers. To achieve this goal, the SSM routing model primarily changes at the edge of the network. The RP in the network is no longer responsible for tracking active sources; therefore, shared trees are not required, and sources don't have to register with the RP. The receiving workstation is now responsible for sending a request to the network to receive multicast traffic with a certain group address from a specific source server's IP address. This simplifies how SSM routing functions within the core of the enterprise network. In the SSM model, the IGMP membership reports sent by workstations contain specific details of the multicast group address and source server's IP address. Three host-signaling methods are IGMP v3, IGMP v3lite, and URL Rendezvous Directory (URD):

• IGMP v3The SSM model requires workstations to use IGMP v3 because it lets workstations send membership reports with the group address and the source server's IP address. A host can signal that it wants to receive traffic from all sources sending to a group except some specific sources (called Exclude mode), or it can signal that it wants to receive traffic from only some specific sources sending to the group (called Include mode). IGMP v3 has challenges involving host stack support, which are detailed next. For more details, refer to http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a008008702e.html.

• IGMP v3lite is a Cisco-developed transitional solution for application developers to immediately start programming SSM applications. It lets you write and run SSM applications on hosts that do not yet support IGMP v3 in their operating system kernel. Applications such as IPTV viewer 3.4 are compiled with the Host Side IGMP Library (HSIL) for IGMP v3lite. IGMP v3lite works by sending an IGMP v2 membership report and a UDP packet to port 465, which is sent to the all-multicast router IGMP 224.0.0.2 address. This interim solution requires receiver first-hop routers, workstations, and applications to support IGMP v3lite. Only Microsoft Windows 2000 workstations can leverage IGMP v3lite. Microsoft Windows XP supports IGMPv3.

• URD is a Cisco-developed transitional solution that allows existing IP multicast receiver applications to be used with SSM without the need to modify the application and change or add any software on the receiver host running the application. URD operates by passing a special URL from the web browser to the receiver's first-hop router. This URD intercept URL is encoded with the (S,G) channel subscription and has a format that allows the receiver's first-hop router to easily intercept it. As soon as the receiver's first-hop router knows about the (S,G) channel, it uses this to send an (S,G) join toward the source.

Using IGMP v3 or IGMP v3lite tells the receiver's first-hop routers about both the group address and the source server's IP address. Because the DR obtains the group and source server's IP address from the IGMP membership report, the DR does not need to build an SPT toward the RP. Instead, the DR immediately starts building an SPT toward the source server. The source server's first-hop router, which should be the DR router for the source server, does not register sources with the RP that fall within the SSM group address rangeagain eliminating the need for an RP.

You should pay attention to the implementation of IGMP in the enterprise. You must review the infrastructure's ability to support SSM, because IGMP v3 is required. For example, if IGMP v2 is deployed in the network, three main areas need to be addressed to ensure support for IGMP v3 and IGMP v3lite so that the SSM routing service can be used. The three main areas are explained in the following section.

Enabling SSM

As a starting point, you should review the IOS and any CatOS versions that are used. The following network components require consideration for SSM:

• Receiver's Layer 2 switches The switches need to support IGMP v3. IGMP v3lite is not a concern because it uses IGMP v2 host signaling.

• Receiver's first-hop router These routers need to support the interface level host-signaling protocols IGMP v3 and IGMP v3lite. The router must also support SSM.

• Transit routers Transit routers are all other multicast-enabled routers within the global infrastructure network. All routers require support for SSM, but only the source server's first-hop router and the RP must have an IOS that supports SSM. None of the remaining transit routers require an IOS that supports SSM because the functionality of SSM within the core of an enterprise network is the same as with the ASM model.

The second important area is to consider host stack support available for all operating systems used within the Acme global enterprise network. If the workstations in the LAN will use IGMP v3, such as Microsoft Windows XP or Linux, special consideration is required on the receiver's first-hop router and switch (as detailed in the previous section) to avoid flooding multicast traffic. Acme's current global desktop operating standard on laptops is Windows 2000, which does not support IGMP v3; therefore, IGMP v3lite must be used. Linux has multiple host stacks that support IGMP v3. Sun currently does not support IGMP v3. Table 6-1 lists operating system support for IGMP.

Table 6-1. Operating System Support for IGMP

Operating System	ASM (IGMP v2)	SSM (IGMP v3lite)	SSM (IGMP v3)
Windows 2000	Yes	Yes (requires IPTV 3.4)	No support
Windows XP	Yes	Not required	Yes
Linux	Yes	No	Yes
Solaris	Yes	No	No support in version 8 or 9

In the third SSM area for consideration, a number of different workstation and server applications need to be considered when it comes to supporting an SSM environment. Table 6-2 shows the workstation and server application releases required to specifically support IGMP v3.

Table 6-2. Viewer Support for IGMP

Application	ASM (IGMP v2)	SSM (IGMP v3lite)	SSM (IGMP v3)
IPTV Viewer	3.1, 3.2, and 3.4	3.4	3.4
IPTV Content Manager	3.2 and 3.4	3.4 (bug)	3.4
IPTV Server	3.2 and 3.4	3.4	3.4
Real Server	Yes	No	Yes
Real Player	3.1, 3.2, and 3.4	No	No