Building Networks on the Fly

By the early 1990s, IBM and Hewlett-Packard, as well as Canon, Hitachi, Ricoh, and other large makers of office equipment, had realized that customers expanding their networks with new copiers and other components almost always got bogged down.

The problem was one of compatibility. Every time a company wanted to attach new equipment to a network, it had to add software to every network node that might ever access the additions. Worse yet, the system was highly unlikely to be homogeneous, as the network devices, new or old, were highly unlikely to be the products of a single manufacturer. So in 1995 U.S. and Japanese companies formed the Salutation Consortium to come up with a solution.

As the consortium members saw it, the solution had two parts: it called for a uniform way of labeling devices digitally with descriptions of their capabilities, plus a single common method of sharing that information. To illustrate, the need was for a printer, say, to be equipped to describe its capabilities to any suitably equipped computer or other network element that might come calling.

Fortunately, industry groups such as the Internet Engineering Task Force (IETF) were already working on the first element--developing standard data formats for different types of equipment. For instance, an IETF standard, Request-for-Comment (RFC) 1759, released in 1995, provides a standard way of describing printer capabilities. Typically, printers can accept different sizes of paper from different input bins, print in different colors, sort and collate, and create printing logs. RFC 1759 describes how this information, along with printer status (such as "in use" or "warming up") should be encoded and stored in a file called the Printer MIB (management information base) table.

How to find and "interview" the printer, though, was up to the consortium. Success depended on cooperation among makers of computers, printers, and other office equipment, who in many cases were also competitors. The formation of the Salutation Consortium overcame that obstacle, creating an open arena in which the work done could be freely shared by all.

Since that time, the idea of automating the way networks are put together has fired the information technology industry's imagination. The Bluetooth Special Interest Group, formed in February 1998 by Ericsson, IBM, Intel, Nokia, and Toshiba, and the Jini organization--started in July of the same year by Sun Microsystems Inc., Palo Alto, Calif.--are among those that have independently tried to create ways to set up networks on the fly. Their initial releases, which were also announced in 1998, have tackled the problem from different perspectives.

The Bluetooth group has worked on defining requirements for wireless networks from the bottom up. Its specification establishes a radio connection between two devices and then covers everything up to the point where the connection is made and applications can be started.

As the specification was originally defined, a computer equipped with a wireless Bluetooth module for sending e-mail to a Bluetooth-enabled phone must first find the phone. It sends out a signal asking any other Bluetooth device in the vicinity to respond, whereupon the phone thus found and the computer use frequency-hopping to establish a secure means of communicating.

That done, the devices still have to discover each other's capabilities. To this end, Bluetooth defines a service discovery protocol, which helps the computer and phone set up a network on the fly. The ad hoc network exists only as long as the computer and phone are close enough to each other and in need of each other's services [see "Bluetooth's slow dawn," IEEE Spectrum, November 2000, p. 61­65].

A computer that uses Sun Microsystems' Jini protocol enhances Java applications, enabling it also to set up an ad hoc network with a printer, say, automatically. The protocol does not specify how the computer and the printer are connected to the network, possibly by Ethernet or even by a radio signal. What it spells out are how the two devices should negotiate a "contract" for services, how long they should stay connected, and where to find the software needed to perform printing operations. As part of that process, Jini includes a discovery protocol [see "Who's Who in Discovery"] that enables devices to find out about each other.

Even though Jini and Bluetooth both have a discovery protocol, the two protocols are incompatible. A Jini device cannot communicate with a phone that uses only the Bluetooth service discovery protocol. However, Salutation, the discovery protocol developed by the Salutation Consortium, may turn out to be the bridge between Bluetooth and Jini devices, as well as to other platforms [see table, above]. Were the devices to use the same protocol, they would at least be able to determine the capabilities of the other devices in the network. What's more, because the same software could be used with a Java- or Bluetooth-enabled device, or one using some other network protocol, Salutation may be the most cost-effective way to develop applications for any networked device [see figure].

Different approaches

Real-world networking problems are the focus of the Salutation protocol--unlike Bluetooth, Jini, or other discovery newcomers. The Consortium's members knew from experience that their customers' networks were not made up of a single manufacturer's pieces of equipment all working the same way. Consequently, when planning the Salutation protocol, they ensured it would be adaptable to different underlying requirements by focusing on having it perform a single task: service discovery.

Salutation owes its flexibility to its architecture [see figure]. It is designed so that it can sit atop any communication technology, for example, a wireless connection or an Ethernet link. The software that manages the Salutation protocol is called the Salutation manager. It is a service broker that acts as a service registry, discovers what services are on the network and whether they are available, and manages the session. It can be adapted to communication technologies by software that is called a transport manager, which sits between the Salutation manager and the rest of the system and comprises about 1000­3000 bytes. The complete Salutation Manager is about 125kB in the Windows operating system.

While each communication technology requires its own transport manager, the Salutation manager is the same across all. Determining how the Salutation system talks to the underlying system software to get the information it needs is the job of the transport manager. Consequently, different transport managers can be written by, say, device manufacturers to adapt their products to software environments like Java or Linux or to various protocols like IrDA, Bluetooth, or TCP/IP.

Many of the newer discovery protocols do not have this flexibility. They require that the systems they run in have particular features to support them. For instance, without a special feature of the Java language, called remote method invocation, the discovery protocol built into the Jini protocol cannot talk to other devices. So to use the Jini discovery protocol, equipment attached to the network must be able to work with Java programs. They must either be able to run the programs themselves, or be attached to a controlling device (called a proxy) that can run Java programs for them.

Microsoft's Universal Plug and Play (UPnP) discovery protocol is similarly restrictive. It employs the hypertext transport protocol (http) used on the Web to communicate with other devices, so that all equipment in the network must support that protocol. To be part of the UPnP network, therefore, a disk drive or printer or other device would have to support that Web protocol.

Building bridges

Members of the Bluetooth Special Interest Group (SIG) and the Salutation Consortium have paired off to synchronize their service discovery approaches, thus allowing software developers to write one application that works with Bluetooth and existing Salutation environments--primarily in office automation equipment. Additional blending of Salutation with UPnP could be achieved by designing a suitable transport manager.

Adapting Salutation to new communications protocols is likely to continue because the number of ways in which digital equipment can be networked is growing every day. Although a new proprietary way to let devices discover the capabilities of other equipment on the net seems to come along with each new networking scheme, Salutation is designed to be adapted to other protocols and thus provide them with a common way to discover device capabilities.

Registered or unregistered

Service discovery protocols obtain the description of a device in one of two ways. With the Bluetooth protocol, discovery information is exchanged directly between two devices. After a connection is established, the devices exchange information about their capabilities using the Bluetooth service discovery protocol (SDP). Universal Plug and Play operates in essentially the same way.

Jini handles the discovery process differently. When a computer first connects to a network, it looks for a server that has been set up as a registry, a so-called look-up server. (A look-up server can be created by adding software to an existing server--which also performs other functions.) The computer registers with the server, giving its capabilities. When it needs the services of another device, such as a printer or fax, it goes to the server to see what printers and faxes are registered.

In the case of both Jini and Bluetooth, the information a device needs to know--what devices are available on the network and what those devices are capable of--is the same. But in the case of Bluetooth, the device gets the information directly from the equipment it wants to tie up with, while in the case of Jini a device must go to a special server to get it. The Salutation discovery protocol works either way, and so can be used with either directory-centric or peer-to-peer schemes.

Enabling equipment from different manufacturers to communicate is the focus of the Salutation protocol

Looking again at Jini, this protocol provides a method for locating and loading special Java code called a proxy object. The proxy object is provided by the discovered device. Because it is written in Java, it is designed to be written once and run on any Java engine, allowing any Java application to access and use the discovered device. But the value is limited to a closed Java environment. In reality, the pervasive networks will not be solely Java. Salutation can locate a Java proxy object, as well as other access-enablers and device drivers written for environments such as Palm or Pocket PC.

Freedom of choice

The fact that the Salutation manager is the same across all network protocols is a boon for software developers. They can write their applications to work with the Salutation manager's application-programming interface (API). These applications do not have to be rewritten whenever they are used with a new communication technology such as Bluetooth or the Home Audio Visual Interoperability (HAVi) protocol.

What's more, the tools for developing and testing Salutation software are readily available today--and they are free. They can be downloaded at no cost from the Salutation Consortium Web site, at https://www.salutation.org. In addition, the source code for Salutation is open for inspection by all, so it can be improved through the work of all interested parties. This makes the software more rugged and reliable.

Not surprisingly, it is the office equipment manufacturers who have been the first to leap on the Salutation bandwagon. In Japan, Ricoh, Canon, Kyocera Mita, and Murata, among others, have added the Salutation protocol to their products.

Consortium-member IBM has also thrown its weight behind the Salutation protocol through NuOffice, a software product from its subsidiary, Lotus Development Corp. NuOffice manages the integration of fax machines, scanners, printers, copiers, and multifunction office equipment into a single network, thus turning these ordinary pieces of office equipment into information access terminals.

As for the ease of porting Salutation to communications protocols, the Consortium and the Bluetooth SIG demonstrated that last year. In a matter of months they worked out a Bluetooth specification for incorporating Salutation in Bluetooth systems.

The specification allows Bluetooth designers to implement Salutation in two ways--either by substituting the Salutation manager for the Bluetooth service discovery protocol software, or else by adding an API translator to each device, in order to map Salutation instructions to Bluetooth code. Salutation continues to work with the Bluetooth SIG to achieve official recognition as a Bluetooth protocol.

The hope is that others beside Bluetooth will adopt the Salutation discovery protocol. The consortium is currently in discussions with the Video Engineering Standards Association (VESA) and the UPnP Forum, and is open to working with any other groups that are developing new approaches to network communications.

Richard Comerford, Editor