IPv4 Multicasting Mechanisms
| Figure 9-3 should have raised a question in your mind. Although it demonstrated how a single flow of communications from one device conserves bandwidth by being forwarded to multiple destinations simultaneously, you should be asking how that can happen. After all, each IP packet has room for only one source address and one destination address. So how can you forward a packet with just one destination address to a limitless number of destinations, each with its own IP address? The answer is remarkably simple: Use a fictitious address that correlates to a list of real IP addresses. Such fictitious addresses are known as multicast addresses. The fictitious nature of such addresses sometimes results in their being called multicast codes instead of addresses. Both terms describe the same thing, but they are properly called addresses. IANA (the Internet's authority for assigned names and numbers) controls the assignment of IP multicast addresses. Originally, the Class D address space was reserved for supporting multicast communications. The Class D address space was identified as all IPv4 addresses that begin with the binary string 1110. The remaining 28 bits were used to uniquely identify multicast groups. Mathematically valid addresses are in the range 224.0.0.0 through 239.255.255.255. These addresses are used individually as destination addresses and are explicitly carried as such in each multicast IP packet's destination address field. The source IP address used in the header of IP multicast packets is always the source address of the machine that originates the multicast. Our review of IP addresses up to this point in the book should leave you secure in the knowledge that end systems can't be configured with an IP address greater than 223.255.255.255. Recall from Chapter 2, "Classical IP: The Way It Was," that this address was the mathematical upper boundary of the former Class C address space. Addresses above that were reserved for a variety of uses, including multicasting. If an address is reserved, and it can't be assigned to an endpoint (much less multiple endpoints), how can it be used to communicate through a network? The answer is deceptively simple: The address corresponds to a list of unique destinations that were previously identified as belonging to a group that wants to receive multicast messages. These groups are the multicast groups we've been talking about. Types of Multicast AddressesHaving seen how multicasting works, it's time to start looking a bit more closely at some of its specialized implementations. Multicast addresses are not created equal, or so it seems when you examine their prescribed functionality. Some addresses are limited in their effective scope to LANs, whereas others are global in scope. Others might be limited to just within a network operator's autonomous system. The four main types of multicast addresses are
A brief look at each of these multicast address types will help you better appreciate some of the capabilities and uses of multicasting. Global AddressesSome multicast addresses are truly global in their scope. This means that they are valid around the world and should be supported globally. Whether they are might depend on your service provider's position on multicasting. Without getting into that, just accept that some multicast addresses are supposed to be globally routable. As such, multicast groups whose individual members are scattered around the world, or even just across different networks regardless of their geographic location, must use global multicast addresses. Limited-Scope AddressesAnother type of multicast address is the limited-scope address. Limited-scope addresses are typically valid only within a specific and finite scope, such as within a single LAN or WAN. This class of multicast addresses lets you satisfy local requirements for multicasting without adding to the burden of the Internet's routers. A more subtle implication of limited-scope addresses is that they do not have to be globally unique. Much like the nonglobally routable addresses reserved by RFCs 1597 and 1918, limited-scope multicast addresses can be reused within different networks without a problem. Two examples of multicast addresses that are limited in scope are the reserved addresses 224.0.0.1 and 224.0.0.2. The first one is used to communicate with all systems on a subnetwork, and the second one is limited to all routers on a subnetwork. GLOP AddressesThe next form of multicast address worth mentioning is the GLOP address. No, I didn't make up that name! RFC 2770, published in February 2000, proposed an experimental protocol for use in supporting multicasting across the Internet. A range of Class D addresses was reserved for use by this experiment. This range was termed GLOP addresses without any explanation of the apparent acronym. I like the name; I just can't explain its significance. An output of the IETF's Multicast Deployment working group (MBONED), RFC 2770 was specifically designed to provide a static mechanism for assigning multicast addresses to protocols and/or organizations. Traditionally, multicast addresses were assigned from the available pool of addresses on an as-needed basis and then were reclaimed when the need expired. For example, a company might want to use multicasting for a new marketing promotion, such as live videocasting of a fashion show. When the show ends, the multicast code would be reclaimed. Although that works well enough, it leaves the Internet without a really coherent approach to supporting long-term multicasting requirements. Dynamic allocation serves sporadic requirements, but as the Internet's user base matures, a more persistent mechanism will likely be required. That's where GLOP comes in. The way GLOP works is simple: You embed a network operator's autonomous system number (ASN) into the second and third octets of an IP multicast address in the 233.0.0.0/8 address block. After having learned about Class D addresses in Chapter 2, you might be wondering about the /8 suffix. After all, these are not blocks of network addresses. Each multicast address uses all 32 bits for identifying unique groups. In this case, the /8 suffix identifies a group of addresses, as opposed to identifying the number of bits that routing decisions are based on. That leaves 24 bits for identifying unique multicast addresses within the 233.0.0.0/8 range. Perhaps an example will help make this concept a bit more understandable. The example used in RFC 2770 uses ASN 5662. Expressed as a binary number, 5662 is 1011000011110. If you used this value as part of an IP address, you would have to pad it with three leading 0s. Mathematicians love to suppress leading 0s, but for reasons explained in Chapter 2, you can't do that for the subfields of a 32-bit IP address without fundamentally changing the overall address. Thus, expressed as a 16-bit binary number, 5662 translates into 0001011000011110. Given that IP addresses are chopped into four 8-bit binary components, this 16-bit string must be segmented into two 8-bit strings. These strings are 00010110 and 00011110. Translating each to decimal yields 22 and 30. Thus, if the network operator that owned ASN 5662 obtained a GLOP address, it would be assigned 233.22.30.0. The fourth octet is available to that operator for specifying up to 255 multicast groups within its autonomous system. NOTE Some sources of technical literature insist on walking you through hexadecimal numbers when calculating a GLOP address. Whether you go directly from Base 10 to Base 2 and then to dotted-quad IP address notation or from Base 10 to Base 16 to dotted-quad is up to you. The mathematics of either operation yield the same result. Given that IPv4 is inherently binary as opposed to inherently hexadecimal, it makes sense to me to simply avoid the Base 16 number system in this case. In theory, individual network operators reserve a numerically contiguous GLOP addresses for use within their respective routing domains. I say "in theory" because this is still just an experimental technology. Whether it becomes a permanent part of the Internet's technology base remains to be seen. I've included it in this chapter because it is an interesting proposal that seems to nicely fill a technological void. As such, I wouldn't be surprised if it advanced beyond the experimental stage. Reserved AddressesOne of the more clever applications of multicasting is its use to satisfy locally bounded broadcast needs of specific technologies. In simpler terms, many niche network functions require one-to-many communications. Previously in this chapter, we assumed that one-to-many was defined globally. On that scale, one-to-all communications would be impractical. However, on a smaller scale, one-to-all communications are highly desirable and useful. When you think about it, a localized one-to-all communication session is actually one-to-many from a global perspective. Reserving link local addresses enabled the implementation of localized one-to-all multicasting. You know that IANA reserved a block of IPv4 address space (known collectively as the Class D address space) for multicasting purposes. However, less well-known is that specific addresses within that reserved block were then reserved for use in performing specific network functions. Table 9-1 contains a small sample of reserved multicast addresses. NOTE Multicast group codes are not reserved in any one particular place. Rather, the way they are used can be highly application-specific. As a result, reservations are made in a startlingly large number of documents. In no particular order, some of these documents include RFCs 1112, 1119, 1045, 1075, 2328, 1190, 1723, 1884, 2114, 2365, and 2730, among others. For a complete list of multicast address assignments and reservations, refer to www.iana.org/assignments/multicast-addresses If you read through this listing, you will notice that specific applications use a specific multicast code. In that regard, multicast addresses can be reserved much like well-known TCP/UDP port numbers.
Reserved multicast addresses number in the hundreds, if not thousands. This listing is just a concise sample to give you an idea of some of the uses of a multicast address. If you followed the link mentioned in the preceding Note to IANA's list of reserved multicast addresses, you would see an interesting pattern in the data. Most of the reserved addresses are used by network layer utilities, but some blocks are set aside for generic use in supporting voice and video communications. NOTE Multicast IP addresses function much like individual host addresses. For example, if you issue a ping command using a multicast address, each host that belongs to the multicast group identified by that address is compelled to reply. A third, important use of multicasting is also evident in that list of addresses. Many companies reserve multicast addresses to directly support their online commercial operations or services. Two examples are Internet gaming and music services. This is an interesting contrast to a multicast address being reserved for use by specific network protocols. Operational MechanicsHaving seen the various types of multicast addresses, the next logical step is to see how a router handles IP packets bearing a multicast address as the destination. From a router's perspective, the destination of a multicast address is an interface, not an end system. At the risk of greatly oversimplifying a complex and critical function, routers deploy a variety of mechanisms to discover other routers in a network or internetwork. After discovery, routers communicate with each other to share what they know about known destinations, possible routes to those destinations, and some measure of the efficiency of each possible route. This information is stored on each router in a routing table. A routing table correlates a destination with the router's interface that should be used to reach end systems within that destination network. Usually, but not always, this destination is a network IP address. To better illustrate this point, look at the network diagram shown in Figure 9-4. This network features a single router that interconnects three LANs. Each host that belongs to the multicast group supported in this network is identified, and separate arrows demonstrate how datagrams are propagated in support of multicasting. Figure 9-4. Multicasting in a Small Network
The router in Figure 9-4 would have a remarkably small routing table. Table 9-2 shows a very sanitized form of the theoretical contents of this router's routing table. For the sake of simplicity, we'll assume that only one routing protocol is in use. Each routing protocol maintains its own routing table, so this assumption lets us use a single routing table.
This routing table demonstrates just four entries: one for each of the three interconnected LANs, plus another entry for a locally supported multicast group. Given this simple network topology and routing table, you can see that the router does not attempt to forward packets to specific destinations. Instead, it forwards multicast addresses out the appropriate interface or interfaces. The onus is then on the downstream hosts to determine whether they are the intended recipients of a multicast stream of packets. The next piece of the multicast puzzle lies in managing multicast addressesor, more precisely, managing the groups of IP addresses that join a multicast group. Group ManagementIt goes without saying that chaos would reign if there were not some central way to manage global multicast groups. Without such regulation, there exists the probability of two or more multicast groups using the same multicast address. The mechanism is known as Internet Group Management Protocol (IGMP). IGMP was first stipulated in RFC 1112, which has subsequently come to be known as IGMP Version 1, or IGMPv1 for short. An update that came about with RFC 2236 is known as IGMPv2. Both are designed to manage multicast groups by providing mechanisms for hosts and routers to share information about multicast group membership. NOTE From the perspective of IGMP, all members of a group are created equal. Thus, no mechanism inherent in the protocol enforces the role of sender versus recipient. The IP multicast model calls for all members of a multicast group to receive any datagrams addressed to that group's address. You do not have to belong to a group to send datagrams to that group. IGMPv1IGMPv1 manages multicast traffic using just two data structures: query packets and report packets. Query messages are used to poll network devices to determine whether they are members of a multicast group. Report packets, logically, are messages sent by network devices in response to queries. Reports notify the querying device of the host's membership status. Responsibility for managing a multicast group's membership falls to the router. Routers configured to support multicasting generate query packets addressed to the all-hosts multicast address 224.0.0.1. In the case of the network shown in Figure 9-4, the router must generate two of these packetsone for each interface that supports multicasting. LAN #2 (10.25.2.0/24) does not support multicasting, and its interface on the router is not configured for this capability. Consequently, such queries are sent only to LAN #1 and LAN #3. IGMP lets individual hosts dynamically register with specific multicast groups on their LAN. Hosts achieve this by sending IGMP messages to their local router. This router must be configured to support multicasting. Otherwise, it won't accept or act on any messages sent to the all-routers multicast address. Joining Groups Using IGMPv1Hosts must have some mechanism to notify their upstream router of their membership in a multicast group. Otherwise, that router won't know to forward multicast data streams to that host. Remember that the router doesn't track individual host membership in multicast groups, but it must track which of its interfaces have downstream devices that are members of particular multicast groups. The way a host joins a multicast group is simple. In fact, there are two options. First, that host can wait for a query packet and then respond. Or it can simply generate a report packet without waiting for a query. Either way, the report packet lets a host identify itself as belonging to a specific multicast group or groups. The report packet must be sent to the all-router multicast group code 224.0.0.2. Leaving Groups Using IGMPv1IGMPv1 did not stipulate any specific mechanism for leaving a multicast group. Consequently, multicast members using this protocol leave groups passively. That is, they don't provide any explicit notification to their upstream router of their departure. Instead, such hosts simply cease responding to queries from their upstream router. The router builds its membership list based on responses, not nonresponses. So a host's failure to respond equates to a passive exit from a multicast group. IGMPv2IGMPv2 came about with the publication of RFC 2236. It is remarkably similar to its v1 counterpart, but it features numerous subtle improvements designed to improve operating efficiency by minimizing lag times for joining and leaving groups. IGMPv2 isn't quite as concise a protocol as IGMPv1, but it achieves its operating efficiency with just four packet types that are used for host-to-multicast-router communications:
In case you wonder why there are two types of membership reports, the answer is simple: It affords backward compatibility with IGMPv1-only machines. The version 2 Membership report differs slightly from the version 1 report in header structure and functionality. The version 1 header contains a field for explicitly identifying a protocol version number as well as an unused field that is set to a pattern of 0s. The version 2 header replaces both of these fields with just a Type field (which identifies which of the four message types is contained in the packet) as well as a Maximum Response Time field. The Maximum Response Time defaults to 10 seconds, but you can change it manually in 1/10 second increments. Its function is to lower the time delay for joining groups by setting a maximum limit on how much time can elapse before a response is sent to a membership query. Implicit in this description is the fact that this field is meaningful only in a membership query. Membership reports and Leave reports cannot use this field. The process of joining a group using IGMPv2 does not differ from that used in IGMPv1. However, the creation of a Leave report means that hosts using IGMPv2 can leave a multicast group immediately. Using the IGMPv1 protocol, such departures are passive rather than active, which translates into a longer interval before the multicast router recognizes the change in membership. |
EAN: 2147483647
Pages: 118