148

MULTICAST

10.2.3.4 PIM Prune Override

PIM-SM uses exactly the same process as PIM-DM for one downstream router on a multi-access network to override prunes sent by another downstream router on the same multi-access network.

10.2.3.5 Source-Specific Multicast (SSM)

SSM is a further development of multicast using PIM-SM. It changes the basis of multicast from the situation where an arbitrary number of sources will transmit to a group and a receiver will take multicast traffic from any source to the situation where the receiver specifies the source from which they will accept data for a particular group. A single (S, G) is known in SSM terminology as a channel.

In order for a host to indicate its desire to join a group with a specific source, that host and the attached PIM routers must support IGMPv3. When a source-specific join is received, the DR immediately creates a SPT directly to the source without joining a RPT first, so the need for a RP is removed.

SSM provides some added benefits with respect to scalability over and above those inherent with the behaviour of multicast. For example, the fact that a stream of data transmitted to one group from one source is completely distinct from a stream of data transmitted to the same group from a different source means that the problems associated with global group allocation are totally alleviated. Now, group addresses have only to be unique with respect to a single source. Because the range 232.0.0.0/8 has been allocated by IANA for use with SSM, it effectively means that each source could transmit streams to 224 groups!

SSM also improves the control of content on a particular channel. Because only one source can transmit onto one channel, it is possible to effectively filter any possible spurious data being injected into a channel.

Finally, the removal of the requirement for an RP means protocol extensions like autoRP and the bootstrap protocol become unnecessary. Also, if there are no RPs, then there is no need for MSDP. Interdomain multicast is simply a case of connecting your PIM-SM domain to that of your neighbours.

10.2.4MULTICAST SOURCE DISCOVERY PROTOCOL (MSDP)

One major scaling issue with multicast is how to exchange multicast group information between multicast domains. One way would be to share RPs, but this has severe limitations with respect to scaling and also requires a significant amount of trust on the part of those who have no direct control over the operation of the RP. This is not a realistic solution for service providers in today’s market. Therefore, an alternative is required. The alternative protocol, which was originally designed as a stopgap until a proper multicast BGP became available, is MSDP.

10.2 MULTICAST ROUTING

149

MSDP exchanges information about active multicast groups and the sources of those groups between independent RPs in one or more multicast domains. Each MSDP router peers directly with other RPs. The RPs send each other messages containing details of groups and the associated active sources.

In order for a host in one domain to join a group that has a source in another domain, the host sends the normal IGMP message, which is translated to a PIM-SM join to the local RP. The local RP then joins the SPT direct to the source in the other domain.

10.2.5MULTIPROTOCOL BGP

As discussed. BGP provides the means to carry NLRI other than that for unicast IPv4 (for which it was originally designed). MBGP can carry multicast RPF information between ASs. MBGP does not carry group information. It is particularly useful when multicast information is being shared between ASs using MSDP between RPs.

10.2.6MULTICAST SCOPING

Multicast scoping is required to ensure that multicast traffic can be constrained within a particular boundary. This is sometimes desirable because some traffic distributed over multicast has a constrained validity or may be of a nature which makes global visibility undesirable (e.g. commercially sensitive material or material for which a fee must be paid to gain access).

Two main mechanisms exist for scoping multicast:

1.TTL;

2.Administrative scoping.

Setting the TTL is a crude mechanism that can be used to create administrative boundaries by ensuring that packets pass no further than a certain number of hops from the source. It is notoriously difficult to use this mechanism to provide accurate, reliable, and consistent scoping of multicast packets. For example, the behaviour in the stable state might be dramatically changed in the presence of failures.

An example of the limitations of scoping based on TTL can be seen in this example. When using PIM-DM, scoping using TTL has some potentially severe side effects on the equipment at the administrative boundary. While in the lab, I came across this problem and spent quite some time working through the variety of symptoms. The network was as shown in Figure 10.2.

The video sources at the bottom of Figure 10.2 were transmitting multicast streams at 20 Mbps with the TTL set to 4. As you can see, packets sent from a CODEC attached to R3 reach the R4 with TTL = 1 so R4 would decrement the TTL and it would expire. On some routers, all packets of this type must be sent to the CPU for processing rather than

150

MULTICAST

R1

OSPF

&

PIM-DM

R3

Analog

Video

IP

Video

CODECs

IGMP

Reports

R2

R4

IP Multicast

traffic

IP

Video

CODECs

Analog

Video

Figure 10.2 Example of the limitations of TTL-based multicast scoping

being switched in hardware. So, we had a stream of data arriving at 20 Mbps with all packets having an expired TTL. This sent the CPU of the devices to between 25 and 40% with just one video source. Worse, because the packets were arriving with TTL = 1 and were expiring on the router, they were not being processed by PIM so no prune was ever sent to R2 and the stream just kept on flowing. We did not actually spot the increased CPU until we had added many streams, all with a TTL of 4. The effect of all those streams, which were never pruned, was that the CPU of the DR became totally overwhelmed by the processing load of responding to all the TTL expired packets. The IGP neighbours and PIM neighbours could no longer be maintained and all the adjacencies were lost. This caused the CPU load to reduce, and as the IGP and PIM adjacencies recovered, the flows started again and the CPU load started to rise again. This cycle continued until the source of multicast packets was removed.

10.2 MULTICAST ROUTING

151

This issue could not be attributed to any single element in the network. The TTL of 4 on the IP video CODECs was not actually in place for the purpose of administrative scoping but was the default, the architecture of the routers R3 and R4 was such that they were particularly vulnerable to this problem and the fact that the packets were (correctly) not being processed by PIM exacerbated the problem by failing to prune the link so the flows never stopped. The fact that the flows were each running at 20 Mbps also exacerbated the problem because this equates to roughly 82,000 packets per second (256-byte packets), each of which must be sent to the CPU and generate an ICMP TTL Expired response.

In order to overcome the limitations of the TTL-based mechanism described above, it is possible to administratively scope a multicast network. A particular range of groups has been specifically defined for this purpose. The range is 239.0.0.0 to 239.255.255.255. Within that range, two subranges have been defined:

1.239.255.0.0 to 239.255.255.255 is reserved for IPv4 site local scope. The definition of ‘site local’ in this sense is actually somewhat nebulous but traffic to these groups may not cross any administrative boundary of any kind.

2.239.192.0.0 to 239.251.255.255 is reserved for IPv4 organization local scope. This range is available for organizations to allocate groups for private use. Routing information and traffic for these groups must never cross the boundary of an autonomous system.

The rest of the range, from 239.0.0.0 to 239.191.255.255 and from 239.252.0.0 to 239.254.255.255, is currently not allocated for any particular purpose but is reserved for expansion of the above two classes, each expanding downwards. These ranges should not be used until the existing scoped addresses have been exhausted.

In addition to 239.0.0.0/8, the range 224.0.0.0/24 has been allocated for well-known link local groups and 224.0.1.0/24 for well-known global scope groups. A number of other groups have been allocated specifically as global scope well known groups.

In addition to the definition of administratively scoped groups, it is necessary to define the boundaries of your network. This is achieved simply by identifying a port and the groups, which may not be forwarded via that port in either direction. That port represents the boundary.