summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc489.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc489.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc489.txt')
-rw-r--r--doc/rfc/rfc489.txt59
1 files changed, 59 insertions, 0 deletions
diff --git a/doc/rfc/rfc489.txt b/doc/rfc/rfc489.txt
new file mode 100644
index 0000000..494885f
--- /dev/null
+++ b/doc/rfc/rfc489.txt
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+Network Working Group Jon Postel
+Request for Comments: #489 UCLA-NMC
+NIC #15298 March 26, 1973
+
+
+ Comment on Resynchronization of Connection Status Proposal
+
+
+This is a comment on the proposal by Burchfiel and Tomlinson in RFC 467
+for a procedure in the host-to host protocol for resynchronization of
+connection status. I endorse their proposal with the following trivial
+change. The commands proposed might be more appropriately be called
+"reset connection allocation sender" and "reset connection allocation
+receiver" since the only aspect of the connection which is reset is the
+allocation. I therefore use the names RAS and RAR respectively.
+
+The table below shows in overly concise notation my interpretation of
+the resynchronizing procedure proposed by Burchfiel and Tomlinson, this
+presentation is not intended to supersede their document but to clarify
+the procedure. The sequence shown here can be initiated by either the
+sender or receiver either for internally generated reasons or upon the
+receipt of a RAS or RAR, if this latter is the case then sender step 5
+or receiver step 4 is satisfied.
+
+SENDER RECEIVER
+
+1. Set state to "wait-for-RAR" 1. Set state to "wait-for RAS"
+2. Wait till no RFNM outstanding 2. Send RAR
+3. Send RAS 3. Process messages until
+4. Process allocates until 4. RAS received then
+5. RAR received then 5. Zero allocation quantities
+6. Zero allocation quantities 6. Set state to "open"
+7. Set state to "open" 7. Send a new allocate
+
+
+
+
+
+
+
+
+
+
+ [ This RFC was put into machine readable form for entry ]
+ [ into the online RFC archives by Alex McKenzie with ]
+ [ support from GTE, formerly BBN Corp. 9/99 ]
+
+
+
+
+
+Postel [Page 1]
+