rfc907.txt

RFC 的详细文档！

          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.
























                                    18








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification






              15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |AR|    REFUSAL CODE    |  A/R MESSAGE NUMBER   |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


                    Figure 3 . ACCEPTANCE/REFUSAL WORD



     [15]      Acceptance/Refusal Type.  This field identifies whether
               A/R information is an acceptance or a refusal.

                    0 = Acceptance
                    1 = Refusal

     [8-14]    Refusal Code.  When the Acceptance/Refusal  Type  =  1,
               this field gives the Refusal Code.

                    0 = Priority not being accepted
                    1 = Source SIMP congestion
                    2 = Destination SIMP congestion
                    3 = Destination host dead
                    4 = Destination SIMP dead
                    5 = Illegal destination host address
                    6 = Destination host access not allowed
                    7 = Illegal source host address
                    8 = Message lost in access link
                    9 = Nonexistent stream ID
                   10 = Illegal source host for stream ID
                   11 = Message length too long
                   12 = Stream message too early
                   13 = Illegal control message type
                   14 = Illegal refusal code in A/R
                   15 = Illegal reliability value
                   16 = Destination host congestion

     [0-7]     A/R Message Number.  This field contains the number  of



                                    19








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



               the  message  to  which this acceptance/refusal refers.
               It  also  applies  to  all  outstanding  messages  with
               earlier  numbers.   Note  that  this field can never be
               zero since a message number of zero  implies  that  the
               A/R mechanism is disabled.







































                                    20








     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      | 1|LB|GOPRI|   XXXX    |  LENGTH   |     1     |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      1      |                HEADER CHECKSUM                |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2      |                      A/R                      |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      .      .                      ...                      .
      .      .                      ...                      .
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      N      |                      A/R                      |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


                   Figure 4 . ACCEPTANCE/REFUSAL MESSAGE



     0[15]     Message Class = 1 (Control Message).

     0[14]     Loopback Bit.

     0[12-13]  Go-Priority.

     0[8-11]   Reserved.

     0[4-7]    Message Length.  This field contains the  total  length
               of this message in words (N+1).

     0[0-3]    Control Message Type = 1 (Acceptance/Refusal).

     1[0-15]   Header Checksum.  The checksum covers words 0-N.

     2[0-15]   Acceptance/Refusal Word.

     3-N       Additional Acceptance/Refusal Words (optional).




                                    21








     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      | 1|LB|GOPRI|   XXXX    | RES-CODE  |     5     |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      1      |                HEADER CHECKSUM                |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2      |                 RESPONSE INFO                 |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      3      |                 RESPONSE INFO                 |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


                      Figure 5 . UNNUMBERED RESPONSE



     0[15]     Message Class = 1 (Control Message).

     0[14]     Loopback Bit.

     0[12-13]  Go-Priority.

     0[8-11]   Reserved.

     0[4-7]    Response Code.

                    3 = Destination unreachable
                    5 = Illegal destination host address
                    7 = Illegal source host address
                    9 = Nonexistent stream ID
                   10 = Illegal stream ID
                   13 = Protocol violation
                   15 = Can't implement loop

     0[0-3]    Control Message Type = 5 (Unnumbered Response).

     1[0-15]   Header Checksum.  Covers words 0-3.




                                    22








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



     2[0-15]   Response Information. If Response Code is:

                    3, Destination Host Address
                    5, Destination Host Address
                    7, Source Host Address
                    9, Stream ID (right justified)
                   10, Stream ID (right justified)
                   13, Word 0 of offending message
                   15, Word 0 of Loopback Request message

     3[0-15]   Response Information. If Response Code is:

                    3,5,7, or 9. Undefined
                    10, Source Host Address
                    13, Word 3 of offending message, or zero if
                        no word 3
                    15, Word 2 of Loopback Request message



























                                    23








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



     6  Setup Level Messages

          Setup  level   protocol   is   provided   to   support   the
     establishment,  modification,  and deletion of groups and streams
     in the packet satellite network.  A host wishing to  perform  one
     of  these  generic  operations interacts with the network service
     host  (logical  address  zero).   The  service  host  causes  the
     requested action to be carried out and serves as the intermediary
     between the user and the rest of the network.  In the process  of
     implementing the requested action, various network data bases are
     updated to reflect the current state of the referenced  group  or
     stream.

          The communication between the host and the service  host  is
     implemented  via special-purpose datagrams called setup messages.
     Each interaction initiated by a host involves  a  3-way  exchange
     where: (1) the user host sends a Request to the service host, (2)
     the service host returns a Reply to the user host,  and  (3)  the
     user  host  returns  a  Reply Acknowledgment to the service host.
     This procedure  is  used  to   insure  reliable  transmission  of
     requests  and  replies.   In  order  to allow more than one setup
     request message from a host to be outstanding,  each  request  is
     assigned   a   unique  Request  ID.   The  associated  Reply  and
     subsequent Reply Acknowledgment are identified by the Request  ID
     that they contain.  Hosts should generally expect a minimum delay
     of about two satellite round-trip times between the  transmission
     of  a setup Request to the SIMP and the receipt of the associated
     Reply.  (Note that the Join Group Request  and  the  Leave  Group
     Request  require  only local communication between a host and its
     SIMP.  The  response  time  for  these  requests,  therefore,  is
     dependent   solely   on   SIMP  processing  time  and  should  be
     considerably shorter  than  two  round-trip  times.)  This  delay
     establishes  a  maximum rate at which changes can be processed by
     the SIMP.  The user should receive a reply  to  a  setup  request
     requiring  global  communication  within 2 seconds and to a setup
     request requiring local communication within 1 second.  The  host
     should respond to a SIMP Reply with a Reply Acknowledgment within
     1 second.






                                    24








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification



          Setup exchanges can also be initiated  by  the  SIMP.  SIMP-
     initiated  setup messages are used to notify a host of changes in
     the status of an associated group or  stream.  Each  notification
     involves  a  2-way  exchange  where: (1) the service host sends a
     Notification to the user host, and (2) the user  host  returns  a
     Notification  Acknowledgment  to  the  service  host. In order to