IP provides a mechanism to allow one computer to multicast to a group of listeners. Such a group, called a host group, has dynamic membership: eligible hosts can join or leave at any time using IGMP (Internet Group Multicast Protocol). The group defines only the receivers: a transmitting host need not itself be a member of the group
Before the group can function it must be allocated a multicast address from the Group D range:
224.0.0.0/4 (all the addresses from 224.0.0.0 to 239.255.255.255).
This range is structured. For example addresses in the 224.0.0.0/24 range are reserved for the local subnet:
A more complete listing can be found at http://www.iana.org/assignments/multicast-addresses
To send a multicast, a host must first determine the address to use. For existing groups a service location protocol can be used to determine its address. To create a new group, an address must be supplied by the application or through an extension of DHCP called MADCAP (Multicast Address Dynamic Client Allocation Protocol). A receiver must similarly determine the address of the group it wants to listen to. Multicasts can be advertised using the Session Announcement Protocol (SAP) described in RFC 2974, which itself multicasts announcements to well-known multicast addresses.
Multicast is implemented by multicast routers. Such routers detect all multicast traffic and forward it using multicast IP forwarding tables. IP multicasts use Layer 2 multicasts to carry packets across LANs. For example the Ethernet address, range:
01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF
is reserved to carry multicast IP packets. The least significant 23 bits of the IP Class D address is carried in the low-order 23 bits of the MAC address (see Figure 1). As can be seen 5 bits of the IP address are dropped so hosts will get frames for groups to which they do not belong. These are simply dropped by IP once the IP packet address has been determined. A multicast router or host will have its network interfaces set to accept any Ethernet frames with an Ethernet multicast address: this is called multicast promiscuous mode.
Figure 1: Mapping IP Multicast Addressing to Ethernet Addresses
Multicast routers use routing algorithms analogous to RIP or OSPF in order to update their forwarding tables. These algorithms include Multicast Open Shortest Path First (MOSPF), Distance Vector Multicast Routing Protocol (DVMRP) and Protocol Independent Multicast (PIM). These involve exchanges of group membership information but are not considered further here.
IGMP is a protocol between a host and local multicast routers which is used to notify routers of which hosts belong to which multicast groups. The protocol has been issued in three revisions which use slightly different approaches to the problem. In IGMPv1 a host wishing to join a group sends a Host Membership Report Message, in an IP packet, to the group's address: this is detected by all locally attached multicast routers and hosts and acts to inform them of group membership. However, a host does not directly indicate when it leaves a group. Instead each multicast router will periodically multicast a (Version 1) Host Membership Query Message onto each of its connected subnets (to address 224.0.0.1). A host receiving such a message will respond with a HMRM unless it sees another host on its subnet respond first. The aim of this exercise is simply to allow the router to determine whether there are any group members active on the subnet in question. If there are no such members the router will know that it no longer needs to deliver messages to the group address in question to that subnet. IGMPv2 is very similar but introduced a faster means of notifying a router that a group has no members left on a subnet, using an additional message type called a IGMP Leave Group. IGMPv3 (RFC 3376) has, however, introduced a different model whereby hosts specify lists of transmitters to listen to These are sent in Version 3 Membership Report Messages to a reserved multicast address 224.0.0.22 which all IGMPv3 capable routers must listen to. Again queries are used by routers to check which devices want which multicasts. IGMPv3 capable devices must also comply with IGMP v1 and v2 to allow for backwards compatibility.
Layer 2 switches can of course update filter tables intelligently to support multicasts if they operate the GMRP protocol that is a variant of GARP (IEEE 802.1p). An interesting relatively recent innovation is IGMP snooping (RFC 4541) which allows a Layer 2 switch to listen directly to IGMP Host Report packets (even though these are Layer 3) and directly update its filter table in accord with the IGMP to Ethernet address translation rule discussed above. This bypasses GMRP but is, of course, only relevant to IGMP multicasts.
Wide area multicasting relies on an network of multicast routers. Modern IP routers are invariably multicast-capable but this was not the case in the past and of course conversion of Internet infrastructure takes many years to accomplish. Whenever multicast routers are connected via routers which cannot forward multicast traffic the former use IP in IP tunnelling to communicate. Such tunnelling held together the MBone (Multicast Backbone), which provided an early global network of multicast IP routers during the 1990s when the majority of Internet routers had no such capability.
One last issue worth mentioning is how a multicast is scoped, that is limited in extent to prevent it travelling beyond certain boundaries. One way of doing this is to use the IP time-to-live field to limit the number of hops; another is to use special multicast addresses in the range 239.0.0.0/8 which are reserved for use inside areas under single administrative control (e.g. AS's). Packets carrying such addresses can be stopped at a boundary by multicast routers which will not propagate them outside the administrative area. The idea is discussed in detail in RFC 2365.