RFC 71 UNKNOWN FLOW CONTROL · ERROR HANDLING · ARPANET

Reallocation in Case of Input Error

A procedure for clearing a link after an input error.

RFC EDITOR

Schipper, T., "Reallocation in Case of Input Error", RFC 71, DOI 10.17487/RFC0071, September 1970, <https://www.rfc-editor.org/info/rfc71>.

BIBTEX

@misc{rfc71,
  series = {Request for Comments},
  number = 71,
  howpublished = {RFC 71},
  publisher = {RFC Editor},
  doi = {10.17487/RFC0071},
  url = {https://www.rfc-editor.org/info/rfc71},
  author = {T. Schipper},
  title = {{Reallocation in Case of Input Error}},
  pagetotal = 1,
  year = 1970,
  month = sep,
}

PUBLISHED: September 1970
AUTHORS: T. Schipper
STREAM: Legacy
DOI: 10.17487/RFC0071

RFC text

Original text · RFC Editor View on rfc-editor.org ↗

Network Working Group                                   Tjaart Schipper
Request for Comments #71                                25 September 1970
                                                        UCLA-CCN


            Reallocation in Case of Input Error


In case of reading a message from the IMP, it may be impossible for the
receiving NCP to determine the length of the message if an input error
occurs. The following protocol will be used at the CCN-Host at UCLA to
resynchronize flow control.

If an input error is detected and the NCP can find the intended link
number, it will send a GVB with frac = O to the sending Host and disregard
further incoming messages on that link. When the RET has been received, a
new ALL will be sent.

If the sending Host is not waiting for a RFNM when the GVB arrives, it will
send the RET immediately. If it is waiting for a RFNM corresponding to the
message with the error or a RFNM corresponding to a following message, it
will send the RET after the RFNM has been received.

In this way, the receiving Host will know that the link is clear before it
issues a new ALL.

TS/rb.




     [ This RFC was put into machine readable form for entry ]
     [ into the online RFC archives by Alexandra Weikert 7/97]

ISO Plain Language

On this page

PROBLEMAn input error may prevent the receiving NCP from determining the message length, leaving the link's flow-control state unclear.

MECHANISMIf it can identify the link, the receiving NCP sends GVB with frac=0, ignores further messages on that link, waits for RET and then sends a new ALL.

RECOVERY PROCEDUREThe receiving host knows the link is clear before issuing a new allocation.

§1When an Input Error Hides Message Length

The note says an input error while reading a message from the IMP may make it impossible for the receiving NCP to determine the message length. It presents a procedure for the UCLA CCN host to resynchronize flow control.

The procedure applies when the NCP detects an input error and can identify the intended link number.

If an input error hides where a message ends, the receiving system may not know the link's state. The note gives a way for the UCLA CCN host to clear that link before continuing.

§1Stop, Wait and Reallocate

The receiving NCP sends GVB with frac = 0 to the sending host and disregards further incoming messages on that link. If the sender is not waiting for an RFNM, it sends RET immediately.

If the sender is waiting for an RFNM for the errored message or a following message, it waits for that RFNM before sending RET. After receiving RET, the receiving side sends a new ALL.

The receiver asks the sender to stop and ignores more messages on that link. It waits for RET, including any pending RFNM, before issuing a new allocation.

§1Confirm the Link Is Clear First

The order of operations matters: the receiving host waits until it has received RET before sending a new ALL. The note says this ensures the link is clear before the new allocation is issued.

The receiving host does not allocate the link again until the sender confirms it is clear. This keeps the two sides' flow-control state aligned.