The Systems Network Architecture (SNA) was introduced by IBM in 1974 in order to provide a framework for joining together the multitude of mutually incompatible IBM products for distributed processing. SNA was one of the first communications architectures to use a layered model, which later became the basis for the OSI model.

The SNA is a hierarchical network that consists of a collection of machines called nodes. There are four types of nodes; Type 1 (terminals), Type 2 (controllers and machines that manage terminals), Type 4 (front-end processors and machines that take some load off the main CPU) and Type 5 (the main host).

Each node has at least one Network Addressable Unit (NAU). The NAU enables a process to use the network by giving it an address. A process can then reach and be reached by other NAUs.

An NAU can be one of three types; an LU (Logical Unit), a PU (Physical Unit) or an SSCP (System Services Control Point). Usually there is one SSCP for each Type 5 node and none in the other nodes.

SNA distinguishes five different kinds of sessions: SSCP-SSCP, SSCP-PU, SSCP-LU, LU-LU and PU-PU.

The SSCP (PU Type 5) is usually implemented in IBM mainframe machines which use channels to connect to control devices such as disks, tapes and communication controllers. These are high speed communications links (up to 17 Mbps).

The communication controller (the FEP Front End Processor, PU type 4) is used to connect low speed SDLC lines. All together the SSCPs, FEPs, channels and SDLC lines connecting them create the SNA backbone. Using SDLC, the FEPs also connect Token Ring LAN or X.25 links and other types of SNA devices such as cluster controllers and RJE stations. These are PU type 2/2.1 devices and are used to manage LUs which are the endpoint of SNA network - elements such as the display terminal (the 3270 family).

SNA information may be transmitted within various protocols. Two protocols which are often used to carry SNA information are SDLC and QLLC (which carries SNA information over X.25). The following diagram shows SNA in relation to the OSI model:



The SDLC (Synchronous Data Link Control) protocol was developed by IBM to be used as the layer 2 of the SNA hierarchical network. SNA data is carried within the information field of SDLC frames. The format of a standard SDLC frame is as follows:

Link Header

Link Trailer


Address field

Control field




SDLC frame format

The value of the flag is always (0x7E). In order to ensure that the bit pattern of the frame delimiter flag does not appear in the data field of the frame (and therefore cause frame misalignment), a technique known as Bit Stuffing is used by both the transmitter and the receiver.

Address field
The first byte of the frame after the header flag is known as the Address Field. SDLC is used on multipoint lines and it can support as many as 256 terminal control units or secondary stations per line. The address field defines the address of the secondary station which is sending the frame or the destination of the frame sent by the primary station.

Control field
The field following the Address Field is called the Control Field and serves to identify the type of the frame. In addition, it includes sequence numbers, control features and error tracking according to the frame type.

Every frame holds a one bit field called the Poll/Final bit. In SDLC this bit signals which side is ‘talking’, and provides control over who will speak next and when. When a primary station has finished transmitting a series of frames, it sets the Poll bit, thus giving control to the secondary station. At this time the secondary station may reply to the primary station. When the secondary station finishes transmitting its frames, it sets the Final bit and control returns to the primary station.

Modes of operation
In SDLC there is the notion of primary and secondary stations, defined simply as the initiator of a session and its respondent. The primary station sends commands and the secondary station sends responses.

SDLC operates in Normal Response Mode (NRM). This mode is totally master/slave meaning that only one station may transmit frames at any one time (when permitted to do so). This mode is signified by the SNRM(E) frame. The primary station initiates the session and sends commands. The secondary station sends responses. Full polling is used for all frame transmissions.

The Frame Check Sequence (FCS) enables a high level of physical error control by allowing the integrity of the transmitted frame data to be checked. The sequence is first calculated by the transmitter using an algorithm based on the values of all the bits in the frame. The receiver then performs the same calculation on the received frame and compares its value to the CRC.

Window size
SDLC supports an extended window size (modulo 128) where the number of possible outstanding frames for acknowledgement is raised from 8 to 128. This extension is generally used for satellite transmissions where the acknowledgement delay is significantly greater than the frame transmission times. The type of the link initialization frame determines the modulo of the session and an "E" is added to the basic frame type name (e.g., SNRM becomes SNRME).

Frame types

The following are the Supervisory Frame Types in SDLC:
RR Information frame acknowledgement and indication to receive more.
REJ Request for retransmission of all frames after a given sequence number.
RNR Indicates a state of temporary occupation of station (e.g., window full).
The following are the Unnumbered Frame Types in SDLC:
DISC Request disconnection.
UA Acknowledgement frame.
DM Response to DISC indicating disconnected mode.
FRMR Frame reject
CFGR Configure.
TEST Sent from primary to secondary and back again.
BCN Beacon.
SNRM Initiator for normal response mode. Full master/slave relationship.
SNRME SNRM in extended mode.
RD Request disconnect.
RIM Secondary station request for initialization after disconnection.
SIM Set initialization mode.
UP Unnumbered poll.
UI Unnumbered information. Sends state information/data.
XID Identification exchange command.
There is one Information Frame Type in SDLC:
Info Information frame.


Graph of distribution of SDLC frames by format type



QLLC is a standard developed for interconnecting SNA LANs over packet switched WANs with X.25. The SDLC header and trailer is stripped off and replaced by similar fields of LAPB before transmission over the network. The standard also defines additional control bytes used to allow the receiving end of the network to reconstruct the original SDLC frame. The SNA information is passed over the network within the X.25 data packet.

The following diagram represents SNA data and QLLC control frames within the X.25 data packet:

SNA data and QLLC control frames are determined by the value of the Q-bit within the X.25 packet header.

QLLC Frame Types

QRR Receive Ready.
QDISC Disconnect.
QUA Unnumbered Acknowledgement.
QDM Disconnect Mode.
QFRMR Frame Reject.
QRD Request Disconnect.
QXID Exchange Identification.
QSM Set Mode.



SNA frames have the following format:

Transmission Header (TH)

Request / Response Header (RH)

Request / Response Unit (RU)

SNA frame structure

Transmission Header
The TH field contains the Format Identifier value (FID). This value corresponds to the type of communication session and the environment in which it is used.

FID2 is the format used between a T4 or T5 node and an adjacent T2.0 or T2.1 node, or between adjacent T2.1 nodes. FID3 is used on links to a PU T1 (such as AS/400 controllers). FID4 is used on links between PU T4s.

The TH field also contains a mapping field (MPF) which indicates whether the frame is a complete SNA frame (containing TH, RH and RU) or just a segment. When the SNA frame is too large to be sent as one frame, it is divided into several segments (first, middle, last or whole). The first segment includes a TH (indicating that it is the first), an RH and the beginning of the RU. Other segments (middle and last) contain a TH (identical to the one of the first except for the MPF field) and the remainder of the RU.

Request/Response Header
The RH field denotes the SNA category of the frame, the format of the RU, whether requests are chained together, bracket indicators, pacing information and various other SNA frame properties.

Request/Response Unit
The RU contains the ‘user data’ that one LU sends to its session partner or a special SNA frame. A field within the RH distinguishes between cases and several classes of SNA frames. There are three categories of SNA frames: NS (function management data), DFC (data flow control) and SC (session control).



SNA TH0 and TH1 correspond to the FID header 0 and 1 respectively.

The format of the packet is shown in the following illustration:




8 bits




DAF (2 bytes)

OAF (2 bytes)

SNF (2 bytes)

DCF (2 bytes)

SNA TH0, SNA TH1 packet structure

Format Identification: 0=FID 0, 1=FID 1.

Mapping field:

0 Middle segment of a BIU
1 Last segment of a BIU
2 First segment of a BIU
3 Whole BIU

Expedited flow indicator:

0 Normal flow
1 Expedited flow

Destination address field. Network address denoting the BIU’s destination network addressable unit (NAU).

Origin address field. Network address denoting the originating NAU.

Sequence number field. Numerical identifier for the associated BIU.

Data count field. A binary count of the number of bytes in the BIU if the BIU segment is associated with the transmission header.

5250 is located in frames with an RH field as may be viewed in the multi-protocol view of the capture buffer.

5250 as viewed in the RH field of the SNA frame



SNATH 5 is the FID 5 header.

The format of the packet is shown in the following illustration:




8 bits

FID5 0101 (4 bits)

MPF (2 bits)



Reserved ( 1 byte)

SNF (2 bytes)

SA (8 bytes)

FID 5 header structure

The value of this field is 0101.

Mapping field.

Reserved bit.

Expedited flow indicator (1 bit).

Sequence number field.

Session address.



HPR network is an extension of the SNA network. HPR (High Performance Routing) is an extension of the base-APPN that provides some key advancements. These new functions include:

  • Non-disruptive path switching.
  • Better utilization of high-speed communication paths.
  • An advanced congestion control methodology.
  • Additional functionality provided by two new components: Rapid Transport Protocol (RTP) and Automatic Network Routing (ANR). These components provide the added functionality exhibited by HPR nodes.


The packet transported along an RTP connection has a specific format. It consists of 3 components. NHDR, THDR and data. The Network Layer Header (NHDR) begins the frame used by RTP (Rapid Transport Protocol) nodes. It provides addressing for the packet as it transverses the HPR network. The components of this header include the transmission priority and the ANR (Automatic Network Routing) labels. NHDR consists of some indicators that identify the packet as a network layer packet.

The format of the header is shown in the following illustration:

Switching mode(3 bits)

Transmission priority field(2 bits)

Function type (4 bits)

Time-sensitive packet indicator
(1 bit)

Slowdown 1 (1 bit)

Slowdown 2 (1 bit)

ANR routing field or function routing field

NHDR header structure

Switching mode
Switching mode may have the following values:

5 Function routing
6 Automatic network routing

Transmission priority field (TPF)
TPF may have the following values:

0 low (L)
1 medium (M)
2 high (H)
3 network (N)

Function type (for switching mode 5)
Function type of 1 indicates logical data link control.

Slowdown 1 and 2
This field indicates when ever a minor (slowdown 1) or significant (slowdown 2) congestion condition exists. Possible values are:

0 Does not exist
1 Exists

ANR routing field (for SM = 6)
A string of ANR labels 1 or 2 bytes long. The string ends with 0xFF.

Function routing field (for SM = 5)
A 2 byte function routing address (FRA) followed by a 0xFF value.


THDR is the RTP Transport header. It is used by the RTP endpoints to provide correct processing of the packet. It is used for communication between the endpoints and to identify the RTP connection.

The format of the header is shown in the following illustration:

TCID assignor

(7 bytes)

Connection setup

(1 bit)

Start-of-message indicator (1 bit)

End-of-message indicator (1 bit)

Status requested indicator (1 bit)

Respond ASAP indicator (1 bit)

Retry indicator (1 bit)

Last message indicator (1 bit)

Connection qualifier field indicator (2 bits)

Optional segments present indicator (1 bit)

Data offset

(2 bytes)

Data length

(2 bytes)

Byte sequence number
(4 bytes)

Control vector 05

Optional segments

THDR header structure

TCID assignor
Transport connection identifier. There are 2 possible values:

0 TCID was assigned by the receiving RTP partner.
1 TCID was assigned by the sending RTP partner.

Connection setup

0 presented
1 not presented

Start of message indicator

0 not start of message
1 start of message

End of message indicator

0 not end of message
1 end of message

Status requested indicator

0 Receiver need not reply with a status segment.
1 Receiver must reply with a status segment.

Respond ASAP indicator

1 Sender will retransmit reply ASAP.

Retry indicator

0 Sender will retransmit this packet.

Connection qualifier field indicator

0 none presented
1 originator

Optional segments present indicator

0 not presented
1 presented

Byte sequence number
Sequence number of the first byte of the data field.

Optional segments
If present the optional segment can contain one or more of the following segments:

0x0E Status segment.
0x0D Connection Setup segment.
0x10 Connection Identifier Exchange segment.
0x14 Switching Information segment.
0x22 Adaptive Rate-Based segment.
0x12 Connection Fault segment.
0x0F Client Out-of-band Bits segment.

The structure of each segment is as follows:

Byte Content
0 Segment length/4
1 Segment type
2 Segment data
Each segment may include control vectors. Supported control vectors are:
0x00 Node identifier Control Vector.
0x03 Network ID Control Vector.
0x05 Network Address Control Vector.
0x06 Cross-Domain Resource Manager Control Vector.
0x09 Activation Request/Response Sequence Identifier Control Vector.
0x0E Network Name Control Vector.
0x10 Product Set ID Control Vector.
0x13 Gateway Support Capability Control Vector.
0x15 Network-Qualified Address Pair Control Vector.
0x18 SSCP Name Control Vector.
0x22 XID Negotiation Error Control Vector.
0x26 NCE Identifier Control Vector.
0x28 Topic Identifier Control Vector.
0x32 Short-Hold Mode Control Vector.
0x39 NCE Instant Identifier.
0x46 TG Descriptor Control Vector.
0x60 Fully qualified PCID Control Vector.
0x61 HPR Capabilities Control Vector.
0x67 ANR Path Control Vector.
0xFE Control Vector Keys Not Recognized Control Vector.



Data Link Switching (DLSw) is a forwarding mechanism for the IBM SNA (Systems Network Architecture) and IBM NetBIOS (Network Basic Input Output Services) protocols. Over IP networks, DLSw does not provide full routing, but instead provides switching at the SNA Data Link layer (i.e., layer 2 in the SNA architecture) and encapsulation in TCP/IP for transport over the Internet.

A Data Link Switch (abbreviated also as DLSw) can support SNA (Physical Unit (PU) 2, PU 2.1 and PU 4) systems and optionally NetBIOS systems attached to IEEE 802.2 compliant Local Area Networks, as well as SNA (PU 2 (primary or secondary) and PU2.1) systems attached to IBM Synchronous Data Link Control (SDLC) links. For the latter case, the SDLC attached systems are provided with a LAN appearance within the Data Link Switch (each SDLC PU is presented to the SSP protocol as a unique MAC/SAP address pair). For the Token Ring LAN attached systems, the Data Link Switch appears as a source-routing bridge. Token Ring Remote systems that are accessed through the Data Link Switch appear as systems attached to an adjacent ring. This ring is a virtual ring that is manifested within each Data Link Switch.

The Information message for DLSw is as follows:

Version number

Header length (=16)

Message length

Remote data link correlator

Remote DLC port ID

Reserved field

Message type

Flow control byte

DLSw information message structure

Version number
Set to 0x31 (ASCII 1) indicating a decimal value of 49. This is used to indicate DLSw version 1.

Header length
Set to 0x48 for control messages and 0x10 for information and Independent Flow Control messages.

Message length
Specifies the number of bytes within the data field following the header.

Remote data link correlator / remote DLC port ID
The contents of the DLC and DLC Port ID have local significance only. The values received from a partner DLSw must not be interpreted by the DLSw that receives them and should be echoed "as is" to a partner DLSw in subsequent messages.

Message type
The following message types are available:

CANUREACH_ex Can U Reach Station-explorer
CANUREACH_cs Can U Reach Station-circuit start
ICANREACH_ex I Can Reach Station-explorer
ICANREACH_cs I Can Reach Station-circuit start
REACH_ACK Reach Acknowledgment
DGRMFRAME Datagram Frame
CONTACT Contact Remote Station
CONTACTED Remote Station Contacted
RESTART_DL Restart Data Link
DL_RESTARTED Data Link Restarted
INFOFRAME Information (I) Frame
HALT_DL Halt Data Link
DL_HALTED Data Link Halted
NETBIOS_NQ_ex NETBIOS Name Query-explorer
NETBIOS_NQ_cs NETBIOS Name Query-circuit setup
NETBIOS_NR_ex NETBIOS Name Recognized-explorer
NETBIOS_NR_cs NETBIOS Name Recog-circuit setup
HALT_DL_NOACK Halt Data Link with no Ack
KEEPALIVE Transport Keepalive Message
CAP_EXCHANGE Capabilities Exchange
IFCM Independent Flow Control Message
TEST_CIRCUIT_REQ Test Circuit Request
TEST_CIRCUIT_RSP Test Circuit Response

Flow control byte
Format of Flow Control is as follows:





Flow control format

FCI Flow control indicatory
FCA Flow control ack
FCO Flow control operator bits


DLSw decode


SNA Terminology

Systems Network Architecture (SNA)
The description of the logical structure, formats, protocols and operational sequences for transmitting information units and controlling the configuration and operation of networks.

Network Address-able Unit (NAU)
A logical unit, physical unit or system services control point which is the origin or the destination of information transmitted by the path control network. Each NAU has a network address that represents it to the path control network.

Logical Unit (LU)
A port through which end users access the SNA network in order to communicate with other end users and the functions provided by system services control points (SSCPs). An LU can support at least two sessions (one with an SSCP and one with another LU) and may be capable of supporting many sessions with other logical units.

Physical Unit (PU)
One of the three types of network addressable units (NAUs). Each node of an SNA network contains a physical unit (PU) that manages and monitors the resources (such as attached links) of a node, as requested by a system services control point (SSCP) via an SSCP-PU session. An SSCP activates a session with the PU in order to indirectly manage resources of the node such as attached links through the PU.

System Services Control Point (SSCP)
A focal point within an SNA network for managing the configuration, coordinating network operator/problem determination requests and providing directory support and other session services for network end users. Multiple SSCPs, cooperating as peers, can divide the network into domains of control, with each SSCP having a hierarchical control relationship to the physical and logical units within its domain.

One or more chains of request units (RUs) and their responses that are exchanged between the two LU-LU half-sessions and that represent a transaction between them. A bracket must be completed before another bracket can be started.

Data Link Control (DLC) Layer
The layer that consists of the link stations that schedule data transfer over a link between two nodes and perform error control for the link.

Normal Flow
A data flow designated in the transmission header (TH) that is used primarily to carry end-user data. The rate at which requests flow on the normal flow can be regulated by session-level pacing. Normal and expedited flows move in both the primary-to-secondary and secondary-to-primary directions.

Expedited Flow
A data flow designated in the transmission header (TH) that is used to carry network control, session control and various data flow control request/response units (RUs). The expedited flow is separate from the normal flow (which carries primary end-user data) and can be used for commands that affect the normal flow.

Explicit Route (ER)
The path control network elements, including a specific set of one or more transmission groups, that connect two subarea nodes. An explicit route is identified by an origin subarea address, a destination subarea address, an explicit route number and a reverse explicit route number.

LU Type 6.2
LU 6.2 is a particular type of SNA logical unit. It uses SNA-defined interprogram communication protocols and is also referred to as Advanced Program-to-Program Communication (APPC).

Network Services (NS) Header
A 3 byte field in an FMD request/response unit (RU) flowing in an SSCP-LU, SSCP-PU or SSCP-SSCP session. The network services header is used primarily to identify the network services category of the RU and the particular request code within a category.

Node Type
A designation of node according to the protocols it supports and the network addressable units (NAUs) that it can contain. Five types are defined: 1, 2.0, 2.1, 4 and 5. Node types 1, 2.0 and 2.1 are peripheral nodes and types 4 and 5 are subarea nodes.

PU Type 2 (T2)
A network node that can attach to an SNA network as a peripheral node.

PU Type 2.1 (T2.1)
A network node that can attach to an SNA network as a peripheral node using the same protocols as type 2.0 nodes; type 2.1 nodes can be directly attached to one another using SNA low-entry networking.

PU Type 4 (T4)
A network node containing an NCP and that is a subarea node within an SNA network.

PU Type 5 (T5)
A network node containing VTAM and that is a subarea node within an SNA network.

RU Chain
A set of related request/response units (RUs) that are consecutively transmitted on a particular normal or expedited data flow. The request RU chain is the unit of recovery: if one of the RUs in the chain cannot be processed, the entire chain is discarded. Each RU belongs to only one chain, which has a beginning and an end indicated via control bits for request/response headers within the RU chain. Each RU chain can be designated as first-in-chain (FIC), last-in-chain (LIC), middle-in-chain (MIC) or only-in-chain (OIC). Response units and expedited flow request units are always sent as OIC.

Session Control (SC)
One of the components of transmission control. Session control is used to purge data flowing in a session after an unrecoverable error occurs, in order to resynchronize the data flow after such an error and to perform cryptographic verification.

A request unit (RU) category used for requests and responses exchanged between the session control components of a session and for session activation and deactivation requests and responses.

SSCP-LU Session
A session between a system services control point (SSCP) and a logical unit (LU); the session enables the LU to request the SSCP to help initiate LU-LU sessions.

SSCP-PU Session
A session between a system services control point (SSCP) and a physical unit (PU); SSCP-PU sessions allow SSCPs to send requests to, and receive status information from individual nodes in order to control the network configuration.

A session between a system services control point (SSCP) in one domain and the SSCP in another domain. An SSCP-SSCP session is used to initiate and terminate cross-domain LU-LU sessions.

Token Ring
A network with a ring topology that passes tokens from one attaching device to another.