The low-level interface is very very lax and permissive and the frame-length filter helps a lot. Anybody could do anything but even incompatible circuits/peers should be able to discover they are not compatible... So let's agree on a "reserved message length" of 6 bits that requires very little complexity to support, and provide basic discovery and link status stuff.

First, the 2 leading bits must be 0 then 1. Any 6-bit message starting with a different header will be rejected. WHY ? So the peer can detect that the link works properly (all-1s and all-0s would indicate stuck or open signals) and if the message is validated, then it ensures that the bits are not swapped. A DFF+XOR can then be configured to "virtually" swap the data polarity, just as if we swapped the bits.

Then we have 4 bits or 16 combinations.

• 0000 and 1111 are invalid. See previous paragraph to see why. This leaves 14 codes. Not all will be used yet.
• INIT instructs the peer to reset its various com layers and start afresh/anew.
• TINI says the peer has been initialised.
• PING is ... well, a test just like on IP stacks.
• PONG is the answer. Too bad we don't have enough room to include some arbitrary garbage but that does not matter at this point.
• WHAT says that the last message is not recognised, for example its length is invalid or the request was invalid.
• DESC requests the peer to send a frame of variable length with UTF8 encoded text that describes that peer.
• IDTT requests a free-length frame containing the type+serial number or something like that.
• CAPS requests a frame where each bit that is set to 1 corresponds to a valid filtered frame (it's free-length too)

That's 8+2 combinations so there is room for 6 more. Nice. They are general and generic enough and if a peer implements very specific control messages (such as sleep/wake or such), a different length (longer) can be implemented without cluttering this simple protocol.