 |
Description  |
|
|
DESCRIPTION
BACKGROUND OF THE INVENTION
1. Technical Field
The field of the invention relates to data processing and more particularly
relates to a method and apparatus for linking SNA data processing
equipment over a packet switched communications network.
2. Background Art
In 1974, IBM's System Network Architecture (SNA) significantly advanced the
state of the art in teleprocessing software systems. E. H. Sussenguth,
"Systems Network Architecture: A Perspective," Conference Proceedings,
1978 International Conference on Computer Communications, Kyoto, Japan,
1978, pp. 353-358; D. Doll, "IBM Strengthens its Architecture," Data
Communications 8, 56-67 (1979). SNA provides a unified design for the
functions and structure of data communications products. Prior to the
introduction of SNA, teleprocessing networks had many problems: Terminals
were often dedicated to the use of a single application, numerous and
diverse line-control procedures and terminal types were ingrained into the
support programs, application programs, and network operations; and
multiple access methods were in common use, thwarting any attempt to share
resources among applications. Each of these problems made it difficult to
expand existing applications or to add new ones. SNA was introduced to
solve these problems and to make teleprocessing applications easier to
install, operate, and expand.
SNA also had its roots in the hardware technological advances of the early
1970s. At that time, it became economically possible to incorporate a
small processor into the design of many terminals.
Prior to such microcomputers, a terminal was commanded directly by its host
computer. For example, each keystroke produced an input character
transmitted independently at the rate of generation; and each output
character was sent at a rate not exceeding that of the printer.
With the new microcomputer-based designs, the processor within the terminal
handles many functions independently of the host, and the transmissions
between host and terminal are complete messages sent at high speed. This
reduces the processing power required at the host and/or allows more
terminals for a host of the same size. A more important change, however,
was in system structure. No longer is a tight coupling between terminal
and host needed; device control now can be placed at or near the end
terminal and not in the host. Thus, system commands, protocols, and
procedures designed for tight coupling are no longer required; instead, a
new set specifically designed for distributed processing is required.
Just as the processor in the terminal now handles device control, it also
readily becomes an application processor. From a system standpoint, the
application may now be performed in any several places within a
network--at the host, at a controller, or even at the terminal itself.
This is a new structure that essentially did not exist before 1974 and
definitions for the control of such a system were heeded. The advent of
distributed processing, then whether for device control or distributed
application processing, was the fundamental technical rationale behind the
creation of SNA.
From an architectural point of view, SNA is a top-down structured design
composed of layers. R. J. Cypser, Communications Architecture for
Distributed Systems, Addison-Wesley Publishing Co., Reading, Mass., 1978;
SNA Technical Overview, Order No. GC30-3073, available through IBM branch
offices. The lowest layer, data link control, directly manages physical
resource--the transmission facilities that connect nodes. Successive
layers provide additional services. For example, the path control layer
provides a routing service so that its users are unaware of the physical
topology of the network, and some nodes contain a control point that
controls the nodes (e.g., terminals and controllers) and lines in their
own portions of the network. Other layers provide services to
applications; these can include transparent access to local or remote
resources, mapping of data streams to and from application data structures
(also called presentation services), access to other local or remote
programs, management of buffer commitments, and encryption of data before
transmission and decryption upon receipt.
In SNA, a network addressable unit (NAU) is a location in the SNA network
that supports one or more ports for communication via the network. Each
NAU has a network address.
SNA defines three types of NAU.
1. System Services Control Point (SSCP): A special-purpose NAU used for
network management. An SNA network can have one or more SSCPs, each of
which manages a portion of the network. The function of the SSCP is the
general management of a control domain, such as bringing up the network,
helping to establish logical connections between other NAUs, and helping
in recovery and maintenance, when necessary. It also provides the
interface to the network operator services for that domain.
2. Physical Unit (PU): An NAU that acts as a companion to the SSCP in SNA
network configuration management. Each node that has been defined to an
SSCP has at least one PU. The PU provides a location for
configuration-related services which must be performed at a particular
node. An SSCP and PUs together control the network configuration and the
data-transportation resources provided by the nodes in the domain of the
SSCP.
3. Logical Unit (LU): An NAU that provides windows or ports through which
the end-user accesses the SNA network. The LU is also the port through
which an end-user accesses SSCP-provided services to help in establishing
logical connections between LUs. The LU may support communication between
end-users (or LUs) by editing or transforming the requests, grouping
requests, correlating responses with requests, and otherwise bridging from
the environment of the end-user.
In SNA, four examples of nodes, hosts, communications controllers, cluster
controllers, and terminal nodes, are designated as types T5, T4, T2 and
T1, respectively. The architectural distinctions among them are in the
layers and function subsets that are used for each type. These type
numbers correspond to each node's PU-type (PU5, PU4, PU2, and PU1), which
denotes the capabilities in the lower layers, particularly in data link
control and path control.
PU1 - Type-1 (Terminal) Node
A terminal is a node of lesser function to which one or more I/O devices
can be attached, and which depends on the boundary function of the
adjacent host or communications controller for (1) transforming network
addresses to local address form, and vice versa, and (2) handling
normal-flow sequence numbers.
PU2 - Type-2 (Cluster Controller) Node
A cluster controller (CLC) node can control a wide variety of devices and
may have a data-processing capability. It depends on the boundary function
of the host node or of the communications controller to which it is
attached for assistance in packing data flow within a session, for
transforming network addresses to local address forms and vice versa, an
for some assistance in session control for its PU and LUs.
PU4 - Type-4 (Communications Controller) Node
A communications controller (COMC) is a node that handles transmission
services for a subarea of the network and controls communication lines and
such related resources as line buffers. It may provide the intermediate
function and also the boundary function for cluster controller nodes and
terminal nodes. Usually, there are no logical units in a COMC; however,
there is no architectural restriction against it. Architecturally, for
example, a COMC might contain some part of LUs for attached devices that
are incapable of housing their own LU functions. The type-4 path control
may have the capability of both segmenting and blocking.
PU5 - Type-5 (Host) Node
A host is a type-5 node of the network. It provides a general purpose
data-processing function, and may also provide the intermediate function
and boundary function (for example, the boundary function for
channel-attached cluster controllers is located in the host). The system
services control point function for a control domain of the network is
often located in a host. A host that houses an SSCP is sometimes referred
to as a control host. The type-5 path control may have the capability of
both segmenting and blocking. Implicit in the host are all the processing
engines, storage devices and management functions needed to carry out its
role.
Networking is the concept of a geographical distribution of terminals
(usually hundreds or thousands in ten to one hundred locations) working
with application programs in computer complexes (usually one to ten or
more computers in a like number of locations).
As the need for general-purpose networking capability grew, so also did the
need for codification of conceptual design so that hardware and software
products would work in harmony, and so that each installation could be
readily tuned for performance and reliability. SNA implemented in such
System/370 software products ad VTAM, TCAM, and NCP, now provides
extensive networking capability. S. Scott, "VTAM Means Software for More
Logical Network Management," Data Communications 8, No. 1, 77-90 (1979).
L. Esau, "How to Access a Network via IBM's TCAM," Data Communications 8,
No. 2, 89-106 (1979). A. Hedeen, "Networking: Building a Software Bridge
Between Multiple Hosts," Data Communications 8, No. 3, 87-100 (1979).
SNA enabled multiple-host networks. J. P. Gray and T. B. McNeill, "SNA
Multiple-System Networking," IBM Syst. J. 18, 263-297 (1979). This
included capabilities in which a terminal controlled by one host could
access an application in any host in the network, and host-to-host
sessions could also be established. The single control point (for session
establishment and configuration services) and hierarchical control were
generalized to a network of multiple control points which operates as
peers of one another. Further enhancements provide functions such as
parallel links, transmission priority, and multiple active routes for data
transmission. Parallel links may be used between adjacent nodes of a
network to provide additional bandwidth and backup, and these parallel
links may be logically grouped to automatically distribute traffic across
the links of a group. This concept also compensates for degradation
resulting from errors on any of the links in the group, because
transmission is disrupted only if the last remaining link in the group
fails. Network availability can also be increased by providing multiple
routes between the same two points in a network, so that traffic can be
rerouted (and disrupted sessions reconnected) to avoid failing
intermediate nodes or failing links. Multiple routes can also be useful
for traffic load leveling. These capabilities gave SNA the complete
configuration flexibility of mesh networks, as distinct from the former
tree structures and connection of trees.
To save costs, networks are normally designed so that the peak rate of
traffic into the network may, at times, exceed the maximum network
throughput. Queues in the network help smooth the peak loads, but
flow-control mechanisms are necessary to prevent substantial throughput
degradation, or even deadlocks, as the offered load increases beyond the
network's capacity. G. A. Deaton and D. J. Franse, "A Computer Network
Flow Control Study," Conference Proceedings, 1978 International Conference
on Computer Communications, Kyoto, Japan, 1978, pp. 135-140. V. Ahuja,
"Routing and Flow Control in Systems Network Architecture," IBM Syst. J.
18, 298-314 (1979). Flow control operate by limiting the rate at which
traffic is accepted into the network. SNA products use a flow control
mechanism based on pacing which allows a specific number of message units
to be sent from one end of a route, after a pacing response is received
from the other end. This number is dynamically adjusted by checking queue
depths at the nodes along the route. The dynamically adjusted pacing
values provide greater throughput than statically defined values used in
other systems. Another aspect of SNA flow control is the use of message
priorities, such that at each trunk line messages are transmitted in the
order of the priority given to their respective sessions.
SNA is based upon predefined routing with pacing which is distinct from
routing schemes for packet switched networks that allow routing decisions
on every message without establishing explicit physical routes for session
traffic.
Packet switching uses asynchronous time-division multiplexing (ATDM) of
messages on each segment of each path. In a switched facility the circuit
is set up by a special signaling message that threads its way through the
network seizing channels in the path as it proceeds. After the path is
established, a return signal informs the source that data transmission may
proceed, and all channels in the path are used simultaneously. A given
message, going from node to node, ties up an entire circuit between that
pair of nodes.
Packet switching provides store-and-forward nodes between the two nodes of
the subscriber. The packet carrier shares that circuit (that was between
packet-carrier nodes) with still other subscribers. There may be a series
of store-and-forward nodes in the path, in which case each segment could
be individually time-shared among subscribers. The circuits provided by
packet carriers are called virtual circuits in that they appear to be
available to a subscriber but may in fact be shared with other subscribers
unknown to him.
On packet-switching networks, there must be a separate and distinct
signaling phase, in which the user exchanges control packets with the
network, to advise the network of the address of the called party. After
access is granted and initial signaling is completed, each user
information record not only must contain the normal data link controls,
but in addition must contain a packet header field. Once the system
determines that it has reached the end of the packet header field, the
user should be free to use any code or bit sequences for either coded or
noncoded information.
The SNA way of accommodating the variable message lengths from different
types of work stations is to provide a facility for segmenting longer
messages into more manageable segments. These segment sizes would be
selected to fit the buffers along the path, and might also be tailored in
accordance with line-reliability problems or response-time requirements.
The architecture then must provide the controls necessary to identify this
segmentation and to permit the reconstruction of the entire messages at
the destination point.
Reassembly of segments that could arrive out of sequence, because they can
take different paths, poses another set of problems. This out-of-sequence
arrival must be prevented in SNA by routing via the same physical path for
each source/destination pair. However, in packet switched networks
additional segment headers and buffer management are used to reestablish
the correct sequence
In message switching an entire message is sent to a centrally located node,
where it is stored for as long as necessary, until an appropriate
connection can be made with the destination. In the process of packet
switching, on the other hand, the source and destination first agree to a
logical connection. The message is segmented into smaller parts if that is
needed to avoid monopolizing a line, and the segments, or packets, are
routed through intermediate nodes in real time to the destination.
Destination tables in each intermediate node permit a given message to
"find its way" at each such node toward its destination. The primary
objective of message switching systems usually is to ensure the ultimate
delivery of a message in a reasonable time which may be minutes, hours or
even days, depending on line availability and line-loading conditions. The
primary objective of packet switching is to preserve fast response time,
on the order of a few seconds, while reducing costs through the shared use
of the lines, which can be high-speed trunks.
The message switching system has very large amounts of secondary storage to
permit the accumulation of relatively large queues of messages. In the
message switching system, the intermediate node that has the message
switching function accepts the responsibility for the ultimate delivery.
It acts as a "recovery node" in that the message is assumed to be safe and
recoverable once it reaches the message switching node. In contrast to
this, the packet switching system first ensures that a
source-to-destination connection exists, that protocols are
pre-established for an effective dialogue between source and destination,
and that buffering and pacing are agreed to beforehand for efficient data
flow. The buffer sizes and the queue management in multiple intermediate
nodes can then be more economical.
Data terminal equipment (DTE) is defined as any type of user facility from
a large computer system to a very simple terminal. Data
circuit-terminating equipment (DCE) is defined as terminating the access
line from the carrier's data switching exchange (DSE) and performing any
signal conversions necessary to the operation of the carrier.
Real digital circuits extend from one DCE, via the DSE network, to another
DCE. In packet switching networks, on the other hand, a real circuit
extends from each DCE to a DSE, and virtual circuits are provided among
DSE's. This involves sharing of a broadband facility among multiple
unrelated subscribers. The technique employes asynchronous time-division
multiplexing on a message (that is, a fixed-size packet) base.
In packet switching all messages (both user information and network call
control information) are formed into discrete units called packets, which
contain a header to specify packet control functions and packet network
destination. The packet network provides a virtual circuit, that is, one
that appears to be a point-to-point connection for a pair of DTEs, but
actually is a circuit that is shared (in part) by many DTEs through
multiplexing (asynchronous time-division multiplexing) provided by the
packet carrier. These virtual circuits may be switched (in which case, a
virtual-call set-up and clearing procedure is required of the DTE).
One of the things desired in some data processing systems is to be able to
multiplex many different sessions across a single interface when different
messages have different destinations. This can be achieved by creating a
logical channel ID to locally designate each virtual circuit. For this,
each virtual call or permanent virtual circuit is locally assigned a
logical channel group number and a logical channel number. For virtual
calls, these are assigned during the call set-up phase. The logical
channel ID (logical channel group number plus logical channel number) then
must be carried in every packet header (except those for restart packets
where these ID fields are zero). A virtual circuit may carry many
different SNA sessions, concerning different logical units (LUs) that are
all located at the same logical channel. The transmission header (TH)
(carried within the data field of the data packet) would identify each
session. Alternatively, a separate virtual circuit (and logical channel)
could be used for each session.
The Data Switching Exchanges (DSEs) of packet switching networks are built
to recognize packets. All of the data to be sent between DTEs are preceded
by packet headers. In addition, all of the network control messages are
also preceded by packet headers. Each packed header also includes the
local logical channel ID for that virtual circuit and also a packet type
indicator.
The ARPANET was the first packet-switching network. This network was
designed under a 1969 DARPA research and development program. Initially
the ARPANET was an experimental network built to test the concepts of
packet switching and resource sharing. As the ARPANET matured, users with
operational requirements, rather than experimental requirements, began to
use it.
In April 1982, the U.S. Department of Defense (DoD) directed that the
Defense Data Network (DDN) be implemented as the DoD common-user
data-communications network, based upon ARPANET technology and
architecture. The Defense Data Network (DDN) is described in the NTIS
publication AD-A166324 entitled "DDN (Defense Data Network) Protocol
Handbook," Vol. 1, DoD Military Standards Protocols, December 1985 by E.
J. Feinler, et al., and its companion volumes 2 and 3 (The DDN Standard).
Additional information can be found in the NTIS publication AD-A137427
"Defense Data Network X.25 Host Interface Specification," December 1983.
FIG. 1 shows a graphic representation of the architectural model of the DoD
protocol suite. The architecture is similar to, but not identical with,
the International Standards Organization (ISO) Open Systems
Interconnection (OSI) architecture. (See Computer Networks, Vol. 7, No. 5,
p. 293-328 (October 1983) for a discussion of the DoD Internet
Architecture Model.)
The DDN standard establishes criteria for the Internet Protocol (IP) which
supports the interconnection of communication subnetworks. It introduces
the Internet Protocol's role and purpose, defines the services provided to
users, and specifies the mechanisms needed to support those services. The
standard also defines the services required of the lower protocol layer,
describes the upper and lower interfaces, and outlines the execution
environment services needed for implementation.
Transmission Control Protocol (TCP) is a transport protocol providing
connection-oriented, end-to-end reliable data transmission in
packet-switched computer subnetworks and internetworks.
The Internet Protocol (IP) and the Transmission Control Protocol (TCP) are
mandatory for use in all DoD packet switching networks which connect or
have the potential for utilizing connectivity across network or subnetwork
boundaries. Network elements (hosts, front-ends, bus interface units,
gateways, etc.) within such networks which are to be used for internetting
shall implement TCP/IP.
The Internet Protocol is designed to interconnect packet-switched
communication subnetworks to form an internetwork. The IP transmits blocks
of data, called internet datagrams, from sources to destinations
throughout the internet. Sources and destinations are hosts located on
either the same subnetwork or connected subnetworks. The IP is purposely
limited in scope to provide the basic functions necessary to deliver a
block of data. Each internet datagram is an independent entity unrelated
to any other internet datagrams. The IP does not create connections or
logical circuits and has no mechanisms to promote data reliability, flow
control, sequencing, or other services commonly found in virtual circuit
protocols.
The DDN standard specifies a host IP. As defined in the DoD architectural
mode, the Internet Protocol resides in the internetwork layer. Thus, the
IP provides services to transport layer protocols and relies on the
services of the lower network protocol. In each gateway (a system
interconnecting two or more subnets) an IP resides above two or more
subnetworks protocol entities. Gateways implement internet protocol to
forward datagrams between networks. Gateways also implement the Gateway to
Gateway Protocol (GGP) to coordinate signaling and other internet control
information.
In an April 1982 directive, the Department of Defense (DoD) stated that the
Defense Data Network (DDN) would be implemented as the common user data
communication network. With DDN, DoD would reduce costs, improve
reliability, and gain interoperability for all information systems and
data networks. Therefore, all major DoD requests for proposals that have
communication networking requirements demand the use of DDN.
IBM, in the early 1970's, adopted System Network Architecture (SNA) as the
standard for communication networking. IBM communication products
developed since that time, including both hardware and software, support
SNA. However, DDN and SNA are incompatible standards. While both standards
consist of a seven layer architecture concept to perform the various
networking functions such as routing and flow control, the separation of
functions into layers and the theories of how to perform the functions are
different.
It is because of these two incompatible standards that the DDN benefits of
reduced cost and improved reliability cannot be achieved at present for
the large number of SNA installations that currently exist within the DoD
community.
______________________________________
$SNA Series/1 Product for SNA PU Functions
#FREEBUF DDN/SNA Buffer Management Macro
to Free a Buffer
#GETBUF DDN/SNA Buffer Management Macro
to Get a Buffer
#RSTRBUF DDN/SNA Buffer Management Macro
to Restore a Buffer
#SAVEBUF DDN/SNA Buffer Management Macro
to Save a Buffer
ABEND Abnormal End of Task
ADM Administrative
AMOD Access Module
AMODs Access Modules
API Application Program Interface
ARJE Advance Remote Job Entry
BCAM Basic Channel Access Method
BMF Buffer Management Facility
CLIST Command List
CPU Central Processing Unit
CSI Console Service Interface
DDN Defense data Network
DDR Direct Datagram Request
DLC Data Link Control
DNAM DDN Access Method
DoD Department of Defense
DSAF Destination Subarea Field
DSX Distribution System Executive
EBCDIC Extended Binary-coded Decimal
Interchange Code
EDL Event Driven Language
EDX Event Driven Executive
ER Explicit Route
ERs Explicit Routes
ERN Explicit Route Number
FEP Front End Processor
FEPs Front End processors
FSGETQ SWOF Macro to Get an Element from Queue
FSPUTQ SWOF Macro to Put an Element to a Queue
HCF Host Command Facility
HLI High Level Interface
HMOD Hardware Module
HMODs Hardware Modules
I/O Input/Output
IP Internet Protocol
IPF Initializtion Parameter File
IPL Initial Program Load
JCL Job Control Language
LU Logical Unit
LUs Logical Units
MACLIB Macro Library
MNCH Master Network Control Host
MVS Multiple Virtual Storage
NCCF Network Communication Control Facility
NCD Network Control Domain
NCF Network Control FEP
NCFs Network Control FEPs
NCH Network Control Host
NCHs Network Control Hosts
NCP Network Control Program
NMVT Network Management Vector Transport
NRD Node Resource Distribution
NRDLs Node Resource Distribution Lists
OSI Open Systems Interconnection
PDS Partitioned Data Set
PDSs Partitioned Data Sets
PIU Path Information Unit
PIUs Path Information Units
PMOD Personalized Module
PS/2 IBM Personal System/2
PU Physical Unit
PUs Physical Units
PU2 Physical Unit 2
PU4 Physical Unit 4
PU5 Physical Unit 5
RAF Remote Access Facility
RAFs Remote Access Facilities
RECFMS Record Formatted Maintenance Statistics
RM Remote Manager
ROS Read Only Storage
Sysgen DDN/SNA System Generation Function
SDS Sequential Data Sets
SDLC Synchronous Data Link Control
SNA System Network Architecture
SNAPS NSA Portable Software by Data
Connections, Ltd.
SNAP-2 SNA PU Type 2 Secondary Product
SNAP-5 SNA PU Type 5 Primary Product
SNAP-LINK SDLC Primary and Secondary Link
Level Product
SNAP-THRU SNA Inter-domain Pass-through
Primary Product
SSCP System Service Control Point
SWOF System Wide Operator Facility
SWOP System Wide Operator Program
TCI Transmission Control Interface
TCP Transmission Control Protocol
TG Transmission Group
TGs Transmission Groups
TGB Transmission Group Control Block
TSO Time Sharing Option
UDP User Datagram Protocol
VM Virtual Machine
VRs Virtual Routes
VSAM Virtual Storage Access Method
VTAM Virtual Telecommunications Access Method
______________________________________
RELATED COPENDING PATENT APPLICATION
A related concept in I/O control is described in the copending U.S. patent
application, Ser. No. 043,798, filed April 29, 1987 by S. L. Estrada, et
al., entitled "Concurrent Multi-Protocol I/O Controller" assigned to IBM
Corporation, the disclosure of which is incorporated herein by reference.
OBJECTS OF THE INVENTION
It is an object of the invention to provide DDN interoperability from IBM
host computers that will let SNA installations communicate over DDN packet
switched networks.
It is another object of the invention to provide SNA terminals to SNA host
function which will enable attachment of remote products such as cluster
controllers and associated terminals and also provide for the direct
attachment of personal computers.
It is another object to provide a centralized network control which will
provide for a centralized communication network manager.
It is still a further object to provide a host-to-host communication
capability, enabling MVS and VM host systems to address each other and
communicate over DDN, providing direct communication data bases. SUMMARY
OF THE INVENTION
These and other objects, features and advantages are accomplished by the
invention disclosed herein. The overall function of the invention is to
provide the basic operating capabilities of SNA both for host based
application to application as well as remote terminal full screen access
across the Defense Data Network (DDN). The problem that is presented by
the integration of these two technologies is that SNA is a connection
oriented technology and DDN is a connectionless or packet switching
technology that requires an Internetting Protocol (IP) header on all
information transmitted through the network and across multiple networks.
One of two key concepts utilized in this system is the definition of a
localized SNA network to each SNA host by the channel attached Front End
Processors (FEPs). These FEPs present either an SNA LU 2 definition or an
SNA PU 4 definition to the host to allow it to carry out regular control
to the host applications or to the terminal users.
The second key concept that has been implemented here is providing primary
SNA support, PU5, in the Remote Access Facilities (RAF). This enables each
RAF to control all the SNA terminals and devices attached to it as
separate networks. The RAF and the FEP working together imbed the SNA
protocols in the IP datagrams and provide the proper SNA connections and
control. This technique also allows any terminal to access any host that
it is authorized for. This is not permissible in normal SNA X.25 networks
today.
The resulting invention provides SNA terminals to SNA host function
enabling attachment of remote products such as 3274 cluster controllers
and associated terminals such as 3278s and 3180s, and also provide for the
direct attachment of PCs emulating 3270 devices. The invention also
provides centralized network control for a centralized communication
network manager using IBM's Network Control program products such as
Network Communications Control Facility (NCFF) and Network Problem
Determination Application (NPDA). The invention further provides
host-to-host communication capabilities, enabling MVS and VM host systems
to address each other and communicate over DDN, providing direct
communication between data base products.
DESCRIPTION OF THE DRAWINGS
These and other objects, features and advantages of the invention will be
more fully appreciated with reference to the accompanying figures.
FIG. 1: is a prior art architectural diagram of the Defense Data Network
FIG. 2: Systems Protocol
FIG. 3: MVS/DDN System Block Diagram
FIG. 4: MVS/DDN ACP Structure
FIG. 5: Internet Communication Using ACP between client and server
FIG. 6: DNET-DNET Hierarchy of Protocols
FIG. 7: Header Format
FIG. 8: Configuration Diagram
FIG. 9: Transaction Delay, Resource Utilization and Memory Usage
FIG. 10: Terminal Series/1 Configuration
FIG. 11: Host FEP Series/1 Configuration
FIG. 12: DDN/SNA Configuration
FIG. 13: SNA Data Traffic Flow over DDN
FIG. 14: PU2 FEP Components and RAF Components
FIG. 15: PU4 FEP Components
FIG. 16: DDN/SNA System Sysgen Overview
FIG. 17: DDN/SNA System Elements
FIG. 18: Phase I Processing Overview
FIG. 19: Phase II Processing Overview
FIG. 20: Phase III Processing Overview
FIG. 21: DDN/SNA Host-to-Host System Overview
FIG. 22: PU4 Host-to-Host Application Overview
FIG. 23: PU4 Host-to-Host Application Data Flow
FIG. 24: DDN/SNA Front End Processor
FIG. 25: DDN/SNA NCF FEP
FIG. 26: DDN/SNA Remote Access Facility
FIG. 27: DNAM Synchronous EDL Instruction Flow
FIG. 28: DNAM Asynchronous EDL Instruction Flow
FIG. 29A & 29B: DNAM Administrative Facility Task
FIG. 30: Series/1 FEP Functional Overview
FIG. 31: Series/1 Front End Processor Diagram
FIG. 32: Series/1 Remote Access Facility Diagram
FIG. 33: Network Control Front End Processor
DESCRIPTION OF THE BEST MODE FOR CARRYING OUT THE INVENTION
The invention solves the problem of using DDN communications network in an
SNA environment. FIG. 2 shows the system protocol development for the
invention.
The invention has three principal features: SNA terminals to SNA host
function--this enables attachment of remote products such as 3274 cluster
controllers and associated terminals such as 3278s and 3180s and also
provides for the direct attachment of PCs emulating 3270 devices.
Centralized Network Control--This provides for a centralized communication
network manager using IBM's Network Control program products such as
Network Communications Control Facility (NCFF) and Network Problem
Determination Application (NPDA).
Host-to-host--This provides communication capabilities, enabling MVS and VM
host systems to address each other and communicate over DDN, providing
direct communication between data base products such as Information
Management System (IMS), and office system products such as Professional
Office System (PROFS) and Distributed Office Support System (DISOSS).
Our technical solution requires that Series/1 (S/1) processors be used as
interfaces between the commercial hardware/software and DDN. The S/1
processors are configured to perform three unique types of functions: (1)
A DDN/SNA Front End Processor (FEP) to interface IBM SNA hosts with DDN,
(2) DD | | |
