Wednesday, 9 November 2011

Xerox Network Systems

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 Interconnect (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


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), 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 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, but 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.
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


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


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


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.



All about: Ajax (programming)ARPANETAustpac, Berners-LeeBulletin board systemCYCLADES, Data communicationDCN, Digital divideDot-com bubble, E-mail, FidoNetHistory of the InternetHistory of the World Wide WebInternetInternet2, IBM Systems Network Architecture,  Internet access worldwide, ICANN, Internet Assigned Numbers Authority,  Internet capitalization conventionsInternet Engineering Task ForceInternet governance, InterNIC Internet Protocol SuiteIPSANET, Len Kleinrock, Leonard Kleinrock, Mobile WebNational Physical Laboratory UK,  NSFNetPacket switchingPacket-switched networkPARC Universal Packet, RANDSearch engine (computing), Simple Mail Transfer ProtocolSociology of the Internet,  TelenetTymnet, UsenetUUCPWeb standards, World Wide Web,  X.25

No comments: