rfc663.txt

RFC 相关的技术文档

at  the  point  where  the  break  occurred  using  the C-channel
specified  by  the  LMR   message.    This   will   restore   the
communication  path  X.   What  happens  if  S  can  not  restore
communication at the break point because it  does  not  have  the
relevant  messages  any more?  This issue can be solved in one of
the two ways: either let the protocol specify a fixed rule that S
will be required to close the connection, or the  protocol  could
allow  S  and R (and may be the users on whose behalf S and R are
communicating on X) to negotiate the action to be taken.  For the
protocol to be presented here, we have taken the approach that  S
may, at its option, either close the connection or negotiate with
R.   What  action  a specific host takes can either be built into
its NCP or determined dynamically.  Those hosts that do not  have
very  powerful  machines will probably chose the static option of
closing the  connection;   other  hosts  may  make  the  decision
depending upon the circumstances.  For example, a host may decide
that  loss  of  messages  is not acceptable during file transfers
whereas  loss of a single message can  be  ignored  for  terminal
output  to  interactive  users.   A  host might even let the user
processes decide  the  course  of  action  to  be  taken.   If  S
determines  that it can not retransmit lost messages, it may want
to let R decide what action is to be taken.   If  S  so  decides,
then  it  may  communicate  this  fact  to  R  by  transmitting a
_L_o_s_t__M_e_s_s_a_g_e__f_r_o_m__S_e_n_d_e_r  (LMS)  control  message  to  R  on  the
channel  S->R.   An LMS message is of the following form:  LMS(X,
CN, MSN, COUNT), where X is the name of the channel,  CN  is  the
name  of  the C-channel obtained from the LMR message, MSN is the
message sequence number of the first message in the  sequence  of
lost  messages,  and  COUNT  is  the  number  of  messages in the
sequence.  S resets its own synch-state for connection X to  S(X,
CN,  MSN+COUNT).   When  S  has  informed  R  of its inability to
retransmit lost messages, the burden of the decision falls on  R,
and  S  simply  awaits R's reply before taking any action for the
channel X.  When R receives the LMS, it may  either  decide  that
loss  is  unacceptable and close the connection, or it may decide
to let S continue.  In the later case R informs S of its decision


                    - 7 -










to continue by transmitting  a  L__o_s_s__o_f__M_e_s_s_a_g_e__A_c_c_e_p_t_a_b_l_e  (LMA)
control  message to S.  Upon receiving the LMA control message, S
resumes transmission on X.  To avoid the possibility of errors in
exchange  of  control  messages,  the  LMA  control  message   is
specified  to  be  an  exact  replica of the LMS control message,
except for the message code which determines  whether  a  control
message is LMA or LMS or something else.


In  general,  a  sending host has only a limited amount of memory
available for storing messages for possible retransmission later.
In section 2.6 we provide a status exchange mechanism that can be
used to determine when to discard these messages.



2.5 RECOVERY ON CONTROL LINKS


We continue our discussion with the  scenario  developed  in  the
previous  section.  The receiver R may detect loss of messages on
control channels by examining the message sequence numbers on the
messages.  When R detects that a message has  been  lost  on  the
channel   S->R,  it  (R)  may  transmit  an  LMR  to  S  on  R->S
communicating the fact of loss of messages.  When S receives  the
LMR  for  the  control  link,  it must either retransmit the lost
messages,  or  "close"  the  connection.  (In  the   context   of
Host-to-Host protocol, closing the network connection for control
link  implies exchange of reset commands, which has the effect of
reinitializing all communication between R and S.)   For  control
links,  S  does  not  have  the  option  of sending an LMS to the
receiver.  If S can not retransmit  the  lost  messages  then  it
aborts  the  output  queue  (if  any)  for  the channel S->R, and
inserts a Reset command at the break point.  Essentially, we  are
specifying  that  if  S  can not retransmit lost control messages
then the error would be considered irrecoverable and fatal.   All
user  communication  between  S  and  R  is  broken  and  must be
restarted from the beginning.


In the above paragraph, we considered the situation  in  which  R
was  able to detect the loss of messages.  It is however possible
that it is the last message transmitted on S->R that is lost.  In
this  case,  R will not be aware of the loss.  In this situation,
recovery can  be  initiated  only  if  S  can  either  positively
determine  or  simply  suspect  that a message has been lost.  In
general, after having transmitted a control message, S  would  be
expecting  some  sort  of  response  from  R.  For  example, if S
transmits a Request-for-Connection (RFC) control message to R,  S
expects  R  to reply either with a Close (CLS) command or another
RFC.  If, after an appropriate time  interval has elapsed  and  S
has  received  no reply from R, our protocol specifies that S may
retransmit the control message.  In retransmitting,  S  must  use


                    - 8 -










the same C-channel and MSN values that were used for the original
message.    Since  R  can,  now,  receive  duplicate  copies,  we
stipulate that if R receives a duplicate of the message  that  it
has already received, it may simply ignore the duplicate.



2.6 SOME OTHER PROBLEMS


There  are  two problems that have not yet been solved.  First, a
sending host will usually have only a limited  amount  of  buffer
space   in   which  it  can  save  messages  for  possible  later
retransmission.  So far, we have not provided any method by which
a  host  may  positively  determine  whether  the  receiver   has
correctly received a certain message or not.  Thus it has no firm
basis  on  which  it  may  decide to release the space used up by
messages that have been already transmitted.  The second  problem
is  created  by  our recycling the message sequence numbers.  For
the MSN mechanism to work correctly, it is essential that at  any
given  instant  of  time there be no more than 15 messages in the
transmission path.  If there were more than 15 messages, some  of
these  messages  would have same MSN and LRN, and if one of these
messages were to be lost, it would be impossible to identify  the
lost  message.   However,  the second problem should not arise in
the ARPA Network, since the IMP sub-network will not  allow  more
than  eight  outstanding  messages between any host pair (NWG-RFC
#660).


We can solve both these problems by a simple yet highly  flexible
scheme.  In this scheme, there are two new control messages.  One
of these, called R__e_q_u_e_s_t S__t_a_t_u_s _f_r_o_m S__e_n_d_e_r (RSS), can be used by
the  sending  host to query the receiver regarding the receiver's
synch-state.  The receiver can supply  its  copies  of  C-channel
number  and  MSN for a transmission path by sending a S__t_a_t_u_s _f_r_o_m
R__e_c_e_i_v_e_r (SFR) control message over the control channel.  An  SFR
provides  positive  acknowledgement;  differing  with  the  usual
acknowledgement schemes in  only  that  here  acknowledgement  is
provided  only upon demand.  Upon receiving SFR, the sender knows
exactly which messages have been properly delivered, and  it  may
free  the  buffer  space used by these messages.  The RSS and SFR
scheme can also be used to ensure that there  are  no  more  than
fifteen messages in the transmission path at any given time.











                    - 9 -










3.0 LOST MESSAGE DETECTION AND RECOVERY PROTOCOL


This  protocol  is  proposed  as an amendment to the Host-to-Host
Protocol for the purpose of letting  hosts  detect  the  loss  of
messages  in  the  network. It also provides  recovery procedures
from such losses.  This protocol is divided into two parts.  Part
1 states the compatibility requirements.  Part 2 states  the  new
protocol and must be implemented by hosts that desire to have the
ability  to  recover  from  loss of messages in the network.  The
reader  will  find  many  comments  interspersed  throughout  the
description of this protocol.  These comments are not part of the
protocol and are provided solely for the purpose of improving the
reader's understanding of this protocol.


The  terminology used in this protocol is similar to that used in
the Host-to-Host protocol.  We speak of  a  "network  connection"
between  a pair of hosts, called the "receiver" and the "sender."
A network connection is described by a pair  of  socket  numbers,
and  once  established, a network connection is associated with a
link (which is described by a link number.)  A network connection
is a logical communication path and the link assigned to it is  a
physical  communication  path.   In  addition to links associated
with the network connections, there are "control-links"  for  the
transmission  of  "control  commands."   When  we  use  the  term
"connection" it may refer to either a network connection  or  the
link  assigned  to  it;  the context decides which one.  The term
"links" encompasses the connection-associated-links  as  well  as
control-links.   Notice  that  a  receiver  of  a  connection may
transmit control commands regarding this connection.


3.1 DEFINTIONS


3.1.1 HOST TYPE "A"


Those hosts that have not adopted the part  2  of  this  protocol
amendment will be known as type A hosts.

(Comment: All existing hosts are type A hosts.)


3.1.2 HOST TYPE "B"


Those  hosts,  that  adopt  the part 2 of this protocol amendment
will be known as type B hosts.





                   - 10 -










3.1.3 MESSAGE SEQUENCE NUMBER (MSN)


A four bit number associated with regular messages and  contained
in  the  bits  25  through  28 of the Host-to-IMP and IMP-to-Host
leaders for regular messages [BBN Report No. 1822].  This  number
is  used  by  the  type  B hosts to detect loss of messages  on a
given link.  Type A hosts always set the MSN  (for  the  messages
they  send out) to zero.  When in use by a type B host, the first
message on a link (after the connection has been established) has
the MSN value of one.  For each successive message on this  link,
the MSN value is increased by one until it reaches a value of 15.
The next message has the MSN value of one.


(Comments:  Type  B  hosts  will  use the MSN mechanism only when
communicating with other type B  hosts.  If  a  type  B  host  is
communicating   with  a  type  A  host,  the  type  B  host  will
essentially simulate the behaviour of a type A host and use  zero
MSN values for this communication.)


3.1.4 LINK RESYNCH NUMBER (LRN)


The  Link Resynch Number is an eight bit number associated with a
link and used for resynchronizing the communication.   For  links
associated  with  a  network  connection (i.e. user links), it is
intially set to zero.  For control links, it is set  to  zero  at
the  time  of  the  Network Control Program (NCP) initialization.
For a given link, its current LRN value is copied  into  the  LRN
field  of  all messages sent out on the link.  The LRN values may
be manipulated by type B hosts in accordance  with  the  protocol
described later.


(Comments:   Our  protocol  specifies  that for all communication
involving a type A host, the LRN value  will  never  change  from
zero.   Since the LRN field is presently unused, all hosts set it
to zero even though they do not explicitly recognize  this  field
as an LRN field.  This guarantees compatibility.)


3.1.5 LRN FIELD


An  eight bit field in the bits 33 through 40 of the Host-to-Host
message header.







                   - 11 -










3.2 NEW CONTROL COMMANDS


3.2.1 LMR - LOST MESSAGE FROM RECEIVER


___8______8_______8_______8____
|     I      I      I     I
I LMR | link | LRN  | MSN I
I______I_______I_______I______I_


The LMR command is sent by a receiving host to  let  the  sending
host  know  that  one  or  more messages have been lost.  The MSN
field specifies the message sequence number of the first  message
lost.   The  LRN  field  specifies the new LRN value that must be
used if and when communication is restored.

(Comments:  As will be seen later, the LMR command also  has  the
effect of resetting the bit and message allocation in the sending
host   to   zero.   In  order  to  permit  a  sender  to  restore
communication, an LMR command will be usually accompanied with an
allocate command.  However notice  that  these  comments  do  not
apply  to  the  control  links  because  there  is  no allocation
mechanism for the control links.)


3.2.2 LMS - LOST MESSAGE FROM SENDER


____8_________8________8__________8_________8_____
I        I       I        I         I       I
I  LMS   I Link  I  LRN   I  MSN    I COUNT I
I__________I________I_________I__________I________I_


This command is sent by a sender host in reply to an LMR  command
if it (the sender) can not retransmit the lost messages specified
by  the LMR command.  The purpose of this command is to query the
receiver whether or not  the  loss  of  messages  is  acceptable.
After  sending  this command, the sender waits for a reply before
transmitting any messages over the link involved.   This  command
may  not  be  sent for control links.  The LRN and MSN values are
same as those specified by the LMR command.  COUNT specifies  the
number of messages lost.



3.2.3  LMA - LOSS OF MESSAGES ACCEPTABLE


This  command  is  identical  to  the  LMS command accept for the
command code.  Upon receipt of an LMS  command,  a  receiver  may


                   - 12 -










send  this command to the sender to let the sender know that loss
of messages is acceptable.  All fields in this command are set to
corresponding values in the LMS command.



3.2.4  CLS2 - CLOSE2


____8___________3_2_______________3_2_____________8_______8______
I       I              I                 I       I      I
I CLS2  I  my socket   I your socket     I  LRN  I MSN  I
I________I_______________I__________________I________I_______I_


The CLS2 command is similar to the current CLS command except for
the LRN and MSN fields included in the  new  command.   Both  the
receiving and sending hosts copy their values of LRN and MSN into
the CLS2 command.  Upon receiving a CLS2 command, a host compares
the LRN and MSN values contained in the CLS2 command with its own
values  for  the  connection  involved.   If  these values do not
match, then an  error  has  occurred  and  a  host  may  initiate
recovery procedures.

(Comments:   The  purpose  of  this command is to ensure that the
last message  transmitted  on  a  connection  has  been  received
succesfully.)



3.2.5 ECLS - ERROR CLOSE


_____8___________3_2___________3_2_________
I        I             I             I
I  ECLS  I my socket   I  your socketI
I_________I______________I______________I_


The  ECLS  command  is similar to the current CLS command.  It is