SNA over sockets dynamic conversion from SNA to TCP/IP at the API layer (implemented in a tandem environment)

Material Information

SNA over sockets dynamic conversion from SNA to TCP/IP at the API layer (implemented in a tandem environment)
Hegde, Ganesh R
Publication Date:
Physical Description:
ix, 82 leaves : illustrations ; 28 cm


Subjects / Keywords:
Computer networks ( lcsh )
SNA (Computer network architecture) ( lcsh )
TCP/IP (Computer network protocol) ( lcsh )
Computer networks ( fast )
SNA (Computer network architecture) ( fast )
TCP/IP (Computer network protocol) ( fast )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )


Includes bibliographical references (leaves 81-82).
General Note:
Department of Computer Science and Engineering
Statement of Responsibility:
by Ganesh R. Hegde.

Record Information

Source Institution:
University of Colorado Denver
Holding Location:
Auraria Library
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
42611569 ( OCLC )
LD1190.E52 1999m .H44 ( lcc )

Full Text
Ganesh R. Hegde
B.E., Computer Engineering, University of Bombay, 1988
A thesis submitted to the
University of Colorado at Denver
in partial fulfillment
of the requirements for the degree of
Master of Science
Computer Science

This Thesis for the Master of Science
degree by
Ganesh R. Hegde
has been approved

Hegde, Ganesh R. (M. S., Computer Science)
SNA Over Sockets Dynamic conversion of SNA to TCP/IP at the API layer
Thesis directed by Don Stanwyck of Lucent Technologies
The evolution of data communications technology has been very rapid, resulting in
growth in inconsistent directions. Due to the inconsistency among the resulting
network protocols, connecting heterogeneous networks causes numerous problems.
As organizations grow, it becomes essential to connect disparate networks into one
seamless entity. Over the years several solutions have been proposed to help connect
various networks together. Some of these approaches are based on hardware, others
on middle-ware, and some on mathematical models. This issue has brought about a
new area of study called protocol-conversion.
The preliminary objective of this thesis is to analyze two of the most popular
protocols in use today, SNA and TCP/IP. While analyzing the workings of SNA and
TCP/IP, this study considers the similarities and differences of the two protocols as
well as areas of incompatibility. This research then derives a conversation state
matrix for the two APIs and analyzes their similarities. The final objective of this
study is to see whether SNA API calls can be converted to TCP/IP API calls within
the underlying API layer.
This thesis documents the similarities of these two protocols and derives a combined
conversation state matrix of the two APIs. It then shows that although SNA API calls
can be translated to TCP/IP API calls, some functionality will be lost because the
two protocols are very dissimilar. This lost functionality is analyzed and wherever
possible, workarounds are suggested.
In summary, this thesis analyzes and compares the two protocols, explores the
possibility of converting SNA API calls to TCP/IP API calls at the API layer,
demonstrates a solution and documents the results.

This abstract accurately represents the content of the candidates thesis. I recommend
its publication.

This thesis is dedicated to my best friend, my wife Vandana.
I am extremely thankful to Don Stanwyck from Lucent Technologies, who despite
his busy schedule and international travels, took time to answer my silliest questions
and helped me take this project from the drawing board to successful completion.
I thank Dr. William Wolfe and John Noll for sharing their wealth of knowledge with
me and for being supportive for the duration of my thesis.

1. The Evolution........................................................1
1.1 Brief Overview of Data Communications..............................1
1.2 Problem Statement: Motivation for This Study.......................2
1.3 Objectives and Approach.............................................3
1.4 Prior Studies in Protocol Translation and Conversion...............4
1.5 Overview of Tandem Computers........................................7
1.6 Roadmap for This Thesis.............................................7
2. Overview of SNA......................................................9
2.1 Systems Network Architecture (SNA) Protocol.......................9
2.2 SNA Basics........................................................10
2.3 Description of the Seven Layers of SNA............................11
2.4 Network Addressable Units in SNA.............*....................13
2.5 Subareas and Domains..............................................14
2.6 Polling and Bracketing............................................15
2.7 SNA Packets and Frames............................................16
3. Overview of TCP/IP..................................................18
3.1 Transmission Control Protocol / Internet Protocol (TCP/IP).........18
3.2 TCP/IP Basics......................................................19
3.3 Description of the Four Layers of TCP/IP...........................20
3.4 Network Addressable Units in TCP/IP...............................22
3.5 TCP/IP Message Formats and Packets................................24
4. Comparison of SNA and TCP/IP........................................27
4.1 Objectives of the Two Protocols....................................27
4.2 Differences in Nomenclature.......................................28
4.3 Modes of Interaction..............................................29
4.4 Application Queue Handling........................................30
4.5 Flow Control......................................................31
4.6 Contention Handling...............................................31
4.7 Dynamic Session Reconfiguration...................................32
4.8 Direction of Data Flow............................................33
4.9 Application Level Acknowledgments.................................34
4.10 Character Set Conversions........................................34

4.11 Protocol Errors Notification and Recovery..............
4.12 Performance..............................................
5. Conversion of SNAX/HLS to TCP/IP............................
5.1 Application of the Conversion via Projection Methodology...
5.2 SNA High Level Support (HLS) API..........................
5.3 SNA HLS Conversation State Matrix.........................
5.4 TCP/IP API and its Variations.............................
5.6 Incompatible Features Between the Two APIs................
5.7 Projection of SNA Calls to TCP/IP.........................
5.8 Combined Conversation State Matrix........................
6. Functionality Sacrificed During Conversion..................
6.1 Session Layer : Ability to Control Data Flow...............
6.2 Session Layer : Ability to Send and Receive Control Information
6.3 Session Layer : Ability to Change Direction of Data Flow..
6.4 Session Layer : Dynamic Session Reconfiguration...........
6.5 Presentation Layer : Character Mode Conversions...........
6.6 Presentation Layer : Requirement to Assemble
and Disassemble Messages...................................
7. Implementation and Results..................................
7.1 Algorithm Development......................................
7.2 Implementation Details....................................
7.3 Test Scenarios............................................
7.4 Test Results..............................................
8. Conclusion..................................................

1.1 Pictorial Representation of Area of Study.......
1.2 Protocol Translation Method for Network Integration,
2.1 Seven Layers of SNA.............................
2.2 SNA Message Formats............................
3.1 Four Layers of TCP/IP...........................
3.2 Classes of IP Addresses........................
3.3 IP Datagram Encapsulation......................
5.1 SNA-HLS Application Environment.................
5.2 TCP/IP Client and Server API Sequence..........
5.3 TCP/IP Finite State Machine....................
5.4 SNA-HLS Over TCP/IP Application Environment...
7.1 The Test Environment............................

3.1 IP Header Layout......................................................25
4.1 Comparison of Nomenclature........................................... 28
4.2 Comparison of API Calls............................................. 29
5.1 SNA Verbs Used to Establish a Session................................ 38
5.2 SNA Verbs Used to Disconnect a Session............................... 38
5.3 SNA Verbs Used for Miscellaneous Functions........................... 39
5.4 SNA Verbs Used for Data Transfer.................................... 39
5.5 SNA-HLS API Responses............................................... 40
5.6 Description of SNA States........................................... 40
5.7 Description of Transition Symbols................................... 41
5.8 SNA Conversation State Matrix........................................42
5.9 TCP/IP API Calls.....................................................45
5.10 SNA API Calls Projected to TCP/IP Socket API Calls................. 52
5.11 SNA-HLS API Responses..............................................53
5.12 Description of TCP/IP States........................................ 54
5.13 Description of Transition Symbols................................... 54
5.14 SOS Conversation State Matrix...................................... 55
7.1 SOS Conversation State Matrix from Section 5......................... 63
7.2 Test Results Indicating SOS Performance.............................68

1. The Evolution
1.1 Brief Overview of Data Communications
Data Communication technology has rapidly evolved over the last few decades and
become an integral part of our everyday lives. The impact of this evolution can be
felt when we try to imagine our lives without Automatic Teller Machines (ATMs),
credit cards, telephone banking, Internet access, e-mail, cellular phones and pagers
[6]. Some might say that these advances in Data Communications have made our
lives less productive and more complex. But the fact remains that such technology
has proliferated into our lives and we must try to make the best of it, for ourselves as
well as for the future generations, by improving the medium as well as the content.
Although data communications encompasses a wide range of devices and
technologies, we intend to focus on computers and the digital network technology
used to connect them together. During the initial part of this evolution, various
commercial vendors and government agencies around the world started designing
and developing their own versions of data communication rules or protocols. These
protocols were developed in secrecy for reasons pertaining to competitive advantage
as well as for national security.
As more and more computers and networks were setup around the world, it was
discovered that homogeneous computers could be connected easily because the same
vendor designed the network technology, whereas a heterogeneous mix of
computers would generate more difficulty in establishing a network due to disparate
network protocols. In order to prevent such complexities in the future, several
committees were formed around the world to establish standard rules for connecting
computers together. The European committee ITU-T (International
Telecommunications Union formerly CCITT) and the International committees ISO
(International Standards Organization) and IEEE (Institute of Electrical and
Electronics Engineers) are examples of organizations that are involved in
establishing standard networking protocols and to handle issues and concerns from

1.2 Problem Statement: Motivation for This Study
Many legacy applications executing on Tandem systems have embedded Systems
Network Architecture (SNA) Application Program Interface (API) verbs and library
calls within the code. Because of this, transitioning to a new protocol becomes very
difficult. This study explores solutions by which older applications continue using
SNA at the API level, but looks at ways to translate the SNA verbs into TCP/IP at
the API level and vice versa. The following picture depicts the before and after
image of such a conversion. The shaded area represents the point of study and
development for this thesis.
Tandem system Remote System
Application Application
SNA High Level Support (HLS) API SNA API
SNA stack SNA stack
NIC Network NIC

Tandem system Remote System
Application Application
TCP/IP API Conversion Layer TCP/IP API
TCP/IP Stack TCP/IP Stack
NIC Network NIC

Figure 1.1
Pictorial representation of area of study
The Grey area is the focus of this study. It is possible to convert SNA API calls to TCP/IP API calls at this layer
in order to provide a seamless protocol conversion.

1.3 Objectives and Approach
The objectives of this study are listed below:
Analyze and compare the functionality of SNA and TCP/IP with respect to the
API layer
Study past approaches in protocol conversion and explore ways of converting
SNA API calls transparently to TCP/IP API calls at the API layer
Demonstrate a solution and document the results
Although SNA and TCP/IP are two very diverse protocols, it is possible to marry the
two protocols in a seamless way, using the protocol projection method [12]. The goal
of a seamless conversion is that applications on the Tandem system believe that they
are communicating using SNA and the applications on the remote system believe
that they are communicating using TCP/IP.
It is the intention of this study to use the following approach in order to reach the
above objectives.
1. Study the similarities and differences between SNA and TCP/IP with respect to
the following issues;
Network addressable units and Addressing formats
Comparison of the two APIs
Packet formats
State transition tables for SNA and TCP/IP (APIs only)
Pacing issues in each protocol
Message assembly and disassembly
Message prioritization
Exception handling
Since SNA is a very complex and vast protocol, it is the intention of this study to
focus on Hierarchical SNA networks only.
2. The next step is to study the protocol conversion methods described later in this
section. Of all the methods presented in [13] and [7], the method called
conversion-via-projection seems most applicable to this study. This method

seems most appropriate because it describes a heuristic approach towards
protocol conversion which can be easily applied to any two protocols being
studied. This method relies on studying the two protocols, SNA and TCP/IP and
their states. This method then requires us to derive a new image from the two
protocols which includes most of the functions and states of SNA and TCP/IP.
3. The next step is to build a mapping matrix of SNA and TCP/IP transition states at
the API level. This matrix will enable us to define a message flow for converting
SNA to TCP/IP in a seamless manner.
4. Since SNA and TCP/IP are dissimilar protocols, such a conversion will definitely
result in some loss of functionality for the applications on either end. These
shortcomings must be documented and where possible workarounds are
5. The final step is to prepare a high level document that can be used to implement
such a conversion on a Tandem system. This solution can be used to validate the
results and perform comparisons, if needed.
1.4 Prior Studies in Protocol Translation
and Conversion
Connecting disparate protocols has resulted in several problems for the user
community due to different interfaces, varying data formats, certain media types
supported as well as due to the underlying design of various protocols. The easiest
solution would be to follow a single data communication standard throughout the
world. This solution is impractical because of the immense amount of investments
made in existing data communications technology by users throughout the world.
Integrating various networks together resulted in the birth of a new branch of studies
related to protocol translation as well as protocol conversion. In some of the early
studies, it was believed that one way to interconnect networks was to use protocol
translation or middle-ware [7] [10]. This method is explained below.

Consider two machines each running an application program that wants to exchange
data with the other application. One machine is on a SNA network and the other is on
a TCP/IP network. Using the protocol translation method, a new machine that
supports both SNA and TCP/IP is inserted between the two networks allowing inter-
operability between the two networks. This new machine can be a software module,
a bridge or a gateway.
The disadvantages to this method are;
Introduction of a new system adds a significant delay to message transmission
Most protocol translators use a proprietary API requiring applications to be
converted to that API before this solution could be tried
Protocol translators support only a subset of the features in each protocol
The end user has to be involved in configuration and addressing in either domain
for this solution to work appropriately

Another method suggests using a theoretical approach to protocol conversion [9]. In
this method, we build a mathematical model for each protocol using Finite State
Machines (FSM). By analyzing each state in each protocol it may be possible to
build a new Finite State Machine that incorporates all of the states within each of the
protocols being considered.
Within the study of protocol conversion, there are several important methodologies
to be considered [13]. One of these methodologies is explained below
Conversion via projection This approach is defined as : Suppose two protocols P
and Q can be projected into a new image protocol called R, then R embodies some of
the functionality that is common to both P and Q. The specification of a converter
can be derived considering that the projection mapping defines an equivalence
between messages of P and Q, just as it does for states. Finding a common image
protocol with useful properties requires a heuristic search using intuitive
understanding of the protocols.
This methodology is important because it provides a simple approach which can be
applied to any two protocols. This method relies on both, the message flow as well as
the state transition changes. This method also requires an understanding of the two
protocols being studied so that a common image of the two protocols can be derived.
In our case, SNA would be protocol P (as explained above) and TCP/IP would be
protocol Q. Our goal is to derive a new protocol R, which has the common properties
of both SNA as well as TCP/IP. The new protocol R can be derived by studying the
message flow and the state transition changes within the SNA and TCP/IP APIs. This
method then requires us to build an equivalence between the messages and states of
SNA and TCP/IP. Once we find some commonality between the two protocols, it
would be possible to build the new protocol R which converts SNA messages to
TCP/IP messages and vice versa.
Studying these past approaches will hopefully help us in understanding, planning and
reaching the objectives of this study.

1.5 Overview of Tandem Computers
According to the Tandem web site [17] Tandem computers, Inc. is a division of
Compaq computers. Tandem is the leading vendor of highly reliable, highly
scaleable solutions for business-critical enterprise applications. Today, Tandem
NonStop systems are deployed throughout the world to manage 90 percent of stock
trades, 80 percent of automated teller machine transactions, 66 percent of credit
card validations, 65 percent of funds transfers, 66 percent of 911 emergency calls,
and 50 percent of public e-mail systems. NonStop Software leverages the Tandem
Divisions two decades ofparallel processing expertise to deliver enterprise-level
availability and scalability while introducing powerful new capabilities to its full
range of NonStop Himalaya servers.
Tandem computers provide an extensive array of data communications software for
inter-operability, superior performance and above all, for reliability. Several Tandem
clients around the world use SNA to interconnect with IBM mainframe systems.
With the advances in data communications technology, several clients have felt a
need to migrate to TCP/IP. In normal circumstances these clients would have to
undertake a major effort to re-write their applications on both ends to use TCP/IP
rather than SNA. If there were a solution that translates the SNA traffic originating
from the Tandem end to look like TCP/IP on the other end, it would make the issue
of migrating to TCP/IP much simpler to handle and manage.
Such a solution is possible and it is the intention of this study to explore mechanisms
to perform SNA to TCP/IP protocol translation at the API layer on the Tandem end.
1.6 Roadmap for This Thesis
This document is organized as follows:
Section 1 gives an overview of data communications along with work carried out in
the areas of protocol conversion. This section presents the objective of this thesis
and explains the approach taken to achieve these objectives.
Section 2 presents an overview of System Network Architecture (SNA). The
objective of this section is to get the reader familiar with the various features and

attributes of SNA in order to compare it with Transmission Control Protocol /
Internet Protocol (TCP/IP).
Section 3 presents an overview of TCP/IP. This section explains the fundamentals of
TCP/IP in order to perform a comparison to SNA. This comparison is performed in
section 4.
Section 4 analyses and compares the two protocols with respect to functionality and
performance. The objective of this section is to isolate functional areas where the two
protocols are not compatible. These areas will be studied in detail in section 6.
Section 5 looks at the similarities between SNA and TCP/IP from the Application
Program Interfaces (API) perspective. This section provides a detailed look at the
Conversation State Matrix (CSM) of SNA API as well as the Finite State Machine
(FSM) of the TCP/IP API. This section then blends the two APIs together and
derives a combined CSM for the two protocols.
Section 6 analyzes the differences between SNA and TCP/IP and presents
workarounds where possible. This section also points out functional areas where the
two protocols are totally incompatible.
Section 7 demonstrates a solution for the protocol conversion problem. It shows a
solution that was implemented in a Tandem environment using C. This section also
presents the results of the conversion using two test applications.
Section 8 presents the conclusions of this study.
The Appendix provides source listings for the programs designed and developed for
this study.

2. Overview of SNA
2.1 Systems Network Architecture (SNA )
During the early evolution of networking technology (around 1974), IBM
dominated the international market for computers and it had developed a proprietary
seven-layer network protocol called SNA. This protocol is being widely used and is
considered a very robust, structured, scaleable and secure way to interconnect-
computers. IBM published, marketed and licensed this protocol to users and other
computer and network vendors. Several computer designers and vendors had to
provide SNA protocol on their computers in order to allow their computers to be
interconnected with IBM systems.
Several protocols that were designed and developed later, like the ISO-OSI model,
were based on SNA [1]. Due to the domination of IBM in world markets, SNA
became a widely used protocol and is still considered a significant force in the
There were three leading disadvantages of the SNA protocol design, these are listed
SNA has a hierarchical design that means that one computer has to be designated
as a controlling node and other nodes would be designated as controlled nodes.
In the event of the failure of a controlling node, there is a potential for the entire
network to collapse (IBM subsequently came up with Peer-to-Peer protocols for
SNA as well as several modifications to its original protocol specifications).
Configuring and managing an SNA network requires an in-depth understanding
of this well-defined, but complex protocol. At the same time, trouble shooting
and isolating problems can get very tedious and time-consuming. Also, adding
new nodes and sub-networks required re-configurations and sometimes, re-
addressing of the entire network.
Most importantly, since one company owned the protocol, it could manipulate
and change the protocol as it saw fit and force everybody to follow its design.
There was an urgent need to define a world standard for data communications
and networking that would be defined and managed by a committee like ISO
rather than IBM.

Like SNA, most protocols during the 1960s and early 1970s depended on circuit
switched networks like the phone switches or dedicated point-to-point connections to
relay information from one node to another. This meant that loss of one key node
could potentially disrupt communications to the rest of the network. This was seen as
a significant disadvantage for mission critical applications.
2.2 SNA Basics
The SNA protocol can be represented using seven layers [2], These seven layers are
described below;
Figure 2.1
Seven Layers of SNA
Application Layer
Presentation Layer
Data Flow Control Layer
Transmission Control Layer
Path Control Layer
Data Link Layer
Physical Layer
Each of the seven layers of SNA provide abstraction and
insulation from the layers below it
IBM designed SNA as a layered protocol for better control and to provide abstraction
at various levels of the network. The OSI model later adopted this design (in a
slightly modified) format.

2.3 Description of the Seven Layers of SNA
The Application Layer
Any applications that need to interface with the SNA network reside here. They use a
well-defined interface called an API, to exchange information with other network
applications. Examples of such applications would be client-server applications, e-
mail services, file and data transfer applications etc.
The Presentation Layer
The objective of this layer is to provide mapping of data representation. For example:
Conversion from one character set to another, formatting inbound and outbound
messages etc. This layer is also responsible for interpreting application related
network interface calls and to enforce the right formats and messages for exchanging
information with remote applications.
The Data Flow Control Layer or The Session Layer
This layer is responsible for establishing sessions between two network applications.
The Session Layer also enforces message flow, direction of flow, synchronization
between the two partners and graceful shutdown of a conversation between two
applications. Applications can use a profile to indicate session rules for sending
receiving and synchronizing data flow between the two partners. Network managers
can configure several profiles in the SNA layer. When an application starts up, it
indicates a profile name during initialization. The application can override the default
setup in the profile by using control functions in the request-response header at the
The Transmission Control Layer
The Transmission Control layer provides very useful functions in a SNA network. It
is responsible for pacing, message assembly and disassembly, verifying message
sequence numbers, re-transmissions and to provide reliable data transport mechanism
to the layers above it. This layer works closely with the next layer, the Path Control
Layer to provide a reliable channel or path to a remote system on the SNA network.

The Path Control Layer
The primary function of this layer is to establish a path or a route between the source
and the destination. This layer dynamically determines an optimum path between the
source and destination over which to send the current message. It also receives
segments from the underlying Link Layer and passes them up to the Transmission
Control Layer.
The Link Layer
This layer provides a connection-oriented, reliable, sequenced and guaranteed
delivery service to the layers above it. The Link Layer is responsible for transferring
segments of messages in the form of bits over the physical layer. This layer is also
responsible for synchronizing with the remote system to accommodate half-duplex
and full-duplex connections. SNA typically rides over SDLC or HDLC which are
lower level protocols.
The Physical layer
This layer determines the electrical interface to the network, including type of
connectors and cables, signal strengths, etc.
The unique aspect about SNA is that the functions performed by these seven layers
vary according to the application. These seven layers can be embedded in a powerful
mainframe system to a simple terminal or a printer on the network. Depending on
their configured role, each network entity will adapt itself to the rules described for
that entity as per the SNA protocol. The following section describes these rules in
more detail.

2.4 Network Addressable Units in SNA
Initially SNA was designed to be a Host based network where one mainframe
computer will control the entire network. Later IBM introduced peer-to-peer
networking in SNA, where two or more networks can be connected and may share
In either mode, components on the network were defined in the following four
categories [2];
System Service Control Point or SSCP
The SSCP is the main controlling node in a SNA network. This is typically a host
system (like a Mainframe). All network addressing, synchronization and control
functions are available from a SSCP node in the network. The SSCP is seen as a
logical entity on the network.
Control Point or CP
A Control Point is usually a cluster controller on the network. This can be a software
unit or sometimes a physical box that manages one or more physical and / or logical
entities on the network. The CP is also seen as a logical entity on the network. A CP
is responsible for managing all the entities defined under it.
Physical Unit or PU
The physical unit is typically a personal computer or a terminal being used by an end
user. A PU can also be a smart printer on the network. A PU has the ability to
support one or more Logical Units or LUs in its domain. Depending on their function
and abilities on a network, the SNA rules define several types of PUs. They are
called PU type 2.0, PU type 2.1, PU type 4 and PU type 5. Of these, PU type 2.1
supports Peer-to-Peer communications and is of most interest here, for this study.

Logical Unit or LU
A Logical Unit is typically an application, a dumb terminal or sometimes even a
printer on the network. Depending on their functions and abilities, SNA defines
several types of LUs. LU Types 0, 1, 2, 3, 4, 6.2 and 7 are various types of LUs.
While developing an application on the network, it is necessary to know the LU and
PU type of the device where the application will be executing, because that
determines how and when information exchange takes place.
2.5 Subareas and Domains
In SNA, it is possible to cluster part of a network together and call it a subarea. Each
subarea gets a unique address. It is not possible for components in a subarea to talk to
components in another subarea without going to a host node. The concept of subarea
in SNA makes it easy to restrict traffic between certain nodes as well as to make the
network scaleable.
When all the subareas of a network are put together, it forms a Domain. A Domain is
a self-contained network where all traffic originates and terminates within one of the
nodes within that Domain.
For any node on the network, its address consists of two parts, a unique node address
and its subarea address. Combining the two gives us
The node address contains two parts, a PU address and a LU address. So a network
element is addressed as follows,
Such an address uniquely identifies each and every element on the network.

2.6 Polling and Bracketing
Information exchange takes place in one of two ways in a hierarchical SNA network.
Each Logical unit in a network gets polled at regularly configured intervals by the
Physical Unit to see whether there is any information to be sent or received. That is
the only opportunity for a LU to exchange data over the network. This concept is
called Polling. This mechanism works best for terminals and printers on a network
so that each devices gets the same opportunity to exchange data on the network and
there is no conflicts during data interchange. Typically Polling times are set in
An alternate mechanism is called Bracketing. This concept is used when two
applications are exchanging information. If the data flow is asynchronous and
unpredictable, this mechanism works best. The Bracket is like a Token. Only one
partner can own the Bracket at any given time. The owner of the bracket has the right
to send information to the destination. The receiver of the information has to wait
until the sender has completed all the data transfer and relinquishes the bracket. Only
then can the receiver become the sender. The SNA layers synchronize and ensure
that there are no conflicts.

2.7 SNA Packets and Frames
Since SNA consists of various types of nodes and applications, the packet formats
vary accordingly [14]. Pictured below is a superset of all SNA headers and control
information contained within a SNA packet traversing over the network.
Basic Link Unit (BLU)
Path Information
Unit (PIU)
Basic Information
Unit (BIU)
Unit (RU)
Figure 2.2
SNA Message Formats
SNA headers consist of fixed and variable length
headers. The FMH is an optional header.
The SNA headers and message structures are explained below;
The actual information payload whether it is application data or SNA control data
is called the Request/Response Unit (RU). Each RU may include zero or more
Function Management Headers (FMH). A Basic Information Unit (BIU) consists of a
fixed length (9 bytes plus any FMH), bit-encoded header followed by an RU. This is
the unit of information exchanged between Applications and SNA layers.
The request/response header (RH) contains specific SNA control information that
relates to the transmission of one particular RU. A Primary LU (Client Application)
or a Secondary LU (Server Application) residing on a Tandem system passes the

BIU to the underlying SNA layers. The application is responsible for setting all the
header bits as appropriate on an outbound message and for interpreting and acting on
these same header bits on an inbound message.
As an outgoing BIU passes down through the SNA layers, each layer appends their
own headers and trailers to it. Similarly, as an incoming BIU passes through the
layers of SNA, each layer strips off the appropriate headers and trailers.
The RH consists of Three bytes and the TH consist of Six bytes. Certain bits in these
headers indicate normal or expedited flow, pacing information, two-step reads, status
and return codes, sequence numbers, sense data, chain indicator, direction indicator,
bracket indicator and encryption indicator. The application also indicates that SNA
must perform ASCII to EBCDIC conversion if needed. As can be seen, the
application needs to be very involved in the communications process.

3. Overview of TCP/IP
3.1 Transmission Control Protocol /
Internet Protocol (TCP/IP)
During the same time that SNA was being designed and developed by IBM, the
Department of Defense, through its Advanced Research Projects Agency (ARPA)
was funding the design and development of a network protocol that would allow
computers to communicate even if part of the network got destroyed by enemy
bombs or due to other failures [1]. During the early part of its development, this
network was primarily being used by academic institutions and defense centers to
prove that such a network could be built.
The biggest difference between the ARPA model and a traditional model, like SNA,
was that the ARPA model considered all nodes to be peers and hence it was a peer-
to-peer network. Secondly, the ARPA model used packet-switched networking rather
than circuit-switched networking. This would result in information packets being
routed from the source to destination computers over multiple paths simultaneously
rather than a single path. This design would adapt itself to failing sub-networks and
nodes and keep information flowing between computers and networks that are
currently functioning.
The resulting protocol is TCP/IP, which is a strongly defined set of rules and
specifications as defined by the Internet Engineering Task Force (IETF). TCP/IP
allows applications residing on various computers connected by an inter-network to
carry on a conversation without caring about the underlying intricacies of the
network like routing, pacing, path redundancy, retries, windowing, ordering etc. This
protocol has become largely successful due to the popularity of the Internet and the
World Wide Web.
TCP/IP is becoming a network protocol of choice for businesses and institutions
around the world for the following reasons;
It is a well-defined and easy to implement layered-protocol, both for software
developers as well as computer and network designers

It adapts very well to inter-operability, redundancy (multiple paths), scalability
(adding nodes and sub-networks), higher speeds (limited by the medium being
used) and reliable performance.
It is easy to manage and administer TCP/IP networks
Standardized applications like FTP, TELNET, SMTP, SNMP, DNS, HTTP make
application development and deployment, easier and more predictable.
A very well defined API makes application development a lot faster and easier.
Due to these reasons, as well as due to the commercial appeal of the Internet, TCP/IP
is fast becoming the protocol of choice for businesses, academic institutions and for
government agencies.
3.2 TCP/IP Basics
The Department of Defenses definition of the four layered TCP/IP stack is as
follows [1];
Figure 3.1
Four Layers of TCP/IP
Each layer provides abstraction
and insulation from the lower
Application Layer
Transport Layer
(TCP or UDP)
Internet Layer (IP)
Network Layer
In many instances,
the session layer
functionality is
built into the
application layer.
For example: FTP,
Telnet, HTTP etc.
The objective of TCP/IP is to be able to connect multiple networks together in a
seamless way. The goal of TCP/IP is to survive any loss of subnet hardware like
routers, gateways and even host systems and continue existing conversations as long
as the source and destination computers are functioning and there exists at least one
path of communication between the two systems. Adapting a packet switched
network philosophy as described in later sections fulfills these objectives and goals
of TCP/IP.

3.3 Description of the Four Layers of TCP/IP
Application Layer
The TCP/IP model dropped the Session and Presentation layers from the SNA and
the OSI model. The Application layer in the TCP/IP model interacts directly with the
Transport layer. The Application layer represents the users interface to the TCP/IP
protocol stack. This layer provides support for higher level protocols like FTP,
Telnet, DNS, HTTP etc. The API is a very simple and clearly defined interface that
can be used to develop applications on platforms that support TCP/IP. Although the
underlying transport layer supports dual protocols, the Application layer remains the
same for either Transport layer protocol.
Transport Layer
The layer under the Application layer is called the Transport layer. TCP/IP supports
two types of transport layers, TCP Transmission Control Protocol as well as UDP -
User Datagram Protocol. A session from the Application layer can specify one or the
other, but not both. The Transport layer permits peer entities on the source and
destination machines to carry on a conversation.
TCP provides a reliable connection oriented protocol. Using TCP, it is possible to
guarantee that a byte stream originating on one machine will be delivered, without
error, to any other machine on the Internet. The TCP protocol handles fragmentation,
assembly, flow control and sequencing. TCP is used in applications that need a
reliable mode of data transfer like file transfer applications, client-server applications
UDP provides an unreliable, connectionless protocol for applications on either end.
Since UDP does not perform any sequencing or flow control, UDP is faster than
TCP. UDP is used in applications where timing is more critical than accuracy.
Applications like Voice over IP and Video over IP tend to use UDP due to decreased

Inter-network Layer
The Internetwork Layer is also referred to as the Internet Protocol or IP layer. This
layer forms the core of TCP/IP packet switched network strategy. The IP layer
accepts packets of information from the upper layers and routes each packet
independently over the network. IP does not ensure the correct ordering of the
packets. The IP layer is responsible for routing packets and at the same time
preventing and avoiding congestion on the network. The upper layers are responsible
for fragmenting each message and wrapping it in a well-defined IP-format before
passing it to the IP layer.
The Network Layer
The Network layer represents the physical connection as well as components such as
cables, NIC and link protocols. The TCP/IP model does not clearly indicate how this
layer should be implemented. The most common network protocols used for TCP/IP
are Ethernet, Token Ring and FDDI.
One important distinction between the SNA model and the TCP/IP model is the
terminology used to describe messages flowing from one layer to the other. In SNA,
the data flow from the application layer to the network layer is described as RU,
BIUs, and PIUs, whereas in TCP/IP, they are described as segments, packets,
datagrams and frames. These differences as well as other major variations between
these two protocols are described in the next chapter.

3.4 Network Addressable Units in TCP/IP
Since Ethernet is the most common medium for TCP/IP, let us assume this
environment for this discussion. In a simple LAN environment where the connecting
medium is IEEE 802.3 (Ethernet), there are three categories of addresses. These are
explained below;
Internet Protocol (IP) Address
An IP address is assigned to every host interface on an IP network. So a host
containing two network interfaces would need two IP addresses. A network
administrator is usually responsible for setting up IP addresses on a network. An IP
address consists of four bytes (in version 4 IPv4). Each of these four bytes
represents a hierarchy in the Internetwork. Hence an IP address is hierarchical in
nature as opposed to an Ethernet address which is a flat address. The four bytes of an
IP address can be divided into a host address and a network address. The network
part of an IP address uniquely identifies the network to which a host belongs and the
host part identifies the unique host on that network. Depending on the number of
hosts and number of networks, IP addresses have been divided into three classes as
depicted below;
Class A
Class B
Class C
Figure 3.2
Classes of IP Addresses
Each class of IP addresses represents a small subset of an entire network.
0 Network Host
7 bits 24 bits
1 0 Network Host
14 bits 16 bits
1 1 0 Network Host
21 bits 8 bits
An IP address is represented using a dotted-decimal notation, where each byte is
separated by a dot. For example would be a Class C IP address

because the first three bits of 102 are 110. The IP addressing schemes permitted
by the classes of address provide a lot of flexibility in defining a wide range of
networks and hosts. Datagrams are the units of data flowing on an IP network.
Port Address
A Port Address is analogous to a mailbox for each application on a given host.
Before two applications on a network can establish a session, they must specify IP
addresses and Port numbers of the source and destination nodes. The combination of
Protocol (TCP or UDP), IP address and a Port number uniquely identifies a particular
application on the network. The post address consists of two bytes. Some of the port
numbers ranging from 0 to 1023 are called well-known ports and are reserved for
certain applications, like port 21 for FTP, port 23 for Telnet etc.
Socket Address
A Socket is the means by which an application attaches to the network [8]. The
TCP/IP API defines the mechanism for creating, attaching and sending and receiving
data using sockets. The application terminates a socket using a close-socket
command. When an application creates a socket, the operating system, in
conjunction with the TCP/IP stack, assigns a new socket address to the newly created
socket. All further communications take place over this socket address.

3.5 TCP/IP Message Formats and Packets
The flow of a message from an application down to the TCP/IP network is depicted
Upper layer data TCP or UDP layer Application layer Transport layer IP Layer j Network Layer
IP Header IP Data

Data Link Header Data Link Data Frame Check ^
Figure 3.3 IP Datagram Encapsulation Each layer is responsible for adding and removing its own headers and trailers.
Each layer inserts and removes its own header and trailer for incoming and outgoing
packets, respectively. For our discussion, we need to focus on the IP header, since
this header exists for all IP message traffic on the network. The underlying frames
contain the data link header and the frame check segments. These will vary
depending on the underlying medium like Ethernet, ATM etc.. The IP header
consists of 24 bytes or longer depending on the IP options specified. This header
could get much larger (40 bytes or more) for IP Version 6 (Ipv6) because it will
permit larger values for addresses (128 bits instead of 32 bits) and it will allow
prioritization of packets.

Each field in the IP header is explained below;
Fieldname Size in bits Description
Version 4 IP Version number
IHL 4 Internet Header Length To determine size of variable length IP header. The length is specified in 32 bit words
Type of Service 8 Defines requirements for precedence, delay, throughput, reliability and cost for each datagram
Total Length 16 Length of IP header plus data in bytes
Identification 16 Uniquely identifies each datagram
Zero 1 Unused
DF 1 Indicator to specify DO NOT FRAGMENT
MF 1 Indicator to specify MORE FRAGMENTS are coming
Fragment Offset 13 Indicates position of data relative to start of original datagram
Time to Live 8 Defined in seconds; specifies maximum lifetime of a datagram on a network
Protocol 8 Describes the upper layer protocol for the destination host
Header Checksum 16 Used to detect any errors in the IP header
Source address 32 Specifies senders IP address
Destination address 32 Specifies receivers IP address
Options 24 Specifies security, routing and timestamps
Padding 8 For future use
Data - The data passed from/to the upper layer
Table 3.1
IP Header Layout
The IP header needs source and destination addresses in every
packet because packets heading for the same destination could
potentially be routed over different paths.

As can be seen from the IP header layout as described above, all the fields are well
defined and are used uniformly across all IP implementations. Applications have the
option of interfacing directly with the IP layer or interfacing to the IP layer through
any of the upper level layers like TCP and UDP.
It is very important to note that IP can run on a variety of lower level data link
protocols like Ethernet, token ring, X.25, ATM etc. Irrespective of the underlying
networks or the Maximum Transmission Unit (MTU) size limitations for various
routers and hosts on the network, the IP layer provides a common logical IP network
that is independent of the physical differences.

4. Comparison of SNA and TCP/IP
SNA and TCP/IP are diverse protocols and the differences are far greater than the
similarities between the two protocols. For this discussion, let us focus on the
following issues;
4.1 Objectives of the Two Protocols
SNA was originally designed by IBM in the sixties to connect various type of IBM
equipment over one uniform protocol rather than the diverse set of protocols being
used at that time. This would result in easier management as well as more control
over the network. Even to this day SNA provides a very robust and reliable way to
operate, manage and control a data-center based environment [2]. SNA is used for
mission-critical applications due to its ability to provide a single point of control for
the entire network. Also, due to the inherent design of SNA and the underlying
SDLC protocol, it is nearly impossible for hackers to break into a SNA network. Due
to its design, SNA is widely used in industries that are data processing intensive, like
finance, retail, insurance and consumer billing.
While SNA was designed for a data center environment, TCP/IP was designed with
interoperability in mind. The main objective of TCP/IP is to interconnect various
types of computers that are spread across a wide geographic area. The Internet
Engineering Task Force (IETF) designed TCP/IP using a RFC (request-for-
comments) approach, where each module is designed using input from hundreds of
engineers and scientists around the world.
In a TCP/IP protocol stack, TCP rides over IP which is designed to be an unreliable
connectionless protocol. Many enterprises complement TCP/IP with other software
products like firewalls and secure sockets to provide a more reliable and secure
network. TCP/IP is popular in client-server applications, e-commerce and
telecommunications industries. TCP/IP is well suited for situations that require
widely distributed systems to be connected together.

4.2 Differences in Nomenclature
Due to their diverse origins and objectives, SNA and TCP/IP use the following
terminology for describing entities within the network;
Entity SNA Terminology Closest TCP/IP Terminology
Application to protocol layer data interchange Basic Information Unit (BIU) Application Data Unit (ADU)
Data unit exchanged between the transport and network layers Path Information Unit (PIU) Datagram for UDP and Segment for TCP
Smallest independent data unit placed on the network Basic Link Unit (BLU) Packet
Physically addressable network unit Physically unit (PU) IP Address
Logically addressable network unit Logical Unit (LU) IP Address and Port number combination
Logical link between two partners Session or Conversation Connection or Session
Identity of an application on the network LU Name or Application name Well known port number
Is API Standard across hardware platforms? No Yes (Somewhat)
Example of a local address in a Tandem environment $SNA1. #LU1 $SNA1.#LU2
Lower level routing Reliable connection oriented Unreliable connectionless
Table 4.1
Comparison of Nomenclature
These differences in nomenclature will provide structure to the discussions in the
following sections where the objective is to try and unite these two protocols.

4.3 Modes of Interaction
In TCP/IP, there are two well-known modes of interaction, Client mode and Server
mode. An application is designed to be in one mode or another depending on its
function. When an application registers with the TCP layer, it uses a certain
sequence of API calls to indicate that it is in Client mode versus another sequence of
API calls to indicate it is in Server mode. The TCP layer receives each sequence of
calls and acts accordingly. Whereas, in SNA, the application uses the same sequence
of API calls in either mode. The Client mode of TCP/IP is called as Primary mode in
SNA and the Server mode of TCP/IP is called as Secondary mode in SNA.
While designing an SNA Application, the systems engineer will design a Profile.
This profile identifies several things related to session establishment, data transfer as
well as presentation layer parameters like character mode translation. When the SNA
application starts up, it will use the name of the designated profile while registering
with the SNA layer. It is up to the SNA layer to interpret and act on the indicated
The following table indicates a typical sequence of calls from an applications
perspective depending on the mode of interaction.
Typical API sequence for TCP/IP Typical API-sec uence for SNA
Client mode Server mode Primary Secondary
Socket() Connect!) Write!) or Send() ReadO or Recv() Close() Socket!) Bind!) Listen!) AcceptQ Send() Recv() CloseQ HLS1 ALLOCATE!) HLS OPEN() HLS SEND HLS_RECV HLS CLOSE HLS DEALLOCATE!) HLS ALLOCATE!) HLS OPEN() HLS SEND HLS RECV HLS CLOSE HLS DEALLOCATE!)
Table 4.2
Comparison of API Calls
SNA calls are the same, irrespective of whether
the application is in Primary mode or Secondary mode
1 HLS Stands for SNA High Level Support, which provides a simple API for applications to use SNA
on Tandem systems. Details are in the Tandem SNAX-HLS Programmers guide.

4.4 Application Queue Handling
In SNA, an application that is sending and receiving data from the network can rely
on the SNA layer to queue messages for both inbound and outbound directions
depending on configured values and physical limitations. Normally, messages are
queued in FIFO order. An SNA Application can override that ordering by using a
special high-priority message called a control message.
When an application sends a control message, the SNA layer treats that as a high-
priority message and moves it to the top of the outbound queue. On the receiving
end, the SNA layer again moves the message to the front of the queue. It is important
to note that control messages can be received out of context and applications must be
designed to handle that.
Another important point that needs to be mentioned is that SNA is a message
oriented protocol. Any message sent by an application is guaranteed delivery to its
partner in the same order of bytes and within the same message boundaries. For
example: if an application send a message abcdef to its partner and then sends
another message ghijkl to the same partner, on the receiving end, the partner will
always receive the two messages in the same order.
In TCP/IP, the application can rely on the TCP layer to queue inbound and outbound
messages depending on configured values as well as physical limitations. Here again,
the messages are queued in FIFO order. An application can override this queue by
designating a message to be an Out Of Band (OOB) data message. This will cause
TCP/IP to push this message to the top of the queue at either end. The application
must be designed to handle OOB data as this could be out of context.
An important distinction with TCP/IP is that it is a streaming protocol. TCP/IP
ensures guaranteed delivery of a data-stream originating from one application to the
destination, but it does not ensure message boundaries. For example: if an
application sends a message abcdef to its partner and then sends another message
ghijkl to the same partner, on the receiving end, the partner may receive the two
messages in the same order or it could get one large message abcdefghijkl, or it
could receive several messages abc, defg, h, ijkl. The applications on either
end must be designed to clearly mark the boundaries of each message and handle
such fragmented delivery.

4.5 Flow Control
In SNA, once data starts flowing between two applications, each application has the
ability to suppress the flow of data by invoking a special API call, HLS-FLOW-
CONTROL [14]. Use of this API call requires a thorough understanding of the SNA
protocol to prevent its misuse.
By using this API call, an application can perform one of the following operations
Request to stop sending data
Confirm a request to stop sending data
Resume sending data
As can be seen, letting the applications handle the flow control makes the application
design complex as well as puts a burden on the designers to understand the
intricacies of the protocol.
Alternatively, it is possible to rely on the underlying SNA layers to perform flow-
control based on configured queue sizes and memory utilization. Using this method,
data flow is started or stopped depending on configured thresholds. Either method of
flow control is not adaptive pacing. Whereas in TCP/IP, the application layer is
completely oblivious to the flow control between the two applications. The
underlying transport and network layers handle all aspects of flow control.
TCP/IP uses a sliding window protocol that increases and reduces the data flow
between two partners depending on the current load on the network [5], TCP/IP uses
this mechanism to ensure that the channel is always full of data and attempts to
minimize the delays experienced while waiting for acknowledgments.
4.6 Contention Handling
The issue of contention handling addresses how a protocol handles multiple requests
for the same resource. This is not the same as flow-control, where protocols use
pacing and queuing to prevent flooding one destination with too much data.
Contention arises because of limited resources and potentially unlimited users. SNA
and TCP/IP handle contention differently, from an applications perspective.

In SNA, an application can be designed to be in a half-duplex mode where each end
takes turns in sending data to its partner. In such a scenario, the applications could
use bracketing to decide who gets to send data over the network. In this case, the
bracket is a token, which permits its owner to transmit data over the network. Once
an application has transmitted all its data, it relinquishes the token to its partner
which can than start transmitting data.
Alternatively, the applications could use the lower layers of SNA to resolve
contention. In such a scenario, each application has the right to send information to
its partner at any time. If two applications attempt to transmit data at the same time,
SNA resolves the contention by using configured rules like primary wins in all
situations etc. In this case, the secondary application will get an error as a result of
the transmit operation and must have the necessary logic to handle the error and retry
at a later time.
In TCP/IP, since all sessions are full duplex, applications do not have to handle
contentions related to data transmissions. The TCP layer will handle all contentions
related to. simultaneous requests to use the underlying IP layers. Also, if TCP/IP is
riding over Ethernet, which is inherently designed as a contention system [1], it will
handle all data link related contentions.
Since the IP layer is a connectionless protocol, it is possible for the TCP layer to
handle datagrams originating from many applications on a given node to be placed
on the network in an interlaced manner. This is because each IP packet contains the
source address as well as the destination address. Whereas, in SNA, once a session
has been established, only the session number is placed in each BLU.
4.7 Dynamic Session Reconfiguration
Once a session has been established between two partners, occasionally it needs to be
reconfigured dynamically to handle changes as needed. In TCP/IP, an application has
the ability to change the settings of a given session using an API call, SETSOCKOPT
[3]. This call lets an application re-configure one attribute at a time (SETSOCKOPT
is implementation specific) and generally allows the following attributes to be

Input and output buffer sizes
Address re-use permissions
Ability to use keep-alive messages
Use of bypass routing for outbound data
Shutdown procedures
Ability to broadcast messages
Ability to receive OOB data
In SNA too, it is possible to change attributes of an ongoing session. Unlike in
TCP/IP, which allows only one attribute to be changed at any given time, SNA lets
applications change multiple attributes using one API call, SET-ATTRIBUTES.
Using this call, an application can make the following changes to an ongoing session.
Use of large message formats (Where the SNA layers would consider multiple
physical data blocks to comprise one logical message)
Turn character translation ON or OFF
Indicate how to handle certain types of responses from the partner
In either case, being able to change the configuration dynamically requires the
application designers to be aware of the underlying protocol and its workings.
4.8 Direction of Data Flow
Since TCP/IP is a fiill-rduplex protocol, all data traffic between session partners can
be simultaneously bi-directional. Also, applications need not wait for their turn to
transmit data. TCP will guarantee that all data being transmitted will be delivered to
the destination in the same byte order.
Whereas in SNA, since sessions can be designed to be half-duplex or full-duplex, the
application needs to be aware of when it is allowed to transmit data and when it is
not. By the use of brackets, applications can exchange control of the channel.
Applications also use start-of-message, middle-of-message and end-of-message
indicators within each data block to inform the partner of the current position within
a message block.
If an SNA session is operating in a full-duplex mode, each partner can transmit data
at any time and the underlying layers will handle the direction of data flow.

4.9 Application Level Acknowledgments
In certain cases, even though the underlying protocol guarantees delivery of a
message to the remote partner, an application still needs to receive an
acknowledgment that the message was indeed delivered to the remote partner.
In SNA, when an application sends a data block, using the SEND-DATA API call, it
can turn on an option called NOTIFY-INDICATOR. When the underlying SNA
layers encounter this bit, it will ensure that an ACK received from the remote system
is propagated to the application. Usually, the session layer discards this ACK. In this
case, the receiving application has no idea that the sending application requested an
In TCP/IP, the protocol does not support Application level acknowledgments. If such
a feature is desired, it must be designed and implemented within the applications on
either end. TCP/IP will treat such an acknowledgment to be like any other data
4.10 Character Set Conversions
SNA supports the ability to perform character set conversions within the underlying
layers of the protocol. This is because IBM systems are inherently EBCDIC
machines and when SNA has to be implemented on other platforms, the need for this
conversion arises.
An application can request character translation using the SET-ATTRIBUTES API
call. The Presentation layer will convert data from ASCII to EBCDIC or vice versa
before handing it over to the application. If the data is binary, an application has to
selectively convert data from one format to another.
TCP/IP does not support character mode translation. Any such translations have to
be built within the scope of the applications.

4.11 Protocol Errors Notification and Recovery
Both SNA and TCP/IP provide an informative and structured way to report errors
back to the application. In both cases it is the responsibility of the application to act
on these error messages and retry an operation if so desired.
In SNA, every API call could return an error code. Some error codes like NO-
DATA-FORTHCOMING is a normal occurrence if an application requests SNA for
any messages that may have been received. An error code of MORE-DATA-
FORTHCOMING is a more serious matter and pertains to a situation where an
application passed a small buffer to receive a large message. In any case, the
application has to be designed to handle the various errors and recover from them.
In TCP/IP too, every API call could potentially return an error code. The application
must handle and recover from these error codes. One significant difference between
the two protocols is that in SNA, if the session breaks down for any reason, it will
immediately notify the application about this breakdown. Whereas, in TCP/IP, if the
application has not requested TCP to periodically send keep-alive message to the
partner, the loss or breakdown of a session is not discovered until the application
attempts to send a data block to its partner.
4.12 Performance
Performance is a complex issue because it depends on system organization, line
speeds, design of the protocol stack and the application design. Given the structure
of the two protocols, TCP/IP has a lot more overhead than SNA. The main reasons
for this is;
The IP header is very large (20 bytes or more per IP packet vs. 15 bytes or more per
SNA BLU) because each IP packet contains the source and destination address. This
header will grow larger (40 bytes or more per packet) in IP Version 6.
A routing decision needs to be made for each IP packet at every intermediate node
TCP/IP does not support compressed data blocks

5. Conversion of SNAX/HLS to TCP/IP
5.1 Application of the Conversion via
Projection Methodology
The objective of this section is to apply the conversion via projection methodology
to SNA and TCP/IP. This method requires us to build an equivalence between the
messages and states of SNA and TCP/IP. Doing this will lead to some commonality
between the two protocols, it would be possible to build the new protocol called
SNA over Sockets (SOS) which converts SNA messages to TCP/IP messages and
vice versa.
Applying the conversion via projection methodology to our problem consists of the
following steps:
Understand the messages and states of SNA and TCP/IP: In order to do this we
need to study each API verb and library call for the two protocols.
Build a Conversation State Matrix (CSM) of the SNA API: Each SNA API call
could result in several errors or may end successfully. Categorizing all the error
conditions and documenting the state transition for each API call will help us
build a CSM for the SNA API.
Study the Finite State Machine for TCP/IP
Build an equivalence matrix for the states in SNA and the states in TCP/IP: Since
we know the CSM for SNA and the FSM for TCP/IP, we should be able to merge
the two states and build a common matrix representing the two protocols
Being able to build an equivalence matrix representing the states of SNA and TCP/IP
proves a successful application of the conversion via projection methodology.
The following sections elaborate on each of the bulleted items mentioned above.

Now, let us compare the two APIs and search for some common ground with respect
to all the issues discussed in the previous section.
5.2 SNA High Level Support (HLS) API
The SNA-HLS API is a well-defined set of library calls used by applications to
communicate with the lower layers of SNA. The following picture describes the
workings of this API.
Figure 5.1
SNA-HLS Application Environment
The application uses a predefined set of verbs and library
calls to interface with the underlying SNA layers
An application that accesses SNA services uses an SNA-HLS API library to
communicate with the SNA-HLS system process. This API library, which contains
nineteen calls, provides a structured way to pass application data to the underlying
SNA layers and report any errors back to the application. The API library does not
process any contents of the message, it just acts as a transport mechanism between
the application and the lower level SNA layers.

The SNA-HLS system process communicates with the underlying SNA line handlers
and the hardware controllers. The SNA-HLS system process performs all the
Presentation and Session layer functionality. Although the user-written application
may be single threaded, the SNA-HLS system process can support both single
threaded as well as multi-threaded applications. The design of the SNA-HLS process
is in itself multi-threaded, so that it can support many applications concurrently.
The SNA-HLS API calls are explained below;
Verbs to Establish Sessions
Verb Function
HLS-ALLOCATE Define the session partner.
HLS-OPEN Allow participation in the SNA session with the session partner.
OPEN-SESSION Includes the combined actions of HLS-ALLOCATE and HLS-OPEN in one call.
Table 5.1
SNA Verbs Used to Establish a Session
Verbs to Discontinue Sessions
Verb Function
PREPARE-TO-CLOSE Request an orderly shutdown of the session.
HLS-CLOSE Perform a close of the session.
HLS-DEALLOCATE Deallocate the session. Includes the actions of HLS- CLOSE if the SNA session is active.
CLOSE-SESSION Discontinue a session. Performs the actions of HLS- CLOSE and HLS-DEALOCATE in one API call.
Table 5.2
SNA Verbs Used to Disconnect a Session

Miscellaneous Verbs
Verb Function
CONVERT-ERROR- CODE Convert a hexadecimal field to display format and obtain message text.
GET-ATTRIBUTES Obtain PROFILE and BIND information.
SET-ATTRIBUTES Set PROFILE options dynamically.
Table 5.3
SNA Verbs Used for Miscellaneous Functions
Data-Transfer Verbs
Verb Function
SEND-DATA Send data to the session partner.
RECEIVE-DATA Retrieves information from the receive queue.
SEND-AND-RECEIVE- DATA Sends data to session partner and then queues a RECEIVE-DATA verb.
HLS-RESPOND Sends a response to partners request.
REQUEST-SEND- STATE Requests permission to send data.
SEND-STATUS Sends a SNA LUSTAT to the session partner.
HLS-FLOW-CONTROL Sends RTR, QEC, QC, or RELQ to the session partner.
RECEIVE-CONTROL Queries the top element of the receive queue and, if it is not the partners data, retrieves it.
RECEIVE-CONTROL- WAIT Waits for a data element to arrive. It then queries the receive queue and if the top element is not the partners data, retrieves it.
Table 5.4
SNA Verbs Used for Data Transfer

5.3 SNA HLS Conversation State Matrix
The following SNA-HLS Conversation State matrix has been developed in order to
study the SNA state transition, as an application program calls each of the API verbs
or calls. The following table explains the symbols used to depict the response for
each API call.
API Call response Meaning
OK No errors. The API call was executed successfully. This will cause a state transition to another state.
PERR Parameter error occurred. This means that the Application will have to remain in the current state and re-issue the same API call.
ERROR The API call resulted in an error. This could be due to a variety of reasons. The Application will transition to another state or may remain in the same state depending on the current state
Table 5.5
SNA-HLS API Responses
Each API call could result in one of these three possibilities
The following table explains the various states and the meaning of each state.
State Number Conversation state Meaning
1 Reset No active session. Underlying SNA layers are still unaware of this application.
2 Initialized Application has informed underlying SNA layers of its existence. Application has also informed the SNA layer of its role (Client or Server and the session parameters). Waiting for session establishment with partner application.
Table 5.6
Description of SNA States
Each API call could result in a transition to one of these states

Table 5.6 (Cont.)
State Number Conversation state Meaning
3 Active Session has been successfully setup with the partner application. Data exchange can happen at this point.
4 Control Application is requesting to change session parameters or is requesting to send or receive control information with its partner.
5 Quiescent Application has requested a session shutdown
6 Shutdown The Application has terminated the session.
Table 5.6 (Cont)
Description of SNA States
Each API call could result in a transition to one of these states
The following table explains the transition symbols and its meaning;
Transition symbol Meaning
State remains unchanged.
This API call cannot be issued in this state.
1,2,3,4,5,6,7,8 State transitions to one of the indicated states (see previous table)
Table 5.7
Description of Transition Symbols
Each API call could result in a state change or remain in the same state

The Conversation state matrix for SNA-HLS is explained below:
API Call Response Reset 1 Initialized 2 Active 3 Control 4 Quiescent 5 Shutdown 6
HLS-ALLOCATE ERROR <-> <1- 4 4 4
HLS-OPEN OK 4 3 4 4 4 4
HLS-OPEN PERR 4 4- 4 4
HLS-OPEN ERROR 4 6 4 4> 4 4
OPEN-SESSION ERROR <-> 4 * 4- 4 4
SEND-DATA OK 4 4 O' 3 4 4
RECEIVE-DAT A OK 4 ** 3 4 4
PREPARE-TO- CLOSE OK * 4 5 4 4 4
HLS-CLOSE OK 4 * 4 6 4
HLS-CLOSE PERR * 4 4- 4 o 4
Table 5.8
SNA Conversation State Matrix
An API Call can only be issued correctly in certain states

Table 5.8 (Cont.)
API Call Response Reset Initialized Active Control Quiescent Shutdown
1 2 3 4 5 6
SEND-STATUS OK * 4 <1- *
Table 5.8 (Cont) SNA Conversation State Matrix
An API Call can only be issued correctly in certain states

This conversation state matrix is a tabular representation of the finite state machine
(FSM) model that represents the various states of SNA-HLS. This table or matrix
provides a better understanding between the states since it considers situations where
an API call might result in error due to incorrect parameter values (PERR) and also
error responses due to sudden failure of an existing session (ERROR). The state
transition, when a call is successful (OK), describes the next state of transition.
By deriving and understanding the Conversation state matrix, it would be easier to
follow the steps needs to transition from one state to another, as a result of the
invocation of an API call. Another use of this table is to eliminate inappropriate calls
and to handle error conditions appropriately.

5.4 TCP/IP API and its Variations
The full set of TCP/IP Sockets calls and their meanings are explained below [3]:
API Call Meaning
socket() Create a socket in order to communicate over the IP network.
connect() Connect to another process (local or remote)[Client mode].
writeO Send outgoing data across a connection. This call is not supported in a Tandem environment.
read() Receive incoming data from a connection. This call is not supported in a Tandem environment.
close() or closesocket() Terminate communication. closesocket() is used in the windows environment.
bindO Bind a local IP address and protocol port to a socket.
listen() Place the socket in passive receive mode.
accept() Accept the next incoming connection [Server].
recv() Receive the next incoming datagram (UDP).
recvmsgO (see recv) This call is not available in the Windows environment.
recvfromO = recv() but with source information provided.
send() Send an outgoing datagram.
sendmsg() (see send) This call is not available in the Windows environment.
sendtoO = send() but with destination information provided.
shutdown() terminate a TCP connection in one or both directions.
getpeemame() get the remote machine's name and IP address from a socket.
getsockoptO get the current socket options.
setsockoptQ Change the current socket options.
Table 5.9
Some of these API Calls will used depending on whether
the application is operating in Client or Server mode

The following picture explains the sequence of TCP/IP calls used within a client and
a server program.
Client Program Server Program
Socketf) SocketO 1
Connect/) i
i Listen/)
Write/) ^ . 1
j ^ Accepiy
Read/) Read/) 1
\ Write/)
Close/) \ 1
Figure 5.2
TCP/IP Client and Server API Sequence
In some instances an application can be designed to perform both these roles
This figure has been adapted from Comer D. E., Stevens D. L.; Internetworking with
TCP/IP Vol. IH; Prentice Hall, New Jersey, 1988, pp. 53

The following picture depicts the finite state machine of the TCP layer.
(Go back to start)
Figure 5.3
TCP/IP Finite State Machine
This FSM represents state transitions for Client mode as well as Server mode.
This figure has been adapted from Siyan K.; Inside TCP/IP Third Edition; New
Riders Publishing, Indianapolis, 1997, pp. 510 511
The TCP/IP finite state machine is explained below:

Each partner, whether it is a client of a server application, starts with the closed state
at the top. From this state, the server application will issue a passive open and move
to the listen state. The client application on the other hand will change from the
closed state to the SYN sent state by sending a SYN flag to its partner (server)
Once the partner (server) application receives the SYN flag, it sends a SYN flag as
well as an ACK flag back to the client application and changes over to the SYN rcvd
state. At this point, the client application receives the ACK from the server
application and sends back an ACK flag for the SYN message sent by the server.
Once this three-way handshake is completed, both the client and server applications
enter into the connection established state.
Either end can shutdown the active connection. The application that issues a closeQ
API call initiates an active close and the other application reacts with a passive close
state transition from the established state. Just as during the establishment of a
session, there is an exchange of ACK messages to ensure delivery of en-route
messages before the session shuts down. The active partner gets into a time-wait
state and waits for twice the MSL (maximum segment lifetime) time interval. This is
to ensure that any older packets will be discarded before a new session is established
which could potentially use the same sequence numbers as the previous session.
Both partners have to agree on closing the connection before a connection is closed.

5.6 Incompatible Features Between the Two APIs
Once we blend TCP/IP and SNA together, the application development environment
should look as shown below;
Objective of this
process is to
convert SNA API
calls to TCP/IP
in a transparent
Figure 5.4
SNA-HLS Over TCP/IP Application Environment
The conversion from SNA to TCP/IP API calls is performed transparently at
the SOS layer.
Here the Application consists of user written programs that have embedded SNA-
HLS calls. When the application invokes any of the SNA-HLS calls, it
communicates with the SNA-0 VER-SOCKETS (SOS) process rather than the SNA-
HLS system process. The SOS process uses a pre-built configuration file to retrieve
data about a SNA session. The configuration file consists of information indicating
whether an application is in client mode or server mode, the address of the remote
machine and a port number.

This method of protocol conversion is different from the protocol translation method
described in section 1 in the following ways:
1. In protocol translation, each message flows four times through all the layers of
each protocol. In the SOS program, the message is intercepted at the session layer
and converted to the new protocol (TCP/IP). This ensures that each message
flows through the protocol stack only twice.
2. In protocol translation, a third system is required to perform the conversion. This
system is an intermediate node for all traffic on the network. In the case of the
SOS program, the conversion is performed transparently.
3. In the case of Protocol translation, all applications typically have to be written to
a generic API. In the case of the SOS program, it uses existing APIs and
performs protocol conversion, not protocol translation.
Since SNA and TC/IP are very dissimilar protocols, we need to handle at least six
areas of differences between the two APIs. The differences between the two APIs
can be handled in one of two ways as explained below;
Function Unsupported Method
Any SNA-HLS function call that cannot be directly translated to a TCP/IP API
function call will be terminated with a response code of function unsupported. For
example: an application requests a HLS-FLOW-CONTROL to be sent to the remote
protocol stack. As soon as the SOS process receives this message, it will respond
back with a function-unsupported error. This will cause the application to error out
and possibly retry the operation. Using this method, it would not be possible to
support existing applications because they might be using these unsupported
functions to a great extent.

Assertive Response Method
In this scenario, the SOS process will accept every API call, even though it may not
be directly translated to a TCP/IP API call, and respond back positively to the
application. Under the circumstances, the SOS process will simply discard the
message. Since the application received a positive response, it will continue
This situation is ideal if the application wishes to change direction of data flow using
the API call REQUEST-SEND-STATE. Since TCP/IP is inherently a full duplex
protocol, even if the SOS process discards this message and responds positively,
there would be no harm caused to the underlying session.
After analyzing around 10 user-written programs from several organizations2 and by
talking to several managers and engineers in the industry, it was determined that it
would be easier to adapt the assertive response method for the SOS process because
of these two reasons;
This method permits existing applications to be converted to TCP/IP with no
changes to the code.
The study of existing SNA-HLS programs indicated that nearly 90% of the
programs use API verbs that can be easily translated to a TCP/IP API verb.
2 Examples were studied from these client sites: Visa debitcard services, TCI, Inc., Innovative
Electronics and Elder-Beerman Stores, Corp.

5.7 Projection of SNA Calls to TCP/IP
The following table attempts to map each of the SNA-HLS API calls to an equivalent
TCP/IP socket API call. This step will help us derive an equivalency between the
two protocols as required by the Conversion Via Projection methodology.
SNA API Call Equivalent TCP/IP Call present? TCP/IP Call(s)
HLS-ALLOCATE NO Assertive response
HLS-OPEN YES Client mode : socket() and connect() Server mode : socket(), bind(), listen() and accept()
OPEN-SESSION YES Client mode : socket() and connect() Server mode : socket(), bind(), listenQ and.accept()
SEND-DATA YES' write() or send()
RECEIVE-DATA YES read() or recv()
SEND-AND-RECEIVE- DATA YES write() or send() followed by a read() or recv()
PREPARE-TO-CLOSE NO Assertive response
HLS-DEALLOCATE NO Assertive response
CONVERT-ERROR-CODE NO Assertive response
HLS-FLOW-CONTROL NO Assertive response
HLS-RESPOND NO Assertive response
RECEIVE-CONTROL NO Assertive response
RECEIVE-CONTROL- WAIT NO Assertive response
REQUEST-SEND-STATE NO Assertive response
SEND-STATUS NO Assertive response
Table 5.10
SNA API Calls Projected to TCP/IP Socket API Calls
Note that some SNA API calls cannot be projected to TCP/IP Socket API calls
Not every SNA call could be mapped on to a TCP/IP Socket API call. This means
that our projection image R as described in the definition of the Conversion Via
Projection methodology will consist of a subset of the calls in SNA and in TCP/IP.
Note that image R will accept every SNA API call. Those calls which could not be
mapped to an equivalent TCP/IP API call will be responded using Assertive
response. Let us now build a combined conversation state matrix for image R.

5.8 Combined Conversation State Matrix
Using the assertive response method of translating calls from SNA to TCP/IP, we
need to attain the following conversation state matrix that combines the SNA states
and the TCP/IP states.
The following table explains the symbols used to depict the response for each API
API Call response Meaning
OK No errors. The API call was executed successfully. This will cause a state transition to another state.
PERR Parameter error occurred. This means that the Application will have to remain in the current state and re-issue the same API call.
ERROR The API call resulted in an error. This could be due to a variety of reasons. The Application will transition to another state or may remain in the same state depending on the current state
Table 5.11
SNA-HLS API Responses
Each API call could result in one of these three possibilities

The following table explains the various states and the meaning of each state.
State Number Conversation state Meaning
1 Closed No active session. Underlying SOS layer is unaware of this application.
2 Initialized Application has informed underlying SOS layers of its existence. Application has also informed the SOS layer of its role (Client or Server and the session parameters). Waiting for session establishment with partner application.
3 Established Session has been successfully setup with the partner application. Data exchange can happen at this point.
4 Quiescent Application has requested a session shutdown
5 Shutdown The Application has terminated the session.
Table 5.12
Description of TCP/IP states
Each API call could result in a transition to one of these states
The following table explains the transition symbols and its meaning;
Transition symbol Meaning
State remains unchanged.
This API call cannot be issued in this state.
1,2,3,4,5,6,7 State transitions to one of the indicated states (previous table)
Table 5.13
Description of transition symbols
Each API call could result in a state change or remain in the same state

The CSM for the SOS layer is explained below (changes are marked in bold):
API Call Response Closed 1 Initialized 2 Established 3 Quiescent 4 Shutdown 5
HLS-ALLOCATE OK 2 * 4- 4> 4>
HLS-ALLOCATE PERR o 4> 4> 4> 4>
HLS-OPEN OK * 3 4> 4* 4>
HLS-OPEN PERR * 4> 4* 4>
HLS-OPEN ERROR 5 4> 4> 4>
OPEN-SESSION OK 3 4> 4> 4> 4>
SEND-DATA OK 4- 4- 4-
SEND-DATA PERR <1- 4- 4> *
SEND-DATA ERROR 4> 5 4> 4>
RECEIVE-DATA OK 4> 4> 4- 4>
HLS-CLOSE OK 4> 4 5 4>
HLS-CLOSE PERR * 4- * O 4>
HLS-CLOSE ERROR 41 4> 4 5 4>
Table 5.14
SOS Conversation State Matrix
An API Call can only be issued correctly in certain states

Table 5.14 (Cont.)
API Call Response Closed I Initialized 2 Established 3 Quiescent 4 Shutdown 5
Table 5.14 (Cont) SOS Conversation State Matrix
An API Call can only be issued correctly in certain states

The new conversation state matrix shows that there is no control state in TCP/IP and
this change is reflected in the transitions resulting in each of the API calls. In the last
six API calls displayed above, the SOS layer replies immediately with an assertive
response and the application remains in the current state instead of transitioning to
the control state.
Also the names of the two states Reset & Active have been changed to Closed &
Established to better reflect the TCP states that we are trying to mirror.
This new conversation state matrix will help in implementation of this application,
since it shows the expected behavior for each of the API calls. The next section
explains the loss of functionality caused because of using the assertive response
method for completing some of the above API calls.
This table represents the equivalency matrix indicated in the conversion via
projection methodology used for protocol conversion. Being able to derive this
matrix proves that there is some commonality between the two protocols and it is
possible to convert SNA calls to TCP/IP calls at the API layer.

6. Functionality Sacrificed During Conversion
It is clear from studying the SNA and TCP/IP protocol stacks that the TCP/IP
protocol stack does not include the Session and the Presentation layers. This is by
design and is not a shortcoming of the TCP/IP stack. The goal of this study is to
demonstrate that the SNA API can provide a transparent API into the TCP/IP
protocol stack and not to perform a simple API to API translation.
The SNA API provides Session and Presentation layer functions, which is not
provided in the TCP/IP stack. These functions can be provided over TCP/IP using
protocol layers like XDR and ASN.l which can provide similar functionality [21]
As we know, TCP/IP and SNA have many fundamental differences in the design and
implementation of the protocol as well as in the API. These differences make a
conversion from one SNA function to an equivalent TCP/IP function, a very difficult
task and in some cases impossible. By using the assertive response method, the API
is feigning certain responses to the application because the TCP/IP API does not
support that function. In order to fully evaluate the functionality lost during such a
conversion, it is necessary to look at several functional areas of the two protocols.
The following discussion lists six areas that require consideration during the
conversion process. For each area, we need to look at the problem and come up with
possible solutions to avoid or circumvent the problem.
In order to provide a meaningful comparison of the functionality lost during
conversion, we need to look at the entry point of each of the SNA layers which are
missing in TCP/IP. These are the Session layer and the Presentation layer. Let us
consider each of these layers and investigate each issue.

6.1 Session Layer:
Ability to Control Data Flow
In SNA, the application has the ability to communicate with the remote protocol
stack and control the flow of data. This enables the application to use limited
resources efficiently. The application can request the remote stack to suspend flow,
restart flow and to send acknowledgments to prior suspensions of data flow.
This function is very useful if the local protocol stack cannot queue messages for an
application. It is also useful if an application is multi-threaded and can only read a
limited number of messages before responding to them.
To provide such a functionality to the application, the SOS process can have a
configurable message queue that can handle inbound as well as outbound messages,
the application need not be involved in flow control. Also, the underlying IP layer is
constantly managing data flow to prevent one node from potentially flooding another
node in the network.
By setting up the queue handling complexities in the SOS process, the application
does not have to deal with data flow control. It can read off each message and
respond to it and move on to the next message in the queue. In order to accommodate
existing applications, which perform flow control, the SOS process will respond
positively to all flow control requests. This will preserve compatibility with older
6.2 Session Layer :
Ability to Send and Receive Control Information
SNA-HLS provides expert users the ability to exchange control information like
sense data and ACKs with the remote protocol stack. This feature is typically used
for multi-system transaction control.
Given the fact that TCP/IP does not provide such a feature and it would not be
feasible to build such a feature into the SOS layer due to the complexity involved as
well as the re-design of every remote application involved in data interconnection,
this function would be lost during the conversion process.

Although the SOS layer will continue to reply with assertive responses to these
requests, it could potentially result in loss of integrity. On the upside, given the
statistics of API verbs used in the applications considered from various client sites, it
is safe to say that less than 5% of the applications use this feature. Hence the impact
would be minimal.
6.3 Session Layer:
Ability to Change Direction of Data Flow
SNA sessions can be configured to be half-duplex or full-duplex depending on the
logical device type as well as the application design. If an application is involved in a
half-duplex conversation, it has the ability to change the direction of data flow in an
orderly fashion using an exchange of brackets.
The owner of the bracket has the right to transmit data on the half duplex connection.
Once the owner of the bracket has completed transmitting all the data its wishes to
transmit to the partner, it can release the bracket.
Since TCP/IP is a full duplex protocol, this issue will not arise. The only concern
with TCP/IP is that both partners will assume that they own the bracket and may
simultaneously start transmitting data. This would be OK because the messages will
get queued for the respective applications and can be retrieved as and when desired
by the applications.
6.4 Session Layer:
Dynamic Session Reconfiguration
Both SNA and TCP/IP permit limited session reconfiguration when a session is
active. The major difference between attributes that can be reconfigured between
SNA and TCP/IP is that the SNA stack routinely analyzes and manipulates user data
whereas the TCP/IP stack never peeks into application data. This is mainly because
SNA includes the session and presentation layers whereas TCP/IP is restricted to the
Transport layer and Network layer.
By including data manipulation capability within the SOS program, it would be
possible to maintain compatibility with existing applications. This can be achieved

by providing user exits where user written functions can manipulate inbound and
outbound messages at the TCP layer.
Overall, these six areas represent major shortcomings between the two protocols.
Some of these issues can be overcome by adding functionality within the SOS
program. This would help maintain compatibility with existing applications and
preserve the uniformity of the SNA-HLS API so that it will behave the same way
whether an application is using the SNA stack or the TCP/IP stack.
6.5 Presentation Layer:
Character Mode Conversions
Given the fact that SNA is widely used on IBM systems that have a native EBCDIC
representation of characters, it becomes a necessity for applications to have the
ability to perform character mode conversions before processing the data. There are
two cases in this scenario. If the data comprises entirely of textual information, it
would be possible for the underlying SNA protocol stack to perform character
On the other hand, if the data comprises of mixed text and binary information, the
application would be responsible for character conversion since it would know the
boundaries of the textual data.
The SOS process could be designed to handle such character mode conversions by
using two methods, one way would be to build user-exits which will be user-written
functions that handle incoming and outgoing data just after it is received from the
TCP/IP stack or just before it is sent down the TCP/IP stack. This will make the
character conversion a responsibility of each implementation. The down side to this
design would be the introduction of bugs during the normal processing of data.
A second method would be to incorporate this library within the SOS program that
will check the parameters before each message is sent or after each message is
received and perform character conversions. This will add a significant delay in the
processing of each message but will maintain compatibility with existing systems.

6.6 Presentation Layer:
Requirement to Assemble and Disassemble
Applications using SNA-HLS for exchanging data with remote applications can be
ensured of two message delivery attributes.
Order of messages will be preserved
Messages boundaries will be preserved '
TCP/IP also ensures that the order of messages will be preserved. The second
delivery attribute poses a problem with TCP/IP because it is a streaming protocol.
TCP/IP will ensure message delivery to the destination application in the same order
of bytes as received from the source application. It is the responsibility of the
applications on either end to encapsulate each message with distinguishable headers
and trailers which can be used to assemble and disassemble each message from a
data stream.
In order to be compatible with existing applications and to ease the complexity of
assembling and disassembling messages from the applications, it would be possible
to build this logic within the SOS program. Using a protocol layer called TPKT
(Transport Packet), which puts a simple header around each TCP packet and unwraps
it before delivering a message to the application [20].
This solution would maintain compatibility with existing applications but would
require that all connected TCP layers use the TPKT protocol for compatibility.

7. Implementation and Results
The previous sections theoretically proved that SNA API calls can be converted to
equivalent API calls over the TCP/IP stack. In this section we intend to develop a
working solution. The equivalency matrix developed in Section 5 is used to design
and develop the SOS application and demonstrate a solution for this study.
7.1 Algorithm Development
Let us consider a part of the Equivalency matrix developed in Section 5.
API Call Response Closed Initialized Established Quiescent Shutdown
1 2 3 4 5
Table 7.1 SOS Conversation State Matrix From Section 5
This table will be converted to an algorithm in this section
The above matrix can be converted to an algorithm as shown below;
A sentence beginning with a indicates a comment.
Algorithm for HLS-ALLOCATE
* Ensure that the current state is CLOSED before accepting this API call
if (current-state != CLOSED) respond (invalid-state)
* Accept and validate all the parameters and store it in local memory
initialize variables and prepare for new session
Read configuration file and determine role (Client or Server)
* Check whether everything was passed correctly
If (parameters are valid)
change state to INITIALIZED
respond (OK)

* user passed in bogus parameters
respond (parameter error)
Algorithm for HLS-OPEN
Ensure that the current state is INITIALIZED before accepting this API call
if (current-state != INITIALIZED) respond (invalid-state)
* Check whether everything was passed correctly
If (parameters are valid)
create a TCP/IP socket and activate the session
if (successful in creating a TCP/IP session)
change state to ESTABLISHED
respond (OK)
change state to SHUTDOWN
respond (line-error)
* user passed in bogus parameters
respond (parameter error)
As the two preceding examples show, it is possible to convert the entire CSM
derived in Section 5 into an equivalent algorithm for each API call.
7.2 Implementation Details
In order to demonstrate a working solution for this study it was necessary to build
two components
A SOS program which will accept SNA API calls and verify message parameters
and perform state transitions according to the derived rules
A test application which can be used to validate that the solution works.

The following picture describes the test scenario:
In this scenario, the same test application can be used as a Sender (Client) or a
Receiver (Server). The test application has embedded SNA verbs and library calls.
Let us assume that this application works perfectly in a pure SNA environment. In
order to demonstrate that our SOS conversion program works correctly, we have to
run the test application over the SOS layer and have it work in the same way.

Proving that the test application works over the SOS layer will indicate the
The conversion procedure called conversion via projection has been correctly applied
for this study.
SNA can be transparently interfaced over the TCP/IP protocol stack.
7.3 Test Scenarios
The following tests were performed in order to prove that the conversion of SNA to
TCP/IP was successful:
1. The test application was used over a regular SNA stack to ensure the following
Session initiation
Session Establishment
Mode selection (Client or Server)
Data transfer (Receiver could receive every block sent by the Sender)
Error notification
2. The same test application was restarted after shutting down the SNA stack and
starting up the SOS layer. The same points were re-checked to ensure proper
3. The same test application was converted to run over a native TCP/IP stack in
order to measure performance overhead. Although this is not an objective in this
study, this test was carried out for additional information in order to measure the
overhead related to this conversion.

Given the practical constraints of time, availability of hardware and other resources,
the above tests will not be able to verify the following:
1. Session layer functions like exchanging control information, ability to handle
message ACKs etc.
2. Presentation layer functions like character mode conversion and message
3. Comparison of the performance of a pure SNA stack versus the SOS layer to
detect the performance overhead.
4. Ability to use XDR and ASN. 1 as a possible complement to the TCP/IP stack in
order to provide Session and Presentation layer functionality.
7.4 Test Results
Each of the three test results are explained below
1. The initial test was run in a SNA environment. The two* test applications were
instantly able to establish a session and start the data transfer. The SNA link was
installed over a 56KB leased line. The underlying protocol was SDLC. This
proves that the test application used the SNA API verbs correctly and
consistently. Next, the leased line was abruptly disconnected The application at
either end was able to detect the line failure and terminate gracefully. 2
2. Next, the SNA stack was shut down. The SOS program was started up on each
system (local and remote). Then the test applications were started up. Session
initiation was verified at each end. The Sender application attempted to establish
the session. The SOS program appropriately created a socket and attempted to
connect to the IP address and the port of the Receiver application as configured.
The two applications were able to establish a session and exchange information
over a TCP/IP link. This proves that the conversion methodology was
implemented correctly. Next, the TCP/IP link was disconnected abruptly. The
applications on either end were able to recover gracefully as before.

3. The performance test results are shown in the tables below
Performance over a 10 Megabit Per Second LAN using a regular TCP/IP stack
versus a SOS stack are shown below:
Message size in bytes Iterations of the test TCP/IP stack Average round trip time in milliseconds SOS stack Average roundtrip time in milliseconds
100 1000 11 13
500 1000 10 11
1000 1000 9 11
5000 1000 13 15
Table 7.2 Test Results Indicating SOS Performance
The results indicate that TCP/IP is slightly faster for all message sizes
This test was performed in order to compare the overhead imposed by the SOS stack
while performing the SNA to TCP/IP conversion. The SOS stack consistently shows
a overhead of 10% to 20% over a normal TCP/IP stack. This is attributed to the
actual processing of the SNA verbs as well as inefficient methods adopted to move
data blocks around in memory before passing to the TCP/IP stack. The performance
can be improved a little bit by making the program more efficient.
A strange trend in the results indicate that the performance is optimum when the
message size is approximately 1000 bytes. This may be because the fragmentation
factor of the underlying layers like routers and hubs may come into play as the
message size grows too large.
These test results indicate that the fundamental objectives of this study have been

8. Conclusion
Although SNA and TCP/IP are very disparate protocols, we have shown that it is
possible to perform a conversion at the API layer. In order to prove this, we started
with the comparison of the two protocols and their features and then discussed the
possible areas of incompatibility. A certain conclusion after this initial study was that
although it may be possible to convert SNA calls to TCP/IP at the API layer, not
every API call had a direct TCP/IP equivalent. This would result in a loss of
functionality as a result of the conversion.
In order to provide compatibility with existing SNA applications, we decided to use
assertive responses to API calls that could not be directly converted to TCP/IP calls.
A study of existing applications at several client sites proved that the impact of using
this method would be minimal.
The task of performing the actual conversion was undertaken with the analysis of the
SNA and TCP/IP APIs. During this analysis, we derived the conversation state
matrix for each of the two protocols and derived a matrix that was a hybrid of the
two APIs. This matrix is the driving factor behind the algorithms that helped us
achieve our goal.
While performing the conversion, we also looked at the loss of functionality that
resulted from such a conversion and looked at various ways to add back that
functionality using additional overhead and logic in the program. This helped us
provide a better conversion tool.
Lastly, the program was implemented in order to show that such a conversion was
indeed possible. A test application has been created to exercise SNA calls and to
report on the validity and performance factors resulting from such a conversion.
An important conclusion resulting from this study is that if we can convert SNA calls
to TCP/IP at the API layer, it may be possible to build a generic API which could
support a wide variety of protocols, but essentially runs on TCP/IP. This could help
large networks migrate from proprietary networks like SNA and DECnet to TCP/IP.

Source Code
/********************************************************************** i
This application can send and receive messages over SOS
in order to test sessions. It receives 4 parameters and uses
these values to establish sessions, format data and exchange
messages with a remote application
Accepts two startup parameters,
/* 1. SOCK NAME 5PROC.#TCP.Snnnn (nnnn = Socket Number) */
/* 3. MSGSIZE MAX 2000 BYTES */
/* */
/* RUN from TACL */
/* */
/* vl.00 22-FEB- 99 Ganesh Hegde (Initial Development) */
/******************************* #pragma SQL tpragma INSPECT #pragma SYMBOLS #pragma RUNNABLE * * j
#include nolist
#include nolist
#include nolist
#include nolist
#include nolist
[[include "hlsddc" nolist
#define VERSION "1.00"
#define SEND MODE 1
tdefine RECV MODE 2
#define MAXSIZE 2000
#define MAXRATE 10000
char sysname[7];
char procname[8] ;
char tcpname[8];
char sockname[8];
} ;
struct HLS_PROC_NAME hlsname;
short first_time = 1, error = 0, inprogress = 0 done, msgrate, msgsize, func,
sessionid, hls_fnum;
char *ptr, separator,temp[80], function[10] filename[40];
char buf[MAXSIZE+500];
unsigned long sendcount, recvcount;
long long sendtime,recvtime,roundtime,starttime,endtime, tempi, temp2;
/* functions declared in this program */

void Establish(void);
void Cleanup (void);
void ProcessLoop (void);
short Sendit (void *buf, short len);
short OpenHLS(void);
short CloseHLS(void);
/* HLS calls */
short allocate_session (void) ;
short open_session (void);
short deallocate_session (void);
short close_session (void);
short send_data (void);
short recv data (void);
* Go belly up if we encounter a fatal error
******************************'*********'***********************,**,******* J
void FatalError (char *rasg)
strcat (msg, "\n");
printf (msg);
exit (1);
* Program main
int main (int argc, char *argv[])
if (argc != 5)
FatalError ("SYNTAX : RUN TESTAPP ")
/* initialize variables */
hls_fnum = 0;
memset ((char *)&filename[0], 0,sizeof(filename));
memset ((char *)&function[0], 0, sizeof(function));
msgrate = 0; msgsize = 0;
memcpy ((char *)&filename[0], argv[l], strlen(argv[l]));
memcpy ((char *)&function[0], argv[2], strlen(argv[2]));
if (!memcmp((char *)&function[0], "SEND", 4))
func = SEND_MODE;
func = RECV_MODE;
msgsize = atoi(argv[3]);
if ((msgsize <= 0 ) I I (msgsize > MAXSIZE)) msgsize = MAXSIZE;
msgrate = atoi(argv[4]);
if ((msgrate <= 0 ) || (msgrate > MAXRATE)) msgrate = MAXRATE;
memset ((char *)shlsname.sysname[0], 0, sizeof(hlsname));


printf("NnFile name : %s \n" , argv[1]);
printf("Function ; %s \n" , argv[2]);
printf("Message Size : %s \n" , argv[3]);
printf("Message Rate : %s \n" , argv[4]);
printf ("\n*-*-*-*-*-*
starttime = 0;
endtime = 0;
sendtime = 0;
recvtime = 0;
roundtime = 0;
while (1) do
sessionid = -1;
/* setup a session with remote partner */
Establish ();
/* process a message depending on client or server mode */
if (sessionid > -1)
/* between establish and process put in a 5 second delay to
let TCPIP set up its buffers */
DELAY (500);
ProcessLoop ();
/* perform cleanup activity, if session went down */
Cleanup ();
/* wait 1 minute after cleanup before re-connecting */
DELAY (6000);
* Perform session establishment sequence to get a session id
****************************************** j
void Establish (void)
short status;
if (hls_fnum == 0)
hls_fnum = OpenHLSO;
if (hls_fnum == 0) return;
status = 0;
status = allocate_session();
if (status != 0)
printf ("\nError %d encountered during HLS-ALLOCATE. Continuing...\n",status)
status = 0;
status = open_session();
if (status != 0)
printf ("\nError %d encountered during HLS-OPEN. Continuing...\n",status);

* Perform cleanup since the session has gone down...
*****************'*r*********'*,****************************************** J
void Cleanup (void)
short -status;
status = 0;
if (sessionid > -1)
status = close_session();
if (status != 0)
printf ("NnError %d encountered during HLS-DEALLOCATE.
status = 0;
if (sessionid > -1)
status = deallocate_session();
if (status != 0)
printf ("\nError %d encountered during HLS-CLOSE. Continuing...\n",status)
if (hls_fnum > 0)
hls_fnum = CloseHLSO;
* Process messages on a given session as per CLIENT or SERVER mode
void ProcessLoop (void)
short status;
while (sessionid > -1)
if (func == SEND_MODE)
status = 0;
if (sessionid > -1)
status = send_data();
if (status != 0)
printf ("NnError %d encountered during SEND-DATA. Continuing...\n",status)
status = 0;
if (sessionid > -1)
status = recv_data();
if (status != 0)
printf ("NnError %d encountered during RECV-DATA. Continuing...Nn",status)
roundtime = roundtime + (temp2 tempi);
if (!(sendcount % msgrate) )
if (sendcount == 0) sendcount == 1;

printf ("\nAverage roundtrip time for %d messages is %03.4f milliseconds /
msg \n",
msgrate, ((roundtime / msgrate)/1000.) );
/* put in a delay so that the system is not adversely affected */
/* initialize all critical counters for the next batch of messages */
starttime = 0;
endtime = 0;
sendtime = 0;
recvtime = 0;
roundtime = 0;
tempi = 0;
temp2 = 0;
status = 0;
if (sessionid > -1)
status = recv_data();
if (status != 0)
printf C'\nError %d encountered during RECV-DATA. Continuing...\n",status);
status = 0;
if (sessionid > -1)
status = send_data();
if (status != 0)
printf ("NnError %d encountered during SEND-DATA. Continuing...\n",status);
roundtime = roundtime + (temp2 tempi);
if (!(sendcount % msgrate) )
if (recvcount == 0) recvcount == 1;
printf ("NnAverage roundtrip time for %d messages is %03.4f milliseconds /
msg \n",
msgrate, ((roundtime / msgrate)/1000.) );
/* put in a delay so that the system is not adversely affected */
pxintf \n***********************_*_****
/* initialize all critical counters for the next batch of messages */
starttime = 0;
endtime = 0;
sendtime = 0;
recvtime = 0;
roundtime = 0;
tempi = 0;
temp2 = 0;
} /* of while */
* Do WRITEREAD to the HLS process

short Sendit (void *buf, short len)
short len_read, error;
if (hls_fnum <= 0)
return(1) ;
error = 0;
if (WRITEREADX(hls_fnum, buf,len, MAXSIZE, &len_read) = CCE)
printf("\nError On WRITEREAD To HLS Process %d\n",error);
* Open the HLS process
******:****************************************** j
short OpenHLS(void)
short c_code, file e_code, proclen, level;
char proc_name[10];
memset ((char *)&proc_name[0], 0, sizeof(proc_name));
level = 0;
e_code = FILENAME_DECOMPOSE_(filename (short)strlen(filename),
(char *)&proc_name[0],
Sproclen, level);
if (e_code != 0)
printf ("\n File name improper \n");
/* c_code = FILE_OPEN_(filename, (short)strlen(filename), sfile); */
printf ("\nOpening HLS process\n");
c_code = FILE_OPEN_(proc_name, (short)proclen, Sfile);
if (c_code != 0)
printf ("\nOpen Error on HLS process\n");
return (file) ;
* CLOSE the HLS process
short CloseHLS(void)
short c_code, file;
printf ("\nClosing HLS processNn);
c_code = FILE_CLOSE_(hls_fnum);
if (c_code != 0)
printf ("\nClose Error on HLS process\n");
return (0);
* Allocate the session

***************************************'**************************** j
short allocate_session (void)
short status, i, j, done;
char int_file_name[24];
hls_allocate_request *rq;
hls_allocate_reply *rp;
/* initialize the buffer */
memset ((char *)&buf[0], 0, sizeof(buf));
/* set up the request and response buffers */
rq = (void *)&buf[0];
rp = (void *)&buf[0];
/* format the request
buffer */
= 0;
= X' ;
= X' ;
i = 0; j =0; done = 0;
memset ((char *)&int_file_name[0], 32, sizeof(int_file_name));
while (!done)
if (filename [i] =
if (filename[i] =:
if (filename [i] =:
'$' )
'&& filename[i+1] == '#'
. && filename[i+1] != '#'
j = 0;
j = 8; i++; }
j = 16; i++; )
int_file_name[j] = filename[i];
if (filename[i] == '\0' I| filename[i] == [[ i > 23) done = 1;
memcpy ((char *)&rq->lu_name[0], (char *)&int_file_name [0],
memcpy ((char *)&rq->profile_name, "TESTAPP ", 8);
rq->pipeline_lu_ind = 'X';
/* send the buffer to the HLS process */
status = 0;
status = Sendit (buf, sizeof(*rq));
/* check for setup the session id */
if (rp->return_code == RC_OK)
/* setup session id */
sessionid = rp->session_id;
/* reset session id */
sessionid = -1;
return (status);

* Open the session
****************************************************************************** j
short open_session (void)
short status;
hls_open_request *rq;
hls_open_reply *rp;
/* initialize the buffer */
memset ((char *)&buf[0], 0, sizeof(buf));
/* set up the request and response buffers */
rq = (void *)&buf[0];
rp = (void *)&buf[0];
/* format the request buffer
rq->verb_code =
rq->session_id =
rq->completion_mode =
'X' ;
'X' ;
memcpy ((char *)srq->application_name[0], (char *)^filename[0] ,
strlen(filename)) ;
memcpy ((char *)&rq->application_name[0], "TESTAPP ", 8);
/* send the buffer to the HLS process */
status = 0;
status = Sendit (buf, sizeof(*rq));
/* check for setup the session id */
if (rp->return_code != RC_OK)
/* reset session id */
sessionid = -1;
return (status);
* Deallocate the session
******************************************************************************* f
short deallocate session (void)
short status;
hls_deallocate_request *rq;
hls_deallocate_reply *rp;
/* initialize the buffer */
memset ((char *)&buf[0], 0, sizeof(buf));
/* set up the request
rq = (void *)&buf[0];
rp = (void *)sbuf[0];
/* format the request
/* send the buffer to the
status = 0;
and response buffers */
buffer */
= sessionid;
= X' ;
= X' ;
HLS process */

status = Sendit (buf, sizeof(*rq));
if (rp->return_code != RC_OK)
/* reset session id */
sessionid = -1;
return (status);
* Close the session
**************************************:****** j
short close_session (void)
short status;
hls_close_request *rq;
hls_close_reply *rp;
/* initialize the buffer */
memset ((char *)sbuf[0], 0, sizeof(buf));
/* set up the request and response buffers */
rq = (void *)&buf[0];
rp = (void *)&buf[0];
/* format the request
buffer */
= sessionid;
= X' ;
= X' ;
/* send the buffer to the HLS process */
status = 0;
status = Sendit (buf, sizeof(*rq));
/* check for setup the session id */
if (rp->return_code != RC_OK)
/* reset session id */
sessionid = -1;
return (status);
* send data to partner
****************************************************************:************ j
short send_data (void)
short status;
send_data_request *rq;
send_data_reply *rp;
receive_data_reply *rrp;
/* initialize the buffer */
memset ((char *)&buf[0], 0, sizeof(buf));
/* set up the request and response buffers */
rq = (void *)&buf[0];
rp = (void *)&buf[0];
rrp = (void *)&buf[0];

/* format the request buffer */
rq->verb_COde = VERB_S END_DATA;
rq->session_id = sessionid;
rq->prepare_to_receive_ind = 1X' ;
rq->end_transaction_ind = 'X';
rq->formatted_data_ind = 'X';
rq->notify_ind = 'X';
rq->message_complete_ind = 1X';
rq->user_data_length = msgsize;
memset((char *)&rq->user_data_s[0], 'V', msgsize);
/* send the buffer to the HLS process */ '
status = 0;
/* set the starttime */
starttime = JOLIANTIMESTAMP();
status = Sendit (buf, (sizeof(*rq) + msgsize));
sendtime = sendtime + (endtime starttime);
/* check for setup the session id */
if (((rp->verb_code == VERB_SEND_DATA) &&
(rp->return_code == RC_0K)) [I
((rrp->verb_code == VERB_RECEIVE_DATA) S&
(rrp->return_code == RC_0K)))
/* setup session id */
if (!(sendcount % msgrate) )
if (sendcount == 0) sendcount == i;
printf ("\nSent %ld messages, each %d bytes long to partner\n",
sendcount, msgsize);
printf ("\nAverage SEND time for %d messages is %03.4f milliseconds / msg \n"
msgrate, ((sendtime/msgrate)/1000.));
/* reset session id */
sendcount = 0;
status = rp->return_code;
sessionid = -1;
return (status);
* Receive data from partner
^^-fr*************************************************************************** j
short recv_data (void)
short status;
receive_data_request *rq;
receive_data_reply *rp;

/* initialize the buffer */
memset ((char *)&buf[0], 0, sizeof(buf));
/* set up the request and response buffers */
rq = (void *)&buf[0];
rp = (void *)&buf[0];
/* format the request buffer */
rq->verb_code = VERB_RECEIVE_DATA;
rq->session_id = sessionid;
/* send the buffer to the HLS process */
status = 0;
starttime = JULIANTIMESTAMP();
status = Sendit (buf, sizeof(*rq));
recvtime = recvtime + (endtime starttime);
/* check for setup the session id */
if (rp->return_code == RC_OK)
/* setup session id */
if (!(recvcount % msgrate) )
if (recvcount == 0) recvcount == 1;
printf ("XnReceived Sid messages, each %d bytes long from partner\n",
recvcount, rp->user_data_length);
printf ("XnAverage RECV time for %d messages is %03.4f milliseconds / msg \n",
msgrate, ((recvtime/msgrate)/1000.) );
l* reset session id */
recvcount = 0;
status = rp->return_code;
sessionid = -1;
return (status);
void T9999D30 TESTAPP_100_24Feb99 () {}

1. Tanenbaum, A. S.; Computer networks Third Edition; Prentice Hall, New
Jersey, 1996.
2. Chiong, J.; SNA Interconnections; McGraw Hill, New York, 1996.
3. Comer D. E., Stevens D. L.; Internetworking with TCP/IP Vol. Ill; Prentice Hall,
New Jersey, 1988.
4. Peterson L. L., Davie B. S.; Computer networks: A systems approach; Morgan
Kaufman Publishers, San Francisco, 1996.
5. Siyan K.; Inside TCP/IP Third Edition; New Riders Publishing, Indianapolis,
6. Clark, D., Pasquale, J. et al.; Strategic directions in networks and
telecommunications; ACM Computing Surveys, Vol. 28, No. 4, December
1996; pp. 679-690
7. Lam, S. S.; Protocol conversion & mdash: correctness problems; Proceedings
of the ACM SIGCOMM conference on communications architecture &
protocols, 1986; pp. 19 28
8. Toll, W. E.; Socket programming in the data communications laboratory;
Papers of the 26th SISCSE technical symposium on computer science education,
1995; pp 39-43
9. Okumura, K.; A formal protocol conversion method; Proceedings of the ACM
SIGCOMM conference on communications architecture & protocols 1986; pp.
10. Bernstein, P. A.; A Middleware a model for distributed system services;
Communications of the ACM Vol. 39, No. 2, February 1996; pp. 86 98
11. Robertson, P.; Integrating legacy systems with modem corporate applications;
Communications of the ACM Vol. 40, No. 5, May 1997; pp. 39 46
12. Lam, S. S., Calvert, L. K.,; An exercise in deriving a protocol conversion;
Proceedings of the ACM workshop on frontiers in computer communications
technology, 1988; pp. 151-160
13. Ubik, S.; Possibilities of using protocol converters for NIR system
construction; ACM SIGCOMM computer communication review; November
1996; pp. 37-48
14. Tandem SNAX/HLS programming manual; Tandem computers, inc.; Operating
system G.06, June 1998.
15. Tandem TCP/IP programming manual; Tandem computers, inc.; Operating
system G.06, June 1998.

16. Tandem SNAX/HLS Configuration and management manual; Tandem
Computers, Inc.; Operating system G.06, June 1998.
17. Digital library contains articles, notes and proceedings.
Accessed between November 1998 and April 1999.
18. OwnFuture This site
contains information about Tandem products and services. Accessed between
November 1998 and January 1999.
19. 5
0/enu/dzbl0m03 .htm This site contains information about IBM publications,
products and services. Accessed between September 1998 and February 1999.
20. [RFC 1006] Rose, M., and D. Cass, "ISO transport services on top of the TCP -
Version: 3", STD 35, RFC 1006, Northrop research and technology center, May
21. .review
This site provides information on the External Data Representation
(XDR) protocol. Accessed between March 1999 and April 1999
22. This site presents a brief but
informative presentation on the workings of Abstract Syntax Notation One
(ASN.l). Accessed between March 1999 and April 1999
23. [RFC0793], "Transmission Control Protocol DARPA Internet program protocol
specification, RFC 0793, Information Sciences Institute, University of Southern
California, September 1981.