Foundation Topics
IP Styles of Addressing
An IP network—and therefore the hardware that makes up the network—supports three types of packets:
Unicast— Packets that are sent from one source address to a single destination host address.
Broadcast— Packets sent to a broadcast destination address.
Multicast— Packets sent to a special group-based destination address.
The following sections describe each packet type in more detail.
Unicasts
Unicasts are packets sent to a specific destination address. When transmitting the same information to a group, unicasts require retransmitting the same information to each individual, which eats up network capacity.
Unicasts are forwarded by a router or Layer 3 switch by finding the destination IP address in its routing table. A Layer 2 switch relies on the destination's MAC address. Unicast forwarding is turned on by default, and is the type of routing familiar to you already.
Broadcasts
Broadcasts are one way to communicate the exact same information to a group. Broadcasts are single transmissions that are received and acted upon by all devices.
Broadcasts can be used to communicate to all devices. For example, some routing protocols use broadcasts to distribute routing information. Rather than requiring a series of unicast transmissions, a single packet can reach all parties.
Broadcasts are also useful when a destination address is unknown. An example of the use of broadcasts is device startup: DHCP uses broadcasts to assign unicast addresses.
Network cards are programmed to listen to all traffic; they are programmed to ignore most frames, but to recognize frames destined for the local MAC address or the broadcast MAC and to copy those frames to the CPU.
The problem with broadcasts is that they must be processed by the CPU. For instance, a PC receiving a RIP advertisement will process the packet enough to understand that it is not interested. That effort leeches computing cycles away from other processes.
Another way to understand this broadcast issue is to consider an example from real life. Have you ever worked or visited an office where anyone could page over the intercom? Regardless of how important a conversation or project is, everyone must stop and listen to every page. Conversations are interrupted and folks look at each other and say "Was that for me?" This can be annoying, distracting, and reduce everyone's ability to concentrate. Broadcasts create a similar annoyance for network systems.
Ethernet broadcasts are sent to the reserved MAC address FFFF.FFFF.FFFF. Layer 2 switches flood broadcasts out all ports in the same VLAN. IP broadcasts use the reserved destination IP 255.255.255.255. Routers do not forward broadcasts by default.
Multicasts
Multicast addresses are "group" addresses. An IP device joins a group by recognizing group IP addresses and reprogramming its network interface card (NIC) to copy traffic destined for the group MAC. Because a multicast goes to a different MAC, some hosts will pay attention to it and others will ignore it. For example, EIGRP uses 224.0.0.10 and the corresponding MAC 0100.5E00.000A. Routers pay attention to this traffic, but your PC can safely ignore it.
Because multicasts allow the NIC to discriminate at the data-link layer, less time is spent processing traffic. For this reason, multicasts are conservative in terms of both bandwidth and processing.
Multicast traffic is generally unidirectional. Because many hosts are receiving the same data, it makes little sense to allow one of the hosts to send packets back toward the source over the multicast mechanism. Instead, a receiving host can send return traffic to the source as a unicast. Multicast traffic is also sent in a best-effort connectionless format. UDP (connectionless) is commonly used, whereas TCP (connection-oriented) is not.
Hosts that want to receive data from a multicast source can join or leave a multicast group dynamically (by enabling the group MAC on their NIC). In addition, a host can decide to become a member of more than one multicast group at any time. The principal network task is then to figure out how to deliver multicast traffic to the group members without disturbing other uninterested hosts.
Multicast traffic is only processed by hosts that are programmed to receive it. A router does not forward IP-multicast packets by default unless some form of multicast routing is enabled. By default, Layer 2 switches flood Ethernet multicasts to all ports on the destination VLAN.
Video over IP Scenario
Figure 17-1 shows a company topology. The CIO wants to address the team via video-over-IP and asks everyone to attend the video briefing. Notice that the Ethernet links are Fast Ethernet (100 Mbps) and that the WAN link is a DS3 (about 45 Mbps). Users A, B, C, and E wish to attend the online briefing, but user D does not.
Figure 17-1. Network Topology
What would happen if the video were distributed using unicast? First, if the video stream were 1-Mbps, each additional user would require a 1-Mbps path to the source. The fast Ethernet links would limit the number of clients to no more than 100 and the DS3 would limit the clients at the remote site to 45 (and inefficiencies in the network would prevent even that many). Figure 17-2 charts this function of clients versus capacity.
Figure 17-2. Utilization Versus Clients
Of course, while those 100 users are listening to the CIO, all possible network capacity is consumed and other users are left unable to use the network. Figure 17-3 shows that individual unicast streams would be required for each user watching the CIO. Although only five users are shown, no more than 55 users at headquarters and 45 users at the remote site could be supported.
Figure 17-3. Unicast Video Traffic
When they recognize the problem, the administrators of this imaginary network try to distribute the video using broadcasts. What happens? Nothing—routers do not forward broadcasts (as shown in Figure 17-4).
Figure 17-4. Broadcast Video Traffic
Even inside a LAN, broadcasts are problematic. Broadcasting inside a LAN does allow one transmission to reach everyone, but now even those devices that are not intended recipients must slog through a megabit per second of video broadcast, burdening their processors.
Multicasting solves this problem. A single multicast stream may be distributed to all users, conserving capacity. Multicasts are routable, and users that do not wish to see the CIO may ignore the video without penalty (processor penalty, anyway).
Exactly what occurs with user D? In the worst-case scenario, user D receives the multicast traffic but the NIC ignores it. In the best-case scenario, the switch is smart enough to filter the multicast (using either IGMP snooping or CGMP). Figure 17-5 shows the video being distributed with multicasts.
Figure 17-5. Multicast Video Traffic on a LAN
Multicast Addressing
As discussed in the previous section, end systems and intermediate devices must have a way to distinguish multicast traffic from unicasts or broadcasts.
At Layer 3, this is done by reserving Class D IP addresses (224.0.0.0 through 239.255.255.255) for multicasting. Network devices can quickly distinguish multicast IP addresses by looking at the first four bits, which are always 1110. Ethernet devices similarly have a range of addresses set aside for multicasts. The low-order bit in the first byte of a MAC address is a unicast/multicast bit, and setting it indicates the frame is a multicast. Beyond this single bit, IP multicasts are mapped to a specific range of MAC addresses to aid hosts in discriminating between multicasts.
Multicast MAC Addressing
At Layer 2, systems recognize multicast traffic because each multicast IP address is mapped to a 48-bit MAC address. The first 24 bits of that MAC address (the organizationally unique identifier or OUI) always begin with 0100.5e and the 25th bit is always 0. The lower 23 bits of the multicast MAC address are copied from the far right 23 bits of the multicast IP address.
Figure 17-6 shows the address-mapping concept. Only the lower 23 bits of the address are copied from IP to MAC (or vice versa). The high-order prefixes of both IP and MAC addresses are fixed, predictable values.
Figure 17-6. Multicast IP to MAC Calculation
Notice that 5 bits of the IP address are not transferred into the MAC address. This creates the possibility of a multicast MAC address not being entirely unique. There are 32 (5-bits worth) different multicast IP addresses that all could correspond to a single multicast MAC address.
This situation is demonstrated in Figure 17-7, showing that the NIC would be unable to distinguish traffic for 234.64.3.5, 225.192.3.5, and 227.64.3.5. The diagram displays the binary for the three IP addresses. The bottom row shows the corresponding multicast MAC address (the black boxes show digits from the IP multicast MAC prefix that are always the same). However, the network card would be able to distinguish traffic for 230.177.3.5 from the other addresses.
Figure 17-7. Multicast IP to MAC Collisions
Because of this ambiguity, a multicast host faces a small problem when it receives an Ethernet frame destined for a multicast MAC address. This single MAC address could correspond to 32 different multicast IP addresses. Therefore, the host must receive and examine every frame that includes the MAC address it is interested in, regardless of which IP address the frame is traveling toward.
The host then examines the destination IP address in the packet header to verify that the more specific IP multicast address is a desired multicast group. If not, the packet is discarded.
Note
Because of the overlap in IP-to-MAC mapping, it is most efficient to use Multicast IP addresses that do not overlap.
Multicast IP Addressing
In addition to the Class D multicast address space, some IP multicast addresses have been reserved for particular uses, such as the following:
Link-local addresses (224.0.0.0/24)— Used on a local segment (TTL=1) only. Routers do not forward these packets because of TTL. These are known as fixed-group addresses because they are well-known and predefined. Examples are given in the following table:
Address Destination 224.0.0.1 All hosts 224.0.0.5 All OSPF routers 224.0.0.6 All OSPF DRs 224.0.0.9 All RIPv2 routers 224.0.0.10 All EIGRP routers Source-specific multicast (232.0.0.0/8)— An extension of multicasting wherein hosts only receive traffic from a particular server instead of from any server using a multicast channel.
GLOP (233.0.0.0/8)— Allocates 256 multicast IP addresses to each registered autonomous system (AS). The 16-bit AS number is used for the middle-two octets, so that AS 1000 has 233.3.232.0/24.
Administratively scoped addresses (239.0.0.0/8)— This space can be used in private multicast domains, much like the private IP address ranges from RFC 1918. These addresses are not supposed to be routed between domains; this way, they can be reused.
Within the administratively scoped addresses, 239.252.0.0/14 is reserved for site-local multicast and the rest of 239.192.0.0/10 is reserved for organization-local scope.
Globally scoped addresses (224.0.1.0–231.255.255.255 and 234.0.0.0–238.255.255.255)— These addresses can be used by any entity and can be routed across an organization or the Internet. They must be unique and globally significant, and therefore are usually temporarily assigned (think of this range as neither local nor private; it is the rest of the multicast range).
Current Multicast Use
This section describes how today's applications use multicasting and the related challenges that you need to be aware of.
Multicast Applications
Multicasting is used in many applications. For example, PC imaging software typically allows image distribution through multicast. In this scenario, a server is loaded with an image and each client is booted with a special disk that sets them to receive the multicast. Schools, for instance, might use this to image a lab in one step. Music-on-hold in IP Telephony systems is another example of the use of multicast in modern networks.
Another common use of multicasting is in "shared whiteboard" applications where many users edit a common workspace. Finally, it is very common to use multicasting for resource discovery; for instance, the routing processes RIPv2, OSPF, and EIGRP discover neighbors using multicasts.
Applications may therefore be one-to-many (imaging), many-to-many (whiteboarding), or many-to-one (routing).
Multicast Issues
There are downsides to multicasting that must be recognized. Because multicast traffic is generally UDP, it lacks windowing functions, packet ordering, and capability for retransmission. It also lacks the ability to allow some users to receive multicasts while preventing others on the segment (although there are ways to block multicasts at the router).
These challenges can be met creatively at the protocol level. For multimedia traffic, ordering is handled by the Real Time Protocol (RTP). Security could be addressed by encrypting the traffic using IPSec.
