Xerox Network Services (XNS)
Xerox
Network Services (XNS) is a computer networking protocol suite developed by
Xerox within the Xerox Network Systems Architecture. It provided general
purpose network communications, internetwork routing and packet delivery, and
higher level functions such as a reliable stream, and remote procedure calls.
XNS predated and influenced the development of the Open Systems Interconnection
(OSI) networking model, and was very influential in local area networking
designs.
Xerox
used XNS for file transfers, sharing network resources, packet transfers,
sharing routing information and remote procedure calls. Its basic working
mechanism is almost the same as in the TCP/IP protocol suit, but XNS contains
only two network layers. This differs from the seven-layer Open Systems
Interconnection (OSI) model, although the functionality is basically the same.
XNS
was a public domain technology and therefore became one of the most commonly
used networking technologies through 1980s. It was replaced by the Internet
Protocol suite.
XNS
contains two major layers, a network layer and a transport layer. The network
layer provides the packet-carrying service and logical addressing. XNS was
developed for many purposes, such as office applications, transmissions,
communication media and processors. There is an echo protocol inside the XNS
suite, which works as a door knocker, checking the connectivity between the two
systems. This is similar to ping in IP systems.
XNS Architectures
XNS
Basic Protocol
Internet
Datagram Protocol (IDP)
The
Internet Datagram Protocol (IDP) delivers a single frame as an independent
entity to an Internet address, irrespective of other packets or addressee
responses. XNS generally limits the IDP packets to a maximum size of 576 bytes,
excluding the data link header.
The following
parameters are available for IDP:
Destination network:
Four-byte address of the destination network.
Destination socket:
Two-byte socket number of the destination port.
Source network: Four-byte
address of the source network.
Source socket: Two-byte
socket number of the source port.
Hop count: Indicates
the number of routers encountered during transport of the packet. Each router
handling a packet increments the hop count by one. When the hop count reaches
16, this protocol discards the packet.
Routing
Information Protocol (RIP)
XNS
uses the Routing Information Protocol (RIP) to maintain a database of network
hosts and exchange information about the topology of the network. Each router
maintains a list of all networks known to that router along with the routing
cost in hops required to reach each network. XNS distributes routing
information on the network by routers broadcasting their routing tables every
30 seconds. This protocol sends routing tables as a result of changes in service
or topology or in response to a request for routing information.
XNS
generally uses the Echo protocol to demonstrate the existence and accessibility
of another host on the network, while using the Error protocol to signal
routing errors.
Packet Exchange Protocol (PEP)
The
Packet Exchange Protocol (PEP) provides a semi-reliable packet delivery service
that orients toward single-packet exchanges.
The
following parameters are available for PEP:
Packet
ID: A unique number used to identify responses as belonging to a particular
request. The sending host sets the packet ID field to a fixed value, then looks
for PEP responses containing the same packet ID value.
Client
type: A registered code used to identify the particular application in use.
Sequenced Packet Protocol (SPP)
The
Sequenced Packet Protocol (SPP) provides reliable transport delivery with flow
control.
The
following parameters are available for SPP:
Source
connection ID: Reference number used to identify the source end of a transport
connection. This protocol establishes Connection IDs at connect time to
distinguish between multiple transport connections.
Destination
connection ID: Reference number used to identify the target end of a transport
connection.
Sequence
number: Sequence number of the packet. Each successive packet transmitted and
acknowledged on the transport connection must have a sequence number one higher
than the previous sequence number.
Acknowledge
number: Sequence number of the last packet that the protocol received properly.
Each side of the transport connection uses its own sequence of numbers for
transmitted packets, resulting in sequence and acknowledge numbers in the same
packet generally being out of phase with each other.
XNS Addresses
An
XNS address occupies 12 bytes and is comprised of three parts:
A
32-bit network ID
A
48-bit host ID
A
16-bit port number
The
host ID is an absolute number that must be unique to all XNS Internets. The AIX
implementation uses the 48-bit Ethernet address as host ID. With unique host
IDs, the network ID is redundant but is required for routing purposes.
XNS
addresses can be represented by several means, as can be seen in the following
examples:
123#9.89.3c.90.45.56
5-124#123-456-900-455-749
0x45:0x9893c9045569:90
0456:9893c9045569H
The
first example is in decimal format, and the second example, using - (minus
signs), is separated into groups of three digits each. The 0x and H examples
are in hex format. Finally, the 0 in front of the last example indicates that
the number preceding the colon is in octal format.
System Network Architecture
SNA
was developed in the 1970s with an overall structure that parallels the OSI
reference model. With SNA, a mainframe running Advanced Communication
Facility/Virtual Telecommunication Access Method (ACF/VTAM) serves as the hub
of an SNA network. ACF/VTAM is responsible for establishing all sessions and
for activating and deactivating resources. In this environment, resources are
explicitly predefined, thereby eliminating the requirement for broadcast
traffic and minimizing header overhead. The underlying architecture and key
components of traditional.
It
is a complete protocol stack for interconnecting computers and their resources.
SNA describes formats and protocols and is, in itself, not a piece of software.
The implementation of SNA takes the form of various communications packages,
most notably Virtual Telecommunications Access Method (VTAM), the mainframe
software package for SNA communications.
Systems
Network Architecture (SNA) is IBM's proprietary networking architecture,
created in 1974. It is a complete protocol stack for interconnecting computers
and their resources. SNA describes formats and protocols and is, in itself, not
a piece of software. The implementation of SNA takes the form of various
communications packages, mostly Virtual Telecommunications Access Method
(VTAM), the mainframe software package for SNA communications.
IBM
SNA Architecture
IBM SNA-model
components map closely to the OSI reference model. The descriptions that follow
outline the role of each SNA component in providing connectivity among SNA
entities.
Data-link
control (DLC)---Defines
several protocols, including the Synchronous Data Link Control (SDLC) protocol
for hierarchical communication, and the Token Ring Network communication
protocol for LAN communication between peers
Path
control---Performs
many OSI network-layer functions, including routing and datagram segmentation
and reassembly (SAR)
Transmission
control---Provides
a reliable end-to-end connection service, as well as encrypting and decrypting
services
Data
flow control---Manages
request and response processing, determines whose turn it is to communicate,
groups messages together, and interrupts data flow on request
Presentation
services---Specifies
data-transformation algorithms that translate data from one format to another,
coordinate resource sharing, and synchronize transaction operations
Transaction
services---Provides
application services in the form of programs that implement distributed
processing or management services
Elements
of SNA
Network
Control Program (NCP): It is a packet forwarding protocol, acting
like modern switch - forwarding data packages to the next node, which might be
a mainframe, a terminal or another 3705.
It is a multiplexer that connected multiple terminals into one
communication line to the CPU, thus relieved the constraints on the maximum
number of communication lines per CPU.
Synchronous
Data Link Control (SDLC):
It is a protocol which greatly improved the efficiency of data transfer over a
single link
SDLC included much
more powerful error detection and correction codes. These codes often enabled
the communications cards to correct minor transmission errors without
requesting re-transmission, and therefore made it possible to pump data down a
line much faster.
Virtual
Telecommunication Access Method (VTAM): VTAM, a software package to provide log-in, session
keeping and routing services within the mainframe. A terminal user would log-in
via VTAM to a specific application or application environment (e.g. CICS or
TSO). A VTAM device would then route data from that terminal to the appropriate
application or application environment until the user logged out and possibly
logged into another application. The original versions of IBM hardware could
only keep one session per terminal. In the 1980s further software (mainly from
third-party vendors) made it possible for a terminal to have simultaneous
sessions with different applications or application environments.
