SNA-System Network Architecture

1.2.3     SNA—Systems Network Architecture

SNA, Systems Network Architecture, was originally released by IBM in 1974. It has since been enhanced many times and is now the predominant method used to form inter­nets of various IBM computers. Additionally, many vendors other than IBM provide various levels of SNA support, allowing many non-IBM systems to participate in SNA networks. SNA is an architecture, not a product. There exist software and hardware products from both IBM and other vendors that implement different portions of SNA.

SNA is covered here because most vendors of UNIX systems now support SNA, in one form or another. Frequently the support is for LU 6.2, which is the emphasis of this section. Unfortunately there is no common pro­gramming interface across all these products, so it is not possible to say much about the C interface to an SNA implementation.

SNA was originally designed to support the networking of nonprogrammable devices, such as terminals (termed "workstations" by IBM) and printers, to IBM main­frames. (An IBM "mainframe" is a system based on the System/370 architecture, as opposed to other IBM systems, both large and small.) Because of this non peer-to-peer evolution, where one system (the mainframe) is always the master in the communication relationship, SNA appears more complicated than the other communication architectures that are discussed (TCP/IP, for example). SNA has always had a terminology all its own, and has been confounded by the mainframe requirements just to implement and configure an SNA network—CICS, VTAM, NCP, cluster controllers, and the like. In the past years SNA has adopted the protocols and implementations that allow two user processes to communicate easily with each other, and without the requirement of a mainframe in the communication link.

The user of a network is defined to be an end user, which is either a user at a termi­nal or an application program (process). An end user interacts with a logical unit (referred to as an LU) to access the network. The type of services provided by the LU to the end user differs for each type of LU. LU types 2, 3, 4, and 7 support communication between processes and terminals, while LU types 1, 6.1, and 6.2 are for communication between two processes. The LU in turn interacts with a physical unit (referred to as a PU). The PU is, in essence, the operating system of the node, and it controls the data-link connections between the node and the network. It is shown in Figure 17.

Figure 17. SNA node with logical unit and physical unit

If we consider the PU as the operating system of the node, then the data-link portion is the device driver of the node. The type of node is specified by the PU type. Five types of nodes are currently supported—1, 2.0, 2.1, 4, and 5. These are referred to, for exam­ple, as a "Type 2.1 node," or "T2.1 node," or as PU 2.1. The term "network host" or a "system on a network," is referred to by IBM as a node—an addressable unit on a network. IBM uses the term node, since an SNA node can be a nonprogrammable device such as a terminal or printer.

Our interest in this text is only with LU 6.2 and PU 2.1, as these are the strategic IBM products, and the only SNA implementations that adequately support communica­tion between processes.

The bibliography lists several SNA manuals available from IBM that provide addi­tional details on all the features mentioned here.

1.2.3.1       Overview

SNA was developed in a layered approach that is similar to the OSI model. The seven SNA layers are shown in Figure 18.

Since SNA predates the OSI model, there is no exact mapping from the seven SNA layers into the seven OSI layers. An approximate mapping between the two, along with a consolidation of the seven SNA layers into the corresponding SNA functions, is also shown in Figure 18.

In the seven SNA layers, the LU performs the functions of layers 4, 5, and 6— transmission control, data-flow control, and presentation services. The top layer, transac­tion services, is called the user process. The bottom two layers are com­bined into what we have called the network access layer, as these are the two layers that change depending on the interface types supported by the node (SDLC, token ring, etc.).

Note that the four SNA functions in Figure 18 correspond to our simplified 4-layer model. What is called a user process is called a transaction program (TP) by IBM.

Two forms of SNA networks have evolved.

•   Subarea SNA networks.

These networks are built around IBM mainframes that maintain centralized con­trol over the network. Internets of independent SNA subarea networks can be formed using the SNA network interconnect (SNI) facility.

•   APPN networks.

APPN stands for "Advanced Peer-to-Peer Networking" and was introduced by IBM in 1986 for the System/36. It has also been called SNA/LEN (low entry net­working). In 1988 the capability was introduced for APPN networks to be con­nected together through an SNA subarea network. APPN is limited to PU Type 2.1 nodes and supports LU 6.2. APPN has features not found in subarea networks, such as dynamic routing. Baratz et al. [1985] describe the prototype implementation of APPN.

Figure 18. 7-layer SNA model and approximate mapping between SNA layers and OSI model

Today most of the more than 20,000 SNA networks in existence are subarea networks based on IBM mainframes. But the increased shift towards smaller systems and the increased capabilities of APPN should lead to the creation of many APPN-based net­works.

1.2.3.2       Data-Link Layer

The predominant form of network access used in SNA networks is SDLC—synchronous data-link control. Typical SDLC links operate between 4.8 Kbps and 57.6 Kbps over leased or switched telephone lines. The token ring is now starting to be used for LANs. One IBM product, the RT, supports LU 6.2 over an Ethernet. IBM mainframes can com­municate with each other using SNA over a System/370 data channel.

1.2.3.3       Path-Control Layer

In the TCP/IP and XNS protocol suites, the IP layer and the IDP layer both provided an unreliable datagram delivery service to the layers above. In SNA we encounter a dif­ferent scenario where the SNA path-control layer provides a virtual circuit service to its upper layer (the LU). This means that the path-control layer, and the data-link layer beneath it, provide error control, flow control, and sequencing.

             Figure 19. Encapsulation of SNA data on an SDLC link

Path control is the layer responsible for moving packets around in an SNA network. Figure 19 shows the encapsulation that each layer applies to a message of user data being transmitted by an SNA node, assuming an SDLC data link.

The request header is the LU header, and the transmission header is the PC (path control) header, if we follow the conventions from the TCP/IP and XNS protocol suites where the name of an encapsulated header is the name of the layer that adds the header. There is another header that is sometimes added by the LU—a function management header (FMH) that carries control information between LUs. This header is placed between the request header and the data, with a bit turned on in the request header specifying that a function management header is present.

In Figure 19 the data portion as being from 0 to 256 bytes in length is shown. The maximum response unit size is typically 256 or 512 bytes, but this size can be negotiated to other values by the two LUs.

Every LU in a given SNA network must have a unique name, from 1 to 8 characters. In an internet of SNA networks, every network must have a unique name, also from 1 to 8 characters. A particular LU in an internet is identified by its network-qualified LU name. This consists of

•     network name,

•     LU name within the network.

The network-qualified LU name is written as netname.LUname using a period between the two names. The actual mapping of this network-qualified LU name to a physical address is handled by a portion of the LU called directory services.

The size of the transmission header that path control uses for moving packets through a network ranges from 6 to 26 bytes, depending on the node types. A 6-byte transmission header is shown in Figure 19. These 6-byte headers are used for traffic between two adjacent Type 2.1 nodes. The 26-byte transmission header is used for data exchanges between two adjacent subarea nodes that support explicit routing and virtual routing. A complete treatment of SNA routing and SNA address formats is beyond the scope of this text. Fortunately, it is not a requisite to understanding the use of LU 6.2, which is the intent of our coverage of SNA.

Path control also does packet fragmentation and reassembly, termed segmenting in SNA, when a packet must be divided into pieces before being passed to the data-link layer. This is similar to the fragmentation and reassembly done by the IP layer in TCP/IP.

1.2.3.4       LU 6.2—APPC

LU 6.2 is also referred to as APPC for Advanced Program-to-Program Communication and was released by IBM in 1982. LU 6.2 can use either PU 2.0 or PU 2.1. The major difference is that PU 2.0 can only be used to communicate with an IBM mainframe, and has inherent in it the master-slave relationship, where the mainframe is the master. PU2.1, however, is newer, and systems implementing PU 2.1 can communicate with each other, without the need for a mainframe in the communication path. All newer IBM implementations of SNA (System/36, System/38, AS/400, RT, PC) support PU 2.1.

LU 6.2 provides a connection-oriented, reliable, half-duplex service to an application program. Note that this is the first half-duplex service that we have encountered. Both TCP and SPP are full-duplex protocols. LU 6.2, however, allows data flow between the user processes only in a single direction at a time. In Figure 20 LU 6.2 is added to the table of protocol features that is being built. This time a row for the connection-oriented protocols indicating whether the protocol provides a full-duplex data stream is added to the user process.

Figure 20. Comparison of protocol features: Internet, XNS, and SNA

Notice that LU 6.2 does not provide an end-to-end data checksum, which is different from the other connection-oriented protocols like—TCP and SPP. The developers of SNA consider the hop-by-hop reliability of the data-link layer (the cyclic redundancy check provided by the SDLC protocol, for example) to be an adequate test for corrupted data. Yet LU 6.2 provides positive acknowledgments, timeout and retransmission, duplicate detec­tion, and sequencing, so it is still considered a "reliable" protocol.

Sessions and Conversations

In SNA terminology, the peer-to-peer connection between two user processes is called a conversation. The peer-to-peer connection between two LUs is called a session. A ses­sion is usually a long-term connection between two LUs, while a conversation is often of a shorter duration. This is shown in Figure 21.

Figure 21. SNA sessions and conversations

Using Figure 21 some of the features provided by a Type 2.1 node that are not available with a Type 2.0 node can be listed.

•      A T2.1 node supports multiple hardware links.

•      A T2.1 node supports parallel sessions for its LUs.  This means that two LUs, each in a different node, can have multiple sessions with each other.

•      A T2.1 node supports multiple sessions for its LUs. This means that a given LU can have sessions with more than one partner LU at the same time.

An example is shown in following Figure 22.

Figure 22. Example of sessions and conversations between Type 2.1 nodes

Sessions are expensive to establish, so a typical LU establishes a certain number of sessions with its partner LUs. This forms a pool of active sessions for the LU to manage. When a user process wants to allocate a conversation, it requests the use of a session" from the LU for the conversation. The LU picks an available session from its pool and dedicates this session to the conversation. The user process can use this conversation for a single transaction with its partner process, or it can hold on to the conversation for a long time. When the process is finished with the conversation, the process deallocates it. This allows the LU to put the conversation back into an available pool.

Sessions are usually established by a network operator or when the system is initialized, so the typical user has no control over the session allocations. Note that LU 6.2 differs from both TCP and SPP in its explicit allocation and use of sessions. While a TCP con­nection between two user processes implies that the two TCP modules have a "session" of some form between them, we do not have to preallocate a certain number of sessions between two TCP modules. There is no inherent limit on the number of "sessions" that a TCP module can have with other TCP modules, other than any resource limits in its implementation (table sizes, number of processes allowed by the operating system, etc.). LU 6.2 requires more user control in specifying the number of sessions to allocate between LUs.

In our client-server model, a server process is identified as a process that had exe­cuted a passive open, awaiting a connection from a client process.  This implied that the server process was already executing when it did the passive open. The server was identified by a well-known address that was protocol-dependent. LU 6.2 is different in that the client specifies .the name of the partner program to execute—called the TP (transaction program) name. Furthermore, the target LU usually creates a new program instance (i.e., a new process) for every conversation that is started with a given TP name. Each LU associates a conversation with a unique identifier, which is called a conver­sation ID, and this ID associates a packet with a particular process. (Since a conversation has exclusive use of a session, we can call this either a conversation ID or a session ID.) In an APPN network the conversation ID is a 16-bit integer. This 16-bit value is carried in the transmission header and is used by APPN to specify the user process. From our definition of an association from the previous chapter, for SNA it consists of

•     the protocol (LU 6.2),

•     the local network-qualified LU name,

•     the local conversation ID,

•     the foreign network-qualified LU name,

•     the foreign conversation ID.

An example of this 5-tuple could be

{Lu62,    NET1.LUJ0E,    5,    NET1.LUMIKE,    3}

Again, we are not concerned with the conversion of a network-qualified LU name, such as NET1.LUJOE, into its internal representation as an SNA address.

LU 6.2 Protocol Boundary

The interface between a user process and the LU is called "presentation services" in SNA. There are two interfaces possible for a user process to LU 6.2:

•     mapped conversations,

•     unmapped conversations.

An unmapped conversation is also called a basic conversation. The major difference between the two types of conversations is in the format of the data that is exchanged between the process and the LU.

The interface between a user process and LU 6.2 is defined as a collection of verbs that a transaction program can execute to request a service from the LU. This defines the protocol boundary between the program and LU 6.2. The actual mapping of these verbs into an application program interface (API) depends on the specific -LU 6.2 software being used. An API could be a set of functions that a user process can call. As men­tioned earlier, there is no standard API for LU 6.2, not even among different IBM prod­ucts. Therefore, instead of describing an actual API, the different LU 6.2 verbs that most LU 6.2 implementations provide are described to an application program.

Here a brief summary of the LU 6.2 verbs are provided. Only the names of the mapped conversation verbs are listed—unless otherwise noted, a basic verb that does a similar function is available, and its name is formed by removing the MC_prefix. For example, ALLOCATE is the basic conversation equivalent of MC_ALLOCATE.

MC_ALLOCATE                               Allocates a conversation with another program. Required arguments are the name of the program to execute and the name of the LU where that program is located. The process issuing the ALLOCATE starts in the send state and the partner process starts in the receive state.

MC_CONFIRM                                  Sends a confirmation request to the remote process and waits for a reply. This allows the two processes in a conversation to synchronize their processing with each other.

MC_CONFIRMED                            Sends a confirmation reply to the remote process.

MC_DEALLOCATE                          Deallocates a conversation.

MC_FLUSH                                        Forces the transmission of the local send buffer to the other LU. In general, LU 6.2 waits until a full buffer is available before sending anything to the other pro­cess.

MC_GET_ATTRIBUTES                 Obtains information about a conversation, such as the name of the partner LU.

MC_PREPARE_TO_RECEIVE      Changes the conversation from send to receive state. Recall that LU 6.2 is a half-duplex protocol, not full-duplex.

MC_RECEIVE_AND_WAIT          Waits for information to be received from the partner process. The information returned can be user data or a confirmation request.

MC_RECEIVE_IMMEDIATE        Receives any information that is available in the local LU's buffer, but does not wait for information to arrive.

MC_REQUEST_TO_SEND             Notifies the partner process that this process wants to send data. When the local process receives a "send" indication from the partner process, the state of the conversation changes.

MC_SEND_DATA                             Sends one data record to the partner process.  For a mapped conversation, one user data record is option­ally mapped into a mapped conversation record (MCR), as described below. For an unmapped conversation, some portion of a logical record is sent. Note that regardless of the conversation type, this verb might not cause any data to be sent to the other process, depending on the buffering in the local LU. See the MC_FLUSH verb above.

MC_END_ERROR                            Informs the partner process that the local process has detected an application error of some form.

There are additional verbs defined by LU 6.2 that are considered "control operator verbs." These are used to start sessions, change the number of sessions, stop sessions, and the like. Their usage is product dependent and they are not considered here.

The LU 6.2 protocol boundary defines numerous return codes from each of the verbs. For example, the SEND_DATA verb can return that all is OK and additionally it can indicate that the partner process has issued a REQUEST_TO_SEND.

Logical Records and GDS Variables

All user process data consists of a 2-byte length field (LL) followed by zero or more bytes of data. This is called a logical record and is shown in Figure 23.

             Figure 23. SNA logical record

The length includes the two bytes occupied by the length field, so its value is always greater than or equal to two.t

Two processes using the basic conversation verbs exchange logical records. A pro­cess that is writing logical records need not write a complete logical record with every SEND_DATA verb. That is, a logical record consisting of 500 bytes (an LL field of 500, followed by 498 bytes of user data) can be written in three pieces—100 bytes, followed by a SEND_DATA of 250 bytes, followed by a SEND_DATA of 150 bytes. Similarly, the receiving process can read the logical record (RECEIVE_AND_WAIT) in whatever sized chunks it desires. A process must write a complete logical record, based on the LL value.

In the above example with an LL of 500, the process cannot write 400 bytes and then do a read. Not writing a complete logical record is called truncation and generates an error indication for the receiving process.

For mapped conversations each MC_SEND_DATA verb executed by the process gen­erates a single user data record. If a mapping is being done, the mapping is applied to the user data record, generating the mapped conversation record (MCR). A 2-byte LL field and a 2-byte ID field are prepended to the beginning of the MCR, generating a logi­cal record. This is shown in Figure 24.

     Figure 24. SNA mapped conversation record

This logical record is the same as the logical record that is written using the basic conver­sation verbs, except a 2-byte ID field follows the LL field. This guarantees that the length of a logical record from an MC_SEND_DATA verb is greater than or equal to 4 bytes (since the lengths of the LL field and the ID field are include in the length). For aft user process data, the ID field is set to 0xl2FF by LU 6.2. Other values of the ID field are used by IBM applications and by the LU for special purposes.

A logical record containing an ID field is also called a GDS variable. GDS is an acronym for Generalized Data Stream. A GDS variable can be comprised of multiple logical records, if the length of the MCR exceeds 32,763 bytes.

No matter how the data was written, using either the basic conversation write or the mapped conversation write, the LU is free to break up the logical records into response units (RUs) as it wishes. The maximum response unit size is negotiated by the two partner LUs when the session is started and its value is typically 256 bytes for an SDLC data link. The LU appends the request header (RH) to the response unit and passes the buffer to path control, as shown earlier.

Confirmation

One parameter for the ALLOCATE verbs is the synchronization level. This can be set to NONE or CONFI RM.t Specifying the confirmation option allows the user processes to use the CONFIRM and CONFIRMED verbs, which were described earlier. This provides an end-to-end confirmation that is built into the LU 6.2 protocol itself. Note that the same type of feature can be built into any protocol, if the two user processes agree on a con­vention for indicating a confirmation.

Buffering and Out-of-Band Data

LU 6.2 internally buffers almost everything that one process sends to another. To cir­cumvent this, the FLUSH verbs are provided to force the LU to send what is has accumu­lated in its buffer. For example, when a program ALLOCATES a conversation with another program and then executes a SEND_DATA to transfer data to that process, the LU. by default, won't send the allocate until its buffer is full. This means that the initiat­ing process won't know if there was an error invoking the partner program until some number of SEND  DATA verbs cause the allocate to be sent to the other side.

LU 6.2 has no out-of-band data mechanism, comparable to TCP and SPP. A user process must issue a SEND_ERROR verb to notify the other pro­cess that attention is required. It is then up to the user processes to determine how to handle things.

Well-Known Addresses

If the first character of the remote transaction program name (TP name) in an ALLOCATE is a special character (OxOO-OxOD or 0xl0-0x3F), then the remote TP is a service transaction program. These programs are typically supplied by IBM and only privileged processes can allocate conversations with them. Three service TPs are DIA, DDM, and SNADS, described in the next section. This feature corresponds to the privileged port feature of 4.3BSD for ports in the Internet domain and in the XNS domain.

Option Sets

The LU 6.2 specification provides a base set of features that any implementation must provide, along with 41 optional features that can also be provided by a given product. For example, one option allows conversations between programs at the same LU. Another option allows a process to flush the LU's buffer using the FLUSH verbs.

Unfortunately, this laxness in the "official" specification of the protocol makes por­tability of LU 6.2 applications less than desired. But most real-world implementations of LU 6.2 on computer systems of general interest (i.e., ignoring special purpose systems that weren't intended to be programmed by end users) tend to support options that should have been in the base set. Furthermore, the publication by IBM of their CPI-Communications API [IBM 1988] gives some indication about the features in LU 6.2 which will be supported in the future.

1.2.3.5       Application Layer

IBM is building distributed applications using LU 6.2. IBM differentiates between two types of user processes that are at the layer above the LU:

•     application transaction programs,

•     service transaction programs.

The only real difference is that service TPs are supplied by IBM and a service TP can provide a service for an application TP. Application TPs are user processes. Service TPs can only be invoked by privileged processes, as described above. From a network pro­gramming perspective the difference is negligible. Both types of TPs access the network in the same way through the LU.

DIA—Document Interchange Architecture

DIA defines the functions required for interchanging documents between different IBM office systems. DIA is implemented on top of LU 6.2. That is, DIA uses LU 6.2 for communicating between different computer systems. DIA provides the following func­tions: document library services (storing and retrieving documents), document distribu­tion (delivering documents to others in the network), and file transfer. DIA specifies the protocols and data structures used to exchange information between two DIA processes—a DIA client process and a DIA server process. An implementation of DIA usually provides a command language for an interactive user to execute DIA commands. These user commands (such as sign on, sign off, search, retrieve, deliver, delete, etc.) are translated into the appropriate DIA functions that are exchanged between the user's DIA client process and the DIA server process, using LU 6.2. DISOSS (Distributed Office Support System) is the IBM mainframe implementation of DIA that runs under CICS.

One type of document that is exchanged using DIA is one whose format is specified by DCA. DCA (Document Content Architecture) specifies the internal format of a docu­ment that can be exchanged between IBM office systems—the data stream and how it is to be interpreted. There are two forms of DCA, revisable form and final form. The revisable form specifies the structure of the document while it can be edited or formatted. The final form specifies the structure of the completed document in a device independent format. The intent of DCA is to allow a document to be moved between different IBM office systems, in either a revisable form or a final format.

SNADS—SNA Distribution Services

SNADS is an asynchronous distribution service for moving distribution objects (such as a document or an electronic mail message) from a source node to a destination node. Asynchronous means that it initiates the sending of the object, but the actual delivery might take place later. Furthermore, the delivery might require temporary storage in one or more intermediate nodes. The asynchronous nature of SNADS is similar to the Unix electronic mail delivery service provided by the Unix uucp program.

Contrast this with a synchronous delivery service where the source and destination are connected together through an LU 6.2 conversation. This synchronous capability is similar to the TCP/IP SMTP application, which uses a TCP connection between the source host and the destination host.

DDM—Distributed Data Management

DDM is another application available from IBM that uses LU 6.2. DDM is IBM's archi­tecture for transparent remote file access in an SNA network. DDM allows an applica­tion program to access the records in a file on another system. To do this, the application program calls the local DDM interface to request a record from a file. If the interface recognizes the request as one for a local file, the local file is accessed. Otherwise, the local interface (the DDM client process) establishes an LU 6.2 session with the DDM server process on the remote system, and the server accesses the record and returns it to the client.