10
Multicast
Multicast has the potential to vastly improve the scalability of networks carrying traffic matching particular profiles and types. It has significant potential to reduce traffic volumes when a relatively low number of sources transmit the same content to a relatively large number of receivers. If this model were supported with pure unicast, then the source would have to sustain the transmission of very large numbers of flows and very large aggregate volumes of data. With multicast, a single stream of data is transmitted by the source and is passed along towards all interested receivers, being replicated only when two receivers can be reached only via different paths.
Multicasting IP data requires a number of protocols, each of which performs a particular portion of the required functionality. Multicast has developed in much the same way as unicast, with separate protocols for communication between host and router and between router and router. However, multicast has the added feature of requiring routing protocols from source to destination and from destination to source!
Multicast traffic is sent by one or more sources (S) to a group (G). Interested hosts join groups. Multicast groups fall into the address range 224.0.0.0/4.1
10.1MULTICAST FORWARDING AT LAYER 2
Most of this chapter focuses on multicast forwarding at Layer 3. However, it is equally important to be able to identify traffic on a multi-access network destined for a particular multicast group at Layer 2.
1 For a complete list of allocated multicast addresses, see http://www.iana.org/assignments/multi- cast-addresses.
Designing and Developing Scalable IP Networks G. Davies
2004 Guy Davies ISBN: 0-470-86739-6
134 |
MULTICAST |
10.1.1 MULTICAST ON ETHERNET AND FDDI
It is necessary to provide a mapping from the Layer 3 multicast group into a Layer 2 multicast address. In an ideal world, this would be a one-to-one mapping. However, rather than mapping the lowest-order 28 bits from the IP multicast group address, the lowest-order 23 bits from the IP multicast address are appended directly onto a MAC prefix. This leaves five bits of the IP multicast group address that can vary while still resulting in an identical Layer 2 multicast group address. Thus, each Layer 2 multicast address maps to 32 Layer 3 multicast groups. The MAC prefix is 0x01005E in the first 24 bits of the MAC address plus 0 in the 25th bit of the MAC address. In order to have a one-to-one mapping, it would have been necessary to obtain 16 OIDs from IEEE. Because each of these OIDs cost $1000, the researchers who were first working on the development of multicast found it impossible to justify the purchase. Therefore, one OID was purchased by the researchers and shared with another project.
10.1.2 MULTICAST OVER TOKEN RING
Token Ring uses functional MAC addresses for devices performing special functions on the ring. The first bit of the first byte of the Token Ring MAC is used to signify whether the destination is unicast or multicast/broadcast. This bit is known as the I/G bit. The second bit of the first byte is used to signify whether the MAC address is a globally significant manufacturer assigned address or a locally significant address assigned by the local administrator. This bit is known as the U/L bit. The first bit of the third byte is used to signify whether an address is a functional address or a locally administered address. This bit is called the FAI bit.
In order to create a functional multicast address, exactly one of the 31 bits following the FAI bit is set to 1. Therefore, it is impossible to directly map IP multicast groups onto multicast Token Ring MACs. It is necessary to employ other means to overcome this constraint. Two mechanisms are currently employed.
The first mechanism uses the broadcast address FFFF.FFFF.FFFF for all multicast frames in addition to true broadcast frames. This is somewhat inefficient because all hosts receive the IP multicast frames, whether or not the hosts are interested in IP.
The second mechanism uses a single functional address C000.0004.0000 for all traffic destined for an IP multicast group. At first sight, this mechanism is a better option, but it relies upon the ability of every NIC on the ring to support and correctly handle this functional address, which many do not. In addition, even if the NIC on the host supports this functional address, the arrival of each multicast packet triggers an interrupt to be sent to the host’s CPU. This can significantly impact the performance of any host on a ring that handles anything more than the smallest amount of multicast traffic. For these reasons, running multicast over Token Ring scales poorly.
10.1 MULTICAST FORWARDING AT LAYER 2 |
135 |
10.1.3INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)
IGMP is the protocol used by a host to inform the nearest multicast-capable router of the multicast groups it wishes to receive. At the time of writing, there are three versions of IGMP, each of which provides a number of enhancements over the previous version.
IGMPv1 provides a simple mechanism for hosts to inform the nearest multicast router that they wish to receive a particular group. This message is known as a report. In addition, IGMPv1 provides a mechanism for routers to query whether any hosts on the LAN are interested in receiving multicast transmissions. IGMP queries are transmitted at regular intervals, the default being 60 seconds, onto the LAN. IGMPv1 provides no explicit mechanism for leaving a group, so even after the last interested host stops sending reports, the multicast router forwards traffic onto the network until the last report times out. If other hosts on the LAN are still interested, their reports ensure that traffic still makes its way onto the LAN. A host has 10 seconds (fixed in IGMPv1) to respond with a report to queries sent by multicast routers if they want to continue to receive any traffic. Because reports are sent to the group the host wishes to receive, all interested hosts receive the report sent in response to a query and do not send duplicate responses to queries.
In addition to the functionality of version 1, IGMPv2 provides an explicit leave function. IGMPv2 also enhances the concept of the query by making it possible for a router to query for members of a specific group, in addition to being able to send a general query. These are major enhancements over version 1 and significantly improve the speed with which multicast traffic for one group can be stopped and, by implication, traffic for another group started. Consider, for example host H that is currently receiving traffic for group G1. H now wishes to stop receiving traffic for group G1 and start receiving traffic for group G2, instead. If it is using IGMPv1, then H will just stop transmitting reports for G1 and start transmitting reports for G2. Until the membership of G1 times out, H will receive traffic for both G1 and G2. If it is using IGMPv2, then H will send an explicit leave for G1 and a report for G2. The leave triggers the router to send an IGMP query (could be a group-specific query or a general query). Assuming no other hosts on the LAN are interested in G1, then the router will stop transmitting traffic for that group onto the LAN.
IGMPv3 provides the means for the host to specify the source from which it wishes to accept data for a particular group (i.e. rather than joining a group with an unspecified source (*, G), the host sends joins, which are analogous to reports in IGMP versions 1 and 2, for a group with a specified, single source (S, G)). This is specifically required for source-specific multicast (see below).
At the time of writing, IGMPv1 and IGMPv2 are widely implemented in both hosts and routers. IGMPv3 is less widely implemented, particularly on host operating systems, although it is becoming more widely implemented. If IGMPv2 is available, it is unquestionably a better, more scalable option that IGMPv1. It is questionable whether IGMPv3 provides any significant benefit over IGMPv2 unless you are implementing SSM, in which case, you must use IGMPv3.
136 |
MULTICAST |
All versions of IGMP are constrained to a single hop at Layer 3 between hosts and the first multicast router. However, this does not totally protect IGMP from scalability issues. For example, consider the situation where there are many hosts in a large switched network. Each of the receivers is interested in a small subset of the total set of groups available. However, because the receivers are all effectively attached to a single router and they are all sending IGMP reports/joins for their required groups, the router will transmit the multicast traffic for all the groups onto the LAN. Because the switch is not aware of who is interested in which groups, it must transmit all traffic for all groups to all switch ports. Even if no single group accounts for more than a few tens or hundreds of kilobits per second of data, the aggregate of hundreds or even thousands of groups could amount to many megabits per second of data, which must be transmitted down every switch port. Thus, there is potential for entirely unwanted traffic to totally over-subscribe a port.
10.1.4 IGMP SNOOPING
IGMP snooping is one widely implemented mechanism for the constraint of the flow of multicast traffic through a switched network. It works by snooping IGMP reports being sent by hosts on each port and explicitly permitting traffic for the requested group to be transmitted onto the port over which the IGMP reports were received. Traffic for that multicast group is not transmitted on any port for which there has been no matching IGMP report received.
This, however, raises another problem, which relates to the ports to which the multicast routers are attached. They never send any IGMP reports (although the IGMP querier, or PIM-designated router, will send IGMP queries) and, therefore, will never receive packets for any multicast groups because the multicast traffic is blocked from the ports to which they are attached. It is possible to manually disable IGMP snooping on a per-VLAN basis, thus explicitly permitting all multicast traffic to those VLANs. However, doing so overrides the behaviour for all ports on the VLAN. Ideally, it would be better to specify the ports connected to the multicast routers and have them accept all groups while still snooping other ports in the VLAN. However, the need to configure ports is really an unnecessary administrative load (although many would consider it desirable for security reasons).
10.1.5 PIM/DVMRP SNOOPING
In order to overcome the need for manual configuration of those ports on which PIM or DVMRP routers are attached, an automated mechanism to overcome this is provided. PIM/DVMRP (see below for descriptions of PIM and DVMRP) snooping can be configured, in addition to IGMP snooping on all ports in a VLAN, so that the switch also snoops PIM or DVMRP packets and IGMP queries. Upon seeing these packets, it marks that port open for all multicast groups. This means that should a new router be installed on the VLAN, it is not necessary to manually configure the directly connected switch.