rfc907.txt

RFC 相关的技术文档

                                    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
     allow more than one Notification  to  be  outstanding,  each   is
     assigned    a    unique   Notification   ID.   The   Notification
     Acknowledgment returned by the user host to the service host must
     contain the Notification ID.

          The general format of every setup message is:

                         <DATAGRAM MESSAGE HEADER>
                        <OPTIONAL INTERNET HEADER>
                          <SETUP MESSAGE HEADER>
                           <SETUP MESSAGE BODY>

     The service host accepts setup requests  in  either  Internet  or
     non-Internet  format.   Replies  from the service host will be in
     the same form as the request,  that  is,  Internet  requests  get
     Internet  replies,  and  non-Internet  requests  get non-Internet
     replies.

          The format of the combined datagram message header and setup
     message header is illustrated in Figure 6.  The body of the setup
     messages depends on the particular setup  message  type.   Stream
     request  and  reply messages are described in Section 6.1.  Group
     request and reply messages are  described  in  Section  6.2.   To
     simplify  the  presentation  in both of these sections, the setup
     messages are assumed to be exchanged between  a  local  host  and
     SIMP  even  though Internet group and stream setups are supported
     (see Figure 6).  The format of notifications, which  consists  of
     only  a  single  word  beyond the basic setup header, is shown in
     Figure 7.  Since the SIMP does not retain the  optional  Internet
     header  information  that  can  be  included  in  setup requests,
     Internet  notifications  are  not  supported.   The   format   of
     acknowledgment   messages   associated   with  request/reply  and
     notification setups is illustrated in Figure 8.





                                    25








     RFC 907                                      Host Access Protocol
     July 1984                                           Specification






              15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0