rfc663.txt

RFC 相关的技术文档

used  for   closing   connections   which   have   sufferred   an
irrecoverable loss of messages.

(Comments: A connection may be closed in any one of the following
three ways:

      1. A connection which has not yet been opened  succesfully
may  be  closed  by  the  CLS command.  All connections
involving type A hosts must be  closed  using  the  CLS
command.
      2. Connections between type B hosts may  be  closed  using
CLS2  command.   A connection is considered closed only
if matching CLS2 commands have been  exchanged  between


                   - 13 -










the sender and the receiver.
      3. Those connections  between  type  B  hosts,  that  have
sufferred  an  irrecoverable  loss of messages, must be
closed by the ECLS command.)



3.2.6 RSS - REQUEST STATUS FROM SENDER


____8_______8______
I      I        I
I RSS  I LINK   I
I_______I_________I_


A sending host may issue an RSS command to  find  out  about  the
status  of transmission on a particular connection or the control
link.



3.2.7  RSR - REQUEST STATUS FROM RECEIVER


____8_________8_____
I       I        I
I RSR   I LINK   |
I________I_________I_


A receiver can issue an RSR command to find out about the  status
of  transmission  on a particular connection or the control link.



3.2.8 SFR - STATUS FROM RECEIVER


____8_________8_________8_________8____
I        I        I        I       I
I SFR    I  LINK  I  LRN   I MSN   I
I_________I_________I_________I________I_


A receiving host may issue this  command  to  inform  the  sender
about  the  state of a particular connection or the control link.



3.2.9 SFS - STATUS FROM SENDER




                   - 14 -










____8_________8_________8_________8____
I        I        I        I       I
I SFS    I  LINK  I  LRN   I MSN   I
I_________I_________I_________I________I_


A sending host may issue this  command  to  inform  the  receiver
about  the  state of a particular connection or the control link.



3.3  THE PROTOCOL


3.3.1 PART ONE


All type A hosts must use zero MSN and LRN values on the messages
sent out by them.  When communicating with a host of  type  A,  a
type B host must simulate the behaviour of type A host.

(Comments:   Notice  that  this  simulation is not complicated at
all.  All that  is  required  is  that   hosts  that  adopt  this
protocol  must  not use it when communicating with the hosts that
have not adopted it.)


3.3.2 PART TWO


This part of the protocol is stated as a set of rules which  must
be  observed  by  all  type B hosts when communicating with other
type B hosts.


3.3.2.1 RESPONSIBILITIES OF HOSTS AS SENDERS


    (1). A type B sending host must use message sequence numbers
on all regular messages that it sends to other  type  B
hosts  as  specified  in  the definition of the message
sequence numbers (Section 3.1.3).
    (2). A type B sending host must use link resynch numbers  on
all  regular  messages  that  it  sends to other type B
hosts as specified in the definition  of  link  resynch
number (Section 3.1.4).
    (3). A sending host may retransmit a message if it  suspects
that  the  message  may  have  been lost in the network
during previous transmission.
    (4). A sending host may issue an RSS command to the receiver
to determine the state of transmission on any link.
    (5). A sending host must use the ECLS  command  to  close  a
connection, if the connection is being closed due to an


                   - 15 -










irrecoverable  transmission  error.  Otherwise, it must
the CLS2 command.



3.3.2.2 RESPONSIBILITIES OF HOSTS AS RECEIVERS


    (1). A receiver host will maintain LRN and  MSN  values  for
each link on which it receives messages.  Initial value
of  LRN  will be zero, and initial value of MSN will be
one.   For  each  receive  link,  the  host  should  be
prepared  to  receive a message with LRN and MSN values
specified by its tables.  When the  host  has  received
the  expected  message  on a given link, it will change
its table MSN value as specified in the  definition  of
MSN.
    (2). On a given link, if a host receives a message  with  an
LRN  value  smaller than the one in use, it will ignore
the message.
    (3). If a host receives a duplicate message  (same  LRN  and
MSN values), it will ignore the duplicate.
    (4). A host will examine  the  MSN  values  on  all  regular
messages  that  it receives to detect loss of messages.
If on any link, one or more messages are found missing,
it will concern itself with only the first message lost
and take the following series of action:

       1. Increase its own LRN value for this  link  by
          one.
       2. Send an LMR command to the sending host  with
          LRN  field set to the new value and MSN field
          set to  the  sequence  number  of  the  first
          message lost.
       3. Realizing that LMR  command  will  cause  the
          allocation  to be reset to zero, it will send
          more allocation. This is  not  applicable  to
          the control links.

However,  if  a  host  does  not  want  to initiate the
recovery procedures, it may simply close the connection
by an ECLS command.
    (5). A receiver host may  issue the RSR command to determine
the state of transmission on any link.
    (6). If a connection is being closed due to an irrecoverable
error, a receiving host  must  use  the  ECLS  command.
Otherwise it must use the CLS2 command.








                   - 16 -










3.3.2.3  SENDING HOST'S RESPONSE TO CONTROL MESSAGES


    (1). RSR command: the sender must transmit a SFS command  to
the receiver for the link involved.
    (2). ECLS command: The sender must cease transmission, if it
has  not  already done so, and issue an ECLS command if
it has  not  already  issues  either  a  ECLS  or  CLS2
command.
    (3) CLS2 command: The sender must compare the  LRN  and  MSN
values  of  the CLS2 command with its own values of the
LRN and MSN for the connection involved.  If  an  error
is  indicated,  it may either close the connection with
an ECLS, or initiate recovery action  as  specified  in
the section 3.3.2.1.
    (4). LMR command for  a  connection  (i.e.,  not  a  control
link):  The  sender may follow any one of the following
three courses of action:

       1. Close the connection with an ECLS command.
       2. Set the allocations for the link involved  to
          zero,  set  LRN  to that specified in the LMR
          command, and  restart  communication  at  the
          point of break.
       3. Set the allocations for the link involved  to
          zero,  set  the  LRN to that specified in the
          LMR command, and send an LMS command  to  the
          receiver  host informing him that one or more
          of   the   lost   messages   can    not    be
          retransmitted.  After sending an LMS command,
          a  sending  host  must  not transmit any more
          messages  on  the  link  involved  until  and
          unless  it  receives  an LMA command from the
          receiver host.

(Comments:  As  we  have  mentioned  before  (Section  2.3),  the
decision  regarding which course of action to follow depends upon
a number of factors.  For example, if a host has implemented only
the detection of lost messages aspect of  our  protocol  (and  no
recovery),  then  it  will  chose the first option of closing the
connection.)

    (5). LMR for a control link: The sender may take one of  the
following two actions:

       1. Set the LRN to  that  specified  in  the  LMR
          command  and  begin  retransmission  of  lost
          messages
       2. Set the LRN to  that  specified  by  the  LMR
          command,  and  insert  a Reset command at the
          break point.




                   - 17 -










(Comment:  If a sending host can not retransmit messages lost  on
a   control   link,   then   this   protocol  requires  that  all
communication between the two host be broken, and  reinitialized.
We do not explicitly specify the actions that are associated with
the  exchange  of Reset commands.  These actions are specified by
the Host-to-Host protocol.)

    (6). LMA command:  When  a  sending  host  receives  an  LMA
command  matching  an  LMS command previously issued by
it, it may resume transmission.

(Comments: The protocol does not require the sending host to take
any specific action with regard to a SFR. However, a sending host
may use the information contained in the  SFR  command  regarding
the  state of transmission.  From a SFR command a sender host may
determine what messages have been received properly.  The  sender
may   use  this  information  to  cleanup  its  buffer  space  or
retransmit messages that it might suspect are lost.)



3.3.2.4 RECEIVING HOST'S RESPONSE TO CONTROL MESSAGES


    (1). RSS command: A receiver is obligated to transmit a  SFR
to the sender for the link involved.

    (2). ECLS command:  The receiver must close  the  connection
by  issuing  an ECLS command if it has not already done
so.

    (3). CLS2 command: A receiver must compare the LRN  and  MSN
values  of  the  command  with  its  own values for the
connection involved.  If an error is indicated, it  may
either  close  the  connection  by  an  ECLS command or
initiate recovery procedures as  specified  in  section
3.3.2.2.

    (4). LMS command: The receiver may take one of the following
two courses of action:

     (1). Close the connection  specified  by  the  LMS
          command, by issuing an ECLS command.
     (2). Set the  link  involved  to  be  prepared  to
          receive  messages  starting with the sequence
          number MSN + COUNT, where MSN and  COUNT  are
          those   specified   by   the   LMS   command.
          (Comment: This action implies  that  receiver
          is  willing  to  accept  the loss of messages
          specified by the LMS command.)

(Comments: The protocol does not require the receiver to take any
specific action with regard to a SFS command. However a  receiver


                   - 18 -










host may use the information  contained in it.)




4.0 CONCLUDING REMARKS


The  design  of  this  protocol  has been governed by three major
principles.  First, we believe that to be useful within the  ARPA
Network,  any  new  protocol must be compatible with the existing
protocols, so that each host can make the transition to  the  new
protocol at its own pace and without large investment.  Secondly,
the  protocol  should  tie  into  the  recovery  mechanism of the
IMP-to-Host Protocol.  The price we pay for this is the small MSN
field and a   message oriented protocol rather than a byte stream
oriented protocol.  The third consideration has been flexibility.
While this protocol guarantees detection of  lost  messages,  the
philosophy  behind  the recovery procedures is that a host should
have several options, each option providing a different degree of
sophistication.  A host can implement a recovery  procedure  that
is  most  suitable  for  its  needs  and  the capabilities of its
machine.  Even though two hosts may  have  implemented  different
recovery  procedures,  they  can communicate with each other in a
compatible way.  In a network of independent machines  of  widely
varying  capabilities and requirements, this seems to be the only
way of implementing such a protocol.  Even though  this  protocol
provides  a  variety  of  options in a given error situation, the
choice of a specific action must be  consistent  with  the  basic
requirements  of  the  communication  path.  For example, partial
recovery is not  acceptable  during  file  transfers.   We  fully
expect   the  File  Transfer  Protocol  to  specify  that  if  an
irrecoverable error occurs, the file transfer must be aborted.






















                   - 19 -