diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc489.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc489.txt')
-rw-r--r-- | doc/rfc/rfc489.txt | 59 |
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] + |