When there is a requirement to send data to many receivers simultaneously, there are two traditional methods that can be used: repeated transmission and broadcast. Repeated transmission may be acceptable if the cost is low enough and delivery can be spread out over time, as with junk mail or electronic mailing lists. Otherwise a broadcast solution is required. With real-time multimedia, repeated delivery is feasible, but only at great expense to the sender, who must invest in large amounts of bandwidth. Similarly, traditional broadcast channels have been very expensive if they cover significant numbers of recipients or large geographic areas. However, on the internet, there is an alternative solution. IP Multicast effectively turns the Internet into a broadcast channel, but one that anyone can send to without having to spend huge amounts of money on transmitters and government licenses. It provides efficient, timely and global many-to-many distribution of data, and as such may become the broadcast medium of choice in the future. The Internet is a datagram network. This means that anyone can send a packet to a destination without having to pre-establish a path. Of course, the boxes along the way must have either pre-computed a set of paths, or be pretty fast at calculating one as needed, and typically, the former approach is used. However, the sending host need not be aware of or participate in the complex route calculation; nor need it take part in a complex signaling or call setup protocol. It simply addresses the packet to the right place, and sends it. As discussed briefly in chapters one and two, this may be a more complex procedure if the sending or receiving systems need more than the default performance that a path or network might offer, but it is the default model. Adding multicast to the Internet does not alter the basic model. A sending host can still simply send, but now there is a new form of address, the multicast or host group address. Unlike unicast addresses, hosts can dynamically subscribe to multicast addresses and by so doing cause multicast traffic to be delivered to them. Thus the IP Multicast service model can be summarised:
Point to multipoint communication is nothing new. We are all used to the idea of broadcast TV and Radio, where a shared medium (the RF spectrum) is partitioned up amongst users (basically, transmitter or TV and radio station owners). It is a matter of regulation that there is typically only one particular unique sender of particular content on a particular frequency, although there are other parts of the RF spectrum given over to free use for multi-party communication (e.g. police radio, citizen band radio, etc etc). The Internet multicast model[#!igmp!#] is very similar. The idea is to convert the mesh wide area network that is the Internet (whether the public Internet, or a private Enterprise net, or Intranet makes no difference to the model), into a shared resource for senders to send to multiple participants, or groups. To make this group communication work for large scale systems (in the sense of a large number of recipients for a particular group, or in the sense of a large number of senders to a large number of recipients, or in the sense of a large number of different groups), it is necessary, both for senders, and for the routing functions to support delivery, to have a system that can be largely independent of the particular recipients at any one time. In other words, just as a TV or Radio station do not know who is listening when, an Internet multicast sender does not know who might receive packets it sends. If this sends alarm bells ringing about security, it shouldn't. A unicast sender has no assurance about who receives their packets either. Assurances about disclosure (privacy) and authenticity of sender/recipient are largely separate matters from simple packet delivery models. We discuss these security matters in some detail in chapter 10.
Basically, the model is an extension of the datagram model, and uses the fact that the datagram is a self contained communications unit, that not only conveys data from source to destination, but also conveys the source and destination, in other words, in some senses, datagrams signal their own path, both with a source and a destination address in every packet. By adding a range of addresses for sending to a group, and providing independence between the address allocation and the rights to send to a group, the analogy between RF spectrum and the Internet multicast space is maintained. Some mechanism, as yet unspecified, is used to choose dynamically which address to send to. In chapter 7, we will take a look at some protocols for carrying out this function, but suffice it to say that for now, the idea is that somehow, elsewhere, the address used for a multicast session or group communication activity is chosen so that it does not clash with other uses or users, and is advertised. Imagine the equivalent in the RF spectrum. A New TV or radio station's manager (or multicast session creator) looks in a TV listings magazine, or in a government or regulatory bodies publications for a list of frequencies (say a bulletin board) in use, and finds one that is free. We write to the TV listings magazine (the bulletin board) and have them advertise this new address. We can now safely send, and receivers find out where to ``receive on''. It is very important to note that unlike the RF spectrum, an IP packet to be multicast carries a unique source identifier, in that such packets are sent with the normal unicast IP address of the interface of the sending host they were sent from. It is also worth noting that an address that is being used to signify a group of entities must surely be a logical address (or in some senses a name) rather than a topological or topographical identifier. We shall see that this means there must be some service that maps such a logical identifier to a specific set of locations in the same way that a local unicast address must be mapped (or bound) to a specific location. In the multicast case, this mapping is distributed. Note also that multicast internet addresses are in some sense ``host group'' addresses, in that they indicate a set of hosts to deliver to. In the Internet model , there is a further level of multiplexing, that of transport level ports, and there is room for some overlap of functionality, since a host may receive packets sent to multiple multicast addresses on the same port, or multiple ports on the same multicast address. We will look at this further in chapter five. There are a number of questions this model raises about address and group management, such as how these addresses are allocated. The area requiring most change, though, is in the domain of the routing. Somehow the routers must be able to build a distribution tree from the senders to all the receivers for each multicast group. The senders don't know who the receivers are (they just send their data), and the receivers don't know who the senders are (they just ask for traffic destined for the group address), so the routers have to do something without help from the hosts. We will examine this is detail in section 3.4