Internet Multicast
A wealth of challenges face implementers and equipment designers interested in providing multicast solutions over the Internet.
By Mike Rodbell
The ability to transmit information from one machine to a particular group of machines on data networks is a result of the evolution of technology. In the early days of internetworking, information was generally transmitted directly from one machine to another. These transmissions were referred to as unicast.
In recognition of certain applications where it could be useful for a single machine to transmit the same information to several computers, broadcast capabilities were introduced. While the
ability to broadcast information helps to conserve network resources, it presents some challenges. Broadcast transmissions cause all machines to absorb the broadcast traffic, regardless of their interest in receiving the information. The problem becomes even more complex when considering the impact and complexity of routing broadcast traffic through a network. If the proper mechanisms don’t exist, transmissions can find their way into routing loops that feedback, causing storms of traffic. Think of
these loops as having an effect similar to sticking a microphone directly in front of the speaker carrying the amplified sound from the microphone. Nothing terribly useful other than noise results.
Given these sets of problems, it became clear that selective broadcast, or multicast, services represent an ideal goal and offer solutions to many of these concerns. So, engineers set off to identify those solutions. The problems come in several flavors:
Addressing schemes must be implemented to
uniquely identify multicast traffic destinations.
Dynamic addressing schemes are required to handle applications that have only intermittent needs for multicast service addresses. There are a finite number of addresses available on the Internet. As multicast transmission feeds are initiated, addresses can be assigned. When the transmissions are complete, these addresses should be returned to a free list for other applications.
Systems must have a way to identify themselves as being interested in receiving
information from particular multicast traffic streams.
Routers must be able to communicate their interest in processing multicast traffic to construct routing information bases for multicast traffic distribution.
As multicast traffic is distributed through the network, the routers must have algorithms that can be used to determine the routes to be used to forward the multicast traffic. Remember that mistakes in these algorithms can be costly. Routing loops can render all occupied subnetworks
useless.
There have been a number of techniques developed to address each of these issues. Some standards address isolated portions of the problem, where others may encompass multiple issues. For example, some of the routing standards are data driven, relying on the effects of the multicast transmissions to discover the optimal paths through the network. With this wealth of challenges, it should be fairly obvious how this topic can easily turn into an all-consuming task. Fortunately, several people, and
companies, have focused on each of these areas to arrive at a number of solutions. This month, let’s review some of the major accomplishments that address each of these issues.
The multicast backbone (MBone) project has been a fertile ground for research into the implementation of multicast services on IP routed networks. Combine the results of this research with the many creative uses of IP networking, such as the push technologies introduced over the last few years, and there is significant reason to
believe that multicast protocols have started to mature.
Multicast addressing
In the domain of IPs, there are two primary considerations in the allocation of multicast addresses: the IP (network layer) and the link layer addresses. Within the context of the IP addresses, there is a set reserved for multicast. The addresses between 224.0.0.0 and 239.255. 255.255 are called class D addresses and are reserved for multicast. Several of these addresses have been reserved, much as static addresses
have been allocated. Some of these reserved addresses are:
224.0.0.1: All systems on the local subnet
224.0.0.2: All routers on the local subnet
224.0.0.4: Distance vector multicast routing protocol routers
224.0.05: Open shortest path first (OSPF) all routers
224.0.0.6: OSPF designated routers.
There are also several other cases of multicast IP addresses that have been reserved for a range of routing and system management protocols. These static address assignments are doled out
by the Internet Assigned Numbers Authority (IANA), in much the same manner as normal static-address assignments. Dynamic-address assignment techniques have also been developed — more on those in a moment.
Where the IP addresses are used to indicate multicast destinations over the network layer, there are a number of mechanisms to represent multicast addresses over the link layer protocols. The most prevalent mechanisms are found within the constraints of the 48-bit LAN, media access control (MAC)
formats used over IEEE 802 class networks.
There are a few peculiarities to multicast addressing over the standard 48-bit LAN addresses. Whereas these addresses originally had an organizationally unique Identifier (OUI) to identify the equipment manufacturer, a standard OUI has been defined for the Internet Engineering Task Force (IETF) by the IEEE. When combined with the multicast bit (set to indicate a multicast transmission), the 3-octet OUI leaves 3 more octets for group specific addressing.
Fortunately, multicast transmissions of IPv4 traffic have a convenient addressing characteristic of requiring 3 octets to uniquely identify the actual multicast IP address. This is due to the fact that the IP class D addresses always have the same value in the first octet of the address. Therefore, equipment can graft these 3 bytes into the address. As a result, it becomes a fairly simple matter for device drivers to selectively receive only the IP multicast traffic that it’s interested in receiving. At a LAN
level, this addresses the inherent broadcast problem of consuming the unnecessary resources of all participating equipment.
Address assignment mechanisms
Some applications need to only exist for brief periods of time or need to use more than a single multicast address at a time. In these cases, it is helpful to have a way to dynamically assign addresses. Consider, for example, a distributed learning system in which many course presentations need to run at the same time. Each course also only
lasts a finite period (say between one and three hours). A central application can signal an interest in registering an IP Multicast address for use during the class. The class participants can then locate the multicast address of the class and develop the necessary application level associations. When the class ends, the multicast addresses can then be released for the use of other courses or applications. There have been a few research efforts (and software) targeted to solving the address management
services. There are a few applications that implement the session advertising protocol (SAP), including the session directory (SD) and its subsequent version SIR (no particular words apply to this acronym), used to help manage sessions on the MBone.
Multicast group membership
Multicast group membership services are used to allow end-stations to identify their interest in participating in particular multicast groups. The Internet Group Management Protocol (IGMP), and its successors, are used to
provide these services. There have been two released versions of this protocol, with subsequent performance and scaleability improvements planned. In general, the services provided by IGMP are sufficient enough to allow routers to determine which multicast groups are represented on each of their attached subnets. Through this knowledge, the routers can then actively participate in the various multicast routing protocols.
Multicast routing
Perhaps the most complicated portion of multicast network
transmissions is routing. Automatic identification of the most efficient routes through the network presents a range of challenges. Routing loops must be avoided. Sparse distribution of group members can lead to an excessive control-traffic load. Dynamic group memberships, network topologies, and performance characteristics dictate a need for algorithms and protocols that can adapt as the networking environment changes.
In general, the concept employed in multicast routing is to provide intelligent
forwarding of multicast packets in a path that directs the packets away from the initial source. If these two objectives can be met, network use can be kept to an absolute minimum, and routing loops can be avoided.
There are two general types of architectures that have been applied to handle the routing of multicast traffic: “broadcast and prune” and “shared trees.” In the case of broadcast and prune architectures, multicast information floods through a portion of the network until routers
reject the traffic, pruning themselves from the distribution of multicast traffic for that particular session. Shared tree approaches are different, in that central points of attachment are defined for the distribution of multicast traffic. In the shared tree approach, the multicast routes must be defined prior to the transmission of data through the network.
There are a number of multicast routing protocols in active use with many more in various stages of research, design, and experimentation. Multicast
protocols that are now in active use include the following:
Distance vector multicast routing protocol (DVMRP)
is loosely based on the standard routing information protocol (RIP). DVMRP constructs and manages tables of routing hops toward specific multicast traffic sources. Through DVMRP, multicast routing is handled through the reverse-path multicasting (RPM) approach, which identifies multicast routerals through a pruning algorithm.
Multicast OSPF (MOSPF)
constructs link-state
tables that identify the routes for multicast traffic within two general levels of the network topology — autonomous systems or areas, and the backbone interconnecting the autonomous systems. MOSPF constructs source-based distribution trees in which nodes and area routers explicitly announce interest in receiving the multicast traffic.
Protocol independent multicast (PIM)
is divided into two general classes of PIM, PIM-dense mode (PIM-DM), and PIM-sparse mode (PIM-SM). Of these two, PIM-DM is
better defined. The term “protocol independent” refers to the ability to operate PIM regardless of the particular unicast route-information protocol being employed.
These three protocols all address the general needs of a DM multicast environment. As the members of the multicast group spread among wider areas, all three of these protocols begin to require considerable network resources to manage the traffic distribution. This use of bandwidth directly contradicts the original intent of the
multicast protocols to help conserve bandwidth. This problem has become evident in the MBone, where DVMRP remains the multicast routing protocol of choice. As a result, several efforts have been initiated to design protocols that address the SM-multicast distribution issues. The PIM-SM protocols are being defined around core-based trees that use core routers to act as focal points for groups of systems involved in widely distributed multicast applications.
As you should now see, implementers and
equipment designers interested in providing multicast solutions over the Internet face many challenges. Since the inception of the MBone in 1992, application of a number of protocols and approaches to solve the efficient distribution of point-to-multipoint traffic have been tried. As the commercial viability of the use of multicast over the Internet grows, the protocols and approaches will surely converge on a more coherent, and interoperable, set of multicast-data networking standards.
Mike Rodbell is
director of embedded software development for CIENA Communications Inc. He has developed voice and data communication systems for a wide range of commercial and military systems. He holds a BSCS from Trinity College of Hartford, CT, and an MSEE from Loyola College of Baltimore, MD. He can be reached at mrodbell@ciena.com or http://www.ciena.com.
Puzzled by a network processing design issue?
