Introduction to IP Multicasting

Introduction to IP Multicasting

Overview

Before we begin our exploration of IP multicasting and multicast routing protocols, we will examine the models of communication between two or more hosts in an intranet or over the Internet. Any book bearing resemblance to a networking book should include a review of the OSI layered communication model (see Figure 1-1). The communication protocols that exist at the various levels in the OSI layered model interoperate extremely well because of the adherence to a layered protocol model. The original model was developed by the OSI to provide a logical separation between the various functions of a network. This model allows for the interaction of software modules from different vendors to coexist and operate properly as long as the published standards are followed.

Figure 1-1: TCP/IP and OSI layered network models

The lowest layer of the OSI model is the physical layer. The physical layer deals with the electrical and mechanical specifications of a particular transport medium and associated interfaces. Physical layer examples are 10 and 100 Mbit ethernet, synchronous and asynchronous serial links, and ATM, to name a few. The physical layer is concerned with getting bits, in an electrical or optical form, from point A to point B. The physical layer does not care about the structure or format of the data that is being transmitted or received; it is only concerned with delivering ones and zeros from the source to the destination.

The next level in the OSI model above the physical layer is the data link layer. This layer is responsibile for creating frames that contain source and destination addresses, adding error detection and possibly correction fields to the frame, and, of course, incorporating a user’s data into the frame. Protocols at the data link layer are not routable, and examples of such layers are ethernet and token ring.

The layer where a network designer spends the most time is the network layer. This layer handles routing across the Internet and is the most important layer as far as multicasting is concerned. For a protocol to be routable, the addressing scheme must include a network and a host address. The last statement is true for “normal” IP traffic, but not for multicast traffic. As we will see, multicast addresses are not in the form of network/host but represent a group address. Although a network/host address pair is not present in a multicast address, multicast traffic is routable. Examples of routable protocols are IP, IPX, AppleTalk, and DECNet.

The transport layer is used to multiplex and demultiplex data streams between upper layer application processes as seen in Figure 1-2. The three upper layers of the OSI model, application, presentation, and session, have been combined in the application layer in the TCP/IP layered model. Typically, it is more difficult to determine where a particular upper layer application should be logically placed. Networks can be designed without knowing which applications the users are going to be employing. Therefore, the specific application is not important, just the protocol that the application will be using. In fact, we will only concern ourselves with the lower four layers of the OSI and TCP/IP models.

Figure 1-2: Multiplexing and demultiplexing in the TCP/IP model

When an application such as telnet wants to send data, the data is sent to the TCP module at the transport layer and TCP then assigns a number to the local and remote telnet session, allowing TCP to determine the session where the data is to be delivered. IP either receives or delivers data to the UDP or TCP module, depending on the type of application.

Finally, an ethernet frame contains an identifier that identifies the network layer protocol it received the data from or the network layer protocol to which it should deliver the data.

To illustrate the interaction between the different layers in the OSI model, we will follow the flow of data from one host to another (see Figure 1-3). Assume we are running a telnet session between two hosts. User data is generated at the application layer and is then passed down the protocol stack to the TCP module in the transport layer. The TCP layer uses an identifier for the session, which is contained in the TCP header, and passes the TCP segment to the IP module at the network layer. IP then tags the packet as a TCP or UDP packet. When the packet is received at the data link layer, an ethernet frame is constructed with an ethernet header and trailer. The header, among other things, contains a field tagging the frame as one that carries the IP data. Finally, the frame is passed to the physical layer for transmission onto the network media.

Figure 1-3: Data encapsulation

When the ethernet frame is received by the remote host, the data link ethernet module strips off the ethernet header and trailer after determining that this frame carries IP data and passes the data to the IP module in the network layer. IP determines if the packet is a TCP or UDP packet and passes it to the appropriate module at the transport layer. Finally, TCP extracts the user data and sends it to the proper user process.

Figure 1-4a: Resolution of IP to ethernet address mapping

Figure 1-4b: Resolution of IP to ethernet address mapping, step two

Figure 1-4c: Resolution of IP to ethernet address mapping, step three

Unicast IP Communication Model

Three models exist for communication between hosts on a network whether or not the network is an intranet or the Internet. The first model is the unicast model, which is one-to-one communication. In Figures 1-4a through 1-4c, one host desires to send traffic to another specific host on the same IP subnet (IP addressing and subnets are covered in detail in Chapter 2, “Internet Protocol (IP), Unicast, Broadcast and Multicast Addresses”). For the ethernet Local Area Network (LAN), the hosts must contend with two different address schemes. The first scheme is the ethernet address that is burned into the Network Interface Card (NIC). The ethernet address is a six-byte (48-bit) link layer address that is globally unique and cannot be changed. Because the ethernet address is burned into the NIC, the ethernet address of the host changes if the NIC is changed. We have seen that on an ethernet LAN all data traffic is encapsulated in frames. Even though the host is sending to an IP address, the IP packet must be encapsulated in an ethernet frame. To accomplish the encapsulation, the sending host must resolve the receiving host’s IP to ethernet address mapping. The mapping is accomplished using the Address Resolution Protocol (ARP).

In Figures 1-4a-c, host A wishes to send a packet to host B. Host A knows the IP address of host B but not the ethernet address of host B. The ARP process, illustrated in the figures, proceeds as follows:

1.   Host A sends an ARP broadcast (see Figure 1-4a) that all hosts on the network receive, including the router.

2.   Host B receives the ARP and recognizes that the IP address contained in the ARP request belongs to host B. Host B sends an ARP reply that contains the ethernet address for host B (see Figure 1-4b).

3.   Host A can now encapsulate the IP packet in an ethernet frame and transmit the frame to host B (see Figure 1-4c).

a. Host A sends an ARP request for IP address 172.16.1.2.

b. Host B responds with its ethernet address.

c. Host A can now send to host B.

If host A wants to send a packet to a host on another IP subnet, then the packet must be sent to the router. Host A will have a default gateway configured that points to the router interface attached to the LAN containing host A. Because the destination IP address is on a different subnet, host A knows to send the frame to the router and will send an ARP for the router’s ethernet address. When the router receives the frame, the IP packet is extracted and the router determines from the destination IP address whether or not the destination is on a directly connected network. If it is on a directly connected network, the router sends an ARP onto that network to resolve the ethernet address of the destination. When the ARP reply is received from the destination, the router can build an ethernet frame containing the IP packet and then send the frame to the destination. If the destination is not on a directly connected network, the router consults the routing table and determines the next router where the frame should be sent. IP unicast routing protocols are not covered in this book, but references are listed at the end of the chapter for further study.

Figure 1-5: Broadcast communication model

Broadcast Communication Model

The broadcast model is one in which a host sends to everyone on the subnet. ARP is not needed because the ethernet broadcast address is a well-known address with the value 0xFF FF FF FF FF FF (Broadcast IP addresses also exist and are covered in Chapter 2). In the unicast model, a host could send an IP packet to any host on any network (assuming we have a route to the destination host). In the broadcast model, the scope of the broadcast is the local subnet. Routers block broadcast traffic, so the scope of a broadcast is limited to the local subnet (see Figure 1-5).

Multicast Communication Model

Now the fun begins. The problem to solve here is the one-to-many communication scenario. If a host wants to send the same packet to more than one receiver, how can this be accomplished? We can try using the unicast communication model and would be successful, but problems occur. Assume host A wants to send a packet to five hosts using the unicast model. This implies that host A knows the IP address of each receiver. If this is the case, then host A would need to send the same packet to five different IP addresses, as shown in Figure 1-6.

Figure 1-6: Using the unicast communication model to achieve multicasting capabilities

As the number of receivers increases, the number of packets that needs to be sent increases linearly. In other words, for n receivers, the host would need to send n copies of each packet. If the host is sending a real-time audio or video presentation, this solution may be workable for very few receivers, but as the number of receivers increases, the load of replicating packets on the host would be such that the delay between distinct packets would be unacceptable. Also, the links on the source router, router E in Figure 1-6, would have the bandwidth severely depleted.

Another major problem with this scheme is the host not knowing where the receivers are. If the receivers that require the traffic don’t change, then they could be entered, but this would be extremely restrictive because new receivers could not dynamically join or leave the group. And what about the broadcast model? Certainly every host on the local subnet would receive the traffic and each packet would only have to be sent once. So what’s the problem? Two come to mind. The first is that only receivers on the same subnet receive the traffic, while receivers on other subnets cannot receive it because the router blocks broadcasts. This is probably a good thing because we don’t want a broadcast to be delivered to the whole world. Yes, some people would like to do this, but in general it is not a good idea.

The second problem with using a broadcast is that every host is required to process the ethernet broadcast in order to determine if the traffic is intended for the host. The IP packet would have to be extracted from the ethernet frame and, because the destination IP address is also a broadcast address, the UDP or TCP portion of the packet would need to be extracted and passed up the protocol stack. If there is a process expecting the data, it would be passed to the application layer. If there is not a process expecting the data, then the data would be discarded. For those hosts not expecting the data, this would be a waste of valuable processing time and a source of many user complaints. Looks like we need another model.

For the multicast communication model, we will need two new types of addresses, an IP multicast address and an ethernet multicast address. An IP multicast address identifies a group of receivers that want to receive traffic destined for the group. Because all IP packets are encapsulated in ethernet frames, a multicast ethernet address is also required. For the multicast model to function correctly, hosts should be able to receive both unicast and multicast traffic, which mandates that hosts need multiple IP and ethernet addresses. A unicast IP and ethernet address are used for unicast traffic and zero or more IP, and ethernet multicast addresses are used for multicast traffic. Zero multicast addresses are needed if the host will not be receiving multicast traffic. A pair of multicast addresses, IP and ethernet, are required for each multicast group that the receiver wishes to join. A major difference between the unicast and multicast addresses is that unicast addresses are unique on each host, while multicast addresses are not. If five hosts wish to receive multicast traffic destined for group A, for example, then the hosts would all listen for traffic destined for the same multicast address, both IP and ethernet. The amount of traffic from the unicast case would be greatly reduced, as shown in Figure 1-7.

Figure 1-7: Multicast communication model

Another characteristic that we would like to have with the multicasting model is the capability for dynamic group membership. A host should receive traffic for a particular multicast group only if there is an active application running that requires the data. Hosts should have the capability to join and leave multicast groups at will, eliminating the need for static group assignments. Efficient use of available bandwidth dictates that routers need to know whether or not the router needs to route multicast traffic to group members. The router must therefore be aware of the dynamic group membership information and must have routing protocols that can handle multicast traffic.

Outline of the Book

The presentations of the solutions to the requirements stated above comprise the remainder of this book. Chapter 2 presents the unicast and multicast IP addressing scheme in detail. Chapter 3, “Internet Group Management Protocol,” deals with the Internet Group Management Protocol (IGMP), the protocol that is used between hosts and routers to report dynamic multicast group membership.

Chapter 4, “Cisco Group Management Protocol,” discusses a proprietary Cisco protocol for determining group membership on a switch. The protocol, Cisco Group Management Protocol (CGMP) is used to limit multicast traffic on a virtual LAN (VLAN) to those hosts that wish to receive it.

Chapter 5, “Distance Vector Multicast Routing Protocol,” begins the study of multicast routing protocols with the Distance Vector Multicast Routing Protocol (DVMRP), which is used on the Internet Multicast Backbone (MBONE). Cisco does not support a full DVMRP implementation but can interact with DVMRP for the exchange of routes from the MBONE into the local environment.

Chapter 6, “Protocol Independent Multicast — Dense Mode,” and Chapter 7, “Protocol Independent Multicast — Sparse Mode,” cover two flavors of the Protocol Independent Multicast (PIM) protocol. The first is referred to as PIM Dense Mode (PIM-DM). PIM-DM is typically used in a LAN environment, while the second flavor, PIM Sparse Mode (PIM-SM), is appropriate for Wide Area Networks (WAN). Both PIM-DM and PIM-SM have implementations on Cisco routers.

Connecting DVMRP and PIM networks is covered in Chapter 8, “PIM-DVMRP Networks.” Because the MBONE runs DVMRP and Cisco implements PIM, a mechanism is needed for DVMRP-PIM interaction.

Multicast configuration commands that can be used with any of the Cisco-supported multicast routing protocols are discussed in Chapter 9, “Multicast Support Commands.” Chapter 10, “Resource Reservation Protocol,” takes us from multicast routing protocols to a protocol that is not used for routing but for reserving resources along the path from a multicast sender to a multicast receiver. The Resource Reservation Protocol (RSVP) is an Internet control protocol that can be used by multicast receivers to request a specific quality of service (QOS) for the data flow from a unicast or multicast source.

In each chapter that covers a Cisco-supported protocol, all Cisco router commands for configuring, monitoring, and debugging the protocol are presented with network scenarios to demonstrate their use. This is where I believe the value of this book becomes evident. Although the information for the specific routing protocols is contained in the appropriate Request for Comment (RFC) and extensive documentation exists from Cisco for multicast router configurations, I hope my explanations and examples will be used to supplement this information and fill in any gaps that may exist.

Recommended Reading List for IP Routing Protocols (RIP, IGRP, EIGRP, OSPF, and BGP)

Cisco Router OSPF Design and Implementation Guide, William R. Parkhurst, CCIE a2969, McGraw-Hill

Advanced IP Routing in Cisco Networks, Terry Slattery, CCIE a1026, and Bill Burton, CCIE a1119, McGraw-Hill

Cisco TCP/IP Routing Professional Reference, Chris Lewis, McGraw-Hill

Internet Routing Architectures, Bassam Halabi, Cisco Press. This book is an excellent presentation of the Border Gateway Protocol (BGP)