Advantages and Disadvantages of SSM

As we have seen thus far, the greatest benefit of SSM is simplicity. In SSM, there is no need for an RP. Thus the difficult decisions regarding BSR versus auto-RP versus static, anycast, and RP placement are not necessary to support SSM. Furthermore, eliminating the need for MSDP has brought about unanimous acclaim throughout the multicast community. Besides eliminating the need for a complex protocol, there has been widespread concern regarding MSDP's ability to scale to millions of sources.

Simplifying the mechanisms needed to deliver multicast leads to a dramatic reduction in operational costs. Engineers who manage an SSM deployment do not have to learn nearly as many features and operations as they must for an ASM implementation. Further, SSM contains fewer "moving parts." Fewer mechanisms mean fewer bugs. Thus SSM should provide more reliable service than ASM.

A number of additional benefits in SSM provide "icing on the cake." First, SSM solves the problem of multicast address allocation, which had long been a headache for the multicast community. In ASM, multicast groups take on global significance. An ASM receiver of 224.1.1.1 would receive the traffic sent by both 10.1.1.1 and 10.2.2.2 if they were both sending packets to this group. Thus ASM requires global coordination in allocating multicast addresses. The recent addition of GLOP to the schemes of SAP/SDP and scoping has enabled the multicast community to consider IPv4 ASM multicast allocation "good enough for now."

The most common case where current ASM address allocation schemes are inadequate occurs when a content provider requires more static group addresses than GLOP can provide. For example, an organization that has reserved only one AS number can derive only a /24 of static multicast addresses using GLOP. If that organization needs 300 static group addresses, only two options exist: Obtain another AS number (which is definitely not the reason AS numbers are assigned), or ask some other AS-possessing organization for the ability to use its GLOP-derived addresses.

In SSM, by contrast, multicast group addresses are no longer globally significant. The source-group tuple provides the uniqueness needed to differentiate between SSM channels. The SSM channel (10.1.1.1,232.1.1.1) is completely different from (10.2.2.2,232.1.1.1) because the sources are different. An SSM subscriber to the

(10.1.1.1,232.1.1.1) channel would not receive packets for the (10.2.2.2,232.1.1.1) channel unless it explicitly subscribed to it as well.

In SSM, the group address provides only the uniqueness to differentiate different multicast streams from the same source. So if every SSM source in the world were transmitting only a single channel, all of them could theoretically use the same group address. In fact, it may seem like overkill to reserve an entire /8 of addresses for SSM when so few are actually needed. However, recall that every multicast MAC address corresponds to 32 different multicast IP addresses. This oversubscription generally has not caused many problems because the chance of two different multicast groups corresponding to the same MAC address appearing on the same LAN is relatively slim. If SSM sources all selected the same group address, the chance of MAC address collision on LANs would greatly increase.

For this reason, it is recommended that SSM sources randomly select from the more than 16.7 million group addresses available in the 232/8 range.

Another major beneficial side effect of SSM is in the area of access control. ASM group members receive traffic from all sources, including the bad ones. A malicious source can easily launch a denial-of-service (DoS) attack on an ASM group by transmitting large amounts of unwanted traffic to that group. This unwanted traffic can fill up the bandwidth of the links connecting to group members and flood members with packets they must process to discard.

ASM's inherent susceptibility to this kind of DoS is not at all a flaw but rather a "feature" that was built in to this model by design. Nevertheless, content providers with one-to-many content have always been wary of this "feature."

The guaranteed single-source nature of SSM is a perfect fit for content such as radio and television, where suppression of all other sources is highly desired.

To launch this same type of DoS attack in SSM, a malicious source must spoof the source address of the SSM channel. Moreover, the spoofing source must be on the same path as the real source. Otherwise, the RPF checks performed in each router will determine that the malicious traffic is received on an interface that is not the RPF interface of the real source. As we learned earlier, multicast traffic that is received by a router on an interface other than the RPF interface is always discarded. Thus this type of DoS attack is not impossible, but it is far more difficult to launch in SSM.

After learning of all the wonders of SSM, the usual response is "Sounds too good to be true! What's the catch?" The short answer is that there really is no catch. The long answer involves state, availability, and source discovery.

Recall from Chapter 3 that the SPT always takes the most efficient path but creates more state than the RPT.

However, because the predominant implementations of PIM-SM switch from the RPT to the SPT immediately, this SPT state is created anyway. In fact, SSM creates slightly less state in this case because the RPT is never joined in the first place, so no (*,G) state is ever created.

The second caveat to consider with SSM is availability. SSM receivers must support IGMPv3 and have SSM-aware applications. The availability of SSM applications should not be much of a concern. Application developers usually make modifications very quickly when it means that their products will become more powerful and prevalent.

Support of IGMPv3 is a function of the operating system. Without kernel modifications, all Windows operating systems earlier than Windows XP do not support IGMPv3. It may take some time before the majority of hosts on the Internet are enabled for IGMPv3.

Finally, it is important to remember that SSM is really providing only a subset of ASM functionality. While this subset supports the majority of applications believed to be most viable in the near future, plenty of useful applications still rely on many-to-many communication.

Because SDR relies on the ASM SAP mechanism, it cannot function in its current form in an SSM-only environment.

Likewise, videoconference and online gaming applications that rely on many-to-many mechanisms must be redesigned to use many one-to-many connections to operate in SSM. This change of paradigm should not be too difficult to achieve because the application layer affords the most amount of flexibility to accomplish the task of source discovery.

This document is created with the unregistered version of CHM2PDF Pilot