Multicast Introduction


This section provides a quick review of IP multicast. For more information on IP multicast, you can check the authoritative references included in Appendix C and D. Multicast is a term that refers to the ability to send data to a group of receivers. Multicast is used in a wide variety of applications, such as the following:

  • Stock price data in financial networks

  • Network control protocols, such as Open Shortest Path First (OSPF)

  • IETF zeroconf protocol (used in the Mac OSX Bonjour feature)

  • IP/TV

In terms of everyday applications, newspaper delivery uses multicast; you get a paper only if you request (and pay for) it. Cable and broadcast television do not use multicast; all the channels in your subscription package are transmitted to your home, whether you watch them or not.

In networks, multicast provides an elegant solution to two sets of problems. First, multicast is a convenient way to discover resources and peers, such as the use of multicast to communicate between OSPF peers on a shared segment. Second, multicast allows a source to send data to a group of listeners without having to know anything about the group's members.

Note

In our discussion, we contrast network multicast with broadcast. However, broadcast is really a special case of multicast. The difference everyone refers to when decrying broadcast as a "bad thing" is how well network resources are used. Sending any data to all end stations is expensive and should be done only within a limited scope. Multicast routing technology aims to provide the mechanisms to efficiently send data to groups.


IP-based television is an excellent example of an application that would be impossible on a large scale without multicast. As already pointed out, (non-IP) television uses a broadcast model today. The data rates are such that it is not cost-effective to pump hundreds of channels worth of data over broadband links to homes. The last-mile connections are a bottleneck (especially in much of the United Statesother parts of the world are luckier). With multicast technology, an end station can receive data for just a single channel by joining a corresponding multicast group. When the subscriber changes channel, the end station simply changes group. As a result, IP/TV providers need to send only a small subset of the total available data over last-mile links. (Our model is actually a naive implementation of IP/TV. In reality, IP/TV has a variety of deployment scenarios.)

There are a number of requirements to manage groups on a network:

  • The ability to identify groups (Class D addressing)

  • The ability for a host to join and leave a group (Internet Group Management Protocol [IGMP])

  • The ability to route multicast packets (PIM)

RFC 1122 reserves a the range of IP addresses from 224.0.0.0 through 239.255.255.255 as a special category called Class D addresses that are reserved for multicast. A multicast source sends data to a group using a Class D destination address just as a unicast source sends data using an address from outside this range. Routers have forwarding tables that map multicast addresses to outgoing interfaces. These tables are built using multicast routing protocols; the most common in use today is PIM.

Any IP endpoint can join any group at any time by using IGMP. No restrictions apply as to the topology imposed by the network; however, devices may be said to be form a tree, with the source at the root, group members as the leaves, and edges as the network paths that connect them. Figure 9-1 shows how a tree is built up as hosts join a group.

Figure 9-1. Multicast Groups Form a Tree


The next two sections introduce IGMP and PIM.

Internet Group Management Protocol (IGMP)

The IGMP protocol allows routers to manage group membership on their directly connected interfaces. End stations use IGMP to join and leave groups. The protocol has two basic types of messages: query and report.

The formal definition of query and report are (quoting from RFC 3376) as follows:

  • Query Membership queries are sent by IP multicast routers to query the multicast reception state of neighboring interfaces.

  • Report Version 3 membership reports are sent by IP systems to report (to neighboring routers) the current multicast reception state, or changes in the multicast reception state, of their interfaces.

In practice, a query message allows multicast routers to periodically poll for group membership. The router sends a query to ask: "Who wants data from this group?" Multicast hosts signal group membership with a report message. Routers then forward multicast packets on all interfaces on which they received an appropriate report message.

Figure 9-2 shows this interaction with the router querying for members of group 239.1.1.1. Both hosts A and B are members of this group, and host B replies with its IGMP report.

Figure 9-2. IGMP Query/Report Interaction


The queries sent by routers can be general or specific. General refers to all groups known on a receiving interface. Specific, as you might expect, refers to a particular group, or a group-source pair (this last feature is for Source-Specific Multicast [SSM], something that we do not cover here). So, the router can ask: "Who is interested in this specific group?" or "Who is interested in this specific group from this specific source?"

Report messages can be used to join a particular group in either INCLUDE or EXCLUDE mode. In INCLUDE mode, the recipient lists the groups (and, optionally, the source) in which they are interested. In EXCLUDE mode, the recipient simply tells the multicast router which groups it does not want to receive.

Starting from IGMPv2, multicast hosts can join a group without first waiting for a query by sending an unsolicited report message. If this is the first request for a particular group, the router arranges to receive the multicast stream (as discussed in the next section) and forwards the packets on the interface on which it received the report. To stop receiving a stream, a recipient sends an IGMP leave message. A router that receives a leave message must first determinewith a querywhether there are any other recipients on that interface before shutting off the flow of packets.

The IGMP protocol goes to some lengths to avoid chattiness. For example, it defines a random host-based timer mechanism to avoid multiple simultaneous reports being sent in reply to every single query. For any given group, a router needs to receive only a single report on an interface to forward data on that interface.

IGMP is lightweight in its state requirements. An end system tracks only its own group memberships. A router need only track active group memberships on an interface. Note that IGMP does not address how hosts discover multicast sources in the first placethat is the hosts' responsibility.

IGMP packets, which are never forwarded by a router (they are sent with a Time To Live [TTL]=1), are themselves sent to multicast addresses, either 224.0.0.1 (all systems), 224.0.0.22 (all IGMPv3-capable routers), or to a group address (in the case of reports and group-specific queries).

Multicast Routing

IGMP manages the interaction between hosts and routers. Therefore, a different mechanism is required to route traffic from the source to the last-hop router. This is where multicast routing comes in.

You must solve two problems:

  • Building a distribution tree to connect members of a group to the source

  • Forwarding multicast traffic along the distribution tree

Let's start with forwarding first because it is the simpler of the two. Although it uses the same packet format and runs across the same network devices, multicast forwarding differs from unicast routing in one important respect: Routers use a packet's source address to determine which outgoing interfaces to use. Forwarding traffic away from a source (or down the distribution tree, to be more exact) instead of toward a known destination is called reverse path forwarding (RPF). Routers also uses RPF to check that incoming packets are received on the interface closest to their source. This is called a RPF check. Packets that fail the RPF check are dropped. RPF and RPF Checking are critical concepts in multicast forwarding. Consider the network shown in Figure 9-3.

Figure 9-3. Multicast Forwarding


Router R1 receives traffic sent by source S to group address 239.1.1.1. Using its multicast forwarding table, R1 works out that the packets should be sent on interfaces R1-O1 and R1-O2. The next router, R2, does a similar lookup and forwards packets on interfaces R2-O1, R2-O2, and R2-O3. Forwardingand replicationcontinues in this way along the distribution tree until data is delivered to all multicast receivers. Each router in the example also performs a RPF check when it receives the multicast packet.

There are two types of tree: source tree and shared tree. Before we discuss them, note the use of some new notation when discussing multicast routing: (S,G) denotes a source S in group G; (*,G) denotes any source in group G.

Source Trees

The source is the root of the distribution tree. All data is forwarded from the source to the leaves. In a naive implementation, when router R1 in Figure 9-3 receives a packet from source S to group 239.1.1.1, it uses RPF to identify which interface it would have used to reach S (in this case, R1-O1 is the egress interface for the shortest path to S).

Source trees use the shortest path to connect root and leaves. Source-tree-based protocols, such as Distance Vector Multicast Routing Protocol (DVMRP) and PIM dense mode, were once widely deployed. However, most networks now prefer shared-tree.

Figure 9-4. Dense-Mode Pruning and Flooding


Shared Trees

Source trees build different shortest-path trees for every source in a group; in other words, for every (S,G) pairing. shared trees use a single tree for all sources in a group; that is, there is a single tree for every (*,G) combination. Figure 9-5 shows how shared-tree forwarding works. All sources in a group send data to a central rendezvous point (RP), R1, which is the root of the shared tree.

Figure 9-5. Shared-Tree Forwarding


Like everything else in life, shared-tree-based forwarding is not perfect. First, the path between source and leaf is suboptimal compared to the shortest path in source tree. Second, the RP is a potential bottleneck through which all the group's data must flow.

Protocol Independent Multicast (PIM)

PIM is an Internet Engineering Task Force (IETF) protocol designed to allow multicast forwarding independently of any unicast routing protocol (unlike, say Multicast OSPF [MOSPF]). PIM is a parasitic protocol. It relies on unicast routing tableswhatever their sourceas the basis of its own forwarding decisions. Therefore, PIM routers do not send or receive multicast routing announcements.

PIM has two modes of operation:

  • Dense mode (PIM-DM) Uses a source-tree to deliver data. PIM-DM floods packets on outgoing interfacesidentified by RPF checks based on the unicast forwarding tableuntil it receives a prune message. When pruned, data will not be sent on an interface until either the router reverts to flooding or a graft message is received from a downstream router. Figure 9-4 illustrates the pruning and flooding operation used in PIM-DM.

  • Sparse mode (PIM-SM) Uses shared-tree distribution. Downstream routers use join messages to explicitly add themselves to the distribution tree (for example, after receiving an IGMP report from an end station). If a router receives a report message and it is not already part of the (*,G) tree, it also sends a PIM join message in the direction of the preconfigured RP.

We have already established how data is multicast from the RP to downstream routers. How does it get from the source to the RP in the first place? The first-hop router plays a special role in PIM. It encapsulates the multicast packet in PIM-SM-register packets and unicasts them to the RP. The RP can then add itself to the source tree for the source using PIM join messages. In fact, any PIM receiver can elect to move from shared to source tree in this way. The intention was to allow shortest-path forwarding for bandwidth-intensive applications that could notor should notgo through an RP. Figure 9-6 shows sample PIM-SM operation for (*,239.1.1.1).

Figure 9-6. PIM-SM


PIM trees are unidirectional. Traffic flows from the RP downward, not the other way around. Bidirectional PIM allows for traffic to flow between all members of a group by building a spanning-tree network with the RP as the root node. After a PIM shared tree is built, each member node can forward traffic upstream without going through any special registration or negotiation. The last-hop router joins the source tree and sends a prune message to the RP. In this way, a new branch of the shared tree is created, and traffic that initially flowed through the RP now bypasses it. In Cisco IOS, you can prevent the switchover of traffic from shared to source tree using the ip pim spt-threshold command.




Network Virtualization
Network Virtualization
ISBN: 1587052482
EAN: 2147483647
Year: 2006
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net