Multicasting is the ability of the network to efficiently deliver information to multiple recipients. An analogy here is with TV and radio broadcasting. The electro-magnetic spectrum (ether) is divided into frequencies which are allocated by some authority to TV and radio stations. These frequencies are then advertised in TV and Radio listings magazines and so forth. Users then tune in to these frequencies by turning a dial on their set. If they have a smart set (or a TV and VCR with separate tuners) they can receive multiple stations.
The multicast packet delivery model, illustrated in figure 1.2, is similar to broadcast, but superior. A multicast capable host computer (or host for short) on the Internet that runs an application which receives multicast simply joins a set of receivers on the net, identified by a group address.
How does an application choose a multicast address to use?
In the absence of any other information, we can bootstrap a multicast application by using well-known multicast addresses. Routing (unicast and multicast) and group membership protocols igmp can do just that. However, this is not the best way of manage applications of which there is more than one instance at any one time.
For these, we need a mechanism for allocating group addresses dynamically, and a directory service which can hold these allocations together with some key (session information for example - see later), so that users can look up the address associated with the application. The address allocation and directory functions should be distributed to scale well.
Address allocation schemes should avoid clashes, hence some kind of hash function suggests itself.
Furthermore, both the address allocation system and the directory service can take advantage of the baseline multicast mechanism by advertising sessions through multicast messages on a well-known address, and using this to inform other directory servers to remove clashes and inform applications of the allocation.
This is discussed in much more detail in chapter seven.
Group addresses are an extension of the Internet addressing scheme to provide dynamically assigned addresses for a set of interfaces with a single identifier. Some people argue that since it is not identifying a location, but is an key for looking up routing entries, it is really a name, not an address, but since it is taken from a new section of the same identifier space as normal Internet IP addresses, the word address has stuck!.
As a side effect of a host computer joining an IP multicast group, two things happen:
Groups are distinguished by having separate multicast addresses (just as unique hosts are distinguished by having unique unicast addresses). Multicast address assignment is generally dynamic (although some addresses are set aside for well known groups), and under the control of collections of the users. This is in contrast to frequency assignment in the electro-magnetic spectrum, where the bandwidth (in the sense of number of different possible frequencies) is a scarce resource compared with the number of multicast Internet addresses. In the radio and TV world, frequencies are assigned under global and national treaties and laws. In the Internet, there are some tools for multicast address management, which we will look at later.
A host computer does not have to be in a multicast group to be able to send to it. Anyone, anywhere, anytime (cue cocktail music) can send a packet to any group (in the time-honoured Internet style!). Hosts can take part in multiple multicast sessions. It is up to the receiving applications to take care of whether they can deal with multiple receptions - for example, if you receive audio from multiple audio sessions, do you want to mix them and then play them out (to the confusion of the user) or let the applications allow the user to choose? Of course, if you are receiving audio from multiple sources sending to the same session, the user probably does want to hear them (though maybe not!). If you receive multiple video sessions, do you want to display the video in multiple windows, or let the user choose one or more sessions. Of course, there are two separate questions here, one of network capacity, and the other of addressing. Since Internet addresses are used for each packet, there is no virtual circuit or long term association, it is possible to flood a receiver with traffic just by knowing their address, and having more capacity near a source than at the sink. With multicast, a receiver can ``pull down'' more traffic than they may be able to handle by joining multiple groups (or even single groups that are being sent to by faster sources than the receiver has upstream capacity for).
The routers in the Internet (the sorting offices or switching matrix glue that link everything together) that are capable of multicast use the location of groups or of senders to determine the delivery tree that is used to get packets from the source to the set of receivers. This tree is usually quite optimal in terms of the number of links that packets traverse. Packets are also not transmitted multiple times on the same link anywhere, they are only copied at appropriate points. Well look at styles of delivery trees a bit more later. For now, imagine sending a memo to a group of people, but only having to print one copy at source. Then as the memo arrives at various sorting offices, if there are any local recipients, the sorting office puts the memo in the copier and delivers it to those recipients, saving on shipping a huge bag of copies from the original sender to all the sorting offices, but at some cost of copying along the way instead.
This model of packet delivery has had a profound effect on the way that application programmers have learned to construct multicasting programs. The tasks of figuring out who is in a conference, whether they are ready to receive or not, whether a user has the right to speak or not and so forth are all moved to a completely separate level of the system because of this model. In other words, the multicast model is policy free in terms of call setup, floor control, membership control, activity and session information and so on. The separate functions of membership, activity and conference control are discussed in detail in chapter six.
This is in direct contrast to existing models of conferencing. For example, in audio telephony, the receiver(s) must have their phones on-hook. A particular caller must call them, each at a time, and add recipients to a conference call. Even if a phone bridge is used, the phone bridge needs to call each of the participants, and all of their calls typically go via the phone bridge. There is more discussion of this model of group communication at the lower levels in chapter three. The way people have come to use Internet multicast conferences is in two styles:
The addition of security/privacy features has also led to closed, more formally structured use which we will look at in chapter ten. The popularity of this technology is indicated to some extent by the growth in the number of sites attached to the Internet that provide global multicast access:
It is instructive to think about alternative ways that group communication might be supported in a network. For example, we might put a list of addresses in a packet of information we wish to send to a list of recipients. This would work so long as the group was fixed and reasonably small, but would quickly become unmanageable for groups in the 100s or 1000s, which we already find in use in the Internet. An alternative might be to employ a central distribution server where we send everything, and it fans it out to all the recipients. This would fly in the face of the entire Internet design philosophy, since it would be a central site, subject to failure and performance problems. Instead, Internet multicast distributes both the group control and the data distribution tasks into the network.
Finally, then routers forwarding packets with multicast destinations use the group address, or the source address together with the information distributed through the group management protocols (as we will see in chapter 3) to determine where to forward packets to.
