Editing Xerox Network Systems (section)

==Description==

===Overall design===
In comparison to the [[OSI model]]'s 7 layers, XNS is a five-layer system,{{sfn|Stephens|1989|p=15}} like the later [[Internet protocol suite]].

The Physical and Data Link layers of the OSI model correspond to the Physical layer (layer 0) in XNS, which was designed to use the transport mechanism of the underlying hardware and did not separate the data link. Specifically, XNS's Physical layer is really the [[Ethernet]] [[local area network]] system, also being developed by Xerox at the same time, and a number of its design decisions reflect that fact.{{sfn|Stephens|1989|p=15}} The system was designed to allow Ethernet to be replaced by some other system, but that was not defined by the protocol (nor had to be).

The primary part of XNS is its definition of the Internal Transport layer (layer 1), which corresponds to OSI's Network layer, and it is here that the primary internetworking protocol, IDP, is defined. XNS combined the OSI's Session and Transport layers into the single Interprocess Communications layer (layer 2). Layer 3 was Resource Control, similar to the OSI's Presentation.{{sfn|Stephens|1989|p=15}}{{sfn|cisco}}

Finally, on top of both models, is the Application layer, although these layers were not defined in the XNS standard.{{sfn|Stephens|1989|p=15}}

===Basic internetwork protocol===
The main [[internetwork]] layer [[Network protocol|protocol]] is the '''Internet Datagram Protocol''' ('''IDP'''). IDP is a close descendant of Pup's [[PARC Universal Packet#Basic internetwork protocol|internetwork protocol]], and roughly corresponds to the [[Internet Protocol]] (IP) layer in the Internet protocol suite.{{sfn|Stephens|1989|p=15}}

IDP uses Ethernet's 48-bit address as the basis for its own [[network address]]ing, generally using the machine's [[MAC address]] as the primary unique identifier. To this is added another 48-bit address section provided by the networking equipment; 32 bits are provided by [[Router (computing)|router]]s to identify the network number in the internetwork, and another 16 bits define a socket number for service selection within a single host. The network number portion of the address also includes a special value which meant "this network", for use by hosts which did not (yet) know their network number.{{sfn|cisco}}

Unlike TCP/IP, socket numbers are part of the full network address in the IDP header, so that upper-layer protocols do not need to implement demultiplexing; IDP also supplies packet types (again, unlike IP). IDP also contains a checksum covering the entire packet, but it is optional, not mandatory. This reflects the fact that LANs generally have low-error rates, so XNS removed error correction from the lower-level protocols in order to improve performance. Error correction could be optionally added at higher levels in the protocol stack, for instance, in XNS's own SPP protocol. XNS was widely regarded as faster than IP due to this design note.{{sfn|Stephens|1989|p=15}}

In keeping with the low-latency LAN connections it runs on, XNS uses a short packet size, which improves performance in the case of low error rates and short turnaround times. IDP packets are up to 576 bytes long, including the 30 byte IDP [[Header (computing)|header]].{{sfn|cisco}} In comparison, IP requires all hosts to support at ''least'' 576, but supports packets of up to 65K bytes. Individual XNS host pairs on a particular network might use larger packets, but no XNS router is required to handle them, and no mechanism is defined to discover if the intervening routers support larger packets. Also, packets can not be fragmented, as they can in IP.

The [[Routing Information Protocol]] (RIP), a descendant of Pup's ''Gateway Information Protocol'', is 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, such as the Internet protocol suite.{{sfn|cisco}}

XNS also implements a simple echo protocol at the internetwork layer, similar to IP's [[Ping (networking utility)|ping]], but operating at a lower level in the networking stack. Instead of adding the ICMP data as payload in an IP packet, as in ping, XNS's echo placed the command directly within the underlying IDP packet.{{sfn|cisco}} The same might be achieved in IP by expanding the ICMP [[IPv4#Protocol|Protocol]] field of the IP header.

===Transport layer protocols===
There are two primary transport layer protocols, both very different from their Pup predecessor:

* '''Sequenced Packet Protocol''' ('''SPP''') is an acknowledgment transport protocol, with a 3-way handshake analogous  to [[Transmission Control Protocol|TCP]]; one chief technical difference is that the sequence numbers count  packets, and not the bytes as in TCP and PUP's BSP; it is the direct antecedent to [[Novell NetWare|Novell's]] [[IPX/SPX]].
* '''Packet Exchange Protocol''' ('''PEP''') is a connectionless non-reliable protocol similar in nature to [[User Datagram Protocol|UDP]] and the antecedent to [[Novell NetWare|Novell's]] PXP.

XNS, like Pup, also uses '''EP''', the ''Error Protocol'', as a reporting system for problems such as dropped packets. This provided a unique set of packets which can be filtered to look for problems.{{sfn|cisco}}

===Application protocols===

====Courier RPC====
In the original Xerox concept, application protocols such as remote printing, filing, and mailing, etc., employed a [[remote procedure call]] protocol named '''Courier'''.  Courier contained primitives to implement most of the features of Xerox's [[Mesa (programming language)|Mesa programming language]] function calls. Applications had to manually serialize and de-serialize function calls in Courier; there was no automatic facility to translate a function activation frame into an RPC (i.e. no "RPC compiler" was available). Because Courier was used by all applications, the XNS application protocol documents specified only courier function-call interfaces, and module+function binding tuples. There was a special facility in Courier to allow a function call to send or receive bulk data.{{sfn|cisco}}

Initially, XNS service location was performed via broadcasting remote procedure-calls using a series of expanding ring broadcasts (in consultation with the local router, to get networks at increasing distances.) Later, the Clearinghouse Protocol 3-level directory service was created to perform service location, and the expanding-ring broadcasts were used only to locate an initial Clearinghouse.{{sfn|cisco}}

Due to its tight integration with Mesa as an underlying technology, many of the traditional higher-level protocols were not part of the XNS system itself. This meant that vendors using the XNS protocols all created their own solutions for [[file sharing]] and [[Printer (computing)|printer]] support. While many of these 3rd party products theoretically could talk to each other at a packet level, there was little or no capability to call each other's application services. This led to complete fragmentation of the XNS market, and has been cited as one of the reasons that IP easily displaced it.{{sfn|Stephens|1989|p=15}}

====Authentication====
The XNS protocols also included an Authentication Protocol and an Authentication Service to support it. Its "Strong credentials" were based on the same [[Needham–Schroeder protocol]] that was later used by [[Kerberos (protocol)|Kerberos]]. After contacting the authentication service for credentials, this protocol provided a lightweight way to digitally sign Courier procedure calls, so that receivers could verify the signature and authenticate senders over the XNS internet, without having to contact the Authentication service again for the length of the protocol communication session.<ref name=XSIS098404 />

====Printing====
Xerox's printing language, [[Interpress]], was a binary-formatted standard for controlling laser printers.  The designers of this language, John Warnock and Chuck Geschke, later left Xerox PARC to start [[Adobe Systems]].  Before leaving, they realized the difficulty of specifying a binary print language, where functions to serialize the print job were cumbersome and which made it difficult to debug errant printing jobs.  To realize the value of specifying both a programmable and easily debug-able print job in ASCII, Warnock and Geschke created the Postscript language as one of their first products at Adobe.

====Remote Debug Protocols====
Because all 8000+ machines in the Xerox corporate Intranet ran the Wildflower architecture (designed by Butler Lampson), there was a remote-debug protocol for microcode.  Basically, a peek and poke function could halt and manipulate the microcode state of a C-series or D-series machine, anywhere on earth, and then restart the machine.

Also, there was a remote debug protocol for the world-swap debugger.<ref>
{{cite web
| title = World-stop debuggers
| url = https://people.ece.ubc.ca/gillies/pages/note1.html
| date = 1999-01-25
| access-date = 2013-07-05}}</ref>  This protocol could, via the debugger "nub", freeze a workstation and then peek and poke various parts of memory, change variables, and continue execution.  If debugging symbols were available, a crashed machine could be remote debugged from anywhere on earth.