There are many different computing and networking technologies — some
available today, some just now emerging, some well-proven, some quite
experimental. Understanding the computing dilemma more completely involves
recognizing technologies; especially since a single technology by itself seldom
suffices, and instead, multiple technologies are usually necessary.
This document describes a sampling of technologies of various types, by using a
tutorial approach. It compares the technologies available in the three major
technology areas: application support, transport networks, and subnetworking.
In addition, the applicability of these technologies within a particular situation is
illustrated using a set of typical customer situations.
This document can be used by consultants and system designers to better
understand, from a business and technical perspective, the options available to
solve customers' networking problems.
available today, some just now emerging, some well-proven, some quite
experimental. Understanding the computing dilemma more completely involves
recognizing technologies; especially since a single technology by itself seldom
suffices, and instead, multiple technologies are usually necessary.
This document describes a sampling of technologies of various types, by using a
tutorial approach. It compares the technologies available in the three major
technology areas: application support, transport networks, and subnetworking.
In addition, the applicability of these technologies within a particular situation is
illustrated using a set of typical customer situations.
This document can be used by consultants and system designers to better
understand, from a business and technical perspective, the options available to
solve customers' networking problems.
A complete and generalized computing reference model is quite helpful in
describing different technologies and their relationships.
Many different groups in the computing industry have been involved during the
last decade in developing computing reference models — some models for
operating systems, some for data bases, some for application systems, and
some for communications networking — but only recently have efforts begun in
earnest to combine these various models into a single, more complete, but yet
simpler reference model. Such a generalized model can be based easily upon
established networking models.
There are, indeed, many different technologies available in today's marketplace
that provide solutions for a variety of networking problems; but, to comprehend
how these technologies function, one must start with a reference model. One of
the best reference models that exists today for networking is the OSI Reference
Model. We will utilize this reference model for all discussion throughout this
book in a slightly simplified format.
Figure 1 relates the terminology used in this book to an approximation of the
terminology used in the Open Systems Interconnection (OSI) model1 created by
the International Standards Organization (ISO).
describing different technologies and their relationships.
Many different groups in the computing industry have been involved during the
last decade in developing computing reference models — some models for
operating systems, some for data bases, some for application systems, and
some for communications networking — but only recently have efforts begun in
earnest to combine these various models into a single, more complete, but yet
simpler reference model. Such a generalized model can be based easily upon
established networking models.
There are, indeed, many different technologies available in today's marketplace
that provide solutions for a variety of networking problems; but, to comprehend
how these technologies function, one must start with a reference model. One of
the best reference models that exists today for networking is the OSI Reference
Model. We will utilize this reference model for all discussion throughout this
book in a slightly simplified format.
Figure 1 relates the terminology used in this book to an approximation of the
terminology used in the Open Systems Interconnection (OSI) model1 created by
the International Standards Organization (ISO).
Referring to the right side of the above diagram, the application programs (the
APPL box in the diagram) conditionally depend upon the application support
programs (the SUPP box in the diagram), which in turn conditionally depend
upon the networking programs (the NETG box in the diagram). That is,
sometime during their execution, application programs may require application
support programs (or in some cases they may not). Likewise, sometime during
their execution, application support programs may require networking programs
(or in some cases they may not).
Referring to the left side of the above diagram, and speaking loosely, the
“bottom” (4 layers) of the OSI model2 accomplishes networking; the “top” (3
layers) of the OSI model accomplishes application and application services. In
the pure OSI networking model, application services are defined to be entirely
within layer 7 (at the bottom of the application layer). We have stretched the OSI
application services definition to include those networking middleware services
provided by OSI layers 5 and 6.
Relative to networking, the simple model shown in Figure 1 on page 2 is
extremely similar to the more detailed IEEE POSIX Open System Environment
(OSE) model3 , as shown on the extreme left side of Figure 2 on page 4, using
just the 'communication entities' (our networking), 'application platform entities'
(our application support), and 'application entities' (our application) parts of the
OSE model.
APPL box in the diagram) conditionally depend upon the application support
programs (the SUPP box in the diagram), which in turn conditionally depend
upon the networking programs (the NETG box in the diagram). That is,
sometime during their execution, application programs may require application
support programs (or in some cases they may not). Likewise, sometime during
their execution, application support programs may require networking programs
(or in some cases they may not).
Referring to the left side of the above diagram, and speaking loosely, the
“bottom” (4 layers) of the OSI model2 accomplishes networking; the “top” (3
layers) of the OSI model accomplishes application and application services. In
the pure OSI networking model, application services are defined to be entirely
within layer 7 (at the bottom of the application layer). We have stretched the OSI
application services definition to include those networking middleware services
provided by OSI layers 5 and 6.
Relative to networking, the simple model shown in Figure 1 on page 2 is
extremely similar to the more detailed IEEE POSIX Open System Environment
(OSE) model3 , as shown on the extreme left side of Figure 2 on page 4, using
just the 'communication entities' (our networking), 'application platform entities'
(our application support), and 'application entities' (our application) parts of the
OSE model.
The OSI networking layers (layers 1 through 4) can be subdivided, approximately
in half, into transport networking (layers 3 and 4) and subnetworking (layers 1
and 2), as shown in Figure 3, thus making four layers instead of three in our
simple model. These four layers (or software program groups) provide the basis
for the discussions in the remainder of this book. The “bottom” two layers can
always be regarded as networking4. The “top” two layers can always be
regarded as the application environment.
Application and application support (boxes) constitute the “top” of the model;
transport network and subnetworking (boxes) constitute the “bottom” of the
model.
in half, into transport networking (layers 3 and 4) and subnetworking (layers 1
and 2), as shown in Figure 3, thus making four layers instead of three in our
simple model. These four layers (or software program groups) provide the basis
for the discussions in the remainder of this book. The “bottom” two layers can
always be regarded as networking4. The “top” two layers can always be
regarded as the application environment.
Application and application support (boxes) constitute the “top” of the model;
transport network and subnetworking (boxes) constitute the “bottom” of the
model.
off-the-shelf purchased application, such as an X.400 mail application or an
X.500 directory server.
• Application Support has two divisions, called the Application Programming
Interface (abbreviated API-A for a particular application 'A'), and Application
Support (abbreviated SUPP-A). The API and the application support are
closely tied together, and are chosen by the application programmer based
upon the requirements of the application.
Examples of application programming interfaces include CPI-C (Common
Programming Interface for Communications), RPC (Remote Procedure Call),
and MQI (Message Queue Interface). Depending upon the API selected, the
application services may be quite different. For instance, CPI-C utilizes
Advanced Program-to-Program Communication (APPC) and SNA logical unit
6.2 (LU 6.2) services, which includes the protocol flows between two
applications for establishing a conversation, exchanging data, ensuring
commitment of resources, and terminating a conversation. RPC does
networking through program stubs that are customized for each application
program and then attached (linked). RPC usually operates over TCP/IP
protocols. MQI provides queue-to-queue communication, in lieu of direct
program-to-program communication over a dedicated logical connection; it is
a form of networking middleware with resource commitment and assured
message delivery. MQI operates over LU 6.2, TCP/IP, and other networking
protocols.
• Transport Network, which corresponds to the critical Transport and Network
OSI layers, is abbreviated TPORT-A for a particular application 'A.' These
two layers work closely together to ensure that user data is transmitted with
a predictable level of service from the source node to an end node, perhaps
through a set of intermediate nodes.
Depending upon the specific protocol chosen, these layers provide such
functions as optimal route determination, error detection and recovery, and
congestion control. Examples of transport protocols include TCP/IP and SNA
Advanced Peer-to-Peer Networking (APPN*). Each of these protocols utilizes
unique addressing structures, protocol flows between peer transport layers
in end nodes, and routing protocols between intermediate nodes. Please
note that throughout this book the term “transport protocol” will refer to the
combination of these two OSI layers (unless explicitly identified as OSI layer
4) to match nomenclature commonly used in the industry.
Also note that, historically, the Application Support and Transport Network
have been very closely tied together, and the selection of a particular API
forced the selection of a particular network protocol, or, conversely, a
programmer was forced to select an API based on the currently supported
transport protocol in the network. For instance, Remote Procedure Call
(RPC) and the TCP sockets interface are closely associated with the TCP/IP
transport protocol, and would be the application programming interface of
choice for a TCP/IP-based transport network; however, if a CPI-C-based
application might solve a particular business requirement, then SNA
transport would have to be added to this TCP/IP network to support the
CPI-C-based application, which might involve substantial effort.
• Subnetworking, abbreviated SNETG, corresponds to the OSI Data Link
Control and Physical layers. These layers are concerned with getting data
on the physical media of the network, and then getting it reliably and
efficiently from one physical node to the next physical node in the network.
X.500 directory server.
• Application Support has two divisions, called the Application Programming
Interface (abbreviated API-A for a particular application 'A'), and Application
Support (abbreviated SUPP-A). The API and the application support are
closely tied together, and are chosen by the application programmer based
upon the requirements of the application.
Examples of application programming interfaces include CPI-C (Common
Programming Interface for Communications), RPC (Remote Procedure Call),
and MQI (Message Queue Interface). Depending upon the API selected, the
application services may be quite different. For instance, CPI-C utilizes
Advanced Program-to-Program Communication (APPC) and SNA logical unit
6.2 (LU 6.2) services, which includes the protocol flows between two
applications for establishing a conversation, exchanging data, ensuring
commitment of resources, and terminating a conversation. RPC does
networking through program stubs that are customized for each application
program and then attached (linked). RPC usually operates over TCP/IP
protocols. MQI provides queue-to-queue communication, in lieu of direct
program-to-program communication over a dedicated logical connection; it is
a form of networking middleware with resource commitment and assured
message delivery. MQI operates over LU 6.2, TCP/IP, and other networking
protocols.
• Transport Network, which corresponds to the critical Transport and Network
OSI layers, is abbreviated TPORT-A for a particular application 'A.' These
two layers work closely together to ensure that user data is transmitted with
a predictable level of service from the source node to an end node, perhaps
through a set of intermediate nodes.
Depending upon the specific protocol chosen, these layers provide such
functions as optimal route determination, error detection and recovery, and
congestion control. Examples of transport protocols include TCP/IP and SNA
Advanced Peer-to-Peer Networking (APPN*). Each of these protocols utilizes
unique addressing structures, protocol flows between peer transport layers
in end nodes, and routing protocols between intermediate nodes. Please
note that throughout this book the term “transport protocol” will refer to the
combination of these two OSI layers (unless explicitly identified as OSI layer
4) to match nomenclature commonly used in the industry.
Also note that, historically, the Application Support and Transport Network
have been very closely tied together, and the selection of a particular API
forced the selection of a particular network protocol, or, conversely, a
programmer was forced to select an API based on the currently supported
transport protocol in the network. For instance, Remote Procedure Call
(RPC) and the TCP sockets interface are closely associated with the TCP/IP
transport protocol, and would be the application programming interface of
choice for a TCP/IP-based transport network; however, if a CPI-C-based
application might solve a particular business requirement, then SNA
transport would have to be added to this TCP/IP network to support the
CPI-C-based application, which might involve substantial effort.
• Subnetworking, abbreviated SNETG, corresponds to the OSI Data Link
Control and Physical layers. These layers are concerned with getting data
on the physical media of the network, and then getting it reliably and
efficiently from one physical node to the next physical node in the network.
The API is a “contract of sorts” whereby the application software (above the API)
requests particular functions and the application support software (beneath the
API) supports the interface by interpreting the requests (program calls),
executing them, and returning the results across the API to the application
software.
The application (APPL) group of programs is often divided into particular
subgroups or application sets or “application suites,” according to the purpose
of each application. The application support (SUPP) group of programs is often
divided into several general types of application support, according to what the
support does for the application.
A network access is a mechanism that defines interoperation between the
application support (SUPP) and the networking (TPORT and SNETG) program
groups.
The network access operates in much the same way as the API but, instead,
operates between a networking user (for example, an application support
program) and a networking provider (for example, a transport network program).
The networking (TPORT and SNETG) group of programs is often divided into
particular types of networking, according to the functions provided and the
communications medium being used.
The various subgroups of the above main groups (layers) of programs are
discussed in more detail later in this chapter.
Lots of different technologies exist for interoperations between these groups
(and between subgroups within these groups). This chapter identifies many of
these technologies, particularly those in the networking groups (that is, in the
transport network and in the subnetworking program groups)
requests particular functions and the application support software (beneath the
API) supports the interface by interpreting the requests (program calls),
executing them, and returning the results across the API to the application
software.
The application (APPL) group of programs is often divided into particular
subgroups or application sets or “application suites,” according to the purpose
of each application. The application support (SUPP) group of programs is often
divided into several general types of application support, according to what the
support does for the application.
A network access is a mechanism that defines interoperation between the
application support (SUPP) and the networking (TPORT and SNETG) program
groups.
The network access operates in much the same way as the API but, instead,
operates between a networking user (for example, an application support
program) and a networking provider (for example, a transport network program).
The networking (TPORT and SNETG) group of programs is often divided into
particular types of networking, according to the functions provided and the
communications medium being used.
The various subgroups of the above main groups (layers) of programs are
discussed in more detail later in this chapter.
Lots of different technologies exist for interoperations between these groups
(and between subgroups within these groups). This chapter identifies many of
these technologies, particularly those in the networking groups (that is, in the
transport network and in the subnetworking program groups)
