|
|
|
|
SNAP-IX provides Systems Network Architecture (SNA) networking support for Solaris workstations. SNA is a set of protocols devised by IBM to facilitate communications between computers.
Over the years, SNA has evolved considerably. Initially, SNA was heavily
oriented towards accessing host computers, and relied on the host to control
the entire network. Each network or sub-network was controlled by the host;
other computers communicated directly with the host but not with each other.
This old-style SNA is called subarea SNA
, and is still widely
used.
Today, SNA provides powerful and flexible networking capabilities, enabling
direct peer-to-peer communications between computers in the network (without
requiring the intervention of the host). In a full-fledged peer-level network,
elements in the network can communicate as required; but no single computer
is in control of the network. This new-style SNA is called APPN
(Advanced Peer-to-Peer Networking).
Many SNA networks have elements of both subarea and peer-to-peer networking. As networks migrate from subarea SNA to APPN, an APPN-capable host can control older systems while acting as a peer to newer systems. Similarly, a single computer can access both peer computers (in an APPN network) and a host computer (in a subarea network). Communication with the host is controlled by the host; communication with other computers is peer-to-peer and does not involve the host.
A simple subarea network includes the following components.
A node is a component or a computer that participates in an SNA network. SNA defines different node types for different roles in the network.
A host is a mainframe computer compatible with the original IBM System/370. A host is a type 5 node.
An FEP (also known as a
communication controller
) is a separate processor attached to the
host, to manage the host's communications with other computers. An FEP is
a type 4 node.
Users are often on a separate site from the host, so the two sites need to be connected by a communications link.
At the remote end of the communications link is a terminal controller, which controls the use of the link and routes data to the terminals. The best-known IBM terminal controllers are the 3174 and 3274, but a computer running SNAP-IX can act as a terminal controller. A terminal controller is a type 2.1 node.
Users work at terminals to submit work to the host or run host applications. The best-known IBM terminal is the 3270.
Printers such as the IBM 3287 can also be attached to the terminal controller. They can receive output from the host.
A diagram of a subarea network looks like an inverted tree, as shown
in
The root of the tree (at the top of the diagram) is the host computer that controls the network. The branches are the communications links. The leaves (at the bottom of the diagram) are the terminals or printers attached to the network and accessed by users.
The traditional subarea SNA setup described here enables users to access the resources of a single host system. The terminals provide only simple data entry and display functions to and from the terminal controller. The terminal controller is responsible for handling SNA communications between the terminals and the host.
The terminal controller and its terminals can be replaced by an SNA product such as SNAP-IX. From the host's point of view, SNAP-IX appears as a terminal controller. However, it provides the users with additional functions, such as the ability to access more than one host system and facilities for customizing screen displays. In addition, SNAP-IX runs on Solaris computers that can also be used for other tasks not related to SNA (unlike the terminal controller, which is used solely for communications with the host).
This section describes the logical SNA components in a subarea network.
The host node contains the following elements:
The host node contains a system services control point (SSCP) that is responsible for managing network resources. Its jobs include activating and deactivating sessions between host and remote components.
The SSCP also provides an interface to network operators at the host system, who can inspect and control resources in the network.
The host node also contains LUs. On the host, each LU provides an access point to the network for an application.
Communication sessions are maintained between host LUs and the LUs on remote devices, to enable remote end-users to communicate with host-based applications.
At the remote end of the communications link, the node in the terminal controller contains the following logical elements to help control communications with the resources on the host:
The node contains LUs that provide access points to the network for end users and terminal applications. Communication sessions are maintained between these LUs and the LUs on the host.
LUs in subarea networks are dependent LUs; they depend on the support of the SSCP on the host. Before two dependent LUs can establish and use a session, the SSCP must establish a session with the PU on the remote node (the SSCP-PU session). The SSCP uses this session to control and monitor resources on the remote node.
Additionally, the SSCP establishes a session to the remote LU (the SSCP-LU session). The SSCP-LU session is used to control and manage both the LU itself and the session between the host and remote LUs. The remote LU uses the SSCP-LU session to request the SSCP to establish a session between the host and remote LUs (the LU-LU session).
When a session is requested, the SSCP manages the host LU to establish
the LU-LU session with the remote LU. The LU on the host is called the
primary LU
(PLU);
it initiates the LU-LU session and is also able to terminate the session.
The LU on the remote node is called the secondary LU
(SLU); it responds to the session initiation
but is unable to initiate sessions in its own right.
The description of the remote node in a subarea network assumes that the remote node is a type 2 node, which can communicate only with a host system. In more modern subarea networks, however, pairs of type 2.1 nodes (such as SNAP-IX) can communicate without needing to send information through the host. Each node is configured with information about the other node's LUs; the nodes can then use a direct communications link to establish LU-LU sessions.
|
|
|
 |
|