Next: Routing and Addressing
Up: Multicast
Previous: Roadmap
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:
- When a host first joins a group, it programs its ethernet interface to accept the relevant traffic, and it sends an IGMP join message on its local network. This informs any local routers that there is a receiver for this group now on this subnet.
- The local routers remember this information, and arrange for traffic destined for this address to be delivered to the subnet.
- After a while, the routers wonder if there is still any member on the subnet, and send an IGMP query message to the multicast group. If the host is still a member, it replies with a new Join message unless it hears someone else do so first. Multicast traffic continues to be delivered.
- Eventually the application finishes, and the host no longer wants the traffic. It reprograms its ethernet interface to reject the traffic, but the packets are still sent until the router times the group out and sends a query to which no-one responds. The router then stops delivering the traffic.
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: Routing and Addressing
Up: Multicast
Previous: Roadmap
Jon CROWCROFT
1998-12-03