CS625: Advanced Computer Networks
Lecture # 18: Multicast Routing
Date: 16 Sep 2003
Scribe by: Lalit Kant Roul (Y0174)

Lecture outline:  
  1. Multicasting semantics and Performance criteria
  2. Multicasting in LAN and Extended LAN
  3. Multi cast in DV-routed network
  4. Reverse Path Flooding
  5. Reverse Path Broadcast and Truncated Reverse Path Broadcasting
  6. Reverse Path Multicast
  7. Multicast in Link state routed network
  8. Hierarchical Multicast

What is multicast:

Multicasting refers to the sending an IP datagram to a set of hosts that form a single multicast group. It is possible for members of the group to be spread across separate physical networks. An efficient multicast facility provides packet delivery to groups of hosts at a lower network and host overhead than broadcasting to all hosts or unicasting to each host in a group.

Multicasting semantics

  1. Group ID: Each multicast group has a unique multicast (class D) address.

  2. Delivery semantics: IP multicasting uses the same best-effort delivery semantics as other IP datagram delivery, meaning that multicast datagrams can be lost , delayed, duplicated, or delivered out of order.

  3. Group semantics: The group semantics are that

    • sender does not receiver set,

    • any receiver can belong to any number of groups,

    • membership in an multicast group is dynamic- any member can join and leave at any time and independently

    • membership in a group determines whether the host will receive datagrams sent to the multicast group; a host may send datagrams to a multicast group without being a member

Performance Criteria

Some of the performance criteria with multicasting of IP datagrams are
  1. Efficient data delivery: There are two criteria for achieving efficient  delivery of data packets are minimising  bandwidth usage and minimising packet delay. However, there is a tradeoff between these two criteria. If we consider the network below:


    Figure 1: Trade-off between minimising bandwidth and packet delay

    If S wants to send data packets to R1 and R2, then there may be a minimum delay path from

    S -> a-> c->R2. But to utilise the bandwidth to the max, the route considered will be s->a->b->d->R1/R2.


  2. Reduce control overhead: there are two issues regarding this. One is to reduce bandwidth and other is to reduce the state at maintained at routers

  3. Minimise join latency: there should be much latency involved for a node to join or leave a group though joining is more important

Multicast in LAN and extended LAN

Multicast is well supported by local area networks such as Ethernet that provide efficient broadcast delivery and a large space of multicast addresses. However, multicast as a general facility across large extended LANs and inter-
networks raises a number of concerns. First, networks and internetworks that are not based on a broadcast facility require extensions to their routing to provide efficient multi-destination delivery. Second, multicasting in extended LANs and internetworks imposes additional routing and traffic costs that may limit the scalability of the multicast service or of the networks that support multicast. The paper discusses about extensions to two common routing algorithms used by network-layer routers-distance-vector routing and link-state routing-to provide efficient routing for multicast across datagram-based internetworks.

Multicast in DV-networks

The issue in DV-networks is that no single tree will solve multicast issues and not suitable, as that helped in the bridged LAN case. The alternate is to have a tree per source. This can put lot of burden on the routers and hence can be modified to tree per group. Now consider following situation. If A wants to send data to C then as per this schema, the packet has to go through 2 hops through B hence tree per source is comparatively better.

Figure 2: DV-network multicast

In order to provide a better multicast strategy, the following steps are taken:

  1. Reverse Path Flooding

  2. Reverse Path Broadcasting

  3. Truncated Reverse Path Broadcasting

  4. Reverse Path Multicasting

Reverse Path Flooding

A router forwards a broadcast packet originating at source S if and only if it arrives via the shortest path from the router back to S . The router forwards the packet out on all incident links except the one on which the packet arrived. Whenever a source wants to send data packets, it floods all the nodes at the outgoing link except on the originating link. In this the data packets are sent onto a router if there is a reverse path of shortest distance from the next router to the source.

The problem with this method is duplication of packets. Consider the following scenario:

Figure 3: Duplication of packets due to multiple paths 

S wants to send data packets onto the link. This is possible through the two nodes A and B. Both A and B have a shortest path to S. So the packet is sent to both routers A and B which in turn duplicate packet on the link. So to avoid this we can consider only one packet from the source which come along the min cost path . In this case packet from B may be discarded. In case of a tie, we can select arbitrarily breaking the tie. This is principle of RPB. It may look as if we are sending packets on only a single link but the packets are sent to all the places in network. To implement the basic reverse path forwarding algorithm, a router must be able to identify the shortest path from the router back to any host which is available from routing tables.

Reverse Path Broadcast and Truncated Reverse Path Broadcasting

To eliminate the duplicate broadcast packets generated by the RPF algorithm, it is necessary for each router to identify child links in the shortest reverse path tree rooted at any given source S. Then, when a broadcast packet originating at S arrives via the shortest path back to S, the router can forward only to child links. The basic scheme is to identify parent router for any router so as to reach each of its source.

A better solution is Truncated Reverse Path Broadcasting where we try to truncate the tree so that we do not send data packets to the tree having no members. So we are going to prune away the leaf nodes (groups) for which the packet may not reach.

This is a two step process:

  1. Identify the leaves
  2. Detect the group membership

If we consider the following topology

Figure 4: Truncated Reverse Path Broadcasting

If we have every router periodically send a packet on each of its links, saying “ This link is my next hop to these destinations” then the parent routers of those links can tell whether or not the links are leaves for each possible destination. Then we can identify the leaves. Once we identify leaves, our next duty is to detect whether or not members of a given group exist on those leaves. To implement this , the hosts periodically report their memberships.
When a multicast packet with source address S and destination group G arrives from the next hop link for S, forward a copy of the packet on all child links for S, except leaf links that have no members of G. In above S is source wants to send data packets to a Group (say G1). The data packets are forwarded to r2, r1. Then to r2 and to leaves. But it can be seen that there is no need to send the packets to r2 as there is no member of the group under its hierarchy( as we are dealing with trees). No router uses the leaves to reach the source. In above we can say that r3 uses r2 to get to the source. So we can have groups propagating up the tree. So if we have no group members then we can truncate at the leaves.

Reverse Path Multicast

This is built on the top of TRPB which will try to prune up the tree. We will build tree for every active source. First we start with truncating reverse path routing. The basic emphasis is made on "non-membership" reports which will propagate up the tree. Whenever there are no members down the hierarchy of a router node (router), it sends non-membership report (NMR) to its predecessor. In the previous example, Z sends NMR to R1. So that the data packet addressed to the group is not sent to this node. When a node contains more than two successors (R3 above), then that node sends NMR only if it gets NMR from all its successors (similar to logical AND). So if R3 gets NMR from X and Y then it sends NMR to R2.

Overhead of number of NMR: The number of NMR states is proportional to (Sa*Ga). This implies that we are maintaining per source tree and per group information.

Cost: The cost of RPM is same as TRPB + cost of storing, forwarding and processing of NMR messages.

Limitation of RPM: NMR may be timed out. NMR refresh is done so as to track a new node(group) in the network. NMR messages should be positively acknowledged.

Multicast in link state routed network

One simple approach is to extend the link state to maintain about membership information. The link maintains group presence information. But, here only local membership reporting is necessary. The propagation through the network is done using flooding. From the link state information a router can compute the shortest path tree from any source. To minimise latency trees can be computed on demand, and only forwarding entry should be stored. The storage cost associated with the link state approach is in the order of the number of groups times the number of senders.

Hierarchical Multicast

Large multicast routing domains can be decomposed into multiple sub-domains, organised hierarchically, such that one sub-domain is treated as a single link in a higher level domain to scale the multicast service up to large internetworks. There can be two types of links - one is point to point. This kind of link may be extended from one router to another within sub domains. A link may be multi access if the multicasted packet reaches all the sub-domain routers connected to it. If this condition is satisfied then we can use the same protocol structure for hierarchical multicasting also. One typical architecture is shown below:

Figure 5: Hierarchical Multicasting



  1. [DC90] Stephen E. Deering and David R. Cheriton, "Multicast Routing in Datagram Internetworks and Extended LANs", ACM Transactions on Computer Systems, 8(2), May 1990, pp. 85-110. Available from the IITK Digital Library.