TUTORIALS > INTEROPERABILITY >

Lesson 41: The Challenge of Interoperability

Interoperability is one of the hot buzz words in the network industry. Increasing larger and complex network environments are forcing network administrators to merge heterogeneous computing systems into interoperable wide area networks.

Unfortunately, discussions about interoperability are often clouded in rhetoric or vendor hype, with multivendor interoperability meaning different things to different people. For instance, interoperability could mean nothing more than straightforward plug-and-play compatibility, such as connectivity to Ethernet cabling, among different vendors’ products. In this case, physical interoperability merely gives users the ability to connect one vendor’s computing devices to another’s over a network.

This isn’t true interoperability, however: Many vendors’ equipment, including Digital Equipment Corp. (DEC) VAXs, PCs, and Sun Microsystems’ SPARCstations, can be connected to an Ethernet via network adapter cards. But it doesn’t mean that VAXs running DECnet over Ethernet cabling can communicate with PCs on a Novell NetWare workgroup attached to the same wire. That’s a far more complex task, involving gateways that convert one protocol to another.

Then what is multivendor interoperability? Here’s a look at some of the issues involved.

AN INTERNETWORK PROBLEM

Before continuing, one point of clarification: Discussions about multivendor interoperability deal with large, so-called global or enterprisewide networks. It is in these internetworking environments, where a variety of far-flung (and dissimilar) workgroups communicate with each other, that multivendor interoperability becomes an important factor.

A look at the composition of networks as they “grow up” explains why this is so. Generally, the computers within a departmental workgroup are of a similar kind—all PCs, PS/2s, or compatibles, or all Macintoshes.

There’s little diversity of equipment in these environments because people working on similar types of projects and software applications typically use similar kinds of computers. In these situations, all devices operate under the same operating system (OS), network OS and protocol, and media-access method.

Without wide product diversity, multivendor interoperability is therefore not an issue. But the scenario changes radically when organizations begin connecting workgroups into large internetworks. In these environments, which can spread across a building, a campus, or a continent, it’s unrealistic and often bad business sense to expect every worker to use the same kind of computer.

For instance, engineers often demand SPARCstations for their design work, while marketing personnel, especially those preparing technical documentation, find the Macintosh ideal for page layout. In addition, both types of users often require access to information stored on a host of some sort. Such an internetwork might also consist of an IBM mainframe communicating with group of PCs through IBM’s Systems Network Architecture (SNA), plus a workgroup of PS/2s linked to a NetWare server via Novell’s IPX/SPX.

When an organization wants to let users on these diverse networks communicate with each other, it must thus concern itself with interoperability among all these different vendors’ products and protocols. For instance, this scenario demands connections between computing products from six separate vendors: DEC, IBM, Apple, Sun, SCO, and a manufacturer of minicomputers.

More importantly, however, this network would require interoperability between six widely differing networking protocols: DECnet, SNA, AppleTalk, Sun’s Network File System (NFS), IPX/SPX, and Transmission Control Protocol/ Internet Protocol (TCP/IP). All networking protocols, they nevertheless operate differently. The interoperability challenge is compounded by the fact that only one of these protocols“TCP/IP“is an “open” standard designed to support a variety of computing devices. The others were developed primarily to support the vendor’s own products, not those of the vendor’s competitors.

INTEROPERABILITY’S CAUSES

At the heart of these interoperability issues is the way in which vendors and standards-setting bodies have implemented their respective network protocol stacks. A protocol stack is a predefined, layered set of rules governing the way two networked computing devices exchange information over a transmission medium (see figure).

For two computers to communicate over a network, their respective protocol stacks must be able to understand each other’s protocol “rules.” When two computers communicate over a network, one of them originates data at the top of its associated protocol stack. This data is processed layer by layer down the stack with each layer appending information and/or instructions to the data, creating a frame, as it moves down the stack. The following figure illustrates this stack-to-stack communication process.

Unfortunately, not all protocol stacks are identical. Vendors and standards-setting groups have taken diverging approaches in developing the protocols they use today on networks. As a result, the various available protocol stacks offer services and capabilities that make them incompatible with other protocols.

For instance, compare the Open Systems Interconnect (OSI) reference model, an accepted “open” industry standard for interoperable multivendor networking, and the Xerox Network System (XNS) protocol stack. The two stacks are substantially different, with the most obvious being the number of layers within each protocol stack: The OSI model contains seven layers; the XNS hierarchy five.

Level 0 in the XNS stack corresponds more or less to OSI layers 1 and 2; it handles link-layer access and manipulation of the serial bit streams placed on the network transmission medium.

Level 1 corresponds somewhat to the OSI layer 3, which handles network traffic, while Level 2 protocols perform much the same functions as those in OSI layer 3, which deal with reliably transporting packets to their destinations, and OSI layer 4, which deals with interprocess communications.

Levels 3 and 4 provide capabilities similar to those offered by the uppermost two OSI layers—that is, handling data structuring, process-to-process interaction, and applications. XNS has no protocol that corresponds to OSI layer 5.

INTEROPERABILITY’S SOLUTIONS

Now consider what would happen if an OSI-based computer attempts to communicate directly with one operating under XNS. An XNS-based data packet wouldn’t contain OSI layer 5 (session layer) instructions, which establish and terminate process-to-process communications between two computers.

This oversight means that a process running on one computer—for instance, a driver giving the host computer’s processor access to a hard disk drive—would not be available to another computer over the network. Without this capability, file servers would not be able to offer remote storage facilities to clients.

How, then, do XNS computers communicate with OSI-based computers? Or OSI-based hosts with VAXs on a DECnet? Communication between computers running different protocols is often handled through devices called gateways or via transport services provided by a network operating system.

A gateway is an application-specific device that operates at all seven layers of the OSI protocol stack. In oversimplified terms, gateway hardware includes a processor, memory, and adapter cards. The hardware device maintains separate connections to the networks being combined—for instance, one an unshielded twisted-pair Ethernet cable network linked to a PC workgroup running Novell’s IPX; a second workgroup connected to a 3270 coax network with the SNA services running on top.

The gateway runs software that performs protocol conversion on a layer-by- layer basis as necessary.

Network vendors have taken two primary approaches to implementing gateways. Some have developed software-only products that require adding NICs to personal computers or servers. Others market integrated, all-in-one “black boxes” for specific protocols—for example, AppleTalk-to-Ethernet gateways. Either way, the functionality of one system must be mapped to the capabilities of the other system.

In addition, many major network operating system vendors integrate protocol- encapsulation or conversion capabilities into their system software. For instance, Novell’s NetWare 3.11 offers native, system-level IPX and TCP/IP transport services.

One protocol may also be encapsulated into another. For example, AppleTalk protocols are often wrapped in TCP/IP packets in a process called tunneling, which lets Mac users to access TCP/IP services.

These methods provide varying degrees of multivendor interoperability, but none provides a complete answer. Emerging technologies based on the OSI model promise to take interoperability to even higher levels over the next several years.