RFC 36

Protocol Notes

📅 published March 1970, from ietf

Network Working Group RFC 36 💌

Okay bestie, this is RFC 36, "Protocol Notes," written by S. Crocker on 16 March 1970 for the Network Working Group 🎀. The original doesn't list a category, and it doesn't obsolete or update any other RFC, so there's nothing to chase down there ✨.

This is part 1 of 2, so buckle up 🦋.

I Overview ✨

okay so the network protocol gives you three facilities 💅:

  • 1. Connection establishment
  • 2. Flow control
  • 3. Reconnection

Reconnection gets its own section because it's complicated, and because Crocker says he doesn't have enough experience with the protocol to explain these ideas as one connected story 🙈.

Connection Establishment

Connection establishment works basically the same way as in NWG/RFC #33 🌸. The big change is that a more general kind of switching now exists on its own, separate from establishment. So establishment gets simpler because it doesn't include the switching procedures anymore 🧚.

Here's the rough scenario, bestie:

  1. Process PA in host A grabs socket SA and asks for a connection with socket SB. It does this with a system call 📞.
  2. At the same time, process PB in host B grabs socket SB and asks for a connection with socket SA 💜.
  3. Responding to PA's request, the network control program in host A (called NCPA) sends a Request-for-Connection (RFC) command to host B. NCPB in host B sends a similar command to host A 🔥. There's no ordering here: NCPB might send its command to NCPA before or after it gets NCPA's command, and that's totally fine ✨.
  4. NCPA and NCPB both know the connection is established once each one has received an RFC command and has received the RFNM for the one it sent. Then they each tell their processes, PA and PB, that the connection is up 🎉.

One of the rules is that either SA is a send socket and SB is a receive socket, or the other way around. People sometimes put it like this: "SA and SB must be a send/receive pair" 💖.

  1. The sending process can finally send 🚀.

Flow Control

So a sending process could totally flood a receiving process if nothing stopped it, which is why the receiver has to be able to stop the flow() 🛑. Flow control is built right into how RFNM handling works in the network 🧠. When a receiving host wants to hold back flow on a particular link, it sends a special message to its IMP. That message makes the next RFNM on that link get changed. The sending host reads this as both an RFNM *and a request to stop sending. A confirming control command comes back too 🫶.

When the receiving host is ready for more, it sends a command (RSM) telling the sending host to start up again 🌈.

Reconnection

For a lot of reasons, it's really useful to be able to switch one end (or both ends) of a connection from one socket to another 🦋. How hard that is depends on what rules the switching has to follow. To get the most generality, Crocker presents a scheme for dynamic reconnection. That means reconnection can happen even after flow has already started 💅. He admits that for most cases this scheme is way more expensive than it needs to be 😭. Still, he claims these virtues:

  • 1. All the various forms of switching connections are provided.
  • 2. Reconnection adds no overhead to processing messages sent over a connection, i.e., the whole cost is paid while processing the protocol ✨.

*BB&N argues that unlimited buffering should be provided. It is possible that this would be a proper strategy, but it is foreign to my way of thinking, and I have based the protocol design on the assumption that only a small buffer is provided on the receive end of each connection.

II Data Structures 🗂️

Here are the five tables:

  1. Connection Table
  2. Process Table
  3. Input Link Table
  4. Output Link Table
  5. Link Assignment Table

Connection Table

This table holds everything about local sockets, especially whether a socket is in a connection and, if it is, what state that connection is in 💖. Entries are keyed by local socket, but other tables have pointers into this one too (see the Process Table, Input Link Table, and Output Link Table) 🧚.

Each entry contains:

  • a) local socket (key)
  • b) foreign socket
  • c) link
  • d) connection state
  • e) flow state and buffer control
  • f) pointer to user's process
  • g) reconnection control state
  • h) queue of waiting callers

The local socket is a 32 bit number. If there's no entry for a particular socket yet, one can be created with null values 🌸.

The foreign socket is a 40 bit number. This field stays unassigned if no connection is established 🫧.

The link is an 8 bit number. It's the link that data gets sent over from the sender to the receiver. A socket is a receive socket iff its low-order bit is zero 🔥.

Connection state tells you whether a connection is open or not, and so on. These are the possibilities:

  • a) local process has requested a connection
  • b) foreign process(es) has/have requested a connection
  • c) connection established
  • d) reconnection in progress
  • e) close waiting
  • f) reconnection waiting

Flow state and buffer control cover checking for RFNM's, and for accepting cease, suspend, and resume commands. They also keep track of incoming or outgoing data 💅.

A pointer to the user's process is needed if the process asked for a connection 👑.

If a reconnection is in progress, you have to keep track of the sequence of events ✨. A socket doing reconnection is either an end or a middle. If it's a middle, you need to store the eight bit name of the other middle attached to the same process, and record whether END and RDY commands have arrived 🎀.

Last one: if RFC's show up while the socket is busy, or when no process has engaged it, the RFC's get stacked first-in-first-out on a queue for the named local socket 📚.

Process Table

This table links a process to a socket. It's used to handle system calls 📞.

This table links receive links to local sockets. It's used to figure out who incoming messages are for 💌.

This table links send links to local sockets. It's used to interpret RFNM's and RSM commands 🧠.

Receivers are the ones who assign links, and this table shows which links are free 🦋.

III Control Commands 🎛️

Command Summary

Here's the whole lineup, bestie 💅:

   0         <NOP>
   1         <RFC> <me> <you>   or   <RFC> <me> <you> <link>
   2         <CLS> <me> <you>
   3         <RSM> <link>
   4         <SPD> <link>
   5         <FND> <me> <you> <asker>
   6         <END> <link> <end>
   7         <RDY> <link>
   8         <ASG> <me> <you> <link>

No Operation

Form:    NOP
         NOP  is X'00'

Purpose: this command is included for completeness and convenience 🫶.

Request for connection

Form:    <RFC> <my socket>  <your socket>
  or     <RFC> <my socket>  <your socket>  <link>
         <RFC> is X'01'
         <my socket> is a 32 bit socket number local to the
         sender
         <your socket> is a 32 bit socket number local to the
         receiver
         <link> is an eight bit link number.
         <my socket> and your socket must be a send/receive pair.
         <link> is included if and only if <my socket> is a
         receive socket

Purpose: this command starts a connection. When two hosts have swapped RFC commands with the same arguments (reversed), the connection is established 💖. Links are assigned by the receiver 🎀.

Close

Form:    <CLS> <my socket> <your socket>
         <CLS> is X'02'
         <my socket> and <your socket> are the same as for <RFC>

Purpose: this command blocks a connection 🛑. It can also abort a connection that's being set up, or refuse a request ✨. Sometimes no connection between the named sockets was set up, or was in the middle of being set up. When that happens, the <CLS> should be discarded 🙈.

Resume

Form:    <RSM> <link>
         <RSM> is X'03'

Purpose: a receiving host sends this to make the sending host resume transmission on the named link 🌈. A sending host suspends sending if it gets a special RFNM for some message. (Special RFNM's get generated by the receiving IMP when its host asks for one.) 🔥

Suspended

Form:    <SPD> <link>
         <SPD> is X'04'

Purpose: a sending host sends this to say it has stopped sending over the named link 🫧. Transmission picks back up when an <RSM> command arrives 🦋.

Part 1 of 2 is done, babe! Part 2 picks up with the Final End and End Found commands and the rest of the document ✨💖

Ready 💖

Okay bestie, this one is the "all done, you can reconnect now" signal 🦋 Here's the form:

Form:    <RDY> <link>

         <RDY> is X'07'
         <link> is an 8 bit link number

So <RDY> is X'07', and it's followed by an 8 bit <link> number 🎀

Purpose: ngl this is so clean ✨ It gets sent from a send socket over to a receive socket to say "hey, I've forwarded everything, so reconnecting is totally allowed now" 💅 That's the whole vibe.

Next up is the glow-up 🌸 Here's the form:

Form:    <ASG> <my socket> <your socket> <link>

         <ASG> is X'08'

<ASG> is X'08' 🍓

Purpose: this is literally the completion of a reconnection 😭 It goes from a receive socket to a send socket, but only after the receive socket has gotten a <RDY>. Once that happens, a new link gets assigned and transmission starts up again 🚀 Iconic behaviour, no notes 👑

Reminder: <ASG> only shows up after the <RDY> has been received. Order matters here, bestie 🫶

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Marc Blanchett 3/00 ]

📦 where this page comes from