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!” ¹⁾

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

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

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 a FQDN or similar
• information about what subnets the host is connected to, and the number of packets sent/received/etc for each subnet.

Other simple protocols include TIME, UPTIME, and DUMP-ROUTING-TABLE. (These are all supported by the “hostat” program which comes with cbridge.)

For many protocols (e.g. FINGER, NAME, and FILE), 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.

To check who is logged in to a host, the (stream) NAME protocol can be used. The arguments can be a specific user name to check, optionally prefixed by “/W” to get longer (“whois”) information. For LISP machines, the (simple) FINGER protocol can be used, where the ANSwer is the userid, location, idle time, full name, and group affiliation, separated by LISPM newlines (0215). ³⁾

For file transfer, the FILE protocol can be used (a modernised version, used by Symbolics, appears in RFC 1037). The MLDEV protocol is used by ITS systems for remote general device access (including hard disk devices), also over TCP. ⁴⁾

The SUPDUP (“SUPer DUPer image TELNET”) protocol can be used to connect to a host for an interactive command-line session (think ssh or 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.

To send interactive “chat” messages, the SEND protocol can be used. The MAIL protocol also has options to deliver messages directly to a logged-in user.

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

You can also connect to TCP using Chaosnet gateways: use the contact name “TCP”, using the host and port number as arguments, e.g. TCP GOOGLE.COM 80. ⁵⁾