Multicasting is a set of addressing methods, protocols, and network design principles that let a single source send, efficiently, to a group of recipients. The group may be predefined as made up of "well-known" addresses, or it may be dynamic, such as when participants join and leave a conference.
To understand multicasting, and indeed one of its most common applications, think of the difference in making a telephone call and watching commercial television. Ordinary telephone callers are pairs of users that decide they want to connect. In television, however, the content goes out without knowing if anyone wants to receive it. Those that do receive it make an individual decision to listen to a channel, without telling the broadcaster.
Phrasing it differently, the televisions of the receiving class need to make a positive assertion that they want to JOIN the particular content (the multicast group) associated with the address, by selecting a channel with the remote control that always seems to have been mislaid, or with the channel selector. Multicast protocols have equivalent JOIN functions, but implemented in protocols.
Broadcasting is a special case of multicast, where all possible destinations, perhaps within a certain area, are part of the destination group. Groucho Marx gave a good description of a broadcast environment when he said he wouldn't join any club that would have him as a member.
Generic multicast topology
Most multicasting is tree-structured, from a source root to many branch destinations. If multicasting is interactive, the end user nodes act as both roots and branches.
A great advantage of multicasting data is that by multicast 1 copy of content at speed M, you save (N-1)M units of bandwidth. Multicasting, in the right application, is extremely cost-effective.
If the source of the multicast content simply connected to another interface of the same router, things would be simple. Usually, however, the content source connects to a distant router, and the two routers, as well as any intermediate routers, need to share location information. This means that the multicast topology will need to be of a tree, with routers at the nodes and receiving hosts at the leaves.
Do note that multicasting follows a one-directional model. If source 1 sends to group 1, which is written
<S1, G1>, source 1 will not automatically receive responses to its messages. If source 1 wants to hear traffic from the reverse direction of the first host, which we designate
<S2, G2>, that will require a separate tree to be constructed.
Multicast addressing in the IEEE 802 architecture
Multicast addressing in the Internet Protocol
IP version 4
IP version 6
Multicast flow in IEEE 802
IP multicast routing
Television distribution is one common application of multicasting, so think of the JOIN command as selecting a channel. A television has picture-in-picture capability, which allows watching two channels at once, a corresponding IP television would send one JOIN for each channel. When a channel changes, the TV set will send out a LEAVE for one channel before it sends a JOIN for the next one.
End host responsibilities
At the actual protocol level, JOIN and LEAVE messags are part of the Internet Group Management Protocol, whose scope is from the end node to the closest router that participates in multicast routing. 
With more recent versions of IGMP, they can LEAVE explicitly. Earlier versions required the hosts to send periodic JOINs to indicate they still were interested in the content. An extension, source-specific multicast, allows the end node to be selective about hearing traffic from particular sources in particular trees.
Multicast routers strive to cover all nodes of the multicast trees while sending as little duplicate traffic as possible, and also recognizing that different multicast applications have different assumptions that impact overhead.
The two basic assumptions are that a given application is either:
- sparse-mode, in which most hosts do not want to receive the content, so the multicast tree needs to be constructed as the minimum topology that will cover the set of requesting hosts. Often, this happens at a rendezvous point, to which all the subnets interested in content need to establish connectivity.
- dense-mode, a less common case in which it can be assumed most hosts want the content, so the tree can be constructed such that it covers all subnets, pruning subnets that it later learns have no hosts interested in the multicast group.
While there is an assortment of multicast routing protocols, the most common are Protocol Independent Multicast (PIM)-Sparse Mode and PIM-Dense Mode. Before the multicast routing protocols can work, a standard unicast routing protocol needs to work out the unicast connectivity on top of which the multicast routing will be layered.
Another refinement of topology has an assorted name, IGMP-snooping being most common. Under most circumstances, multicast routing will deliver a packet, with a multicast address, to subnets that have at least one participant in the group. Having a multicast packet go out to all members of the subnet means that at least their network interfaces has to go through the processing to decide that it is not a member of the group associated with the packet.
When the hosts connect individually to the ports of a Layer 3-aware switch, it snoops the IGMP JOINs sent by the hosts, and only sends packets, belonging to a multicast group, out a port for which the corresponding host has expressed interest in seeing that multicast content. If the host on that port JOINs more than one group, the switch will send out the number of groups joined, but no other groups.
- S.E. Deering (August 1989), Host extensions for IP multicasting, RFC1112
- B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan (October 2002), Internet Group Management Protocol, Version 3, RFC3376
- H. Holbrook, B. Cain, Source-Specific Multicast for IP, RFC4607
- H. Holbrook, B. Cain, B. Haberman (August 2006), Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast, RF4604
- P. T. Pusateri (August 2006), Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis, RFC4602
- B. Fenner, M. Handley, H. Holbrook, I. Kouvelas (August 2006), Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), RFC4601
- A. Adams, J. Nicholas, W. Siadak (January 2005), Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised), RFC3973