rfc907.txt

RFC 相关的技术文档

                    0 = Discard message if data errors detected.
                    1 = Don't discard message if data errors detected.


               The value of this flag, set  by  the  source  host,  is
               passed on to the destination host.

     3[12]     Data Error Flag.  This flag is used in conjunction with
               the  Discard  Flag  to indicate to the destination host
               whether any data  errors  have  been  detected  in  the
               message  prior  to  transmission  over the SIMP-to-Host
               access link.  It is used only if Discard Flag = 1.   It
               should be set to zero by the source host.




                                    11








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



                    0 = No Data Errors Detected
                    1 = Data Errors Detected


     3[10-11]  Time-to-Live Designator.  The  source  host  uses  this
               field  to  specify  the  maximum  time  that a  message
               should be allowed to exist within the satellite network
               before being deleted.  Messages may be discarded by the
               network prior to this maximum elapsed time.

                    0 = 1 seconds
                    1 = 2 seconds
                    2 = 5 seconds
                    3 = 10 seconds


               The Time-to-Live field is undefined  in  messages  sent
               from a SIMP to a host.

     3[8-9]    Priority.  The source host uses this field  to  specify
               the  priority  with which the message should be handled
               within the network.

                    0 = Low Priority
                    1 = Medium-Low Priority
                    2 = Medium-High Priority
                    3 = High Priority


               The  priority  of  each  message  is  passed   to   the
               destination host by the destination SIMP.

     3[6-7]    Reliability.   The  source  host  uses  this  field  to
               specify  the  basic  bit error rate requirement for the
               data portion of this message.   The  source  SIMP  uses
               this   field   to   determine   the  satellite  channel
               transmission parameters required to  provide  that  bit
               error rate.

                    0 = Low Reliability
                    1 = Medium Reliability



                                    12








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



                    2 = High Reliability
                    3 = Reserved


               The Reliability field is  undefined  in  messages  sent
               from a SIMP to a host.

     3[0-5]    Reliability Length.  This source host uses  this  field
               to  specify  a portion of the user data which should be
               transmitted at the highest  reliability  level  (lowest
               bit error rate).  Both the six message header words and
               the first Reliability Length words of user data will be
               transmitted at Reliability=2 while the remainder of the
               user data will be transmitted at  whatever  reliability
               level  is  specified  in field 3[6-7].  The reliability
               length mechanism gives the user the ability to transmit
               private  header  information (e.g., IP and TCP headers)
               at a higher reliability level than the remainder of the
               data.   The  Reliability  Length  field is undefined in
               messages sent from a SIMP to a host.

     4[0-15]   Destination Host  Address.   This  field  contains  the
               satellite  network  logical  address of the destination
               host.

     5[0-15]   Source Host Address.  This field contains the satellite
               network logical address of the source host.

     6-N       Data.  This field contains up to 16,384 bits (1024  16-
               bit words) of user data.














                                    13








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



     4  Stream Messages

          Stream messages are the second type of  message  level  data
     messages.   As  noted  in  Section  2, streams exist primarily to
     provide a one satellite hop delay for volatile  traffic  such  as
     speech.   Hosts  may  also use streams to support high duty cycle
     applications which require guaranteed channel bandwidth.

          Streams must be created before stream messages can flow from
     host  to  host.   The  protocol  to accomplish stream creation is
     described  in  Section  6.1.   Once  established,  a  stream   is
     associated   with  a  recurring  channel  allocation  within  the
     satellite network.  This fixed allocation imposes  rather  strict
     requirements  on  the  host using the stream if efficient channel
     utilization is to be achieved.  In  particular,  stream  messages
     must  match  the  stream allocation both in terms of message size
     and message interarrival time.

          Within the bounds  of  its  stream  allocation,  a  host  is
     permitted  considerable  flexibility  in how it may use a stream.
     Although the priority, reliability,  and  reliability  length  of
     each  stream  message  is  fixed  at  stream  creation  time, the
     destination logical address  can  vary  from  stream  message  to
     stream  message.   A host can, therefore,  multiplex a variety of
     logical flows onto a single host stream.  The  format  of  stream
     messages is described in Figure 2.


















                                    14








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification






              15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0      | 0|LB|GOPRI|   XXXX    |     MESSAGE NUMBER    |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      1      |               HEADER CHECKSUM                 |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2      |                      A/R                      |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      3      | 1|IL| D| E| TTL |       HOST STREAM ID        |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      4      |            DESTINATION HOST ADDRESS           |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      5      |              SOURCE HOST ADDRESS              |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     6-N     |                     DATA                      |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


                         Figure 2 . STREAM MESSAGE



     0[15]     Message Class = 0 (Data Message).

     0[14]     Loopback Bit.

     0[12-13]  Go-Priority.

     0[8-11]   Reserved.

     0[0-7]    Message Number.  This field serves the same purpose  as
               the  message  number  field  in  the  datagram message.
               Moreover, a single message number sequence is used  for
               both datagram and stream messages (see Section 5).

     1[0-15]   Header Checksum.  Covers Words 0-5.

     2[0-15]   Piggybacked A/R.



                                    15








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



     3[15]     Data Message Type = 1 (Stream).

     3[14]     Internet/Local Flag.

     3[13]     Discard Flag.

     3[12]     Data Error Flag.

     3[10-11]  Time-to-live Designator.

                    0 = Reserved
                    1 = 1 second
                    2 = Reserved
                    3 = Reserved

     3[0-9]    Host Stream ID.  The service host uses  this  field  to
               identify  the  host stream over which the message is to
               be sent by the SIMP.  Host stream IDs  are  established
               at  stream  creation time via host exchanges with their
               network service host (see Section 6.1).

     4[0-15]   Destination Host Address.

     5[0-15]   Source Host Address.

     6-N       Data.  This field contains up to 16,000  bits  of  user
               data (multiple of 16-bits).

















                                    16








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



     5  Flow Control Messages

          The SIMP supports an acceptance/refusal (A/R)  mechanism  in
     each  direction  on  the  host access link.  The A/R mechanism is
     enabled for the link by the host by setting a bit in the  Restart
     Complete  control  message  (see  Section  8).  Each datagram and
     stream message contains an 8-bit message number used to  identify
     the  message  for  flow  control purposes.  Both the host and the
     SIMP increment this number modulo 256 in successive messages they
     transmit.   Up  to  127  messages  may  be  outstanding  in  each
     direction at any time.  If the receiver of a message is unable to
     accept  the  message, a refusal indication containing the message
     number of the refused message and the reason for the  refusal  is
     returned.   The  refusal  indication  may  be piggybacked on data
     messages in the opposite direction over the link or may  be  sent
     in a separate control message in the absence of reverse traffic.

          Acceptance indications are returned  in  a  similar  manner,
     either  piggybacked  on  data  messages or in a  separate control
     message.  An acceptance is returned by the receiver  to  indicate
     that   the   identified  message  was  not  refused.   Acceptance
     indications returned  by  the  SIMP  do  not,  however,  imply  a
     guarantee of delivery or even any assurance that the message will
     not be intentionally discarded by the network at  a  later  time.
     They  are  sent  primarily to facilitate buffer management in the
     host.

          To reduce the number of A/R messages exchanged, a single A/R
     indication   can   be  returned  for  multiple  (lower  numbered)
     previously  unacknowledged  messages.   Explicit  acceptance   of
     message  number  N  implies  implicit  acceptance  of outstanding
     messages  with  numbers  N-1,  N-2,  etc.,   according   to   the
     definition  of  acceptance  outlined  above.  (Note that explicit
     acceptance of message number N  does not imply that  all  of  the
     unacknowledged  outstanding  messages  have  been  received.)  An
     analogous interpretation of refusal  message  number  allows  the
     receiver  of  a  group  of  messages  to  reject  them as a group
     assuming that they all are being refused for the same reason.  As
     a  further  efficiency  measure,  HAP  permits  a  block  of  A/R
     indications to be aggregated into a single A/R  control  message.
     Such  a  message might be used, for example, to reject a group of



                                    17








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



     messages where the refusal code on each is different.

          In  some  circumstances   the   overhead   associated   with
     processing A/R messages may prove unattractive.  For these cases,
     it is possible to disable the A/R mechanism and operate  the  HAP
     interface  in  a purely discard mode.  The ability to effect this
     on a link basis has already been noted (see Sections  2  and  8).
     In  addition,  messages  with  sequence number  zero are taken as
     messages for which the A/R mechanism is selectively disabled.  To
     permit  critical  feedback,  even when operating in discard mode,
     HAP defines an "Unnumbered Response" control message.

          The format shown in  Figure 3  is used both for piggybacking
     A/R  indications on data messages (word 2), and for providing A/R
     information in separate control messages.  When separate  control
     messages  are  used to transmit A/R indications, the format shown
     in  Figure  4  applies.   Flow  control  information  and   other
     information  which cannot be sent as an A/R indication is sent in
     an Unnumbered Response control message.  The format of this  type
     of message is illustrated in Figure 5.