February 1999

Reliable Multicast For Remote Server Synchronization

BY KEN MILLER

Multicast IP network services offer new opportunities to provide value-added applications that involve many to many transmissions such as conferencing or network gaming, or one to many applications such as multimedia events, tickertape feeds, and general data delivery - where the many could be thousands or even conceivably millions.

Multicast IP services use a different kind of IP address called Class D. In contrast to individual addresses (Class A-C), which include a host and network component and are usually semi-permanent, Class D multicast addresses, by design, may be used only for a particular session. They can also be semi-permanent, as multicast groups may be set up and torn down in a matter of seconds.

Hosts join groups at the receiver's initiation using the Internet Group Management Protocol (IGMP). When a host joins a group, it notifies the nearest multicast subnet router of its presence in the group. IGMPv1 was first defined in RFC 1112 and is still the version of IGMP most widely supported. IGMPv2 has recently been documented as an official RFC in RFC 2236. The main feature of IGMPv2 is reduced latency for leaving groups. In IGMPv1 - the designated multicast router for the subnet polls for multicast group members - no response between polls indicates all hosts in a particular multicast group have left the group, and the routers can prune back the multicast routing tree.

Network infrastructure devices like routers need to provide a routing protocol to forward multicast packets to group members, in a fashion similar to unicast routing. Multicast IP packet forwarding is best effort, just as with unicast packet forwarding. However, most unicast applications use TCP as a transport layer to provide guaranteed packet ordering and delivery. Some examples of applications that use TCP are FTP for file transfer and HTTP for Web access.

However, TCP is a unicast (point-to-point) only transport protocol. Thus, all multicast applications must run on top of UDP or alternatively, interface directly to IP via "raw" sockets and provide their own customized transport layer. UDP provides only minimal transport layer services, error detection, and port multiplexing. Thus, if there are any errors or if there was packet loss due to congestion, packets are simply lost to the application and not recoverable. Thus, all multicast applications must have a specific transport layer service to support that particular application. When that transport layer operates over UDP, it operates in the application layer. When it interfaces directly to IP, it is specialized to the particular application that uses it.

It should be pointed out that TCP only supports data reliability and is not suited for transport of multimedia streams, which require consistent time delivery at the receiver and only need to be semi-reliable. Thus, multimedia streaming applications need a specialized transport layer such as the Real Time Protocol (RTP) for unicast as well as multicast transmissions.

Many equate multicast with multimedia, thinking that the Internet and private Intranets will become an alternative entertainment media to television using multicast IP network services and multimedia streaming technology. However, there are a large number of other multicast applications, which require reliability rather than timeliness. These are multicast applications that are similar to those unicast applications that operate over TCP except that delivery is to many recipients rather than just one.

USING RELIABLE MULTICAST
Corporations and other organizations are increasingly becoming geographically dispersed. Companies are merging, creating different large geographic pockets of the organization, which need to stay coordinated with each other. Additionally, it is becoming a more competitive and fast moving world, where technology is being used by organizations to both become more efficient and be able to move more rapidly to changing market conditions. This technology needs to be dispersed to the far-flung geographic areas of the organization cost effectively and rapidly.

To avoid killing wide-area networks with needless traffic, local servers are increasingly being deployed at a rapid pace at remote sites to service desktops at other sites. This deployment creates the need to keep these servers updated with software, documents, and any other relevant information for the personnel at that site. It also creates the need to manage these computing resources, and the only cost effective and rapid way to do that is centrally.

The requirements for remote server synchronization consist of the following:

• Content should be able to be distributed to many thousands of sites at not much more time than required for delivery to one site (CD-ROM delivery via snail mail is unacceptable).
• Content organization on the remote server should be able to be managed from the central site.
• Software should be able to be delivered and installed at remote sites with minimal, if any, assistance from personnel at the remote site.
• Groups of recipient servers should be able to be set up and administered from the central site.
• Status of each remote server should be able to be monitored and managed from the central site.
• These capabilities should be made possible without having to spend inordinate amounts of money on communications and computing infrastructures (i.e., only modest bandwidth and one central server should be needed).

The bottom line is that the organization should be able to deploy new technical solutions to remote locations rapidly without requiring support from remote technical personnel. Additionally, there should not be a requirement for large expenditures for network bandwidth and server resources.

THE SOLUTIONS
Reliable IP multicast and an underlying multicast IP network infrastructure are ideal tools to solve the problem of remote server synchronization effectively. Content of all kinds may be sent once from the source and replicated inside the network efficiently to provide simultaneous delivery to thousands of recipients at the same speed one transmission previously took. What was only possible by CD-ROM delivery to this number of sites via snail mail is now possible in minutes or hours electronically over the organization's network.

Alternatively, if the underlying network infrastructure is not currently IP multicast ready, "tunneling" multicast packets inside unicast packets may be used to traverse pieces of the network that are not multicast enabled. Virtually all router manufacturers support tunneling. Additionally, StarBurst Software offers some software called "FanOut" which provides most of the benefits of multicast routing in the network by adding servers in judicious places in the network (see sidebar entitled Starburst Fans Out Multicast Routing. The FanOut software essentially provides static multicast routing in the network at the application layer and requires no change to the existing router infrastructure.)

Server synchronization involves the delivery of all forms of content to keep remote servers consistent with each other in all regards: Software loaded on the server, content resident on the server, and "state" of the server. If the servers are all the same, it makes them easier to manage from a central site. Central site management is extremely cost effective; it allows scarce technical resources to be concentrated centrally, providing a cost-effective way to utilize these resources. Fast and efficient delivery of content to remote servers allows technology to be deployed rapidly, providing a competitive advantage to those organizations using technology to benefit their business. The efficient part of the equation means that these services may be provided without breaking the budget for WAN networking costs.

CENTRALIZED GROUP MANAGEMENT
Server synchronization can be accomplished without the knowledge or support of personnel at the remote site. As such, it is essential that groups be set up centrally and content that is to be delivered to a particular group needs to be scheduled centrally without any involvement of remote sites. Certification of delivery is required to provide the information to centralized administrators that content was in fact delivered and, if not, to reschedule delivery at a later time. Centralized group management also provides full reporting, so transfers, installations, and remote content management can report back to the central location about their status.

IP multicast group host activities are receiver initiated events as previously described. Centralized group creation/destruction requires a mechanism to notify receivers to take action based on that notification. This could be accomplished many ways - the trick is to make it scalable to very large groups, i.e., thousands of group members.

No standardized protocol exists to accomplish this. The MMUSIC working group is responsible for protocols in this area in the Internet Engineering Task Force (IETF), and it has created protocols such as Session Announcement Protocol (SAP) and Session Description Protocol (SDP) for advertising and describing content to give receivers the knowledge needed to decide to join groups. Essentially, these are the equivalent of an electronic "IP TV Guide," and do not offer centralized group management tools.

The specific group model desired for remote server synchronization is the MFTP Closed Group. The significance of the Closed Group is that it provides the ability for a sender to completely define a multicast group and direct them to join the group using IGMP and further, to "register" back to the sender that they have in fact joined the group. At the end of the session, there is confirmation of delivery by all receivers or, if the session timed out, the sender knows who did not get it. Senders may schedule transmissions at any time without advance knowledge of receivers. This is especially useful when the receiving site is unmanned, such as when transmissions are sent during the night, when networks are lightly loaded.

CONCLUSION
Remote server synchronization that can be accomplished rapidly without requiring excessive network and server resources is a huge competitive advantage to those companies that have been the pioneers in using this technology.

Ken Miller is chief technology officer of StarBurst Communications Corp. StarBurst is a leading developer of content distribution solutions that provide one-to-many, simultaneous, and guaranteed distribution of content. Solutions allow video, audio, software, and large data files to be distributed to hundreds, thousands, or tens of thousands of remote sites, LAN servers, and desktops. For more information, visit the company's Web site at www.starburstcom.com.

One barrier to deployment of efficient and rapid server synchronization applications is the lack of IP multicast support in most private intranets today. Even though virtually all router companies support multicast IP routing in their products, and have for a number of years, in most cases it is not turned on in today's corporate network. Organizations critically depend on their network to run their business, and are afraid to do anything to change the network that could possibly destabilize its operation. Additionally, there can be significant human resource commitments needed to reconfigure routers, and possibly to do some hardware upgrades to support multicast and make sure all is working satisfactorily.

Recognizing that this could be a significant barrier to deployment by many organizations, StarBurst developed FanOut to break down these barriers while at the same time providing substantially the same benefits IP multicast brings when deployed with routers.

FanOut servers are deployed in appropriate places in the network and provide provisioned static multicast routing services. The first FanOut server is configured to accept certain multicast addresses. The FanOut server closest to the source accepts the packets with the multicast addresses it is configured to receive. These incoming packets are then replicated on the fly and sent to the list of unicast addresses configured in the server. Each packet also encapsulates the multicast address originally sent as a destination address.

If the destination address is another FanOut server, it can forward to both the multicast address included in the packets sent and to other unicast addresses that may be configured.

There are five remote servers (A-E) to be synchronized. These servers reside in different parts of the network. Server A is on the same LAN, and so is reached directly via multicast. The first FanOut server is also on that LAN, and receives the multicast packets at the multicast addresses for which it is configured. In turn, it replicates the incoming packets two times with different destination unicast addresses, one to remote server E and one to another FanOut server, which receives the incoming packet and forwards it after inserting the group multicast address as the destination address. This is forwarded over the multicast enabled LAN to remote servers B, C, and D. FanOut also has the flexibility to send the last hop via broadcast or multiple unicasts if the last hop of the network also did not support multicast.

Given a WAN that is not multicast enabled, FanOut allows the network to optimally transmit unicast when required and multicast when possible, providing virtually all of the benefits of a fully multicast ready network.

Toys 'R' Us recognizes technology's ability to make its 900 stores run more efficiently, and has invested in information systems that enable it to service customers more effectively. Every Toys 'R Us store is equipped with PCs and a complete suite of Microsoft applications for tracking inventory, scheduling personnel, running registers, handling credit authorizations, and other important business functions.

Deploying, updating, and debugging so much software on so many machines, at so many locations, is a huge logistical undertaking, even with a two-way VSAT network that links all Toys 'R' Us stores with the corporate data center in Parsippany, N.J. Until recently, the company updated software through point-to-point transfers that took days to complete and tied up large chunks of the VSAT network's bandwidth. Multicasting has significantly reduced unnecessary network traffic and slashed software delivery time from days to hours.

Toys 'R' Us uses StarBurst Multicast in its 900 stores to upgrade existing applications and deploy new ones. The Toys 'R' Us network architecture is designed to relieve traffic on the frame relay wide-area network (WAN) that links all the stores together by transferring software over the WAN to servers on local-area networks (LANs), which have more capacity. The VSAT network also serves as a backup to the terrestrial network. Each store then accesses the new software from the LAN, making the transfer and updating process less bandwidth-hungry.

The presence of the VSAT multicast overlay network using reliable multicast for remote server synchronization was analyzed for traffic analysis and shown to greatly reduce the bandwidth growth requirements on the terrestrial network, as well as providing the benefits of rapid deployment of new applications.