14.4 Multicast Routing

Networks of all types are constructed of myriad subnets provided connectivity by routers at Layer 3. The importance of knowing who you are (source IP address) and where you are going (destination IP address) is how IP unicast routing operates. This is a rather simplistic way of explaining how IP routing works; however, that is okay for purposes of comparing and explaining how multicast routing works. The IP routing procedure is relatively straightforward, but the fundamental point to keep in mind is the binding of a single address to a single host.

Multicast routing, however, is a bit more complex than IP routing because a multicast address identifies a multicast group instead of a physical destination. An individual host is able to join a multicast group by using IGMP to communicate the join message to its LAN router. Because the number of receivers for a multicast session can be quite large, the source of the multicast transmission does not need to know all the relevant destination addresses of the hosts that have elected to receive (i.e., join) the multicast session. The routers only need to know that on a given LAN, there is at least one host interested in this multicast group. The basic principal involved in multicast routing is that routers interact with each other to exchange information about neighboring multicast routers.

To avoid duplication of effort, a single router is selected (via IGMP) as the DR for each physical network. The DR constructs a tree from the source that connects each IGMP interface (port) reporting group members to the multicast group. This tree stretches throughout your WAN and is also referred to as the spanning tree, distribution tree, and source tree.

The tree employs technology to ensure that it is loop-free in nature. Figure 14-10 shows a tree that has no loops and also compares a normal IP routing structure based on subnets (left) and a multicast distribution tree (right).

Figure 14-10. Comparisons of IP Subnet Structure for Routing and a Multicast Distribution Tree

As you can see in the figure, the multicast distribution tree (right) is built with a single active multicast path to each router that has interfaces (connected to each router) that need to receive the multicast event. There can be one or more hosts that are part of the multicast group on the networks connected to these interfaces. Multicast messages are replicated only at those points where the tree branches, thus minimizing the number of copies of the messages that are transmitted through the network. Multicast-enabled applications send one copy of each packet using a multicast address, and the network routers forward the packets to only those LANs that have receivers.

As already discussed, hosts can join or leave multicast groups at anytime . This ability requires that the multicast tree have the ability to be dynamically updated to reflect these changes. Imagine if the router was forwarding the multicast information to a LAN where only one host was designated to receive it and that host left the tree. This could have a serious effect on the tree. Thus, the tree is designed to be dynamically updatable by pruning (removing) branches that no longer need the multicast data.

Branches with no listeners are discarded (pruned). The type of distribution tree used and the way multicast routers interact depend on the objectives of the routing protocol. For example, the multicast routing protocols have different philosophies with regard to receiver distribution, number of sources, reliability of data delivery, speed of network convergence, shared path versus source path, and, if shared path, the direction of data flow. We could devote many pages to discussing these concepts and comparing them. However, to do so is really beyond the scope of this book. For additional information, refer to the bibliography for more resources.

14.4.1 Shared and Source Trees

There are two different types of multicast trees possible: shared and source. Each type of tree, as you will see, has various benefits and risks as well. The type of tree used is determined by the multicast routing protocol being used in the network.

When the multicast routing protocol creates a shared distribution tree, the route to and from a source of a multicast broadcast can be shared and accessed by all sources over a topology that is either one-way or bidirectional. This has the added benefit of using less memory because a router will be the root of multiple multicast flows, thus aggregating them at one central point. However, the most important issue is that you may get suboptimal paths from the multicast event source(s) to all receivers, and shared trees may introduce extra delay in your network. Notice in Figure 14-11 that the shared root router D has induced an additional two hops from source 1.

Figure 14-11. Shared Distribution Tree

A multicast routing protocol creates a source distribution tree as a separate tree for each source via a single path through the network. The routers use a greater amount of memory as multiple paths are created, but you get more optimal paths from source to all receivers and delay is minimized. An example of a source-based distribution tree is shown in Figure 14-12. You can see the tree is developed completely from the multicast source.

Figure 14-12. Source Distribution Tree

14.4.2 Dense- and Sparse-Mode Routing Techniques

As described earlier, IP multicast traffic is generated by a source and is transmitted to a group of receivers. The path to each group is calculated via the creation of a tree. There are two types of trees, shared and source, to distribute multicast traffic.

Multicast routing algorithms and protocols follow one of two basic approaches to route: dense mode or sparse mode. The selection of the appropriate approach to use is based on the distribution of the multicast group members across the network. Members are either densely or sparsely distributed, and this forms the basis of each type.

A dense-mode approach is based on the assumption that multicast group members are densely distributed across the network and that available bandwidth is plentiful. Multicast routing protocols that rely on this mode will use periodic flooding to set up and maintain their distribution trees. Examples of protocols that use dense mode are DVMRP, MOSPF, and Protocol-Independent Multicast ”Dense Mode (PIM-DM).

A sparse-mode approach is based on the assumption that multicast group members are sparsely distributed across the network and that available bandwidth is not plentiful. Sparse mode addresses concerns opposite to those addressed by dense mode and is typically used when multicasting across multiple routing domains, including Internet scenarios. An important design and use point is that sparse mode does not imply that a group has few members, just that they are widely dispersed. This means that sparse mode will not use flooding to accomplish the creation of its distribution tree; instead, it will use more selective techniques, which we will discuss in that protocol-specific section. Sparse-mode routing protocols include Core-Based Trees (CBT) and Protocol-Independent Multicast ”Sparse Mode (PIM-SM). PIM-SM is the most common multicast technology used on the Internet today.

In conclusion, if you are trying to decide which PIM mode to use and when, many networks with a lot of multicast users on a LAN should use PIM-DM. Enterprise networks with heavy multicast transmission needs. Service providers should use PIM-SM.

14.4.2.1 Routing with JUNOS and Multicast

A separate routing table, known as a RIB, is needed for DVMRP to operate correctly. The IP unicast routing table is needed as DVMRP relies on the presence of routes in the inet.0 routing table to function properly.

Because we are going to enter into the realm of RIBs again, let's take a moment to review what they are and what their function is. We first introduced RIBs when discussing BGP; however, they are used in multicasting as well. Table 14-4 lists the various predefined routing tables in JUNOS and their use.

Table 14-4. JUNOS Routing Tables

Table	Function
inet.0	Default unicast routing table
instance- name .inet.0	Unicast routing table for a given routing instance
inet.1	Multicast forwarding cache
inet.2	Unicast routes used for multicast RPF lookup
inet.3	MPLS routing table for path information
mpls.0	MPLS routing table for LSP next -hops

When using multicast function in JUNOS, you cannot transfer routing information from one family type to another. Unicast routes cannot be placed in the multicast table, and multicast routes cannot be placed in the unicast table. To work around this, JUNOS uses the rib-group statement, which will allow JUNOS to install unicast or multicast route information in the rib-group .

Thus, the rib-group is where JUNOS will place the unicast and multicast routes once the group is defined. We will look at how this configuration is done as part of configuring each multicast protocol. Two other aspects of rib-groups important to configuring them are the export-rib and import-rib statements, which allow the placing of routing information into and out of the rib-group . This allows us to exercise some granular control, which also will be demonstrated later. A brief example will suffice for now. In this example, we will use the inet.2 RIB to hold the multicast routing information. The use of inet.2 for this purpose is recommended in the Juniper Networks documentation and is shown in Table 14-4 above.

 routing-options {       rib-groups {           multicast-rib {                export-rib inet.2;                import-rib inet.2;           }      } } 

As the above example shows, we can create a rib-group to hold our multicast routes, and once that occurs, the group can then be used by a multicast protocol.