Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 133
Page 133
16
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 1R). To
illustrate the utility of the framework, two other interoperation
proposals, one developed by the Cross-Industry Working Team (XIWT
2R) and one by the Computer Systems
Policy Project (CSPP 3R), 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.
OCR for page 134
OCR for page 135
OCR for page 136
OCR for page 137
OCR for page 138
OCR for page 139
OCR for page 140
OCR for page 141
OCR for page 142
OCR for page 143
OCR for page 144
Representative terms from entire chapter:
bearer service
Page 134
Figure 1
A simple protocol stack,
organized as layers.
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 1R) 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.
Page 135
Figure 2
A four-layer model for the ODN (reprinted from 1R, p. 53).
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.
Page 136
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.
•
National Television System Committee (NTSC)
video delivery: All the systems that are part of delivering
NTSC—over the air broadcast, cable, VCRs, satellite, and so
on—interconnect in an effective manner to deliver a video
signal from various sources to the consumer. But NTSC video
delivery is the only application supported. This circumstance has a
different set of objectives for the range of technology that it
spans below and the range of applications that it supports above.
Compared to the RTIF hourglass, this would look more like a funnel
sitting on its wide end.
•
ATM (asynchronous transfer mode): Some of
the developers of ATM, which is one of the network technologies in
the bottom of the RTIF hourglass, have expressed the ambition that
an eventually ubiquitous ATM would come to serve for all networking
needs. Were this to happen, it would not then be necessary to
define a separate bearer service above it, because the service
provided by ATM would become the universal basis for application
development. While this vision does not seem to be working out in
practice, it illustrates an approach to interoperation at a lower
point than the RTIF bearer service. This, if drawn, might look like
a funnel sitting on its narrow end. The virtue of this approach is
that a single technology solution might be able to offer a
sophisticated range of services, and thus support an even wider
range of applications than, for example, the Internet approach. So
the funnel, while narrow at the bottom, might be wide at the
top.
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
Page 137
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
4R 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.
Page 138
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.
Page 139
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 3R) has proposed four critical
interfaces; the Cross-Industry Working Team (XIWT 2R), 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.
TABLE 1 Interfaces of the CSPP and XIWT Models
CSPP
XIWT
Network-Network
Network-Network
Appliance-Network
Appliance-Network
Resource-Network
Application-Application
Appliance-Appliance
Resource-Resource
Resource-Application
Appliance-Application
System Control Point-Network
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.
•
One approach would be technology specific, such as
the network-network interface (NNI) of the ATM Forum.
•
The Internet or the RTIF ODN model would employ a
low-level but technology-independent spanning layer.
•
Another approach would be a higher-level but
application-independent layer such as a client-server invocation
paradigm.
•
Finally, a network-network interface could be
constructed at the application layer—for example, a mail
gateway.
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
Page 140
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
Page 141
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
Page 142
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:
•
The span of infrastructure options over which the
interoperation occurs;
•
The range of higher-level applications the
spanning layer supports; and
•
The degree of symmetry in the services of the
spanning layer and its interfaces, and in the higher layers up to
the application definitions.
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 1R 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 2R and CSPP
3R 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.
Page 143
[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 5R. 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 layer 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.
Page 144
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.
