Difference between revisions of "PARC Universal Packet"

From Computer History Wiki
Jump to: navigation, search
(Some implementations.)
(Application protocols: +EFTP)
 
(6 intermediate revisions by 2 users not shown)
Line 11: Line 11:
 
The main internet layer protocol was PUP, which roughly corresponds to the [[Internet Protocol]] (IP) layer in TCP/IP. A full PUP [[network address]] consisted of an 8-bit network number, an 8-bit host number, and a 16-bit socket number. The network number had a particular special value which meant 'this network', for use by hosts which did not (yet) know their network number.
 
The main internet layer protocol was PUP, which roughly corresponds to the [[Internet Protocol]] (IP) layer in TCP/IP. A full PUP [[network address]] consisted of an 8-bit network number, an 8-bit host number, and a 16-bit socket number. 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 were part of the full network address in the PUP [[header]], so that upper-layer protocols did not need to implement their own demultiplexing; PUP also supplied packet types (again, unlike IP). Also, an optional 2-byte checksum covered the entire [[packet]].
+
Unlike TCP/IP, socket fields were part of the full network address in the PUP [[header]], so that upper-layer protocols did not need to implement their own demultiplexing; PUP also supplied packet types (again, unlike IP). Also, an optional 2-byte [[checksum]] covered the entire [[packet]].
  
PUP packets were up to 554 bytes long (including the 20 byte PUP header), and the checksum. This was a smaller packet size than IP, which requires all hosts to support at least 576 (but supports packets of up to 65K bytes, if the hosts support them); individual PUP host pairs on a particular network might use larger packets, but no PUP [[router]] was required to handle them. Unlike in IP, larger packets could be fragmented.
+
PUP packets were up to 554 bytes long (including the 20 byte PUP header), and the checksum. This was a smaller packet size than IP, which requires all hosts to support at least 576 (but supports packets of up to 65K bytes, if the hosts support them); individual PUP host pairs on a particular network might use larger packets, but no PUP [[router]] was required to handle them. Unlike in IP, larger packets could not be fragmented (except locally).
  
 
A protocol named the ''Gateway Information Protocol'' (a remote ancestor of [[Routing Information Protocol|RIP]]) was used as both the [[routing protocol]] (the router information-exchange system), and for hosts to discover routers.
 
A protocol named the ''Gateway Information Protocol'' (a remote ancestor of [[Routing Information Protocol|RIP]]) was used as both the [[routing protocol]] (the router information-exchange system), and for hosts to discover routers.
Line 27: Line 27:
 
==Application protocols==
 
==Application protocols==
  
PUP supported a large number of applications. Some of them, such as [[Telnet]] and [[File Transfer Protocol]], were basically the same protocols as used on the [[ARPANET]] (much as occurred with the TCP/IP suite).
+
PUP supported a large number of applications. Some of them, such as [[Telnet]] and [[File Transfer Protocol]], were basically the same protocols as used on the [[ARPANET]] (much as occurred with the TCP/IP suite). One very early one was [[EFTP]], which provided file transfer functionality in very spare/scant implementation environments.
  
 
Others were novel, including protocols for printer spooling, copying disk packs, page-level remote access to file servers, name lookup, remote management, etc (although some of these capabilities had been seen before, e.g. the ARPANET already made heavy use of remote management for controlling the [[Interface Message Processor]]s which made it up).
 
Others were novel, including protocols for printer spooling, copying disk packs, page-level remote access to file servers, name lookup, remote management, etc (although some of these capabilities had been seen before, e.g. the ARPANET already made heavy use of remote management for controlling the [[Interface Message Processor]]s which made it up).
Line 43: Line 43:
 
* [[TOPS-20]]
 
* [[TOPS-20]]
 
* [[WAITS]]
 
* [[WAITS]]
 +
* [[4.2BSD]]
 
* [[MINITS]]
 
* [[MINITS]]
 +
* [[C Gateway]]
  
 
==Further reading==
 
==Further reading==
Line 55: Line 57:
 
* Edward A. Taft, ''Pup Error Protocol'' (Xerox Parc, Palo Alto, July, 1978 and October, 1975)
 
* Edward A. Taft, ''Pup Error Protocol'' (Xerox Parc, Palo Alto, July, 1978 and October, 1975)
 
* Jon A. Hupp, ''Pup Network Constants'' (Xerox Parc, Palo Alto, July, 1979)
 
* Jon A. Hupp, ''Pup Network Constants'' (Xerox Parc, Palo Alto, July, 1979)
 +
 +
==External links==
 +
 +
* [https://xeroxalto.computerhistory.org/_cd8_/pup/.index.html PUP] - Documentation in the Xerox PARC archives
  
 
[[Category: Network Protocols]]
 
[[Category: Network Protocols]]
 +
[[Category: Xerox]]

Latest revision as of 14:34, 16 November 2024

The PARC Universal Packet (commonly abbreviated to PUP, although the original documents usually use Pup) was one of the two earliest internetworking protocol suites; it was created by researchers at Xerox PARC in the mid-1970s.

(Technically, the name "PUP" only refers to the internetworking layer protocol, but it is also applied to the whole protocol suite.) The entire suite provided path selection and packet delivery, as well as higher level functions such as a reliable byte stream, along with numerous applications.

The origins of the PUP suite lie in two developments; in the same events in the early 1970s as the very earliest stage of the development of TCP/IP, and the creation of the Ethernet local area network at PARC. However, the development of PUP split off because Xerox PARC wished to move ahead with implementation, for in-house use. The fundamental design of the PUP suite was substantially complete by 1974.

In the 1980s Xerox used PUP as the base for the Xerox Network Services (XNS) protocol suite; some of the protocols in the XNS suite (e.g. the Internetwork Datagram Protocol) were lightly modified versions of the ones in the PUP suite, but others are quite different, reflecting the experience gained with PUP.

Basic internetwork protocol

The main internet layer protocol was PUP, which roughly corresponds to the Internet Protocol (IP) layer in TCP/IP. A full PUP network address consisted of an 8-bit network number, an 8-bit host number, and a 16-bit socket number. 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 were part of the full network address in the PUP header, so that upper-layer protocols did not need to implement their own demultiplexing; PUP also supplied packet types (again, unlike IP). Also, an optional 2-byte checksum covered the entire packet.

PUP packets were up to 554 bytes long (including the 20 byte PUP header), and the checksum. This was a smaller packet size than IP, which requires all hosts to support at least 576 (but supports packets of up to 65K bytes, if the hosts support them); individual PUP host pairs on a particular network might use larger packets, but no PUP router was required to handle them. Unlike in IP, larger packets could not be fragmented (except locally).

A protocol named the Gateway Information Protocol (a remote ancestor of RIP) was used as both the routing protocol (the router information-exchange system), and for hosts to discover routers.

PUP also included a simple echo protocol at the internetwork layer, similar to IP's ping, but operating at a lower level.

Transport layer protocols

To establish a transport connection, two protocols came into play. The first, the Rendezvous and Termination Protocol (RTP), which was used to initiate communication between two entities, as well as manage and terminate the connection. The second was the primary transport layer protocol, Byte Stream Protocol (BSP), which was analogous to TCP.

Once RTP had started the connection, BSP took over and managed the data transfer. Like TCP, BSP's semantics and operation were in terms of bytes; this was discarded in favour of packets for the equivalent protocol in XNS, Sequenced Packet Protocol (SPP).

Application protocols

PUP supported a large number of applications. Some of them, such as Telnet and File Transfer Protocol, were basically the same protocols as used on the ARPANET (much as occurred with the TCP/IP suite). One very early one was EFTP, which provided file transfer functionality in very spare/scant implementation environments.

Others were novel, including protocols for printer spooling, copying disk packs, page-level remote access to file servers, name lookup, remote management, etc (although some of these capabilities had been seen before, e.g. the ARPANET already made heavy use of remote management for controlling the Interface Message Processors which made it up).

Impact

In showing that internetworking ideas were feasible, in being influential in the early work on TCP/IP, and as the foundation for the later XNS protocols, PUP was very influential. However, its biggest impact was probably as a key component of the 'office of the future' model first demonstrated at Xerox PARC; that demonstration would not have been anything like as powerful as it was without all the capabilities that a working internetwork provided.

The Gateway Information Protocol's descendant, RIP, (somewhat modified to match the syntax of addresses of other protocol suites), remains in wide use today in other protocol suites. One version of RIP served as one of the initial so-called interior gateway protocols for the growing Internet, before the arrival of the more modern OSPF and IS-IS. It is still in use as an interior routing protocol, in small sites with simple requirements.

Implementations

Further reading

  • David R. Boggs, John F. Shoch, Edward A. Taft, Robert M. Metcalfe, Pup: An Internetwork Architecture (IEEE Transactions on Communications, COM-28(4):612-624, April, 1980)

Reference

  • Edward A. Taft, Robert M. Metcalfe, Pup Specifications (Xerox Parc, Palo Alto, June, 1978 and October, 1975)
  • Edward A. Taft, State Machine for Rendezvous/Termination Protocol (Xerox Parc, Palo Alto, July, 1978 and October, 1975)
  • Edward A. Taft, Naming and Addressing Conventions for Pup (Xerox Parc, Palo Alto, July, 1978 and October, 1975)
  • Edward A. Taft, Pup Error Protocol (Xerox Parc, Palo Alto, July, 1978 and October, 1975)
  • Jon A. Hupp, Pup Network Constants (Xerox Parc, Palo Alto, July, 1979)

External links

  • PUP - Documentation in the Xerox PARC archives