NII White Papers--Table of Contents NII White Papers--Chapter 15 NII White Papers--Chapter 17

Interoperation, Open Interfaces, and Protocol Architecture

David D. Clark
Massachusetts Institute of Technology

ABSTRACT

This paper provides a framework for defining and understanding the terms interoperation and open; this framework is then used to develop operational criteria for assessing different approaches to achieving interoperation. This framework is related to the report released by the NRC entitled Realizing the Information Future (RTIF [1]). To illustrate the utility of the framework, two other interoperation proposals, one developed by the Cross-Industry Working Team (XIWT [2]) and one by the Computer Systems Policy Project (CSPP [3]), are compared. Finally, as an illustration of the framework, it is mapped onto a particular set of network protocols, the Internet protocol suite.

INTRODUCTION

Superficially, interoperation is simply the ability of a set of computing elements to interact successfully when connected in a specified way. From the consumer's perspective, this operational test is sufficient. However, at a deeper level, it is useful to ask why interoperation was achieved in a particular situation, because the why question will shed some light on when and where this interoperation can be expected to prevail. Interoperation can be achieved in a number of ways, with different implications.

Interoperation is based on the use of common standards and agreements. One could imagine a computer application being specified in such a way that all the needed standards are described as part of the application itself. However, in most cases a more modular approach is taken, in which the application is defined to depend on certain externally defined services. These services, called protocols in network parlance, are often organized in layers, which help structure the dependencies that exist in achieving interoperation. Thus, in the protocols that are part of the Internet protocol suite, an application such as mail (which has its own specifications and standards) depends on the transport control protocol (TCP), which in turn depends on the network Internet protocol (IP). These protocols, organized into layers of building blocks, provide an infrastructure that makes it easier to achieve interoperation in practice. This sort of dependency in protocols is often illustrated by drawing the protocols in a stack, as in Figure 1.

However, if one examines the various layers of protocols, one usually finds that there is a layer below which common standards need not be used to achieve interoperation. Again, using the Internet suite as an example, mail can be exchanged between two machines even though one is attached to an Ethernet and one to a token ring LAN.

Why are common standards needed at one layer but not at another? Certain protocols are designed with the specific purpose of bridging differences at the lower layers, so that common agreements are not required there. Instead, the layer provides the definitions that permit translation to occur between a range of services or technologies used below. Thus, in somewhat abstract terms, at and above such a layer common standards contribute to interoperation, while below the layer translation is used. Such a layer is called a "spanning layer" in this paper. As a practical matter, real interoperation is achieved by the definition and use of effective spanning layers. But there are many different ways that a spanning layer can be crafted.

THE INTERNET PROTOCOLS AS AN EXAMPLE

Expanding the Internet example above may make these points clearer. The Internet protocol suite contains a protocol that plays the role of a spanning layer, IP. Consider how IP supports the forwarding of simple text mail. The format of mail is defined by the standard RFC-822,1 the required common agreement at the application layer. This protocol in turn depends for its delivery on the Internet's TCP. And finally, TCP uses the services of IP, which provides a uniform interface to whatever network technology is involved.

How does the IP spanning layer achieve its purpose? It defines a basic set of services, which were carefully designed so that they could be constructed from a wide range of underlying network technologies. Software, as a part of the Internet layer, translates what each of these lower-layer technologies offers into the common service of the Internet layer. The claim is that as long as two computers running RFC-822 mail are connected to networks over which Internet is defined to run, RFC-822 mail can interoperate.

This example illustrates the role of the spanning layer as the foundation on which interoperation sits. To determine whether two implementations of RFC-822 mail can interoperate, it is not necessary to look at the implementation of Internet over any specific network technologies. The details of how IP is implemented over Ethernet or over ATM are not relevant to the interoperation of mail. Instead, one looks at the extent, in practice, to which IP has succeeded in spanning a number of network technologies. And the practical conclusion, as reflected in the marketplace, is that IP defines a successful spanning layer. The functions and semantics of the IP layer are well defined, as shown by the fact that many companies have become successful by selling routers, the devices that implement the translation required by IP.

A PROPOSAL FOR A SPANNING LAYER

As a part of its proposed open data network (ODN) architecture for the national information infrastructure (NII), the report Realizing the Information Future (RTIF [1]) proposes a specific spanning layer, a module it calls the ODN bearer service. This is illustrated on p. 53 of the report, in the "hourglass picture," which is reproduced here in Figure 2. It illustrates a collection of applications at the top (presumably desirous of interoperation), and at the bottom a collection of network technologies, which support the interoperation.

In the middle of this picture, at the narrow point in the hourglass, is the ODN bearer service. This layer is the key to the approach that RTIF takes to interoperation. The bearer service provides a set of capabilities sufficient to support the range of applications illustrated above it. It implements these capabilities by building on the more basic capabilities of the various network technologies below. The bearer service would thus span the broad range of network technologies illustrated below it, hide the detailed differences among these various technologies, and present a uniform service interface to the applications above. The bearer service is thus an example of a spanning layer, with specific features and capabilities.

The ODN bearer service is shown as the narrow point in the hourglass to illustrate that there must be a narrowing of the range of alternatives at that layer. There can be a wide range of applications supported over the bearer service and of technologies utilized under it, but the bearer service itself must represent the point at which there is a single definition of the provided capabilities. The power of the scheme is that programmers for all the applications write code that depends only on this single set of capabilities and thus are indifferent to the actual technology used below. If instead there were competing alternatives in the definition of the bearer service, the application programmers would have to cope with this variation, which in the limit is no more useful than having applications deal directly with the individual network technologies. In computer science terms, if there are N applications and M technologies, the bearer service reduces the complexity of the resulting situation from N M to N + M. But for this to succeed, the bearer service must be a point of agreement on a single set of capabilities.

OTHER EXAMPLES OF A SPANNING LAYER

The bearer service is not the only way that one could achieve interoperation. There are other approaches in use today, with different objectives as to the range of spanned technologies and the range of supported applications. Some specific examples may make the alternatives clear.

All of these schemes have in common that there is some "narrow point" in their structure, with a single definition of service capability. Whether it is a definition tied to one application, or to one network technology, this narrow point in the picture corresponds to a spanning layer and is what forms the foundation of the approach to interoperation.

COMPARING APPROACHES TO INTEROPERATION

The various examples given above suggest a fundamental way to evaluate different approaches to interoperation, which is to assess what range of technology they can span "below" and what range of applications they can support "above." The essential claim of the RTIF bearer service is that the NII needs an hourglass rather than either of the two possible funnel pictures as its key spanning layer. An approach that spans a broad range of networks is needed because there has never been, and in practice never will be, a single network technology sufficiently powerful and general to meet everyone's needs. The ATM solution, if fully embraced, would require replacing all the legacy networks, such as Ethernet, token ring, the telephone digital hierarchy, and so on. And even if this victory over heterogeneity occurred, we must expect and plan for new innovations, which will in turn replace ATM. For example, there is an ongoing research effort attempting to define a next-generation network based on wavelength division multiplexing (WDM) over fiber. This evolution will always happen; it is a necessary consequence of innovation, cost reduction, and so on.

At the same time, the NII must support a broad range of applications, not just one, because there is wide disagreement and uncertainty as to what the successful applications of the NII will finally be. One school believes that the NII will be dominated by video on demand. Others think it will be more Internet-like, with a range of interactive and transaction-oriented applications, and a wide range of service providers on a global infrastructure. Not knowing for sure what the range of applications is, it seems foolish to propose an application-specific approach to interoperation. So RTIF proposed a middle ground of interoperation, which permits both a range of applications above and a range of technologies below.

The Internet provides a concrete example of this tradeoff in span below and range of common function above. While the Internet protocol is the primary spanning layer of the suite, it is not the only one. For example, the Internet mail transfer protocol SMTP (RFC-821) is carefully written to be independent of TCP or any other transport protocol. Thus Internet mail has "built in" an alternative spanning layer. Any reliable byte stream can be used to deliver Internet mail. And indeed, there are viable products, called mail gateway, that support mail forwarding between networks with different transport protocols.

Using the mail protocol as a spanning component provides a very wide range of spanning options. This wider range of technology and protocol options translates into a wider range of real world deployment; IP-level Internet access reaches about 86 countries today, while Internet mail reaches about 168.2 The price for this is that the only application supported is mail. There is no access to remote login, file transfer, the World Wide Web, and so on. So interoperation at the mail level is, again, a funnel sitting on its wide end.

SPANNING LAYERS—ONE OR MANY?

An obvious question at this point is whether there must be a single point of narrowing in the hourglass or, instead, there can be multiple points of common agreement. In fact, as these examples suggest, the situation that prevails in the real world is more complex than the single hourglass might imply, and one finds multiple points of narrowing at the same time. But the idea of a narrow point is always present in any general approach to interoperation. The hourglass of the RTIF should thus be thought of as both an abstract and a concrete approach to interoperation. It illustrates the key idea of a spanning layer and then makes a specific assertion as to where that point ought to be.

WHAT IS OPENNESS?

Since successful interoperation is based on the common use of protocols and standards, a key issue is whether the necessary standards are available openly, so that different implementors can use them as a basis for implementation. Real interoperation is thus closely related to the issue of openness. There are two aspects to defining open. One is the question of just how public, free, and available a specification needs to be in order to be called open. The issues here are control of intellectual property rights and the control of how interfaces may be used. For a good discussion of competing views on this point, see the paper by Band [4] in this volume.

The other aspect of openness is its relationship to the layering that was described above. If our goal is open interoperation, what specifications need to be open? All, or perhaps only some? The key to sorting this out is to realize that, from the consumer perspective, what matters is the interoperation of applications—the software packages that actually perform functions directly useful to users. Since applications are what customers care about, the constructive definition of openness starts with applications. An application supports open interoperation if the definition of the application and each of the layers below it are open (by whatever definition of open prevails), down to an acceptable spanning layer. It is a simple test.

Is Internet text mail an open application? Mail is defined by RFC-822, which is an open standard.3 It depends on SMTP, the Internet mail transfer protocol, which is open, and this depends on TCP, which is open; this in turn runs on IP, which is open. Since IP is a spanning layer, Internet text mail provides open interoperation.

It is usually not necessary to look below the spanning layer to see if all those network technology standards are open, exactly because that is the benefit of a spanning layer. Instead, one looks to the market to see if a spanning layer is successful. Even if some of the technologies below the spanning layer were proprietary, applications still would provide open interoperation, so long as the translation boxes that implement the spanning layer have dealt with the issues of attaching to that technology.

Even if all the definitions at the application layer are open, the application does not support open interoperation if any of the layers it depends on between it and a spanning layer are not open. An application that is openly defined, but that runs on top of a proprietary service layer that runs on TCP and IP, does not support open interoperation. This situation is uncommon but illustrates how the test for open interoperation might fail.

SYMMETRY—A FINAL ASPECT OF INTEROPERATION

A final aspect of interoperation is the issue of whether, when two (or more) entities interact, they do so as equals or peers, or instead in some asymmetric way, for example as client and server, or as provider and consumer. Protocols are sometimes designed in such a way that not all the participants in the protocol can play all the roles. For example, some of the early remote file access protocols were designed so that the functions that implemented the file server and the file user were separately specified. This made it easy to produce implementations that omitted the server code, so that the resulting software could only play the role of the user. It was then possible to sell the server code for additional money.

In general, symmetry, like openness, tends to reflect business issues. However, some asymmetries are justified on the basis that they usefully simplify one end of an interaction. For example, some of the tasks having to do with network operation (such as resolution of faults or traffic routing) are often designed so that the network carries most of the burden and the end-node has a simplified interface. The other framework documents discussed below offer additional insights on the implications of asymmetric interfaces.

WORKING WITH HETEROGENEITY OR PAPERING OVER DIFFERENCES?

There are two different views or philosophies about a spanning layer and its manifestation, which is a translation of some sort. One view is that heterogeneity is inevitable, and thus translation is inevitable. A properly designed spanning layer is thus a key to successful technology integration. The other view is that a proper technology design would include the goal of interoperation as a core function, and so the need for a higher level translation capability is a papering over of engineering failures at a lower level.

In different situations, both views may be true. The phone system today represents an example of an integrated approach to spanning, in which there is a wide range of underlying technologies, from copper wire to the digital hierarchy, and (in the future) ATM. However, interoperation among all of these has been a goal from the beginning and is integrated into the technology as a basic capability.

In contrast, Internet interoperation has not been engineered into most of the technologies over which it runs. The Internet has sometimes been called a "hostile overlay," because it runs above (and invisible to) the underlying technology. This sometimes leads to operational issues, since the management tools below the Internet level cannot be used to manage the Internet. However, it is the key to the growth and evolution of the Internet, since the Internet is not restricted to operating over only those technologies that were designed for that purpose.

In fact, this distinction is probably key to understanding how new services will first emerge and then mature in the NII of the future. Given that spanning layers can be defined to operate on top of other spanning layers (for example, the Internet mail spanning layer on top of the IP spanning layer), it is easy to bring a new spanning layer as well as a new application into existence by building on one of the existing interfaces. If the service proves mature, there will be a migration of the service "into" the infrastructure, so that it becomes more visible to the infrastructure providers and can be better managed and supported.

This is what is happening with Internet today. Internet, which started as an overlay on top of point-to-point telephone circuits, is now becoming of commercial interest to the providers as a supported service. A key question for the future is how the Internet can better integrate itself into the underlying technology, so that it can become better managed and operated, without losing the fundamental flexibility that has made it succeed. The central change will be in the area of network management: issues such as accounting, fault detection and recovery, usage measurement, and so on. These issues have not been emphasized in many of the discussions to this point and deserve separate consideration in their own right.

COMPARISON TO OTHER MODELS

RTIF took a stand as to where the spanning point ought to be: a layer just above the network technology options, which the report called the ODN bearer service. Other reports have attempted to define interoperation in a somewhat different way, by cataloging critical interfaces.

The Computer Systems Policy Project (CSPP [3]) has proposed four critical interfaces; the Cross-Industry Working Team (XIWT [2]), seven. They are summarized in Table 1, where they are grouped to best show their commonalities. These interfaces are proposed as the key to open interoperation. How do these relate to the RTIF model and the framework developed here? Although the approach to interoperation expressed in these two models may seem rather different from the definition proposed above, based on the identification of a spanning layer, these models can be mapped easily onto this framework and express a similar set of objectives.

The Network-Network Interface

A good place to start with the CSPP/XIWT models is the network-network interface. This interface connects different network technologies and thus implies a spanning layer. However, it could be implemented in several ways as discussed above.

Just calling for an open network-network interface does not define which of the above is intended. The XIWT report suggests that there may be several forms of the network-network interface, while the CSPP report suggests that their concept is a fairly low-level interface.

The Application-Application Interface

Next, the CSPP report identifies an interface called the application-application interface, which it describes as the protocols that one NII application uses to communicate with another application. The XIWT has a more detailed structure, with three versions of this interface as listed in Table 1. To unravel what this interface is, one must start with some known network-network interface, since that characterizes the spanning layer and thus the foundation of the common standards. We then apply the test for open interoperation offered above. Two applications have an open interface for interoperation if their interface specifications, and all the layers below them, are open, down to a suitable spanning layer. That spanning layer is the network-network interface.

These options are clearly illustrated in the CSPP report. In one option,4 there is a messaging interface between the networks, which is a high-level (application-specific) example of a network-network interface. Another option,5 instead of having a messaging interface between the networks, has a lower-level network-network interface, together with the other standards necessary to interwork the applications over that interface. The coexistence of these two forms is the exact analogy of the Internet example above, where mail can interwork either by a messaging interface (RFC-822 mail gateway) or by a full protocol stack of 822 over SMTP over TCP over IP, which would be the lower-level network-network interface.

The Appliance-Network Interface

The appliance-network interface defines the way an appliance (host, set-top box, or whatever) attaches to the network. This interface, although it may not be so obvious, is another manifestation of the spanning layer. An Internet example may help illustrate this. There are low-level technology interfaces that connect appliances to networks, such as the Ethernet or the token ring standards, or ISDN. But the key to Internet interoperation is that the applications in the appliance are insulated from which technology is being used by the Internet layer. Thus, the Internet layer not only spans divergent network technologies but also "spans" the host interface to those technologies.

The above discussion suggests that the appliance-network interface could be similar to the network-network interface discussed above. In particular, the capabilities of the spanning layer must be supported across both the appliance-network and the network-network interface. To first order, in the Internet protocol these two are the same. In practice, there are differences in detail, because it is desirable to simplify the appliance-network interface as much as possible. For example, the Internet does not define appliances (hosts) as participating in the full routing protocol, which is an essential part of the Internet network-network interface, but instead provides a more simple appliance interface to routing. The ATM Forum is defining both the user-network interface (for users, or appliances) and the network-network interface, for hooking networks together. They have many similarities, but they differ in the details of what commands can be issued across the interface to set up connections, request services, and so on. The ODN model, which does not develop the network-network interface in much detail, defines them only to the extent that both must support the same end-to-end capabilities, both based on the bearer service.

The Appliance-Application Interface

The CSPP identifies the appliance-application interface, which is the API for the infrastructure (e.g., the operating system on the computer). It is concerned with software portability as much as interoperability. Thus, RTIF does not emphasize this interface. But the interface makes a good illustration of the utility of a spanning layer to insulate higher levels from issues and options at the lower levels.

Applications today can be ported between a Unix, a Windows system, and a Macintosh, perhaps with some difficulty, but with some success. Even though the operating systems have different interfaces, there is some alignment at the abstract level among the services of the three. This is not totally true, and some applications do not port, but the point is that if an application builder accepts an abstract service definition (an interface to a spanning layer) to the operating system, then that application is much more likely to avoid getting trapped onto a concrete interface that is proprietary or has license problems. That freedom is the equivalent of what the bearer service gives us. The lower layer, whether the operating system or the network technology, can evolve. For example, if the well-known token ring patent had been too much of a problem, the community could have abandoned the specific technology, without any changes at the higher levels. In exchange, the application builder must accept that the details of the appliance technology may be hidden to some extent beyond this abstract interface, and someone (the application builder or a third party) must write "glue code" at the bottom of the application to port the application to each operating system. This code is the equivalent of what the router vendors write in their devices to map the IP layer onto specific network technologies, and the software above the "network device driver" code, which performs the same mapping in the host.

So this interface, even though it is somewhat outside the framework proposed for interoperation, can illustrate why an abstract service definition (a spanning layer) is powerful as a point of convergence.

Other Interfaces

In addition to the interfaces discussed above, the XIWT report proposes an interface to a service control point, which is outside the scope of this discussion. It also breaks apart the previously discussed interfaces into variants that reflect the different roles of an information resource provider and a user of the network. There are three variants of the application-application interface: the appliance-appliance interface, the resource-resource interface, and the resource-appliance interface, and there are two variants of the appliance-network interface: the appliance-network and the resource-network interfaces. These variations in the interfaces capture the idea, presented above, that the various participants in an interaction may not play as equals, but rather in some asymmetric way.

The Internet philosophy is that any user of the network is also to some extent a provider, and the distinction between user and provider is not sharp but a continuous gradation. Thus, the Internet, in its IP layer, makes no discrimination between the two. At the technology level, a provider might like to attach to the Internet in ways that are different from those of a user, perhaps with higher bandwidth, or with more redundancy, and so on. These differences are important, but the Internet protocols treat this as happening below the spanning layer.

One might take a different tack and provide a (resource) provider attachment paradigm that is different from an appliance (user) attachment in its relation to the spanning layer itself. One would have to see the technical arguments in favor of this discrimination to judge the benefit. In some cases, the purpose of this distinction has been not technical but financial—the provider, if he must attach using a different interface, may be thus identified and separately billed, presumably at a higher rate.

As noted above, the appliance-network interface and the network-network interface have a lot in common, in that they must both support the same end-to-end capabilities. In the Internet case, the network-network interface is symmetric, which means that the networks meet as equals. The routing protocols do not force one network to be controlled by another, nor do the management protocols. The appliance-network interface is intentionally asymmetric; for example, as discussed above, the appliance cannot participate in the routing protocols but must use a surrogate protocol.

The purpose of this asymmetry was simplicity, but one should also note that asymmetry, especially in control functions, mandates the shifting of functions to one side of the interface, which affects both the technical and the business arrangements of the network. For example, in the telephone system, there is a network-network interface of sorts between a PBX and the public telephone system. However, this interface is not symmetric and does not let the PBX attach to the public system as a full peer. This is, no doubt, not a mere oversight.

There are many other examples of interfaces that might or might not be symmetric. The network-network interface sits at a point where symmetry or lack thereof in the interface will dictate to a large extent the relative power and business position of the various providers. This is also true of application-application interfaces. A critical point of assessment for approaches to interoperation is the symmetry, or lack thereof, in the interface.

SUMMARY

This paper proposes a framework for understanding and assessing interoperation and openness.

We offer a careful definition of interoperation, beyond the operational test of "does it work?" Two implementations of an application can interoperate if (1) they are based on common definitions and standards at the application layer, (2) they use supporting services in a consistent manner, (3) they are based on a common spanning layer as a foundation for these services, and (4) the range of underlying network technologies to which the applications are actually attached is within the range that the spanning layer can reach.

There are two important aspects to this definition. First, it is stated in terms of interoperating applications. If the question of interoperation has been framed in terms of a different entity, such as a computer, there is no well-formed answer. Computers may interoperate, or not, depending on what application is running. Second, the spanning layer is defined as the "foundation" on which the definition rests. This word was chosen because one does not have to look below it when testing for interoperation. If the spanning layer is well defined and is known to work over the network technology in question, then the fact that the application is defined in terms of this spanning layer is sufficient.

A spanning layer is characterized by three key parameters, which define the sort of interoperation it supports:

Different approaches to interoperation can be evaluated by assessing these characteristics; this paper attempts to map the RTIF model and the XIWT and CSPP interfaces in this way. In general, there is no conflict between these models, but the RTIF framework [1] is more specific on certain points, in particular as to the exact modularity of its bearer service, which provides the basis in the RTIF framework of the network-network, the appliance-network, and (if it separately exists) the resource-network interface. The XIWT [2] and CSPP [3] reports are more specific, on the other hand, in calling for a distinct and full definition of the network-network interface, while RTIF discusses only those aspects that relate to the end-to-end capabilities of the bearer service.

Using this framework, RTIF observes that openness is a characteristic of interoperation. That is, if all the protocols that accomplish a particular sort of interoperation are open, from the application down to the relevant spanning layer, then one is justified in calling that form of interoperation open. Again, the definition is in terms of an application, which, from the user's perspective, is the relevant objective of an interoperation test.

RTIF also uses the Internet architecture as an example of a concrete set of protocols that embody an RTIF-style bearer service approach to interoperation: Internet defines a largely symmetric bearer service, the Internet protocol itself, which has been shown in the marketplace to span a wide range of network technologies and support a wide range of applications. The network-network interface in Internet is defined by IP itself, together with the routing, management, and other control protocols. It is completely symmetric. The appliance-network interface is defined by IP, together with ICMP and the other host-related control protocols. There is no separate resource-network interface.

ACKNOWLEDGMENT



A number of people have read and commented on this paper. Neil Ransom, from the XIWT, and Tom Gannon, from the CSPP, provided valuable feedback on my comparisons. Marjory Blumenthal and Louise Arnheim, both of the Computer Science and Telecommunications Board of the NRC, offered extensive comments that greatly improved the paper.

References

[1] Computer Science and Telecommunications Board (CSTB), National Research Council, Realizing the Information Future: The Internet and Beyond, National Academy Press, Washington, D.C., 1994.

[2] Cross-Industry Working Team (XIWT), Corporation for National Research Initiatives, An Architectural Framework for the National Information Infrastructure, CNRI, Reston, Va., 1994.

[3] Computer Systems Policy Project (CSPP), Perspectives on the National Information Infrastructure: Ensuring Interoperability, Computer Systems Policy Project, Washington, D.C., 1994.

[4] Band, Jonathan, "Competing Definitions of 'Openness' on the NII," in this volume.

[5] Object Management Group (OMG), Object Management Architecture Guide, Object Management Group, Framingham, Mass., 1990.

APPENDIX I



More Detail on the Bearer Service: What Is It Exactly? Where Is It?

The general argument in favor of an hourglass is not enough to support the specific details of the RTIF bearer service approach. Other spanning layers could be defined that, while still "in the middle," are at a higher level in the protocol stack.

One approach would be to standardize a protocol by which a user program can call a server across the network, such as the client-server invocation protocol proposed by the Object Management Group (OMG [5]). Interoperation through a standard client-server invocation paradigm would in fact permit a wide span below, because it could run not only over a range of network technologies but also over a range of protocol suites. It could, for example, operate over TCP/IP or vendor specific protocols such as Novell's IPX or IBM's System Network Architecture (SNA).

Another approach would be to standardize an interface directly above the transport layer in the protocol stack, corresponding to TCP in the case of the Internet suite. IBM has recently proposed such a thing, a spanning layer that spans TCP and SNA. Such a layer would permit an application from either the Internet suite or SNA to run over any combination of the two protocols.6 Spanning both TCP and SNA covers a wide range of underlying technologies and might prove powerful.

What is the limitation of these schemes? First, these potential spanning layers are separated from the actual network technology by more protocol modules (more layers of software) than the ODN bearer service is. These intervening modules make it less likely that a higher-level spanning layer can interact with the network technology to change the quality of service delivered. Various applications need different performance from the underlying network. Some services, like real-time video, require delivery within a predictable delay. Others, like e-mail, may require only the most minimal of best-effort delivery. (This variation in offered performance is called quality of service, or QOS, in the network community.) Most existing protocol suites do not provide a useful way, from high in the protocol "stack," to reach down across the layers and control the QOS. This argues for an interoperation layer at a low point in the protocol stack, close to the network technology itself.

For example, in the case of the SNA/TCP spanning layer, the capabilities of the service are constrained by the particular protocols out of which the service was built, TCP or SNA, which offer a reliable delivery protocol with no ability to bound delivery delays. So the SNA/TCP spanning service, although it has a broad span over network technology, cannot make use of other QOS in the lower layers and thus cannot support applications such as real-time audio and video.

Second, one of the features of a spanning layer must (almost always) be an address space or numbering plan.7 One cannot interoperate with something one cannot name or address. So any protocol layer designed to span a range of lower-level technologies must implement an address space at this layer. Experience suggests that providing a single global address space at a low level is most effective.

There are a number of examples of different address or name spaces in use today. The Internet mail protocol was designed as a spanning layer and thus has its own address space, the mailbox names. The syntax for mailbox names can get quite complex and can express a range of functions such as source routing. However, since the address space is not as well defined or engineered as the IP address space and is not as well supported by management tools, problems with mailbox names and mail forwarding when using mail as a spanning layer are well known.

Another name space of interest is the naming of information objects in the World Wide Web, the so-called universal resource locators, or URLs. The WWW transfer protocol, HTTP, is currently defined to run on top of TCP. However, it provides its own name space and thus might be able to function as an application-specific spanning layer. This extension would require some reengineering of the URL name space, an area of current research.

In contrast to IP or the Internet mail protocol, if one were to ask if TCP (the transport protocol that sits above IP) could be a spanning layer, the answer is no. It is defined to depend on IP and cannot be run on top of another internetwork layer protocol. TCP is part of the Internet interoperation story (it defines a popular common service), but it is not a spanning layer.

Notes

1. The Internet standards are specified in a series of documents called RFCs, or Requests for Comments, which are available on the Internet. Contact rfc-info@isi.edu.

2. These numbers are from the international connectivity data collected by Larry Landweber and provided by the Internet Society as a part of its Web information collection. See http://info.isoc.org/home.html.

3. All Internet standards are published for use in any way without any constraints or license. This perhaps represents the most open form of "open."

4. CSSP [3], p. 16, example 3A.

5. CSSP [3], p. 17, example 3E.

6. Note that this proposal does not support the interworking of an SNA application with an Internet application. By our definition of interworking, that would require a spanning layer specific to each pair of applications to be interconnected. The goal here is more modest: to take existing applications from either protocol suite and support them over a new spanning layer that allows them to sit above both TCP and SNA.

7. There are examples where a spanning layer tries to avoid a common address space by supporting multiple address spaces or by translating among several. These approaches are often complex.