Broadcast routing is simple once a spanning tree connecting all of the nodes has been constructed: the simple uncontrolled flooding algorithm works optimally as long as it only uses edges of the spanning tree.
One way to construct a spanning tree of a network is to pick one node as the "center", and have all other nodes send join messages towards the center along the usual unicast paths. Each node and link traversed by the join messages is part of the spanning tree. Although guaranteed to find a spanning tree, this algorithm is not guaranteed to find the minimum spanning tree. However, it is still a useful building block for broadcast and multicast routing algorithms.
Multicast routing is the problem of allowing a message to be efficiently sent to an arbitrary subset of other nodes anywhere in the internet. Some possible applications: streaming video, multiplayer games, video conferencing.
Issues: (1) joining a multicast group and membership management, (2) multicast routing.
Multicast group membership is handled by the first-hop router. End systems that wish to join a multicast group use IGMP (Internet Group Management Protocol) to inform the router which groups they wish to join. The first hop router forwards datagrams destined for a multicast group to the larger network, where routers within the network use a multicast routing protocol to ensure that the datagrams reach all of the first hop routers that have end systems that are part of the destination multicast group.
IGMP message types:
IGMP is a soft state protocol: membership in a multicast group requires the end systems to respond to the membership-query messages sent by the router. Systems that don't respond (possibly because they have gone offline) are removed from the group.
A multicast address is allocated from a reserved block of IP addresses. There is no central assignment of multicast addresses; when forming a multicast group, end systems simply choose a multicast group at random and use it. Obviously this could cause problems if the address is already in use!
Once inside the network, datagrams whose destination is a multicast group must be delivered to all first hop routers that have end systems which belong to the multicast group specified by the destination address.
Group-shared tree: One approach is for the routers inside the network to form a single spanning tree for the multicast group. (Pick a center and use the spanning tree construction algorithm described above.)
Source-based tree: Another approach is to use a separate spanning tree for each sender in the multicast group. For many multicast applications, like streaming video, there is only a single sender, or a small number of senders. Constructing a single tree per-sender results in shorter paths from sender to recipient.
Rather than explicitly constructing the spanning tree for each sender, we can use reverse path forwarding to forward the multicast datagrams to their recipients. However, since the sender does not know precisely which last-hop routers have end systems that are part of the multicast group. This may result in the delivery of many unwanted datagrams to routers which do not have any end-systems in the mutlicast group on the path from the sender:
The diagram above shows part of a network in which multicast datagrams are sent to downstream routers which have no need to receive them (because no group members are attached to end-systems). The red arrows show where unwanted datagrams are sent. When a last-hop router receives an unwanted multicast datagram, it sends a prune message back towards the sender. When intermediate routers receive a prune message from all downstream routers, they can send a prune message upstream. Eventually the source-based tree will have only links to routers that have group members downstream.
All routers in an AS must use the same multicast routing algorithm. But, different autonomous systems use different multicast routing algorthms. Therefore, inter-AS multicast routing is a problem, and it is not generally possible to construct a multicast group with widely separated members.
It is worth mentioning that is is not necessary to implement multicast as a function of the network layer. An alternative is to construct an overlay network at the application layer.
The diagram shows a physical network (black lines) where the labeled nodes have formed an overlay network (blue lines). The links in the overlay network are simply connections (e.g., TCP) between peer applications. The overlay network is a tree, so uncontrolled flooding over the overlay links is sufficient to deliver messages to every member of the multicast group. Although some physical links carry multiple copies of the same message, the number of duplicated messages can be small, as long as the topology of the overlay network is a good match for the topology of the physical network. For example, in the example, no physical link carries more than 3 copies of a multicast message.