Multicast Architectures

In contrast to my original intention, I have decided not to just offer some hints about multicast architecture, but also to offer a quick qualitative introduction to UNIX multicast issues, routing, MBONE tunneling, and multicast-monitoring and -debugging techniques. I hope this provides just enough of a teaser to put things into perspective and to encourage you to play with intradomain multicast issues and eventually create enough interest that you seek out additional interdomain details. Three example applications are used to demonstrate multicasting:

• nte (a network text editor)

• ntpd (Network Time Protocol) in multicast mode

• mtest (send and receive)

Multicast Deployments

Multicast is one-to-many (1:n) or many-to-many (n:m) source-to-sink data delivery for multicast applications over multicast-enabled transport networks and data link layers. The most obvious reason for multicast deployments is bandwidth and server resource conservation with regard to efficient content distribution. That can be summarized as efficient and scalable multicasting, instead of costly unicast services, by simultaneously delivering a single stream of information to thousands of subscribers or recipients.

This potential is especially interesting as an additional mechanism in modern converged networks with regard to videoconferencing, video on demand, Internet audio, interactive gaming, multimedia events, e-learning software distribution, newscasts, and content delivery. Converged networks transport voice, video, data, and storage traffic over multipurpose IP networks. This variety of applications spans multimedia and data-only uses with or without real-time (latency, jitter) and high-availability requirements. The following discussion separates multicasting into data link layer, network layer, and application layer multicasting. Because of its intrinsically connectionless mode of operation, multicast uses User Datagram Protocol (UDP) as its transport protocol. Occasionally, raw IP sockets are used. These are exceptions to the common UDP rule.

Multicasting essentially can be seen from both intradomain and interdomain points of view, similar to intra-and interdomain traditional unicast routing. An in-depth discussion of multiprotocol (multicast) BGP used for interdomain signaling goes beyond the scope of this book. Note that we have to abandon a client/server perception when discussing multicasting and think instead in terms of content sources, transport networks, and sinks. Another important aspect is the distribution of multicast sinks (group subscribers), which can be either dense or sparse. Some algorithms have proven more suitable for the former, and some others for the latter. As a rule of thumb, dense distributions correlate with LANs or small campus networks, whereas metropolitan networks or the global Internet show a sparse distribution of multicast participants. The purpose of multicast signaling protocols is to build efficient multicast distribution trees for each multicast group of subscribers and not to burden routers and links with group traffic when no associated recipients exist. The process of adding and removing branches to this tree is referred to as grafting and pruning.

Multicasting is easy to configure, but its foundation is quite complex, especially the interface between intra and interdomain multicasting. Therefore, I recommend extensive research before deploying multicast architectures.

NOTE

Currently we face a "hen and egg" problem: Internet service providers (ISPs) complain about the lack of multicast applications to make multicast service offerings commercially feasible, and application developers counter with the lack of multicast-enabled autonomous systems and interdomain multicast deployments. However, one thing is certain: Conventional unicast streams cause a horrible waste of network and server resources.