GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc907
   RFC 907
                  HOST ACCESS PROTOCOL SPECIFICATION
                               July 1984
                             prepared for
               Defense Advanced Research Projects Agency
                         1400 Wilson Boulevard
                       Arlington, Virginia 22209
                                  by
                 Bolt Beranek and Newman Laboratories
                           10 Moulton Street
                    Cambridge, Massachusetts 02238
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   Preface (Status of this Memo)
        This document specifies  the  Host  Access  Protocol  (HAP).
   Although  HAP was originally designed as the network-access level
   protocol for the DARPA/DCA sponsored  Wideband  Packet  Satellite
   Network,  it is intended that it evolve into a standard interface
   between hosts and  packet-switched  satellite  networks  such  as
   SATNET  and  TACNET (aka MATNET) as well as the Wideband Network.
   The HAP specification presented here is a minor revision of,  and
   supercedes,  the  specification  presented  in  Chapter  4 of BBN
   Report No. 4469, the  "PSAT  Technical  Report".   As  such,  the
   details  of  the  current  specification  are  still most closely
   matched to the characteristics if the Wideband Satellite Network.
   Revisions  to  the  specification  in the "PSAT Technical Report"
   include  the  definition  of  three  new  control  message  types
   (Loopback Request, Link Going Down, and NOP), a "Reason" field in
   Restart Request control messages, new Unnumbered Response  codes,
   and  new  values  for  the setup codes used to manage streams and
   groups.
        HAP is an experimental protocol, and  will  undergo  further
   revision as new capabilities are added and/or different satellite
   networks  are  supported.   Implementations  of  HAP  should   be
   performed  in coordination with satellite network development and
   operations personnel.
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
                           Table of Contents
   1   Introduction.......................................... 1
   2   Overview.............................................. 3
   3   Datagram Messages..................................... 8
   4   Stream Messages...................................... 14
   5   Flow Control Messages................................ 17
   6   Setup Level Messages................................. 24
   6.1   Stream Setup Messages.............................. 32
   6.2   Group Setup Messages............................... 44
   7   Link Monitoring...................................... 58
   8   Initialization....................................... 62
   9   Loopback Control..................................... 68
   10   Other Control Messages.............................. 72
                                   i
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
                                FIGURES
   DATAGRAM MESSAGE.......................................... 9
   STREAM MESSAGE........................................... 15
   ACCEPTANCE/REFUSAL WORD.................................. 19
   ACCEPTANCE/REFUSAL MESSAGE............................... 21
   UNNUMBERED RESPONSE...................................... 22
   SETUP MESSAGE HEADER..................................... 26
   NOTIFICATION MESSAGE..................................... 29
   SETUP ACKNOWLEDGMENT..................................... 31
   STREAM EXAMPLE........................................... 33
   CREATE STREAM REQUEST.................................... 35
   CREATE STREAM REPLY...................................... 37
   CHANGE STREAM PARAMETERS REQUEST......................... 39
   CHANGE STREAM PARAMETERS REPLY........................... 41
   DELETE STREAM REQUEST.................................... 42
   DELETE STREAM REPLY...................................... 43
   GROUP EXAMPLE............................................ 45
   CREATE GROUP REQUEST..................................... 47
   CREATE GROUP REPLY....................................... 48
   JOIN GROUP REQUEST....................................... 50
   JOIN GROUP REPLY......................................... 52
   LEAVE GROUP REQUEST...................................... 53
   LEAVE GROUP REPLY........................................ 55
   DELETE GROUP REQUEST..................................... 56
   DELETE GROUP REPLY....................................... 57
   STATUS MESSAGE........................................... 59
   HAP LINK RESTART STATE DIAGRAM........................... 64
   RESTART REQUEST.......................................... 65
   RESTART COMPLETE......................................... 67
   LOOPBACK REQUEST......................................... 71
   LINK GOING DOWN.......................................... 73
   NO OPERATION (NOP)....................................... 75
                                  ii
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   1  Introduction
        The Host Access Protocol (HAP) specifies the  network-access
   level communication between an arbitrary computer, called a host,
   and a packet-switched satellite network.  The  satellite  network
   provides  message  delivery services for geographically separated
   hosts: Messages containing data which are meaningful to the hosts
   are submitted to the network by an originating (source) host, and
   are passed transparently through  the  network  to  an  indicated
   destination host.  To utilize such services, a host interfaces to
   the satellite network via an access link to a  dedicated  packet-
   switching  computer,  known  as  a  Satellite  Interface  Message
   Processor (Satellite IMP or SIMP).   HAP  defines  the  different
   types  of  control messages and (host-to-host) data messages that
   may be exchanged over the access link connecting  a  host  and  a
   SIMP.   The  protocol establishes formats for these messages, and
   describes procedures for determining when each  type  of  message
   should be transmitted and what it means when one is received.
        The term "Interface Message  Processor"  originates  in  the
   ARPANET, where it refers to the ARPANET's packet-switching nodes.
   SIMPs differ from ARPANET IMPs in that SIMPs form a  network  via
   connections  to a common multiaccess/broadcast satellite channel,
   whereas ARPANET IMPs are interconnected  by  dedicated  point-to-
   point   terrestrial   communications   lines.   This  fundamental
   difference between  satellite-based  and  ARPANET-style  networks
   results in different mechanisms for the delivery of messages from
   source  to   destination   hosts   and   for   internal   network
   coordination.   Additionally,  satellite  networks  tend to offer
   different type of service options to their connected  hosts  than
   do  ARPANET-style  networks.   These  options are included in the
   Host Access Protocol presented here.
        Several types of Satellite IMPs have  been  developed  on  a
   variety  of processors for the support of three different packet-
   switched satellite networks.  The original SIMP was  employed  in
   the Atlantic Packet Satellite Network (SATNET).  It was developed
   from one of the models of ARPANET IMP, and was implemented  on  a
   Honeywell  316  minicomputer.   The  316  SIMPs were succeeded in
   SATNET by  SIMPs  based  on  BBN  C/30  Communications  Processor
   hardware.   The  C/30 SIMPs have also been employed in the Mobile
                                   1
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   Access Terminal Network (MATNET).  The SATNET  and  MATNET  SIMPs
   implement  a  network-access  level protocol known as Host/SATNET
   Protocol.  Host/SATNET Protocol is the precursor to  HAP  and  is
   documented  in  Internet  Experiment  Note  (IEN)  No.  192.  The
   Wideband  Satellite  Network,  like  SATNET,  has  undergone   an
   evolution  in  the development of its SIMP hardware and software.
   The original Wideband Network  SIMP  is  known  as  the  Pluribus
   Satellite  IMP,  or  PSAT,  having  been  implemented  on the BBN
   Pluribus Multiprocessor.  Its successor, the BSAT,  is  based  on
   the  BBN  Butterfly  Multiprocessor.   Both the PSAT and the BSAT
   communicate with their connected network hosts via HAP.
        Section 2 presents an  overview  of  HAP.   Details  of  HAP
   formats and message exchange procedures are contained in Sections
   3  through  10.   Further  explanation  of  many  of  the  topics
   addressed  in  this  HAP specification can be found in BBN Report
   No. 4469, the "PSAT Technical Report".
        The protocol used to provide sufficiently  reliable  message
   exchange  over the host-SIMP link is assumed to be transparent to
   the network-access protocol defined in this  document.   Examples
   of  such  link-level protocols are ARPANET 1822 local and distant
   host, ARPANET VDH protocol, and HDLC.
                                   2
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   2  Overview
        HAP can  be  characterized  as  a  full  duplex  nonreliable
   protocol  with  an optional flow control mechanism.  HAP messages
   flow simultaneously in both directions between the SIMP  and  the
   host.  Transmission is nonreliable in the sense that the protocol
   does not provide any guarantee of error-free sequenced  delivery.
   To  the  extent that this functionality is required on the access
   link  (e.g.,  non-collocated  SIMP  and  host  operating  over  a
   communication  circuit),  it  must be supported by the link-level
   protocol  below  HAP.   The  flow  control   mechanism   operates
   independently in each direction except that enabling or disabling
   the mechanism applies to both sides of the interface.
        HAP  supports  host-to-host  communication  in   two   modes
   corresponding  to  the  two  types of HAP data messages, datagram
   messages and stream messages.  Each type of message can be up  to
   approximately  16K bits in length.  Datagram messages provide the
   basic transmission service in the  satellite  network.   Datagram
   messages transmitted by a host experience a nominal two satellite
   hop end-to-end network delay. (Note that this delay, of about 0.6
   sec  excluding  access  link  delay,  is associated with datagram
   transmission between hosts on different SIMPs.  The  transmission
   delay  between  hosts  on  the  same  SIMP  will  be much smaller
   assuming the destination is not a group address.  See  Section  3
   and  6.2.)  A  datagram control header, passed to the SIMP by the
   host along with message text, determines the  processing  of  the
   message  within the satellite network independent of any previous
   exchanges.
        Stream  messages  provide  a   one   satellite   hop   delay
   (approximately  0.3  sec)  for  volatile traffic, such as speech,
   which  cannot  tolerate  the  delay  associated   with   datagram
   transmission.   Hosts  may  also use streams to support high duty
   cycle applications which require  guaranteed  channel  bandwidth.
   Host  streams are established by a setup message exchange between
   the host and the network prior to the commencement of data  flow.
   Although  established host streams can have their characteristics
   modified by subsequent setup messages while they are in use,  the
   fixed  allocation  properties  of  streams  relative to datagrams
   impose rather strict requirements on the source  of  the  traffic
                                   3
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   using  the stream.  Stream traffic arrivals must match the stream
   allocation  both  in  interarrival  time  and  message  size   if
   reasonable efficiency is to be achieved.  The characteristics and
   use of datagrams and streams are described in detail in  Sections
   3 and 4 of this document.
        Both datagram  and  stream  transmission  in  the  satellite
   network  use  logical  addressing.   Each  host on the network is
   assigned a permanent 16-bit logical address which is  independent
   of  the physical port on the SIMP to which it is attached.  These
   16-bit logical addresses are provided  in  all  Host-to-SIMP  and
   SIMP-to-Host data messages.
        Hosts may also be members of groups.   Group  addressing  is
   provided  primarily  to  support  the  multi-destination delivery
   required for  conferencing  applications.   Like  streams,  group
   addresses are dynamically created and deleted by the use of setup
   messages exchanged between a host and the network.  Membership in
   a  group  may consist of an arbitrary subset of all the permanent
   network hosts.   A  message  addressed  to  a  group  address  is
   delivered to all hosts that are members of that group.
        Although HAP does not guarantee error-free  delivery,  error
   control is an important aspect of the protocol design.  HAP error
   control is concerned with both local transfers between a host and
   its local SIMP and transfers from SIMP-to-SIMP over the satellite
   channel.  The  SIMP  offers  users  a  choice  of  network  error
   protection  options based on the network's ability to selectively
   send messages over the  satellite  channel  at  different  coding
   rates.  These forward error correction (FEC) options are referred
   to as reliability levels.  Three reliability levels (low, medium,
   and high) are available to the host.
        In  addition  to  forward  error  correction,  a  number  of
   checksum  mechanisms are employed in the satellite network to add
   an error detection capability.  A host has  an  opportunity  when
   sending  a  message  to  indicate  whether  the message should be
   delivered to its destination or discarded  if  a  data  error  is
   detected  by  the  network.  Each message received by a host from
   the network will have a flag indicating whether or not  an  error
   was  detected in that particular message.  A host can decide on a
                                   4
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   per-message basis whether or not it wants to  accept  or  discard
   transmissions containing data errors.
        For connection of a host and SIMP in close proximity,  error
   rates  due  to  external noise or hardware failures on the access
   circuit may reasonably be expected to be much  smaller  than  the
   best satellite channel error rate.  Thus for this case, little is
   gained by using error detection and retransmission on the  access
   circuit.   A  16-bit  header  checksum  is  provided, however, to
   insure that SIMPs do not act on  incorrect  control  information.
   For    relatively    long   distances   or   noisy   connections,
   retransmissions over  the  access  circuit  may  be  required  to
   optimize  performance  for both low and high reliability traffic.
   It is expected that link-level error control procedures (such  as
   HDLC) will be used for this purpose.
        Datagram and stream messages being presented to the  network
   by  a  host may not be accepted for a number of reasons: priority
   too low, destination dead, lack of buffers in  the  source  SIMP,
   etc.  The host faces a similar situation with respect to handling
   messages from the SIMP.  To permit the receiver of a  message  to
   inform  the  sender  of  the local disposition of its message, an
   acceptance/refusal (A/R) mechanism is implemented.  The mechanism
   is  the external manifestation of the SIMP's (or host's) internal
   flow and congestion control algorithm.  If A/Rs are  enabled,  an
   explicit  or  implicit  acceptance or refusal for each message is
   returned to the host by the SIMP (and conversely).   This  allows
   the  host  (or  SIMP) to retry refused messages at its discretion
   and can provide information useful for optimizing the sending  of
   subsequent  messages if the reason for refusals is also provided.
   The A/R mechanism can be disabled to  provide  a  "pure  discard"
   interface.
        Each message submitted to the SIMP by a host  is  marked  as
   being  in one of four priority classes, from priority 3 (highest)
   through priority 0 (lowest).  The priority class is used  by  the
   SIMP  for  arbitrating  contention  for  scarce network resources
   (e.g., channel time).  That is, if the network cannot deliver all
   of the offered messages, high priority messages will be delivered
   in  preference  to  low  priority  messages.   In  the  case   of
   datagrams,  priority  level  is  used  by  the  SIMP for ordering
                                   5
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   satellite channel reservation requests at  the  source  SIMP  and
   message  delivery  at  the  destination  SIMP.   In  the  case of
   streams, priority is associated with the ability of one stream to
   preempt another stream of lower priority at setup time.
        While the A/R mechanism allows control of individual message
   transfers,  it  does not facilitate regulation of priority flows.
   Such regulation is handled by passing advisory status information
   (GOPRI)   across   the   Host-SIMP   interface  indicating  which
   priorities  are  currently  being  accepted.   As  long  as  this
   information, relative to the change in priority status, is passed
   frequently, the sender can avoid originating messages  which  are
   sure to be refused.
        HAP defines both data messages (datagram messages and stream
   messages)  and  control messages.  Data messages are used to send
   information  between  network  hosts.    Control   messages   are
   exchanged  between  a  host  and  the network to manage the local
   access link.  HAP can also be viewed in  terms  of  two  distinct
   protocol  layers,  the  message  layer  and the setup layer.  The
   message layer is associated with the transmission  of  individual
   datagram  messages and stream messages.  The setup layer protocol
   is associated with the establishment, modification, and  deletion
   of  streams  and  groups.   Setup  layer  exchanges  are actually
   implemented as datagrams transmitted between the user host and an
   internal SIMP "service host."
        Every HAP message consists of an integral number  of  16-bit
   words.   The  first  several  words of the message always contain
   control information and are referred to as  the  message  header.
   The  first  word  of  the  message  header identifies the type of
   message which follows.  The second word of the message header  is
   a  checksum  which  covers  all  header information.  Any message
   whose received  header  checksum  does  not  match  the  checksum
   computed  on  the  received header information must be discarded.
   The format of the rest of the  header  depends  on  the  specific
   message type.
        The formats and use of  the  individual  message  types  are
   detailed  in the following sections.  A common format description
   is used for this  purpose.   Words  in  a  message  are  numbered
                                   6
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   starting  at  zero  (i.e.,  zero  is  the first word of a message
   header).  Bits within  a  word  are  numbered  from  zero  (least
   significant) to fifteen (most significant).  The notation used to
   identify a particular field location is:
   <WORD#>{-<WORD#>}  [ <BIT#>{-<BIT#>} ]  <description>
   where optional elements in {} are used to specify the (inclusive)
   upper  limit  of a range.  The reader should refer to these field
   identifiers for precise field size specifications.  Fields  which
   are  common  to  several  message  types are defined in the first
   section which uses them.  Only the name of the field will usually
   appear in the descriptions in subsequent sections.
        Link-level protocols used to support HAP can differ  in  the
   order  in which they transmit the bits constituting HAP messages.
   For HDLC  and  ARPANET  VDH,  each  word  of  a  HAP  message  is
   transmitted  starting  with the least significant bit (bit 0) and
   ending with the most significant bit (bit 15).  The words of  the
   message  are transmitted from word 0 to word N.  For ARPANET 1822
   local and distant host interfaces, the order of bit  transmission
   within  each  word is the reverse of that for HDLC and VDH, i.e.,
   the transmission is from bit 15 to bit 0.
                                   7
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   3  Datagram Messages
        Datagram messages are one of the two types of message  level
   data  messages  used to support host-to-host communication.  Each
   datagram can contain up to 16,384 bits of  user  data.   Datagram
   messages  transmitted  by  a  host  to  a  host  on a remote SIMP
   experience a nominal two satellite hop end-to-end  network  delay
   (about  0.6  sec),  excluding  delay  on  the access links.  This
   network delay is due to the reservation  per  message  scheduling
   procedure  for datagrams which only allocates channel time to the
   message for the duration of the actual transfer.  Since  datagram
   transfers between permanent hosts on the same SIMP do not require
   satellite channel scheduling prior  to  data  transmission,   the
   network delay in this case will be much smaller and is determined
   strictly  by  SIMP  processing  time.  Datagrams  sent  to  group
   addresses  are treated as if they were addressed to  remote hosts
   and are  always sent over the satellite channel.  It is  expected
   that  datagram  messages  will be used to support the majority of
   computer-to-computer and terminal-to-computer  traffic  which  is
   bursty in nature.
        The format of datagram messages and the purpose of  each  of
   the header control fields is described in Figure 1.
                                   8
   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  | F|     MESSAGE NUMBER    |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    1      |               HEADER CHECKSUM                 |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    2      |                      A/R                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    3      | 0|IL| D| E| TTL | PRI | RLY |      RLEN       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    4      |            DESTINATION HOST ADDRESS           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    5      |              SOURCE HOST ADDRESS              |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   6-N     |                     DATA                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                      Figure 1 . DATAGRAM MESSAGE
   0[15]     Message Class.  This bit identifies the  message  as  a
             data message or a control message.
                  0 = Data Message
                  1 = Control Message
   0[14]     Loopback Bit.  This bit allows the sender of a  message
             to determine if its own messages are being looped back.
             The host and the SIMP each use  different  settings  of
             this bit for their transmissions.  If a message arrives
             with the loopback bit set equal to its outgoing  value,
             then the message has been looped.
                  0 = Sent by Host
                  1 = Sent by SIMP
                                   9
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   0[12-13]  Go-Priority.   In  SIMP-to-Host  messages,  this  field
             provides  advisory  information  concerning  the lowest
             priority currently being accepted  by  the  SIMP.   The
             host  may optionally choose to provide similar priority
             information to the SIMP.
                  0 = Low Priority
                  1 = Medium-Low Priority
                  2 = Medium-High Priority
                  3 = High Priority
   0[9-11]   Reserved.
   0[8]      Force Channel Transmission Flag.  This flag can be  set
             by  the  source  host to force the SIMP to transmit the
             message over the satellite channel even if the  message
             contains   permanent   destination   and   source  host
             addresses corresponding to hosts which  are  physically
             connected to the same SIMP.
                  0 = Normal operation
                  1 = Force channel transmission
   0[0-7]    Message Number.  This field contains the identification
             of  the  message  used  by the acceptance/refusal (A/R)
             mechanism (when enabled).  If  the  message  number  is
             zero,  A/R  is disabled for this specific message.  See
             Section  5  for  a  detailed  description  of  the  A/R
             mechanism.
   1[0-15]   Header Checksum.  This field contains a checksum  which
             covers  words  0-5.   It is computed as the negation of
             the 2's-complement sum  of  words  0-5  (excluding  the
             checksum word itself).
   2[0-15]   Piggybacked   A/R.    This   field   may   contain   an
             acceptance/refusal word providing A/R status on traffic
             flowing in the opposite direction.  Its  inclusion  may
             eliminate  the  need for a separate A/R control message
             (see Section 5).  A value of zero for this word is used
             to  indicate  that  no  piggybacked  A/R information is
                                  10
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
             present.
   3[15]     Data Message Type.  This  bit  identifies  whether  the
             message is a datagram message or a stream message.
                  0 = Datagram Message
                  1 = Stream Message
   3[14]     Internet/Local Flag.  This flag is set by a source host
             to  specify  to  a  destination  host  whether the data
             portion of the message contains a standard DoD Internet
             header.   This  field  is  passed  transparently by the
             source  and  destination  SIMPs  for  traffic   between
             external   satellite   network  hosts.  This  field  is
             examined by internal  SIMP  hosts  (e.g.,  the  network
             service host) in order to support Internet operation.
                  0 = Internet
                  1 = Local
   3[13]     Discard Flag.   This  flag  allows  a  source  host  to
             instruct   the   satellite   network   (including   the
             destination host) what to do with the message when data
             errors  are  detected  (assuming the header checksum is
             correct).
                  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.
                                  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
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   0-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   6-N     |          <OPTIONAL INTERNET HEADER>           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   N+1     |      SETUP TYPE       |      SETUP CODE       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   N+2     |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   N+3     |                   SETUP  ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 6 . SETUP MESSAGE HEADER
   0-5        Datagram Message Header.  Each  setup  message  begins
              with the six word datagram message header (see Section
              3).
   6-N        Internet  Header  (Optional).   These   fields,   when
              present, conform to the DoD Standard Internet Protocol
              (IP). The Internet header size  is  a  minimum  of  10
              words  but  can  be  longer  depending  on  the use of
              optional  IP   facilities.    (Internet   notification
              messages are not supported.)
   N+1[8-15]  Setup Type.  This field determines the type  of  setup
              message.
                   0 = Acknowledgment
                   1 = Request
                   2 = Reply
                   3 = Notification
   N+1[0-7]   Setup Code.  For requests,  this field identifies  the
                                  26
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
              Request Type.
                   1 = Create group address
                   2 = Delete group address
                   3 = Join group
                   4 = Leave group
                   5 = Create stream
                   6 = Delete stream
                   7 = Change stream parameters
                   8 = Reserved
              For Replies, this field provides the Reply Code.  Some
              of  the  Reply  Codes  can  be  returned  to any setup
              request and others are request specific.
                   0 = Group or stream created
                   1 = Group or stream deleted
                   2 = Group joined
                   3 = Group left
                   4 = Stream changed
                   5 = Reserved
                   6 = Bad request type
                   7 = Reserved
                   8 = Network trouble
                   9 = Bad key
                  10 = Group address/stream ID nonexistent
                  11 = Not member of group/creator of stream
                  12 = Stream priority not being accepted
                  13 = Reserved
                  14 = Reserved
                  15 = Illegal interval
                  16 = Reserved
                  17 = Insufficient network resources
                  18 = Requested bandwidth too large
                  19 = Reserved
                  20 = Reserved
                  21 = Maximum messages per slot not consistent with
                       slot size
                  22 = Reply lost in network
                  23 = Illegal reliability value
                                  27
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
              For   Notifications,   this   field    contains    the
              Notification Type.
                   0 = Stream suspended
                   1 = Stream resumed
                   2 = Stream deleted
                   3 = Group deleted by host
                   4 = Group deleted by SIMP
                   5 = All streams deleted
                   6 = All groups deleted
              For   Acknowledgments,   this   field   contains   the
              Acknowledgment Type.
                   0 = Reply acknowledgment
                   1 = Notification acknowledgment
   N+2[0-15]  Setup Checksum.  The checksum covers the  three  setup
              message  header  words and the setup message body data
              words.  Setups received with  bad  checksums  must  be
              discarded.
   N+3[0-15]  Setup ID.  This field  is  assigned  by  the  host  to
              uniquely  identify  outstanding  requests (Request ID)
              and  by  the  service  host   to   uniquely   identify
              outstanding notifications (Notification ID).
                                  28
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           3           |   NOTIFICATION TYPE   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                 NOTIFICATION ID               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |                NOTIFICATION INFO              |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 7 . NOTIFICATION MESSAGE
   0-5         Datagram Message Header (see Section 3).
     6[8-15]   Setup Type = 3 (Notification).
     6[0-7]    Notification Type.
                    0 = Stream suspended
                    1 = Stream resumed
                    2 = Stream deleted
                    3 = Group deleted by host
                    4 = Group deleted by SIMP
                    5 = All streams deleted
                    6 = All groups deleted
     7[0-15]   Setup Checksum. Covers words 6-9.
     8[0-15]   Notification ID.
     9[0-15]   Notification Information.  This  field  contains  the
               16-bit   group   address  in  the  case  of  a  group
                                  29
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
               notification (types 3 and  4)  and  the  10-bit  host
               stream  ID  (right justified) in the case of a stream
               notification (types 0-2).  This  field  is  zero  for
               Notification  Types  5  and  6,  which pertain to ALL
               streams and groups, respectively.
                                  30
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           0           |        ACK TYPE       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                   SETUP  ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 8 . SETUP ACKNOWLEDGMENT
   0-5         Datagram Message Header.
     6[8-15]   Setup Type = 0 (Acknowledgment).
     6[0-7]    Acknowledgment Type.
                   0 = Reply acknowledgment
                   1 = Notification acknowledgment
     7[0-15]   Setup Checksum.  Covers words 6-8.
     8[0-15]   Setup  ID.   This  is  either  a  Request  ID  or   a
               Notification ID.
                                  31
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   6.1  Stream Setup Messages
        Hosts use  streams to support high duty  cycle  applications
   and   applications   requiring   a   one  satellite  hop  network
   transmission delay.  Host streams must be set  up  before  stream
   data messages can flow.  The stream setup messages defined by HAP
   are Create Stream Request, Create  Stream  Reply,  Delete  Stream
   Request,  Delete  Stream Reply, Change Stream Parameters Request,
   and Change Stream Parameters Reply.  The use of these messages is
   illustrated  in  the scenario of exchanges between a host and its
   local SIMP shown in Figure 9 where the host establishes a stream,
   sends  some data, modifies the stream characteristics, sends some
   more data, and finally closes down the stream.
        It is worthwhile noting that the setup exchanges in Figure 9
   are  completely  between  the host originating the stream and its
   local SIMP.  Other SIMPs and hosts are essentially unaware of the
   existence   of   the  stream.   Stream  messages  received  by  a
   destination  host  are,  therefore,  processed   identically   to
   datagram  messages.   (All SIMPs must, of course, be aware of the
   channel allocation associated with a  host  stream  in  order  to
   perform  satellite  channel  scheduling.)   Not  illustrated, but
   implicit in this  scenario,  are  the  optional  A/R  indications
   associated with each of the stream setup messages.
                                  32
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
                                            Host       SIMP
           Create Stream Request                ------>
           Create Stream Reply                  <------
           Reply Acknowledgment                 ------>
           Stream Message                       ------>
                .
                .
           Stream Message                       ------>
           Change Stream Parameters Request     ------>
           Change Stream Parameters Reply       <------
           Reply Acknowledgment                 ------>
           Stream Message                       ------>
                .
                .
           Stream Message                       ------>
           Delete Stream Request                ------>
           Delete Stream Reply                  <------
           Reply Acknowledgment                 ------>
                       Figure 9 . STREAM EXAMPLE
        Host streams have six characteristic  properties  which  are
   selected  at stream setup time.  These properties, which apply to
   every message transmitted in the stream, are: (1) slot size,  (2)
   interval,  (3) reliability, (4) reliability length, (5) priority,
   and (6) maximum messages per slot.  To establish  a  stream,  the
   host  sends  the  Create  Stream  Request  message illustrated in
   Figure 10 to the SIMP.  After the satellite network has processed
   the Create Stream Request, the SIMP will respond to the host with
   a Create Stream Reply message formatted as shown  in  Figure  11.
   Assuming  that the reply code in the Create Stream Reply  is zero
   indicating that the stream has  been  created  successfully,  the
   host may proceed to transmit stream data messages after sending a
                                  33
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   Reply Acknowledgment.
        During the lifetime of a stream, the host which  created  it
   may  decide that some of its six characteristic properties should
   be modified.  All of the properties except  the  stream  interval
   can  be  modified  using  the  Change  Stream  Parameters Request
   message.  The format of this command is illustrated in Figure 12.
   After  the  network  has  processed  the Change Stream Parameters
   Request, the  SIMP  will  respond  by  sending  a  Change  Stream
   Parameters  Reply to the host with the format shown in Figure 13.
   A host requesting a reduced channel  allocation  should  decrease
   its  sending  rate immediately without waiting for receipt of the
   Change Stream Parameters Reply.  A host requesting  an  increased
   allocation  should  not  proceed to transmit according to the new
   set of parameters without first having received a Reply Code of 4
   indicating that the requested change has taken effect.
        When the host which created the host stream determines  that
   the  stream  is  no  longer  needed  and the associated satellite
   channel allocation can be freed up, the host sends its local SIMP
   a  Delete Stream Request message formatted as indicated in Figure
   14.  After the network has processed the Delete  Stream  Request,
   the  SIMP  will  respond  by sending a Delete Stream Reply to the
   host with the format shown in Figure 15.
                                  34
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           1           |           5           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |  MAX MES  | INT | PRI | RLY |      RLEN       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   10      |                   SLOT SIZE                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                   Figure 10 . CREATE STREAM REQUEST
   0-5         Datagram Message Header.
     6[8-15]   Setup Type = 1 (Request).
     6[0-7]    Request Type = 5 (Create Stream).
     7[0-15]   Setup Checksum.  Covers words 6-10.
     8[0-15]   Request ID.
     9[12-15]  Maximum Messages Per Slot.  This field specifies  the
               the  maximum number of stream messages that will ever
               be delivered to the SIMP by the host for transmission
               in one stream slot.
     9[10-11]  Interval.  This  field  specifies  the  interval,  in
               number of 21.2 ms  frames, between stream slots.
                                  35
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
                    0 = 1 frame
                    1 = 2 frames
                    2 = 4 frames
                    3 = 8 frames
               As an example, an interval of 4 frames corresponds to
               an allocation of Slot Size words every 85 ms.
     9[8-9]    Priority.  This field specifies the priority at which
               all messages in the host stream should be handled.
                    0 = Low priority
                    1 = Medium Low Priority
                    2 = Medium High Priority
                    3 = High Priority
     9[6-7]    Reliability.  This field  specifies  the  basic  bit-
               error  rate  requirement  for the data portion of all
               messages in the host stream.
                    0 = Low Reliability
                    1 = Medium Reliability
                    2 = High Reliability
                    3 = Reserved
     9[0-5]    Reliability Length.  This field  specifies  how  many
               words  beyond  the  stream  message  header should be
               transmitted at maximum reliability for  all  messages
               in the host stream.
     10[0-15]  Slot Size.  This field specifies  the  slot  size  in
               16-bit  words of stream message text.  Stream message
               header words are excluded from this count.  The  host
               can partition this allocation on a slot-by-slot basis
               among a variable number of messages as  long  as  the
               maximum  number  of messages per slot does not exceed
               MAX MES.
                                  36
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           2           |      REPLY CODE       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |      XXXXX      |       HOST STREAM ID        |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 11 . CREATE STREAM REPLY
   0-5          Datagram Message Header.
     6[8-15]    Setup Type = 2 (Reply).
     6[0-7]     Reply Code.
                     0 = Stream created
                     8 = Network trouble
                    12 = Stream priority not being accepted
                    17 = Insufficient network resources
                    18 = Requested bandwidth too large
                    21 = Maximum messages per slot not consistent
                         with slot size
                    22 = Reply lost in network
                    23 = Illegal reliability value
     7[0-15]    Setup Checksum.  Covers words 6-9.
     8[0-15]    Request ID.
                                  37
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
     9[10-15]   Reserved.
     9[0-9]     Host Stream ID.  This field contains a  host  stream
                ID  assigned by the network.  It must be included in
                all stream data messages sent by the host  to  allow
                the SIMP to associate the message with stored stream
                characteristics and the reserved  satellite  channel
                time.
                                  38
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           1           |           7           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |      XXXXX      |       HOST STREAM ID        |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   10      |  MAX MES  | INT | PRI | RLY |      RLEN       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   11      |                   SLOT SIZE                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             Figure 12 . CHANGE STREAM PARAMETERS REQUEST
   0-5          Datagram Message Header.
     6[8-15]    Setup Type = 1 (Request).
     6[0-7]     Request Type = 7 (Change Stream Parameters).
     7[0-15]    Setup Checksum.  Covers words 6-11.
     8[0-15]    Request ID.
     9[10-15]   Reserved.
     9[0-9]     Host Stream ID.
     10[12-15]  New Maximum Messages Per Slot.
                                  39
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
     10[10-11]  Interval.   This  field  must  specifiy   the   same
                interval  as  was  specified  in  the  Create Stream
                Request message for this stream.
     10[8-9]    New Priority.
     10[6-7]    New Reliability.
     10[0-5]    New Reliability Length.
     11[0-15]   New Slot Size.
                                  40
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           2           |      REPLY CODE       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
              Figure 13 . CHANGE STREAM PARAMETERS REPLY
   0-5        Datagram Message Header.
     6[8-15]  Setup Type = 2 (Reply).
     6[0-7]   Reply Code.
                   4 = Stream changed
                   8 = Network trouble
                  10 = Stream ID nonexistent
                  11 = Not creator of stream
                  12 = Stream priority not being accepted
                  15 = Illegal interval
                  17 = Insufficient network resources
                  18 = Requested bandwidth too large
                  21 = Maximum messages per slot not consistent with
                       slot size
                  22 = Reply lost in network
                  23 = Illegal reliability value
     7[0-15]  Setup Checksum.  Covers words 6-8.
     8[0-15]  Request ID.
                                  41
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           1           |           6           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |      XXXXX      |       HOST STREAM ID        |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                   Figure 14 . DELETE STREAM REQUEST
   0-5      Datagram Message Header.
   6[8-15]  Setup Type = 1 (Request).
   6[0-7]   Request Type = 6 (Delete Stream).
   7[0-15]  Setup Checksum.  Covers words 6-9.
   8[0-15]  Request ID.
   9[10-15] Reserved.
   9[0-9]   Host Stream ID.
                                  42
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           2           |      REPLY CODE       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 15 . DELETE STREAM REPLY
   0-5      Datagram Message Header.
   6[8-15]  Setup Type = 2 (Reply).
   6[0-7]   Reply Code.
        1 = Stream deleted
        8 = Network trouble
       10 = Stream ID nonexistent
       11 = Not creator of stream
       17 = Insufficient network resources
       22 = Reply lost in network
   7[0-15]  Setup Checksum.  Covers words 6-8.
   8[0-15]  Request ID.
                                  43
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   6.2  Group Setup Messages
        Group addressing allows  hosts  to  take  advantage  of  the
   broadcast  capability  of  the satellite network and is primarily
   provided to support the multi-destination delivery  required  for
   conferencing   applications.   Group  addresses  are  dynamically
   created and deleted via setup messages  exchanged  between  hosts
   and  the  network.   Membership  in  a  group  may  consist of an
   arbitrary subset of all the permanent network hosts.  A  datagram
   message  or  stream  message  addressed to a group is always sent
   over the satellite channel and delivered to all  hosts  that  are
   members of that group.  The group setup messages are Create Group
   Request, Create Group Reply, Delete Group Request,  Delete  Group
   Reply, Join Group Request, Join Group Reply, Leave Group Request,
   and Leave Group Reply.
        The use of group setup messages is shown in Figure 16.   The
   figure  illustrates a scenario of exchanges between two hosts and
   their local SIMPs.  In the scenario one host, Host A,  creates  a
   group  which  is  joined by a second host, Host B.  After the two
   hosts have exchanged some data mesages addressed  to  the  group,
   Host  B  decides  to leave the group and Host A decides to delete
   the group.  As in the scenario in Section  6.1,  A/R  indications
   have been omitted for clarity.
        Part of the group creation procedure involves  the   service
   host  returning a 48-bit key along with a 16-bit group address to
   the host creating the group.  The creating host must pass the key
   along with the group address to the other hosts which it wants as
   group members.  These other hosts must supply the key along  with
   the  group address in their Join Group Requests.  The key is used
   by the network  to  authenticate  these  operations  and  thereby
   minimize the probability that unwanted hosts will deliberately or
   inadvertently become members of the group.  The procedure used by
   a  host to distribute the group address and key is not within the
   scope of HAP.
                                  44
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
                                 Host   SIMP    SIMP   Host
                                  A      A       B      B
      Create Group Request         ------>
      Create Group Reply           <------
      Reply Acknowledgment         ------>
           .
           .
                                   >>Group Address,Key>>
           .
           .
      Join Group Request                          <------
      Join Group Reply                            ------>
      Reply Acknowledgment                        <------
      Data Message 1               ------>
      Data Message 1               <------        ------>
      Data Message 2                              <------
      Data Message 2               <------        ------>
      Leave Group Request                         <------
      Leave Group Reply                           ------>
      Reply Acknowledgment                        <------
      Delete Group Request         ------>
      Delete Group Reply           <------
      Reply Acknowledgment         ------>
                       Figure 16 . GROUP EXAMPLE
        Any host no longer wishing to participate  in  a  group  may
   choose  to  drop out.  This can be accomplished by either a Leave
   or a Delete.  Both Leave and Delete operations are  authenticated
   using  the 48-bit key.  Leave is a local operation between a host
   and its SIMP which removes the requesting  host  from  the  group
   membership  list  but  does not alter the global existence of the
                                  45
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   group.  A Delete, on the other hand, expunges  all  knowledge  of
   the  group  from  every SIMP in the network.  HAP will permit any
   member of a group to delete the group at any time.   Thus,  group
   addresses  can  be  deleted  even  if  the  host which originally
   created the group has left the group or has  crashed.   Moreover,
   groups may exist for which there are currently no members because
   each member has executed  a  Leave  while  none  has  executed  a
   Delete.  It  is the responsibility of the hosts to coordinate and
   manage the use of groups.
        The Create Group Request message sent to the service host to
   establish a group address is illustrated in Figure 17.  After the
   network has processed the Create Group Request, the service  host
   will  respond  by  sending  a  Create  Group Reply to the host as
   illustrated in Figure 18.
        A host may become a member of a  group  once  it  knows  the
   address  and key associated with the group by sending the service
   host the Join Group Request message  shown  in  Figure  19.   The
   service  host  will respond to the Join Group Request with a Join
   Group Reply formatted as indicated in Figure 20.  The host  which
   creates  a  group  automatically  becomes  a member of that group
   without any need for an explicit Join Group Request.
        At any time after becoming a member of a group, a  host  may
   choose  to  drop out of the group.  To effect this the host sends
   the service host a Leave Group  Request  formatted  as  shown  in
   Figure  21.   The  service  host  will respond to the Leave Group
   Request with a Leave Group Reply formatted as shown in Figure 22.
        Any member of a group can  request  that  the  service  host
   delete  an existing group via a Delete Group Request.  The format
   of the Delete Group  Request  setup  message  is  illustrated  in
   Figure  23.   After  the  network  has processed the Delete Group
   Request, the service host will respond to the host with a  Delete
   Group Reply formatted as illustrated in Figure 24.
                                  46
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           1           |           1           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                   Figure 17 . CREATE GROUP REQUEST
   0-5        Datagram Message Header.
     6[8-15]  Setup Type = 1 (Request).
     6[0-7]   Request Type = 1 (Create Group).
     7[0-15]  Setup Checksum.  Covers words 6-8.
     8[0-15]  Request ID.
                                  47
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           2           |      REPLY CODE       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |                 GROUP ADDRESS                 |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   10      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   11      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   12      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 18 . CREATE GROUP REPLY
   0-5        Datagram Message Header.
     6[8-15]  Setup Type = 2 (Reply).
     6[0-7]   Reply Code.
                   0 = Group created
                   8 = Network trouble
                  17 = Insufficient network resources
                  22 = Reply lost in network
     7[0-15]  Setup Checksum.  Covers words 6-12.
     8[0-15]  Request ID.
                                  48
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
     9[0-15]  Group Address.  This field contains a  16-bit  logical
              address  assigned  by the network which may be used by
              the host as a group address.
     10-12    Key.  This field contains a 48-bit key assigned by the
              network  which  is  associated with the group address.
              It must be provided for subsequent  Join,  Leave,  and
              Delete requests which reference the group address.
                                  49
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           1           |           3           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |                 GROUP ADDRESS                 |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   10      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   11      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   12      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 19 . JOIN GROUP REQUEST
   0-5        Datagram Message Header.
     6[8-15]  Setup Type = 1 (Request).
     6[0-7]   Request Type = 3 (Join Group).
     7[0-15]  Setup Checksum.  Covers words 6-12.
     8[0-15]  Request ID.
     9[0-15]  Group Address.  This is the  logical  address  of  the
              group that the host wishes to join.
   10-12      Key.  This  is  the  key  associated  with  the  group
                                  50
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
              address.
                                  51
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           2           |      REPLY CODE       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                     Figure 20 . JOIN GROUP REPLY
   0-5        Datagram Message Header.
     6[8-15]  Setup Type = 2 (Reply).
     6[0-7]   Reply Code.
                   2 = Group joined
                   9 = Bad key
                  10 = Group address nonexistent
                  17 = Insufficient network resources
     7[0-15]  Setup Checksum.  Covers words 6-8.
     8[0-15]  Request ID.
                                  52
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           1           |           4           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |                 GROUP ADDRESS                 |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   10      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   11      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   12      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 21 . LEAVE GROUP REQUEST
   0-5        Datagram Message Header.
     6[8-15]  Setup Type = 1 (Request).
     6[0-7]   Request Type = 4 (Leave Group).
     7[0-15]  Setup Checksum.  Covers words 6-12.
     8[0-15]  Request ID.
     9[0-15]  Group Address.  This is the  logical  address  of  the
              group that the host wishes to leave.
   10-12      Key.  This  is  the  key  associated  with  the  group
                                  53
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
              address.
                                  54
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           2            |     REPLY CODE       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                     Figure 22 . LEAVE GROUP REPLY
   0-5        Datagram Message Header.
     6[8-15]  Setup Type = 2 (Reply).
     6[0-7]   Reply Code.
                   3 = Group left
                   9 = Bad key
                  10 = Group address nonexistent
                  11 = Not member of group
                  17 = Insufficient network resources
     7[0-15]  Setup Checksum.  Covers words 6-8.
     8[0-15]  Request ID.
                                  55
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           1           |           2           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |                 GROUP ADDRESS                 |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   10      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   11      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   12      |                      KEY                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                   Figure 23 . DELETE GROUP REQUEST
   0-5        Datagram Message Header.
     6[8-15]  Setup Type = 1 (Request).
     6[0-7]   Request Type = 2 (Delete Group).
     7[0-15]  Setup Checksum.  Covers words 6-12.
     8[0-15]  Request ID.
     9[0-15]  Group Address.
   10-12      Key.
                                  56
   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-5     |            DATAGRAM MESSAGE HEADER            |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |           2           |      REPLY CODE       |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                 SETUP CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                  REQUEST ID                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 24 . DELETE GROUP REPLY
   0-5        Datagram Message Header.
     6[8-15]  Setup Type = 2 (Reply).
     6[0-7]   Reply Code.
                   1 = Group deleted
                   8 = Network trouble
                   9 = Bad key
                  10 = Group address nonexistent
                  11 = Not member of group
                  17 = Insufficient network resources
                  22 = Reply lost in network
     7[0-15]  Setup Checksum.  Covers words 6-8.
     8[0-15]  Request ID.
                                  57
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   7  Link Monitoring
        While the access link is operating,  statistics  on  traffic
   load  and  error  rate  are maintained by the host and SIMP.  The
   host and SIMP  must  exchange  status  messages  once  a  second.
   Periodic  exchange  of  status  messages permits both ends of the
   link to monitor flows in both  directions.  Status  messages  are
   required  to  support monitoring by the Network Operations Center
   (NOC).
        The link restart procedure (see Section 8)  initializes  all
   internal  SIMP  counts  and statistics for that link to zero.  As
   data and control messages are processed, counts  are  updated  to
   reflect  the  total  number  of  messages sent, messages received
   correctly, and messages received with different classes of errors
   since  the last link restart.  Whenever a status message arrives,
   a snapshot is taken of the local SIMP counts.  The local  receive
   counts,  in  conjunction  with  a  sent  count  contained  in the
   received status  message,  permits  the  computation  of  traffic
   statistics  in  the  one second update interval assuming that the
   set of counts at the time of the previous monitoring report  have
   been  saved.   By  including  in  the status message sent (in the
   opposite direction) the receive  counts  and  the  received  sent
   count that was used with them, the transmitting end of the access
   link as  well  as  the  receiving  end  can  determine  the  link
   performance  from  sender  to receiver.  The format of the Status
   control message is illustrated in Figure 25.
                                  58
   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|         XXXXX         |     0     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    1      |                HEADER CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    2      |             MOST RECENT A/R SENT              |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    3      |                STREAM CAPACITY                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    4      |                   TIMESTAMP                   |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    5      |                      SBU                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    6      |                      STU                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    7      |                      RNE                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    8      |                      RWE                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    9      |                      BHC                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   10      |                      HEI                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                      Figure 25 . STATUS MESSAGE
   0[15]     Message Class = 1 (Control Message).
   0[14]     Loopback Bit.
   0[12-13]  Go-Priority.
   0[4-11]   Reserved.
                                  59
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   0[0-3]    Control Message Type = 0 (Status).
   1[0-15]   Header Checksum.  Covers words 0-10.
   2[0-15]   Most Recent A/R Sent.  This field is a duplicate of the
             most recent acceptance/refusal word.  It is included in
             the  periodic   status   message   in   case   previous
             transmissions containing A/R information were lost.
   3[0-15]   Stream Capacity.  When sent by  the  SIMP,  this  field
             indicates  how much stream capacity is unused, in units
             of data  bits  per  frame.   Since  available  capacity
             depends directly on a variety of parameters that can be
             selected by the user, the value of this  field  is  the
             maximum  capacity  that  could  be achieved if existing
             host streams were expanded at  low  reliability.   This
             field  is  undefined  in messages sent from the host to
             the SIMP.
   4[0-15]   Timestamp.  This field  indicates  the  time  that  the
             status message was generated.  When sent by a SIMP, the
             time is in  units  of   seconds  since  the  last  link
             restart.   The  host should also timestamp its messages
             in units of seconds.
   5[0-15]   Sent By Us. Count of messages sent by us since the last
             link restart (not including this one).
   6[0-15]   Sent To Us.  Count of messages sent  to  us  since  the
             last  link  restart.   This is the count from word 5 of
             the last status message received.
   7[0-15]   Received, No Errors. This  is  the  count  of  messages
             received  without  errors (since the last link restart)
             at the time that the last status message was received.
   8[0-15]   Received With Errors.  This is the  count  of  messages
             received  with  errors (since the last link restart) at
             the time the last status message was received.
   9[0-15]   Bad Header Checksums. This is  the  count  of  messages
                                  60
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
             received with bad header checksums (since the last link
             restart) at the  time  the  last   status  message  was
             received.
   10[0-15]  Hardware  Error  Indication.   This  is  the  count  of
             messages  received with hardware CRC errors or hardware
             interface  error  indications  (since  the  last   link
             restart)  at  the  time   the  last  status message was
             received.
                                  61
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   8  Initialization
        The Host Access Protocol uses a number  of  state  variables
   that  must  be  initialized in order to function properly.  These
   variables are  associated  with  the  send  and  receive  message
   numbers   used   by  the  acceptance/refusal  mechanism  and  the
   statistics  maintained  to   support   link   monitoring.    Link
   initialization  should be carried out when a machine is initially
   powered up, when it does a system restart, when the ON state (see
   below)  times  out,  when  a  loopback  condition  times out (see
   Section 9), or whenever the link transitions from non-operational
   to operational status.
        Initialization is accomplished by the  exchange  of  Restart
   Request  (RR)  and  Restart Complete (RC) messages between a host
   and a SIMP.  The state diagram in Figure 26 shows the sequence of
   events  during initialization.  Both SIMP and host must implement
   this state diagram  if  deadlocks  and  oscillations  are  to  be
   avoided.   This  particular initialization sequence requires both
   sides to send and receive the Restart Complete message.   Because
   this  message  is  a  reply  (to  a  Restart  Request  or Restart
   Complete), its receipt  guarantees  that  the  physical  link  is
   operating  in both directions.  Five states are identified in the
   state diagram:
   OFF            Entered  upon  recognition  of  a  requirement  to
                  restart.     The   device   can   recognize   this
                  requirement  itself or be forced  to  restart   by
                  receipt of an RR  message from the other end while
                  in the ON state.
   INIT           Local state variables have  been  initialized  and
                  local  counters  have  been  zeroed but no restart
                  control messages have yet been sent or received.
   RR-SNT         A request to reinitialize (RR) has  been  sent  to
                  the other end but no restart control messages have
                  yet been received.
   RC-SNT         A reply (RC) has been sent to  the  other  end  in
                  response  to  a  received reinitialization request
                                  62
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
                  (RR).  The device is waiting for a reply (RC).
   ON             Reply  (RC)  messages  have  been  both  sent  and
                  received.   Data  and  control messages can now be
                  exchanged between the SIMP and host.
        All states have 10-second timeouts (not  illustrated)  which
   return  the  protocol  to  the  OFF state.  The occurrence of any
   events other than those indicated in the diagram are ignored.
        The Restart Request control message illustrated in Figure 27
   is  sent  by  either a host or a SIMP when it wishes to restart a
   link.  The Restart Request causes all the  monitoring  statistics
   to  be  reset  to  zero and stops all traffic on the link in both
   directions.  The Restart Complete message illustrated  in  Figure
   28  is  sent in response to a received Restart Request or Restart
   Complete to complete link initialization.  The  Restart  Complete
   carries  a  field  used  by  the  host  to  enable or disable the
   acceptance/refusal mechanism for the link  being  restarted  (see
   Section 5).  After the Restart Complete is processed, traffic may
   flow on the link.
                                  63
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
  1. ——

Any Timeout or —–>| OFF |←—————————-

       Device Down          -------                             |
                               |                                |
                               |  Device Up                     |
                               |  Initialize Variables          |
                               |                                |
                               V                                |
                           ---------                            |
                           | INIT  |                            |
                           ---------                            |
                             |   |                              |
                    Rcv RR   |   |   Snd RR                     |
                    Snd RC   |   |                              |
                             |   |                              |
                --------------   --------------                 |
                |                             |                 |
                |                             |                 |
                V           Rcv RR            V                 |
           ----------       Snd RC        ----------            |
           | RC-SNT |<--------------------| RR-SNT |            |
           ----------                     ----------            |
                |                             |                 |
       Rcv RC   |                             |   Rcv RC        |
                |                             |   Snd RC        |
                V                             V                 |
                -------------------------------                 |
                               |                                |
                               |                                |
                               V                                |
                            -------                             |
        Rcv Any      ------>| ON  |------------------------------
        Other        |      -------    Rcv RR
                     ----------|
              Figure 26 . HAP LINK RESTART STATE DIAGRAM
                                  64
   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|     XXXXXXX     |  REASON   |     3     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   1       |                HEADER CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   2       |          HOST ADDRESS / SITE NUMBER           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   3       |                  LINK NUMBER                  |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                      Figure 27 . RESTART REQUEST
   0[15]    Message Type = 1 (Control Message).
   0[14]    Loopback Bit.
   0[8-13]  Reserved.
   0[4-7]   Reason.  This field is used by the SIMP or the  host  to
            indicate the reason for the restart as follows:
                 0 = power up
                 1 = system restart
                 2 = link restart
                 3 = link timeout
                 4 = loopback timeout
   0[0-3]   Control Message Type = 3 (Restart Request).
   1[0-15]  Header Checksum.  Covers words 0-3.
   2[0-15]  Host Address  /  Site  Number.   The  host  inserts  its
            satellite  network  address  in  this  field.   The SIMP
            validates that the host address is correct for the  port
                                  65
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
            being  used.   When  sent  by  the SIMP, this field will
            contain the SIMP site number.
   3[0-15]  Link  Number.   This   field   contains   the   sender's
            identification  of  the  physical link being used.  This
            information is used to identify the link when  reporting
            errors to the Network Operations Center (NOC).
                                  66
   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|          XXXXXX          |AR|     4     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   1       |                HEADER CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   2       |          HOST ADDRESS / SITE NUMBER           |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   3       |                  LINK NUMBER                  |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                     Figure 28 . RESTART COMPLETE
   0[15]    Message Type = 1 (Control Message).
   0[14]    Loopback Bit.
   0[5-13]  Reserved.
   0[4]     Acceptance/Refusal Control.  This bit  is  used  by  the
            host   to   enable  or  disable  the  acceptance/refusal
            mechanism for all traffic on the link.
                 0 = Disable acceptance/refusal
                 1 = Enable acceptance/refusal
   0[0-3]   Control Message Type = 4 (Restart Complete).
   1[0-15]  Header Checksum.  Covers words 0-3.
   2[0-15]  Host Address / Site Number.
   3[0-15]  Link Number.
                                  67
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   9  Loopback Control
        The Host Access Protocol provides a Loopback Request control
   message  which  can  be  used  by a SIMP or a host to request the
   remote loopback of its HAP messages.  Such requests  are  usually
   the  result of operator intervention for purposes of system fault
   diagnosis.  For clarity in the  following  discussion,  the  unit
   (SIMP  or  host) requesting the remote loopback is referred to as
   the "transmitter" and the unit implementing  (or  rejecting)  the
   loopback  is  referred  to  as  the  "receiver".  The format of a
   Loopback Request control message is illustrated in Figure 29.
        When a transmitter  is  remotely  looped,  all  of  its  HAP
   messages  will  be  returned, unmodified, over the access link by
   the receiver.  The receiver will not send any of its own messages
   to  the  transmitter  while  it  is implementing the loop.  SIMP-
   generated messages are distinguished from host-generated messages
   by means of the Loopback Bit that is in every HAP message header.
        Two types of remote loopback may be requested:  loopback  at
   the  receiver's interface hardware and loopback at the receiver's
   I/O driver software.  HAP does not specify the  manner  in  which
   the  receiver  should  implement  these loops; additionally, some
   receivers may  use  interface  hardware  which  is  incapable  of
   looping the transmitter's messages, only allowing the receiver to
   provide software loops.  A receiver may not be able to  interpret
   the  transmitter's  messages as it is looping them back.  If such
   interpretation is possible, however, the receiver will not act on
   any   of  the  transmitter's  messages  other  than  requests  to
   reinitialize the SIMP-host link  (Restart  Request  (RR)  control
   messages; see Section 8.)
        When a receiver initiates a loopback condition  in  response
   to  a  loopback request, it makes an implicit promise to maintain
   the condition for the duration specified in the Loopback  Request
   message.  However, if an unanticipated condition such as a system
   restart occurs in either the transmitter  or  the  receiver,  the
   affected  unit  will  try  to  reinitialize the SIMP-host link by
   sending an RR message to the other unit.  If the  RR  message  is
   recognized  by  the other unit a link initialization sequence can
   be  completed.   This  will  restore  the  link  to  an  unlooped
                                  68
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   condition  even  if  the  specified  loop  duration  has  not yet
   expired.  If a  receiver  cannot  interpret  a  transmitter's  RR
   messages,  and  in  the  absence  of operator intervention at the
   receiver, the loop will remain in place for its duration.
        HAP does not specify the  characteristics  of  any  loopback
   conditions  that  may be locally implemented by a given unit.  An
   example of such a condition is that obtained when a SIMP commands
   its  host interface to loop back its own messages.  If such local
   loop conditions also cause the reflection  of  messages  received
   from  the  remote unit, the remote unit will detect the condition
   via the HAP header Loopback Bit.
        A specific sequence must be followed for setting up a remote
   loopback  condition.   It  begins  after  the  HAP  link has been
   initialized and a decision is made to request a remote loop.  The
   transmitter then sends a Loopback Request message to the receiver
   and waits for either (1) a  10-second  timer  to  expire,  (2)  a
   "Can't  implement  loop"  Unnumbered  Response  message  from the
   receiver, or (3) one of its own reflected messages.  If event (1)
   or  (2) occurs the request has failed and the transmitter may, at
   its option, try again with a new Loopback  Request  message.   If
   event   (3)  occurs,  the  remote  loopback  condition  has  been
   established.  While waiting for one  of  these  events,  messages
   from  the receiver are processed normally.  Note that RR messages
   arriving from the receiver during this time  will  terminate  the
   loopback request.
        When a receiver gets a Loopback Request message,  it  either
   implements  the  requested  loop  for  the specified duration, or
   returns a "Can't implement loop" response  without  changing  the
   state  of  the  link.  The latter response would be returned, for
   example, if a receiver is incapable of implementing  a  requested
   hardware  loop.   A  receiver should initiate reinitialization of
   the link with an RR  message(s)  whenever  a  loopback  condition
   times out.
        There is  one  asymmetry  that  is  required  in  the  above
   sequence  to resolve the (unlikely) case where both SIMP and host
   request a remote loopback at the same time. If a SIMP receives  a
   Loopback  Request  message from a host while it is itself waiting
                                  69
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   for an event of type (1)-(3), it will return a  "Can't  implement
   loop"  response to the host and will continue to wait.  A host in
   the converse situation, however, will abort its loopback  request
   and will instead act on the SIMP's loopback request.
                                  70
   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|   XXXXX   | LOOP TYPE |     8     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   1       |                HEADER CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   2       |                LOOP DURATION                  |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                     Figure 29 . LOOPBACK REQUEST
   0[15]     Message Type = 1 (Control Message).
   0[14]     Loopback Bit.
   0[12-13]  Go-Priority.
   0[8-11]   Reserved.
   0[4-7]    Loop Type.  This field indicates the type of loop  that
             is being requested as follows:
                  0 = Undefined
                  1 = Loop at interface (hardware loop)
                  2 = Loop at driver (software loop)
                  3-15 = Undefined
   0[0-3]    Control Message Type = 8 (Loopback Request).
   1[0-15]   Header Checksum.  Covers words 0-2.
   2[0-15]   Loop  Duration.   The   transmitter   of  a    Loopback
             Request  message uses this field  to specify the number
             of seconds that the loop is to  be  maintained  by  the
             receiver.
                                  71
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
   10  Other Control Messages
        Before a SIMP or a host  voluntarily  disables  a  SIMP-host
   link, it should send at least one Link Going Down control message
   over that link.  The format of such a message is  illustrated  in
   Figure  30.   HAP  does  not  define the action(s) that should be
   taken by a SIMP or a  host  when  such  a  message  is  received;
   informing  the Network Operations Center (NOC) and/or the network
   users of the impending event is a typical course of action.  Note
   that  each Link Going Down message only pertains to the SIMP-host
   link that it is sent over; if a host and a SIMP are connected  by
   multiple links, these links may be selectively disabled.
        A No Operation (NOP) control message may be sent at any time
   by a SIMP or a host.  The format of such a message is illustrated
   in Figure 31.  A NOP message contains up to 32 words of arbitrary
   data which are undefined by HAP.  NOP messages may be required in
   some cases to clear the state of the SIMP-host link hardware.
                                  72
   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|   XXXXX   |  REASON   |     7     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   1       |                HEADER CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   2       |               TIME UNTIL DOWN                 |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   3       |                DOWN DURATION                  |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                      Figure 30 . LINK GOING DOWN
   0[15]     Message Type = 1 (Control Message).
   0[14]     Loopback Bit.
   0[12-13]  Go-Priority.
   0[8-11]   Reserved.
   0[4-7]    Reason.  This field is  used by the  SIMP or  the  host
             to  indicate  the  reason  for disabling this SIMP-host
             link  as follows:
                  0 = NOT going down:  Cancel previous Link
                      Going Down message
                  1 = Unspecified reason
                  2 = Scheduled PM
                  3 = Scheduled hardware work
                  4 = Scheduled software work
                  5 = Emergency restart
                  6 = Power outage
                  7 = Software breakpoint
                  8 = Hardware failure
                                  73
   RFC 907                                      Host Access Protocol
   July 1984                                           Specification
                  9 = Not scheduled up
                 10 = Last warning:  The SIMP  or host  is disabling
                      the link in 10 seconds
                 11-15 = Undefined
   0[0-3]    Control Message Type = 7 (Link Going Down).
   1[0-15]   Header Checksum.  Covers words 0-3.
   2[0-15]   Time Until Down.  This field specifies  the  amount  of
             time  remaining   until the  SIMP or host  disables the
             link (in minutes).  An  entry of  zero  indicates  that
             there is less than a minute remaining.
   3[0-15]   Down Duration.  This field  specifies  the   amount  of
             time   that  the  SIMP-host  link  will   be  down  (in
             minutes).   An entry of  zero indicates  that the  down
             duration  will  be  less than a minute.  An entry of -1
             (all bits set) indicates an indefinite down duration.
                                  74
   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|            XXXXX            |     6     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   1       |                HEADER CHECKSUM                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   2-N     |                ARBITRARY DATA                 |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    Figure 31 . NO OPERATION (NOP)
   0[15]     Message Type = 1 (Control Message).
   0[14]     Loopback Bit.
   0[4-13]   Reserved.
   0[0-3]    Control Message Type = 6 (NOP).
   1[0-15]   Header Checksum.  Covers words 0-N.
   2-N       Arbitrary Data.  Up to 32 words of data  may  be  sent.
             The data are undefined by HAP.
                                  75
/data/webs/external/dokuwiki/data/pages/rfc/rfc907.txt · Last modified: 1992/09/23 19:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki