Xerox Network Services
From Wikipedia, the free encyclopedia
Xerox Network Services (commonly XNS) was a protocol suite promulgated by Xerox, which provided routing and packet delivery, as well as higher level functions such as a reliable stream, and remote procedure calls. It is the canonical local area networking protocol, copied to some degree by practically all networking systems used in the 1980s and 90s. During the 1980s XNS was used by 3Com and (with modifications) a number of other commercial systems which became more common than XNS itself, including Ungermann-Bass Net/One, Novell NetWare, and Banyan VINES.
It was developed at Xerox PARC in the early 1980s, based heavily on the earlier PARC Universal Packet (PUP) protocol suite done there in the late 1970s; some of the protocols in the XNS suite were lightly modified versions of the ones in the PUP suite. XNS was intended to be a commercial descendant of the research/development oriented PUP.
Contents |
[edit] Basic internetwork protocol
The main internetwork layer protocol was IDP, the Internet Datagram Protocol. IDP is a close descendant of PUP's internetwork protocol, and roughly corresponds to the Internet Protocol (IP) layer in TCP/IP.
Designed from the outset to complement the Ethernet Local Area Network (also developed by Xerox), a full XNS network address consisted of a 32-bit network number, a 48-bit host address, and a 16-bit socket number; the host address was usually the host's MAC address. The network number had a particular special value which meant 'this network', for use by hosts which did not (yet) know their network number.
Unlike TCP/IP, socket fields are part of the full network address in the IDP header, so that upper-layer protocols did not need to implement their own demultiplexing; IDP also supplied packet types (again, unlike IP). IDP also contained a checksum covering the entire packet, but it was optional, not mandatory.
IDP packets were up to 576 bytes long (including the 30 byte IDP header), smaller than IP (which required all hosts to support at least 576, but supports packets of up to 65K bytes). Individual PUP host pairs on a particular network might use larger packets, but no PUP router was required to handle them, and no mechanism was defined to discover if the intervening routers would support larger packets. Also, packets could not be fragmented, as in IP.
XNS also included a simple echo protocol at the internetwork layer, similar to IP's ping, but operating at a lower level.
RIP, a descendant of PUP's Gateway Information Protocol, was used as the router information-exchange system, and (slightly modified to match the syntax of addresses of other protocol suites), remains in use today in other protocol suites.
[edit] Transport layer protocols
There were two primary transport layer protocols, both very different from their PUP predecessor:
- Sequenced Packet Protocol (SPP) was an acknowledged transport protocol, analogous to TCP; one chief technical difference is that the sequence numbers count the packets, and not the bytes as in TCP and PUP's BSP; it was the direct antecedent to Novell's IPX/SPX.
- Packet Exchange Protocol (PEP) was a connectionless non-reliable protocol similar in nature to UDP (and the antecedent to Novell's PXP).
XNS, like PUP, also used EP, the Error Protocol, as a reporting system for problems such as dropped packets. This provided a unique set of packets which could be filtered to look for problems.
[edit] Applications
In the original Xerox concept, applications protocols such as remote printing, filing, etc ran above a remote procedure call protocol named Courier. However, these Xerox applications protocols never made it into wide use, and most commercial offerings using XNS, such as Novell Netware, defined their own applications protocols.
[edit] Impact
Last used by Xerox for communication with their DocuTech 135 Publishing System, XNS specifically is no longer in use, due to the all-pervasiveness of IP. However, it played an important role in the development of networking technology in the 1980s, by forcing software and hardware vendors to seriously consider the need for computing platforms to support more than one network protocol stack simultaneously.
In particular, it helped to validate the design of the 4.2BSD network subsystem by providing a second protocol suite, one which was significantly different from the Internet protocols; by implementing both stacks in the same kernel, the Berkeley researchers demonstrated that the design was suitable for more than just IP. (Some modifications were eventually necessary to support the full range of OSI protocols.)
[edit] References
- Xerox System Integration Standard - Internet Transport Protocols (Xerox, Stamford, 1981)
- Xerox System Integration Standard - Courier: The Remote Procedure Call Protocol (Xerox, Stamford, 1981)
