Guest

IP Multicast

Multicast Routing

White Paper

Multicast Routing May 5, 1995

Introduction

Traditional network computing applications involve communication between two computers. However, some important emerging applications such as LAN TV, desktop conferencing, corporate broadcasts, and collaborative computing require simultaneous communication between groups of computers. This process is known generically as  multipoint communications.

Design Considerations

There are three ways to design multipoint networking applications: unicast, broadcast, and multicast.

  • Unicast. With a unicast design, applications can send one copy of each packet to each member of the multicast group. This technique is simple to implement, but it has significant scaling restrictions if the group is large. In addition, it requires extra bandwidth, because the same information has  to be carried multiple times—even on shared links.

  • Broadcast. In a broadcast design, applications can send one copy of each packet and address it to a broadcast address. This technique is even simpler than unicast for the application to implement. However, if this technique is used, the network must either stop broadcasts at the LAN boundary (a  technique that is frequently used to prevent broadcast storms) or send the broadcast everywhere. Sending the broadcast everywhere is a significant usage of network resources if only a small group actually needed to see the  packets.

  • Multicast. With a multicast design, applications can send one copy of each packet and address it to the group of computers that want to receive it. This technique addresses packets to a  group of receivers rather than to a single receiver, and it depends on the network to forward the packets to only the networks that need to receive them.

Multicast can be implemented at both the data-link layer and the  network layer. Ethernet and FDDI, for example, support unicast,

multicast, and broadcast addresses. An individual computer can listen to a unicast address, several multicast addresses, and the broadcast address. Token Ring also supports the concept of multicast addressing but uses a different technique. Token Rings have functional addresses that can be used to address groups of receivers.

If the scope of an application is limited to a single LAN, using a data-link layer multicast technique is sufficient. However, many multipoint applications are valuable precisely because they are not limited to a single LAN.

When a multipoint application is extended to an internet consisting of different media types, such as Ethernet, Token Ring, FDDI, ATM, Frame Relay, SMDS, and other networking technologies, it is best to implement multicast at the network layer.

There are several parameters that the network layer must define in order to support multicast communications:

  • Addressing. There must be a network-layer address that is used to communicate with a group of receivers rather than a  single receiver. In addition, there must be a mechanism for  mapping this address onto data-link layer multicast addresses where they exist.

  • Dynamic registration. There must be a mechanism for the computer to communicate to the network that it is a member of a particular group. Without this ability, the network cannot know which networks need to receive traffic for each  group.

  • Multicast routing. The network must be able to build packet distribution trees that allow sources to send packets to all receivers. A primary goal of these packet distribution trees is to ensure that each packet exists only one time on any given network (that is, if there are multiple receivers on a given branch, there should only be one copy of the packets on that  branch).

IP Multicast

The Internet Engineering Task Force has been developing standards that address each of the issues described above.

  • Addressing. The IP address space is divided into four pieces: Class A, Class B, Class C, and Class D. Classes A, B, and C are used for unicast traffic. Class D is reserved for multicast traffic. Class D addresses are allocated dynamically.

  • Dynamic registration. RFC 1112 defines the Internet Group Membership Protocol (IGMP). IGMP specifies how the host should inform the network that it is a member of a particular multicast group.

  • Multicast routing. There are several standards available for routing IP Multicast traffic:

  RFC 1075 defines the Distance Vector Multicast Routing Protocol (DVMRP).
  RFC 1584 defines the Multicast Open Shortest Path First (MOSPF) protocol—an extension to OSPF that allows it to support IP Multicast.
Two Internet standards-track drafts describe PIM—a multicast protocol that can be used in conjunction with all unicast IP routing protocols. These documents are  entitled Protocol-Independent Multicast (PIM): Motivation and Architecture and Protocol-Independent Multicast (PIM): Protocol Specification.

DVMRP (RFC 1075)

DVMRP uses a technique known as Reverse Path Forwarding. When a router receives a packet, it floods the packet out of all  paths except the one that leads back to the packet's source. Doing so allows a data stream to reach all LANs (possibly multiple times). If a router is attached to a set of LANs that do  not want to receive a particular multicast group, the router can send a "prune" message back up the distribution tree to  stop  subsequent packets from traveling where there are no  members.

DVMRP will periodically reflood in order to reach any new hosts that want to receive a particular group. There is a direct relationship between the time it takes for a new receiver to get the data stream and the frequency of flooding.

DVMRP implements its own unicast routing protocol in order to determine which interface leads back to the source of the data stream. This unicast routing protocol is very like RIP and is based purely on hop counts. As a result, the path that the multicast traffic follows may not be the same as the path that the unicast traffic follows.

DVMRP has significant scaling problems because of the necessity to flood frequently. This limitation is exacerbated by  the fact that early implementations of DVMRP did not implement pruning.

DVMRP has been used to build the MBONE—a multicast backbone across the public Internet—by building tunnels between DVMRP-capable machines. The MBONE is used widely in the research community to transmit the proceedings of  various conferences and to permit desktop conferencing.

Multicast Extensions to OSPF (RFC 1584)

Multicast OSPF (MOSPF) was defined as an extension to the OSPF unicast routing protocol. OSPF works by having each router in a network understand all of the available links in the network. Each OSPF router calculates routes from itself to all possible destinations.

MOSPF works by including multicast information in OSPF link  state advertisements. An MOSPF router learns which multicast groups are  active on which LANs.

MOSPF builds a distribution tree for each source/group pair and computes a tree for active sources sending to the group. The tree state is cached, and trees must be recomputed when a  link state change occurs or when the cache times out.

MOSPF works only in internetworks that are using OSPF.

MOSPF is best suited for environments that have relatively few  source/group pairs active at any given time. It will work less well in environments that have many active sources or environments that have unstable links.

PIM (Internet Draft "Protocol-Independent Multicast [PIM]:Protocol Specification")

Protocol-Independent Multicast (PIM) works with all existing unicast routing protocols. PIM supports two different types of  multipoint traffic distribution patterns: dense and sparse.

Dense mode is most useful when:

  • Senders and receivers are in close proximity to one another.

  • There are few senders and many receivers.

  • The volume of multicast traffic is high.

  • The stream of multicast traffic is constant.

Dense-mode PIM uses Reverse Path Forwarding and looks a lot like DVMRP. The most significant difference between DVMRP and dense-mode PIM is that PIM works with whatever unicast protocol is being used; PIM does not require any particular unicast protocol.

Sparse multicast is most useful when:

  • There are few receivers in a group.

  • Senders and receivers are separated by WAN links.

  • The type of traffic is intermittent.

Sparse-mode PIM is optimized for environments where there are many multipoint data streams. Each data stream goes to a relatively small number of the LANs in the internetwork. For these types of groups, Reverse Path Forwarding techniques waste bandwidth. Sparse-mode PIM works by defining a Rendezvous Point. When a sender wants to send data, it first sends to the Rendezvous Point. When a receiver wants to receive data, it registers with the Rendezvous Point. Once the data stream begins to flow from sender to Rendezvous Point to receiver, the  routers in the path will optimize the path automatically to remove any unnecessary hops. Sparse-mode PIM assumes that  no hosts want themulticast traffic unless they specifically ask for it.

PIM is able to simultaneously support dense mode for some multipoint groups and sparse mode for others.

Conclusion

New computer networking applications continue to create the need for new communication protocols. Multipoint applications such as collaborative computing, desktop conferencing, and  LAN TV have the potential to significantly improve productivity. In order to support these applications it will be necessary to build networks that can implement multicast efficiently.