Multicast Communication

Unicast is a one-to-one communication model; multicast is a one-to-many model. Unicast is used to create an individual connection through which data can be sent reliably between two hosts; Multicast is used to send data to many hosts at one time without a direct connection. The notion of a networking system, in which there is no direct communication between server and client—a broadcast model of networking—is not a natural extension of modern networks, specifically IP networks.

Multicasting was created many years ago to enable host computers to communicate in groups, called multicast groups. For example, four end users could connect to a multicast group, and send and receive text messages that would be read by all the users in the group. Today this sort of communication is most often handled with a unicast solution, such as an instant messenger system in which a number of users connect to a chat server. Collaboration is made possible by the chat server, and each user connects to the server using a unicast protocol. Multicast today is used primarily for one-to-many communication, such as broadcasting streaming media. Applications can also use multicasting for file distribution, pre-stuffing data to caches, and sending messages between systems.

In the unicast model, communication is initiated by a client. The content sits on a server until a client requests it. In the multicast model, the server sends the stream regardless of whether there is a client to accept it because there is no communication between client and server. In the unicast model, a client reaches a server using the server’s IP and MAC addresses. In the multicast model, a client makes a request to join a multicast group, using the group address. Instead of addressing an IP packet to a specific client, the server addresses multicast packets to a multicast group. And instead of a client sending a request directly to a server, a client sends a request to join a multicast group, which is received and handled by routers and switches in the network.

To distribute multicast traffic on a network, network infrastructure devices such as routers and switches exchange information by using a system of communication protocols. The information enables the devices to set up distribution paths for the multicast packets. In order for a network to handle multicast, therefore, the devices must be configured to use the protocols.

There are several types of one-to-many communication models reflecting the improvements made over the years. Since Fabrikam will be configuring a new system, we do not need to dwell on understanding the history of multicasting. But it is helpful to understand how a simple one-to-many system works.

IP Broadcasting

Unicast is the basic one-to-one communication model. IP broadcast, on the other hand, is the basic one-to-many communication model. IP broadcast should not be confused with broadcast in Windows Media. Windows Media live streams can be broadcast to many clients using the unicast or multicast model, but not IP broadcast. In IP broadcast, the server sends IP packets that reach every part of the network. Routers block broadcast traffic, so the scope is limited to a local subnet. Figure 22.1 shows an IP broadcast.

Figure 22.1: An example of IP broadcasting.

The problem with IP broadcast is that it does not scale well. If it were possible to configure all routers to pass IP broadcast traffic, the packets would flood the network. Even if only three users requested the packets, the traffic would still consume bandwidth on all segments of the network. Imagine a network using many low-bandwidth WANs, and then adding a number of IP broadcast streams. Imagine the multitude of bandwidth and collision problems if you were to attempt this on the Internet. A simple IP broadcast solution is fine on a small network. However, as you increase the number of clients, the scope of the broadcast, or the number of concurrent broadcasts, the solution quickly becomes impractical.

In the multicast model, a stream is restricted to only those paths where it is requested by clients. This traffic control is handled primarily by routers and switches, using a system of messages and timers. In the multicast system, routers and switches do not pass multicast traffic until a request is received from a client.

The key to understanding multicast is having a clear picture of the messages that network components send to each other in order to add or delete distribution paths. In this chapter we will focus on the system implemented at Fabrikam. The system uses Internet Group Management Protocol version 2 (IGMPv2) to send messages between the client (the computer requesting a stream) and the router. It also uses the Protocol Independent Multicast-Sparse Mode version 2 (PIM-SMv2) to direct multicast traffic between routers. There is no communication between the source or server and a network device, because it is the client request that initiates the routing of the multicast packets.

Communication Between Clients and Routers

Routers that connect directly to clients are sometimes called leaf or last-hop routers because they are on the ends of network branches. IGMP is the protocol used for communication between a client and the leaf router. In IGMPv2, there are three types of messages:

• Membership Query. Sent by a router to determine whether any clients are members of a multicast group.

• Membership Report. Sent by a client if it receives a query message and is a member of a group. A client also sends a membership report to initially join a group.

• Leave Group. Sent by a client when an end user closes the multicast stream on the Player.

When a leaf router receives a membership report, it begins a process to locate and route the stream to the client. After it starts forwarding multicast traffic, it periodically queries all clients on the interface. If no clients return a membership report, the router terminates the traffic and initiates a process to stop (or “prune”) traffic from other routers. If the router receives a Leave Group message from a client, it will immediately query all clients on the interface and terminate the stream if it gets no response within a specified time.

As long as a router receives periodic membership reports, it forwards the stream on one or more of its interfaces regardless of whether the stream is being received by one client or 1,000 clients. In PIM-SMv2, the multicast state of the router depends on the messages it receives, both from other routers and from clients.

In IGMPv2, the Membership Report message contains only the address of the multicast group the client is requesting. The client has no routing information about the source of the multicast, just as the source has no information about the clients who want the stream. It is up to the routing system to determine how to locate the multicast source or stream and forward the packets to the client.

Communication Between Routers and Switches

A router is a layer 3 device, which means it reads the IP address of packets. By reading IP addresses, it determines which packets are multicast packets, and on which interfaces to route the traffic. A switch, on the other hand, is a layer 2 device, which means it reads the Ethernet or MAC addresses of frames, which are encapsulated packets. MAC addresses do not provide enough information for routing multicast traffic, so when a switch, hub, or repeater receives a multicast packet, it forwards the packet to all ports. This is sometimes called “flooding” the ports.

Without a system for controlling the flow of traffic through a switch, much of the gains made with router control would be lost. For example, a subnet containing 150 clients would be flooded with a multicast stream, even if only one client requested the stream. The solution that many switches use today is called “IGMP snooping.” Switches that have this feature are able to read the IP headers of packets in order to separate IGMP messages from other multicast packets. With this information, the switch can forward multicast traffic to only those ports on which an IGMP membership report was received. Most switches that offer the feature can also remove the connection when an IGMP Leave Group message is received.

Cisco routers and switches can be configured to use the Cisco Group Membership Protocol (CGMP), which relieves the switch from the task of reading IP headers. When a CGMP-configured router receives an IGMP Membership Report from a client, the router sends a CGMP message to the switch. The switch then forwards multicast packets only to that port.

After the source computer has delivered packets to its leaf router and the client has requested the packets from its leaf router, the routers that make up the infrastructure of the network send and receive messages to locate and forward the traffic to the client.

Communication Between Routers

When a router receives either an IGMP membership request from a client or a multicast packet from a source, it starts communicating with other routers by sending and receiving messages. Fabrikam will use PIM to route multicast traffic. This protocol can be implemented in either dense or sparse mode. Fabrikam will use sparse mode (PIM-SMv2), in which all requests for a multicast group are sent through a router designated as a Rendezvous Point (RP). Figure 22.2 shows an RP in a network. A network can have multiple RPs that can each handle multiple multicast groups. However, there is normally only one active RP for each multicast group address.

Figure 22.2: A Rendezvous Point (RP) in a multicast-enabled network.

The alternative to using RPs is for clients to reference a multicast from its source. Source-based routing is used in dense mode, which is not used as often because it is based on a “flood and prune” model. In this model, the network is first flooded with multicast traffic, and then pruned back on those branches that have no clients requesting the multicast. As you might imagine, flooding areas with multicast packets is not an efficient method for managing bandwidth. Also with dense mode, routers must maintain more state information, which requires more memory and processing.

In sparse mode, no multicast traffic is forwarded until a client requests a stream. Then the stream is routed through the RP to the client. Forwarding of multicast packets can be handled quickly and there is no flooding.

Dense and sparse modes produce what are commonly called source trees and shared trees, respectively. These trees create multiple, branch-like paths that lead away from the source or RP to multiple clients. A router can be assigned as the RP statically or by using a dynamic method that provides redundancy in the event an RP router should fail. Fabrikam will use the static method.

In order to get the packets from here to there, a complex system of messages and timers is used to open and close paths. The object of the routing mechanism is to provide a high-quality user experience and make the most efficient use of network resources and bandwidth. The following points describe the router messages that apply to PIM-SMv2 with a static RP:

• Hello. A router periodically sends a hello message to neighboring routers to confirm the presence and status of the router.

• Register. When a leaf router receives multicast packets from a source, it sends a register packet to the RP. This initiates the process of creating a path for the source stream to the RP. Register packets are unicast packets that encapsulate the multicast packet.

• Register-stop. The RP sends a register-stop packet back to the source leaf router to stop sending register packets.

• Join/Prune. A join message causes an upstream router to route packets from a multicast group on the interface on which the join was received. A prune message causes an upstream router to stop sending the multicast group out of the interface. Joins and prunes are initiated when a leaf router receives a Membership Report or Leave Group message from a client.

• Bootstrap. A message from the selected bootstrap router (BSR), which is used to announce the presence and location of the RP to all routers. The bootstrap system was developed for PIM-SMv2. Many multicast systems still use the Auto-RP method of dynamically assigning RPs that was developed by Cisco for PIM-SMv1. If Auto-RP is used, a message similar to the bootstrap message is used to announce the presence of an RP.

• Assert. Determines a designated forwarding router for a multi-access network. This method eliminates the situation where a router receives the same multicast packet from multiple routers connected to different interfaces.

When a leaf router receives an IGMP membership report from a client or a mult-icast packet from a source, it initiates the process of forwarding the multicast stream to the receiving clients by routing the stream through the RP. When a leaf router receives a Membership Report, it sends a join message to the RP, which then begins sending the multicast stream out the interface that the message was received on.