_____                   _                  _____            _____       _ 
  |     |___ _____ ___ _ _| |_ ___ ___ ___   |  _  |___ ___   | __  |___ _| |
  |   --| . |     | . | | |  _| -_|  _|_ -|  |     |  _| -_|  | __ -| .'| . |
  |_____|___|_|_|_|  _|___|_| |___|_| |___|  |__|__|_| |___|  |_____|__,|___|
  a newsletter by |_| j. b. crawford               home archive subscribe rss

>>> 2020-12-22 Xerox brand network product (PDF)

While I have more radio topics to talk about, I think it'd be good to take a break from the airwaves and get back to basics with computer topics. I've mentioned before that one of the things I really enjoy are pre-IP network protocols, from the era when the design of computer networks was still a competitive thing with a variety of different ideas. One of the most notable of the pre-IP protocols, as I've mentioned before, is the Xerox Network System or XNS.

It is an oversimplification, but not entirely wrong, to say that XNS was created by Bob Metcalfe, the creator of Ethernet, so that he had something to use Ethernet for. In fact, XNS is an evolution of an earlier protocol (called PUP but more adorably written Pup) which was designed by Metcalfe and David Boggs for use with Ethernet as a demonstration. For reasons that are difficult to understand now but tied to the context of the time, Xerox was not particularly enthusiastic about Ethernet as a technology and Metcalfe found himself fighting to gain traction for the technology, including by developing higher-level protocols which took advantage of its capability.

This bit of history tells us two important things:

  1. The widespread misunderstanding that IP and Ethernet are somehow designed for each other is quite incorrect---in fact, if Ethernet "naturally" goes with another protocol and vice versa, that stack is Ethernet and XNS.
  2. As has been seen many times in computer history, XNS's lack of popularity with its corporate sponsors was, ironically, a major factor in its success.

Xerox's roots in more academic research (Metcalfe and the Xerox PARC) and Xerox's lack of vigor in commercializing the technology essentially lead to it being openly published as a research paper and then Xerox not doing a whole lot else with it (using it only for a couple of less important projects). XNS was viewed as academic rather than commercial, and that's how it escaped.

Xerox's lack of motivation to pursue the project was not shared by the rest of the industry. After XNS was published, a number of other software vendors, and especially designers of Network Operating Systems, picked it up as the basis of their work. The result is that XNS was used in a variety of different network systems by different vendors (although not always by that name), and that it became quite influential in the design of later protocols because of its being a "common denominator" between many protocols based on it.

IP and XNS are largely contemporaries, the two having been under active development during the same span of a few years. Both appear to incorporate ideas from the other, in part because IP originated out of ARPANET which was one of the biggest network projects of the time and the designers of XNS were no doubt keeping an eye on it. There were also a couple of personal relationships between designers of XNS and designers of IP, so it's likely there were some notes exchanged. This is a powerful part of how these early standards form, people working in parallel and adopting similar ideas.

So let's talk about XNS. Wikipedia starts its explanation of XNS by saying that "In comparison to the OSI model's 7 layers, XNS is a five-layer system, like the later Internet protocol suite." The "later" here is a little odd and depends on where exactly you set the milestones, but I like this start to the design explanation because it emphasizes that both XNS and IP have little to do with the OSI model.

As I like to repeat to myself under my breath on a daily basis, the widespread use of the OSI model as a teaching device in computer networking is a mistake. It leads students and instructors of computing alike to act as if the IP stack is somehow defined by or even correlates to the OSI stack. This is not true. The OSI model defines the OSI network protocols, which are an independent network architecture that ultimately failed to gain the traction that IP did. IP is different from the OSI stack in a number of intentional and important ways, which makes attempts to describe the IP stack in terms of the OSI model intrinsically foolish, and worse, confusing and misleading to students.

Anyway, given that the XNS stack has five layers (and NOT seven like OSI adherents feel the need to tell you), what are those layers?

  1. Physical (not defined by XNS, generally Ethernet)
  2. Internal Transport
  3. Interprocess Communications
  4. Resource Control
  5. Application (not defined by XNS)

Layer 1 of XNS is the internet datagram protocol, or IDP. If this sounds kind of similar to IP, it is, and beyond just the naming. There are some important differences though, which are illuminating when we look at the eccentricities of IP.

To start with, IDP makes use of Ethernet addressing. Sparing the details of bits and offsets, IDP network addresses consist of the Ethernet (MAC) address of the interface, a network number (specified by the router), and a socket number. While the MAC address serves as a globally unique identifier, the network number is useful for routing (so that routers need not know the addresses of every host in every network). The socket number identifies services within a given host, replacing the ports that we use in the IP stack.

That difference is particularly interesting to highlight: IP chooses to identify only the host, leaving identification of specific services or sockets to higher-level network protocols like TCP. In contrast, XNS identifies individual sockets within IDP. As usual it's hard to say that either method is "better" or "worse," but the decision IP made certainly leads to some odd situations with regards to protocols like ICMP that do not provide socket-level addressing.

Another interesting difference is that, while IDP allows for checksums, it does not require them. This is an allowance for the fact that Ethernet provides checksums, making bit-errors on Ethernet networks exceedingly rare. In contrast, IP requires a checksum (but curiously only over the header), which is effectively wasted computation on media like Ethernet that already provide an integrity check.

To bring my grousing about IP full circle, these differences reflect two things: First, IP was designed with no awareness of the addressing scheme that is now virtually always used at a lower layer. Second, IP has a redundant integrity scheme. Both are simply results of IP having not been designed for a lower layer that provides these, while XNS was.

At the next layer, the interprocess communications layer, XNS provides us with options that will once again look fairly familiar. Sequenced packet protocol (SPP) provides reliable delivery, while packet exchange protocol (PEP) provides unreliable delivery. The design of these protocols is largely similar to TCP and UDP, respectively, but of course with the notable difference that there is no concept of port numbers since that differentiation is already provided by IDP.

As more of a special case, there is the XNS error protocol, which is used to deliver certain low-level network information in a way analogous to (but simpler than) ICMP. The error protocol enjoys the advantage, compared to ICMP, of being easily correlated to and delivered to specific sockets, since it has the socket number information from IDP. This means that, for example, an XNS implementation of "ping" on Linux would not require root (or rather raw socket) privileges.

The resource control layer in XNS is somewhat ill-defined, but was implemented for example by Novell as essentially a service-discovery scheme filling a similar role to UPnP, mDNS, etc. today. Resource control was not necessary for the operation of an XNS network, but was useful for autoconfiguration scenarios and implemented that way by many vendors. We can thus question whether or not resource control really counts as a "layer" since it was not, in practice, generally used to encapsulate the next layer, but everyone who teaches with the OSI model is guilty of far greater sins, so I will let that slide. Sometimes it is useful to view a protocol as occupying a "lower layer" even if it does not encapsulate traffic, if it fulfills a utility function used for connection setup. I am basically making excuses for ARP, here.

Application protocols are largely out of scope, but it is worth noting that Xerox did design application layer protocols over XNS, which consisted primarily of remote procedure call. This makes sense, as RPC was a very popular concept in networking at the time, likely because it was closely analogous to how terminals interacted with mainframes. Nowadays, of course, RPC tends to make everyone slightly nauseous. Instead we have REST, which is analogous to how something, uh, er, nevermind.

XNS is now largely forgotten, as all of the systems that implemented it failed to compete with IP's ARPANET-born takeover. That said, it does have one curious legacy still with us today. Routing Information Protocol (RIP), commonly used as a "lowest common denominator" interior gateway protocol, was apparently originally designed as part of XNS and later ported to IP.