This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improve this article by introducing more precise citations. (January 2013)

Xerox Network Services (XNS) is a protocol suite developed by Xerox within the Xerox Network Systems Architecture. It provided general purpose network communications, internetwork routing and packet delivery, including 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.

XNS was developed at Xerox PARC in the early 1980s, based heavily on the earlier (and extremely influential) 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. The protocol suite specifications were placed in the public domain.

Being in the public domain, XNS became a canonical local area networking protocol in the 1980s, copied to various degrees by practically all networking systems in use into the 1990s. It had little impact on TCP/IP, however. During the 1980s XNS was used by 3Com and, with modifications, by a number of other commercial systems which became more common than XNS itself, including Ungermann-Bass Net/One, Novell NetWare, and Banyan VINES.

Basic internetwork protocol [edit]

The main internetwork layer protocol was the Internet Datagram Protocol (IDP). 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. This led to the decision to use Ethernet's 48-bit address as the basis for its own network addressing, generally using the machine's MAC address as the primary unique identifier. The full 12-byte address also included a 32-bit network number for routing purposes, and a 16-bit socket number for service selection. The network number also had a special value which meant 'this network', for use by hosts which did not (yet) know their network number.

Unlike TCP/IP, socket numbers are part of the full network address in the IDP header, so that upper-layer protocols did not need to implement 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. In comparison, IP 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.

The Routing Information Protocol (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.

Transport layer protocols [edit]

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.

Applications [edit]

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.

Impact [edit]

Last used by Xerox for communication with the DocuTech 135 Publishing System, XNS is no longer in use, due to the ubiquity of IP. However, it played an important role in the development of networking technology in the 1980s, by influencing 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, Berkeley researchers demonstrated that the design was suitable for more than just IP. Some modifications were eventually necessary to support the full range of Open Systems Interconnection (OSI) protocols.

References [edit]

• Xerox System Integration Standard - Internet Transport Protocols (Xerox, Stamford, 1981)
• Xerox System Integration Standard - Courier: The Remote Procedure Call Protocol (Xerox, Stamford, 1981)

We're sorry, but there's no news about "Xerox Network Systems" right now.