|
Conferences and Events | Online Resources | Programs | Security | Services | Shared Network | Technical Support | Training Home » Technical Support » Research and Innovation » IP Multicast |
|
Implementing IP Multicast in the MOREnet NetworkBackgroundMany emerging Internet applications exhibit one-to-many or many-to-many connections where one or more sources send to multiple receivers. Examples include real-time broadcasts of stock tickers, audio/video streams, and software/data updates. The traditional unicast IP implementation shown in Figure 1 requires a separate flow between the source and destination for each transmission. Thus, a single sender with ten receivers establishes ten flows; 100 receivers require 100 flows, and so forth. This model does not scale well—the bandwidth required for a single stream multiplied by several thousand recipients (or more) would consume the majority of the traffic capacity of the Internet.
A multicast implementation relies upon a receiver-based protocol and multicast-aware/enabled switches and routers to replicate a single stream to multiple destinations. As shown in Figure 2, a multicast transmission does not establish a stream for each sender/receiver pair. Instead, multicast receivers join a session, but only the devices that are in the path of the closest branch point know about a particular receiver; the sender does not know about any receivers. Thus, only one copy of a transmission exists at any point in the network, thereby providing the bandwidth control and performance utilization required to scale the one-to-many/many-to-many transmission to thousands or millions of receivers.
In unicast applications, bandwidth usage grows at a 1:1 ratio to clients. In multicast applications, the rate is greatly reduced since only one copy exists at any point in the network. As shown in Figure 1, there are five streams of data leaving the source on the first link. On the same link in Figure 2, however, there is only one stream. Each router that receives the multicast stream only copies it to the links that have active receivers, thus saving bandwidth and utilizing the network more efficiently. The example shown in Figure 3 demonstrates bandwidth advantages of multicast versus unicast for distribution of an 8 Kbps audio stream:
To support multicast traffic, all devices in the path between the sender and receiver(s) must be multicast-aware. This includes the routers in the WAN as well as the switches in the LAN. Note that Ethernet hubs are not multicast-aware—they replicate every packet out every port and unnecessarily consume LAN bandwidth by flooding the network with traffic. This also causes all the host machines on the network to process all the multicast packets without regard to addressing, thus consuming CPU cycles and degrading performance. There are some disadvantages to multicast. The most important disadvantage is that multicast is UDP-based, so delivery is best effort. In addition, there is no congestion avoidance mechanism, and applications must be able to deal with duplicate packets due to multicast topology changes. Multicast and MOREnetMOREnet is implementing support in the network infrastructure for multicast and is pursuing opportunities to attach to other multicast-enabled networks to support a global distribution of multicast traffic. In the future, MOREnet clients will be able to join real-time multicasts of audio/video streams, receive software/data updates, and enable one-to-many collaboration and sharing applications. MOREnet is taking a 3-step approach to delivery of multicast to clients:
In supplying IP multicast services, MOREnet is taking a bounded domain approach as shown in Figure 4. Each domain includes all of the inner domains but cannot communicate outside the boundary to the outer domains, thus controlling the scope of the multicast domain. The first domain is the locally administered and controlled multicast domain of the customer network. The second and third domains are MOREnet-controlled; the second domain is a regional group for each MOREnet hub (Columbia/Jefferson City, Kansas City, St. Louis, and Springfield) and the third domain is the entire MOREnet network. The forth domain is the global network—this domain provides access outside the MOREnet network to any connected and multicast-aware systems.
By using this architecture, address space in the 239.x.x.x space, which is not propagated into the global Internet, can be used to constrain multicast traffic to specific regions/networks. This control not only provides bandwidth management, but also provides security since no one outside the administratively-scoped region can join the multicast. Customer ConnectionsIn order for multicast applications to run across the network, customer networks (where the workstations and applications are located) need to be enabled for multicast. Once a multicast policy is available, MOREnet can configure a specific router to accept multicast from a customer site. In addition, bandwidth constraints can be placed on multicast traffic to ensure that it does not overrun unicast traffic and starve other applications from network resources. The most important piece of the customer connection is the architecture of the customer network. Once a multicast packet is delivered to the egress interface of the MOREnet router, the customer network handles its delivery to the receiver. Unless the customer network devices (routers & switches) are multicast-aware, multicast packets are treated as broadcasts. This is not an issue for a single stream on a lightly loaded network, but as streams are added, they are replicated EVERYWHERE. This load can quickly overload a switch or hub, as well as disrupt unicast applications due to lack of bandwidth or processing power (as every NIC has to inspect every broadcast packet). An extremely careful approach should be taken to implementing multicast in a customer network. Since multicast is by nature a hierarchical protocol, multicast will be easier to implement in hierarchical networks rather than flat, star, or bus networks. Deciding which portions of the network should be multicast-aware, and then ensuring that each piece of equipment on those network legs is IGMP- and multicast-aware, is critical. Figure 5 displays an example architecture with Ethernet switches. This same architecture and example also apply to WANs where the switches may be routers.
If each switch in Figure 5 is IGMP-aware, then only the end stations that request a multicast stream will receive it. If they are not IGMP-aware, the switches (or hubs) will replicate the stream to every interface in order to ensure that it reaches its destination. If only a section of the network needs to be multicast-enabled, then just the devices in the path need to be IGMP-aware. For example, if the receivers attached to Switch 6 need multicast, then Switches 1, 2, and 6 need to be IGMP-aware. Since these switches are actively participating in the multicast, they know which ports and devices need to have the multicast packets. All other ports are left alone; i.e., the multicast packets are not replicated out them. This means that Switch 7 will not see the multicast packets, since the requesting device was on Switch 6. In addition to the architecture, a customer needs to determine which routing protocol they wish to use for multicast traffic. PIM sparse-mode and PIM dense-mode are the general favorites and they are the protocols that MOREnet supports in the network infrastructure. The customer will likely need a multicast-enabled router within the network to manage multicast routes, as well as to act as a rendezvous point for local traffic if PIM sparse-mode is used. If the campus/district architecture is not hierarchical, the customer should contact MOREnet for assistance in determining the best implementation for their particular configuration. NotesFor more information about IP Multicast, please refer to these resources:
|
|
|
Copyright © 2001 MOREnet. All rights reserved. Reviewed January 10, 2002.
Contact communications@more.net. DMCA and other copyright information. Site Information: Copyright, accessibility, privacy and other information about this site. PageMinder: Receive an e-mail notice when this page updates.
|