next up previous contents
Next: Routing and Addressing Up: Multicast Previous: Roadmap

Host Functions

IGMP v1 Status: IETF Standard (RFC 1112)
IGMP v2 Status: IETF Proposed Standard (RFC 2236)
IGMP v3 Status: IETF Work in Progress


As we stated above, host functionality is extended through the use of the IGMP protocol. Hosts, and routers which we will look at later, must be able to deal with new forms of addresses. When IP version 4 addressing was first designed, it was divided into classes as shown in table 3.1.

 
Table 3.1: Class D addresses are Multicast
Class A 1.0.0.0 to 126.255.255.255
Class B 128.0.0.0 to 191.255.255.255
Class C 192.0.0.0 to 223.255.255.255
Class D 224.0.0.0 to 239.255.255.255
 

Originally class A was intended for large networks, B for middle size networks and C for small networks. Class D was later allocated for multicast addresses. Since then, classless addressing has been introduced to solve internet scaling problems, and the rules for class A, B and C no longer hold, but class D is still reserved for multicast, and so all IPv4 multicast addresses start with the high order 4 bit nibble: 1110 In other words, from the 232 possible addresses, 228 are multicast. This means that there can be up to around 270 Million different groups, each with as many senders as can get unicast addresses! This is many orders of magnitude more than the RF spectrum allows for typical analog frequency allocations. 3.1

For a host to support multicast, the host service interface to IP must be extended in 3 ways:

1.
A host must be able to join a group. This means it must be able to re-program its network level, and possibly, consequentially, the lower levels, to be able to receive packets addressed to multicast group addresses.
2.
An application that has joined a multicast group and then sends to that group must be able to select whether it wants the host to loop-back the packets it sent so that it receives its own packets.
3.
A host should be able to limit the scope with which multicast messages are sent. The Internet Protocol contains a time to live field, used originally to limit the lifetime of packets on the network, both for safety of upper layers, and for prevention of traffic overload during temporary routing loops. It is used in multicast to limit how ``far'' a packet can go from the source. We will see below how scoping can interact with routing.
When an application tells the host networking software to join a group, the host software checks to see if the host is a member of the group. If not, it makes a note of the fact, and sends out an IGMP join message. It also maps the IP address to a lower level address and reprograms its network interface to accept packets sent to that address. There is a refinement here: a host can join ``on an interface''; that is, hosts that have more than one network card can decide which one (or more than one) they wish to receive multicast packets via. The implication of the multicast model is that it is ``pervasive'' so that it is usually only necessary to join on one interface3.2. Taking a particular example to illustrate the IP level to link level mapping process, if a host joins an IP multicast group using an Ethernet interface, there is a mapping from the low 24 bits of the multicast address into the low 24 (out of 48) bits of the ethernet address. Since this is a many-to-one mapping, there may be multiple IP multicast groups occupying the same ethernet address on a given wire, though it may be made unlikely by the address allocation scheme (as discussed in chapter 7). An ethernet LAN is a shared medium network3.3, thus local addressing of packets to an ethernet group means that they are received by ethernet hardware and delivered to the host software, only of those hosts with members of the relevant IP group. This means that host software is generally saved the burden of filtering out irrelevant packets. Where there is an ethernet address clash, software can filter the packets efficiently. How IGMP works can be summarised as follows: Thus joining a multicast group is quick, but leaving can be slow with IGMP version 1. IGMP version 2 reduces the leave latency by introducing a "leave" message, and an assorted set of rules to prevent one receiver leaving from disconnecting others. IGMP version 33.4 introduces the idea of source-specific joining and leaving whereby a host can subscribe (or reject) traffic from individual senders rather than the group as a whole, at the expense of more complexity and extra state in routers.
next up previous contents
Next: Routing and Addressing Up: Multicast Previous: Roadmap
Jon CROWCROFT
1998-12-03