Comment on resynchronization of connection status proposal
Jon Postel's naming change for a connection-allocation recovery procedure.
Postel, J., "Comment on resynchronization of connection status proposal", RFC 489, DOI 10.17487/RFC0489, March 1973, <https://www.rfc-editor.org/info/rfc489>.
@misc{rfc489,
series = {Request for Comments},
number = 489,
howpublished = {RFC 489},
publisher = {RFC Editor},
doi = {10.17487/RFC0489},
url = {https://www.rfc-editor.org/info/rfc489},
author = {J. Postel},
title = {{Comment on resynchronization of connection status proposal}},
pagetotal = 1,
year = 1973,
month = mar,
} RFC text
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 ]
ISO Plain Language
On this page
§1A Comment on Connection Resynchronization
Jon Postel comments on the resynchronization procedure proposed by Burchfiel and Tomlinson in RFC 467. He endorses their proposal with a naming change and says his condensed table is meant to clarify, not supersede, their document.
Postel supports the procedure in RFC 467. He proposes clearer command names and provides a shorter explanation of the sequence.
§2The RAS and RAR Names
Postel proposes the names RAS, for reset connection allocation sender, and RAR, for reset connection allocation receiver. He says these names are more appropriate because the procedure resets allocation, which is one aspect of a connection.
RAS and RAR name the sender and receiver steps. The names emphasize that allocation is reset, not the entire connection.
§3Sender and Receiver Steps
The table shows the sender waiting until no RFNM is outstanding, sending RAS, and processing allocates until RAR arrives. The receiver sends RAR, processes messages until RAS arrives, zeros allocation quantities, returns to open state, and sends a new allocate.
Either side can initiate the procedure for internal reasons or after receiving RAS or RAR, as the RFC explains.
The sender and receiver exchange RAS and RAR, reset their allocation quantities, and return to the open state. Either side may start the procedure.