OpenRFC.org Requests For Comments ... for the community
Welcome to OpenRFC
Home Full RFC index RFC humour Our technology
 
<< Previous <<      RFC 489      >> Next >>    
Comment on resynchronization of connection status proposal.
J. Postel. March 1973.

 
[Direct link][Download PDF version][Download text version]
 

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]

   

[Home] [Full RFC index] [RFC humour] [Our technology]

Copyright © Inter-Corporate Computer & Network Services, Inc.  All rights reserved.
All trademarks and RFC contents are the property of their respective owners.