The original spec, MIT AIM 628, is sometimes not totally clear, and partly out-of-date (e.g. for the link layer and down). What is below might perhaps not be clearer, but more succinct. The real definition is in the behaviour of the implementations - “use the source, Luke!” ¹⁾

For another list of Chaosnet protocols, see the Computer History Wiki.

Chaosnet addresses are 16 bits: 8 bits for subnet (MSB), 8 bits for host (LSB). Neither byte can be zero for an individual host, but the address 0 is used for broadcast (on the local subnet). They are almost always presented in octal.

Notes:

• There are no port numbers to use for connecting to a service, instead a “contact name” (ASCII) in the packet data is used, see below.
• The source and destination index fields identify the connection (together with source and destination addressess).
• The data length field has 12 bits so data could be 4096 bytes, but for historical backwards compatibility, data length is restricted to 488 bytes. (The original Chaos hardware packets were limited to 4032 bits, of which 16 bytes are the Chaosnet header.)
• The forwarding counter has 4 bits so the maximum distance a packet is transported is 16 hops.
• Packet number and acknowledgement fields refer to packets, as opposed to TCP which refers to data bytes.
• The acknowledgement field has the highest packet number which has been delivered to the user (cf receipts in OPN and STS packets).

Describe “hardware trailer” (cf Section 2.5 of MIT AI Memo 628).

The opcodes, briefly:

• RFC (request for connection) is sent from the client to the server to start a connection. The data part of the packet starts with the contact name (e.g. “NAME”) which is optionally followed by a space and protocol-specific arguments (e.g. “/W VICTOR”). The destination index should be zero.
• OPN (open) is sent as a response to an RFC in order to start a stream protocol. The source index is initialized here, and the data initializes the local window size (16 bits) and a “receipt”, which is the highest packet number received so far (probably the RFC pkt number) but not necessarily delivered to the user process.
• CLS (close) is sent to reject an RFC, or to close the connection at other times. The data contains a message intended for the user, e.g. “No server for this contact name”. The connection is immediately closed at the sender end.
• FWD (forward) is sent in response to an RFC, to reject the connection but tell who should be contacted instead (the forwarding address is in the Acknowledgement field).
• ANS (answer) is sent in response to an RFC when the protocol is a “simple” transactional protocol (cf. UDP). The data contains the response data, and no connection is established.
• SNS (sense) is sent to ask the other end to send a STS response:
• STS (status) is sent to inform the other end about the current local window size and the “receipt”, which is the highest packet number received so far (probably the RFC pkt number) but not necessarily delivered to the user process.
• RUT (routing information) is broadcast every 15 seconds, containing information about which subnets the sender is aware of and the “cost” of reaching them. Cf RIP.
• LOS (lose) conveys an error message (cf CLS above), in response to various error conditions. If there was a connection, it is now closed.
• EOF (end-of-file) is used in various application protocols to indicate the end of a record of information, e.g. in a file transfer.
• UNC (uncontrolled data) is used to send data without Chaosnet flow-control, e.g. to encapsulate another protocol (maybe UDP or TCP or PUP).
• BRD (broadcast) is used to send a “broadcast RFC” to specific subnets (not limited to the local subnet). Recipients of a BRD packet treat it as an RFC, and the sender deals with the responses as it sees fit.
• DAT (data) is used to send data. Opcodes 0200-0277 are used for 8-bit data, while 0300-0377 are used for 16-bit data (in network order).

What is described here is not only “proper” link layers, but more generally in the sense of means of transporting individual Chaosnet packets.

Chaosnet packets are sent using the standard Ethernet protocol number (or EtherType) 0x0804. No “hardware trailer” is used, since the Ethernet header does the corresponding job (it includes source and destination hardware addresses, and a checksum). Packets are sent in “big-endian” (network) order.

When configured to use Ethernet, ARP packets are sent and received in a standard manner to find ethernet-chaos mappings, with the protocol type for Chaosnet (0x0804) and address length 2.

Chaosnet packets are sent in IP or IPv6 packets, using the standard IP protocol number 16. Packets are sent in “big-endian” (network) order (sometimes with a “hardware trailer”).

Chaosnet addresses are independent of IP/IPv6 addresses, but can be mapped to IP/IPv6 addresses either individually, or for a whole subnet (see Cisco's implementation, the PDP-10/X project, or cbridge). A version of TOPS-20 implemented IP encapsulation.

Note that Chaosnet addresses where the host byte is 0xFF (which is legal by the specification) cannot be used with subnet mappings on IPv4, since they map to the broadcast address.

Chaosnet packets are encapsulated in UDP packets, using a four-byte header (version=1, function=1, 0, 0), and with a “hardware trailer” containing the destination and source addresses and an Internet Checksum.

In the current implementation (for klh10 and in cbridge), packets are sent in "little-endian", i.e. with the least significant byte of a 16-bit word before the most significant byte. (I'm really sorry about this, and might develop version 2 of the protocol with the only change being big-endian byte order.)

The Chaos-over-UDP encapsulation protocol has also been implemented in Python and Common Lisp by Joe Oswald

Chaosnet packets are sent over TLS, with a 2-byte header (length MSB, length LSB). Packets are sent in “big-endian” order, with a “hardware trailer”.

There are different reasons to want to use TLS:

• one is for improved security (confidentiality, authenticity), and
• another is for clients which don't have externally reachable and stable IP addresses and thus are not reachable by UDP. TCP would suffice, but since clients don't have stable IPs, it would be hard to firewall - instead you need an open server which is not so nice/secure. TLS helps with authentication.

When using TLS, some certificate infrastructure is needed. There is one for the Global Chaosnet.

Chaosnet packets are sent over a named Unix socket (typically /var/tmp/chaosd_server), with a 4-byte header (length MSB, length LSB, 1, 0). Packets are sent in “big-endian” (network) order, with a “hardware trailer”.

This has been implemented in usim (the CADR emulator) and in Python by Joe Oswald.

There are two transport protocols.

To the right is an approximate state diagram. The green box is where it starts, the red where it ends. Blue and brown text is sent by one end and the other. (Note that LSN is not really a packet sent over the network.)

In a simple protocol, an RFC is sent and the response is normally an ANS containing the answer. The response can also be CLS or FWD.

The RFC is retransmitted until a response is received, or some timeout occurs. The response is “uncontrolled” in the sense that it is not retransmitted, but since the RFC is retransmitted a new response will (probably) be sent.

In a stream protocol, an RFC is sent, and the response is normally an OPN which confirms the connection and informs of the local window size. The initiator then responds with an STS to inform of its window size, and then the connection is open.

Window management is done using the receipt and window-size values in STS packets. A sender is expected to respect the remote window size, of course. And retransmissions occur, for “controlled” packets (RFC, OPN, EOF, BRD, and DAT).

The connection is closed by a CLS (or in case of an error, by LOS, or a timeout).

Many of the protocols are informally described in Section 5 of MIT AI Memo 628: Chaosnet, by David A. Moon (webified here). Some are specified in RFCs, while some exist only in source code.

Below, “simple” means a connectionless protocol which returns an ANS packet with data, and “stream” means that a connection is established (using OPN and STS).

For many protocols (e.g. FINGER, NAME, and FILE, see below), a special LISPM 8-bit character set us used ²⁾, which includes some greek letters, arrows etc, and notably maps carriage return, linefeed, formfeed and tab to character codes +0200.

All hosts are required to respond to the simple protocol STATUS. The response indicates

• that the host is “alive”
• what name the host likes to be called - this could be a “pretty name” rather than an official host name
• information about what subnets the host is connected to, and the number of packets sent/received/etc for each subnet.

A “unidirectional” routing protocol is implemented using RUT packets, which are sent by routers (or “bridges” in Chaosnet lingo). Packets contain the routing info for up to 122 (decimal) subnets. For each subnet, the next bridge address (or the local interface nr) and the cost is announced. The cost increases by 1 every 4 seconds, up to a maximum value (for most systems, 512, but for others, 1024).

DUMP-ROUTING-TABLE is a simple protocol which returns information on routing tables up to subnet 0172 (122 decimal). See e.g. Lisp code for details. Not implemented by ITS.

TIME returns the number of seconds since midnight Greenwich Mean Time, Jan 1, 1900 as a 32-bit number in four 8-bit bytes, least-significant byte first. To convert to standard Unix time, subtract 2208988800 (see RFC 868).

UPTIME retuns the uptime in 1/60ths of seconds, 4 bytes, lsb first.

ECHO reads DAT packets and sends them back, until an EOF packet is received (or the connection is closed).

BABEL sends the string

" !"#$%&'()*+,-.//0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}"

over and over again until the stream is closed.

These protocols use the LISPM character set mentioned above.

NAME is a stream protocol.

1. If no arguments are given, it returns a list of logged-in users and brief information about them.
2. If an argument is given, it returns information about that particular userid (even if not logged in), and even more info about the user if the argument is prefixed by “/W” (for “whois”).

FINGER is a simple protocol, used on Lisp Machines, which returns information about who is logged in: the userid, location, idle time, full name, and group affiliation, separated by LISPM newlines (0215). If noone is logged in, the userid and full name are empty.

(Yes, it is confusing that the TCP protocol "finger" corresponds to NAME rather than to FINGER.)

LOAD is a simple protocol, which responds with a two-line ANSwer stating the “fair share” if you would use the remote system, and the number of users currently logged in. Example:

Fair Share: 96%
Users: 1.

HOSTAB, see here, is used to look up hosts in a host table. A host name is sent to the server, which responds with attributes of the host followed by an EOF; the interaction can be repeated until the connection is closed.

DOMAIN is a protocol for doing look-ups in the Domain Name System. It works just like the TCP version of DNS (port 53).

DNS is a (non-standard) simple protocol interface to the Domain Name System, implemented by the Chaosnet Bridge. The RFC argument is the DNS query (as plain 8-bit bytes), and the ANS contains the response. Note the size limit of Chaosnet packets (488 bytes).

BYE returns a (funny) quip, suitable as a message when a user logs out.

YOW similarly returns a Zippy quote.

LIMERICK similarly returns a limerick.

DOOR (a simple protocol) was used at ITS to open the door to the 9th floor of the AI building (with argument D), and sending an elevator to floor 8 or 9 (with argument 8 or 9). The ANS packet had no data. ³⁾

TTYLINK (a simple protocol) responds in a negative way using VT100 terminal escape codes: “Ouch! Don't do that!” (clear screen, move to mid-screen, turn on blink, write “Ouch! Don't do that!”, turn off blink, move to upper left corner). Possibly the server previously established a tty link on ITS (see ITS documentation).

These protocols can be used to connect to a host for an interactive command-line session (like ssh, but no security, or telnet).

TELNET establishes a Telnet protocol connection.

SUPDUP (“SUPer DUPer image TELNET”), specified in RFC 734 is “smarter” than Telnet. It uses a “software terminal” abstraction which standardizes cursor motion, insert/delete operations etc. An implementation which uses the cbridge NCP for connecting to Chaosnet can be found here.

NOTIFY (a simple protocol on Lisp Machines) displays the RFC argument string as a notification on screen, unless it is exactly the same message as the last one (to protect against retransmissions).

SEND is used for interactive messages, what we now call “chatting”. The RFC argument is the destination user, and the content is sent over the stream connection. The first line of the content is expected to be the source, e.g. “userid@host”, the subsequent lines are the message text. The connection is then closed.

MAIL, SMTP.

FILE is implemented by ITS, TOPS-20, Lisp Machines, and the Chaos-over-unix-sockets implementation. A modernised version, used by Symbolics, appears in RFC 1037.

MLDEV is used by ITS systems for general remote device access (including hard disk devices) (also over TCP). ⁴⁾

EVACUATE - “Encode ITS file for evacuation to Unix”. RFC argument is a mode byte followed by an ITS pathname, data coming back is content of file. The mode byte can e.g. be 010 for “don't set reference date” (see SYSTEM;BITS >).

MINI is a mini file server. Send a pathname - if packet opcode is 0200, ask for character mode, if opcode is 0201, ask for binary. Get back one packet (opcode 0202) with the truename and octal creation date of the file, and then the content of the file in 0200 packets (for character mode) or 0300 packets (for binary). If the reponse uses opcode 0203, it is an error message. An EOF signals end of file.

REMOTE-DISK, implemented on Lisp Machines, is for reading and writing a/the disk. (Be careful about access to this server.)

BAND-TRANSFER, implemented on Lisp Machines, is for reading/writing a loadband/partition, typically to distribute a new loadband to other machines. (Be careful.)

ITSDEV - ITS device server. (Be careful.)

The DOVER protocol was used for sending documents to be printed on a Dover printer.

TCP is a gateway protocol for connecting to TCP. Use the host and port number as arguments, e.g. TCP GOOGLE.COM 80. ⁵⁾

• describe GENSYM (DB), GMSGS (DB), etc (ITS).