home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-04-21 | 126.9 KB | 4,582 lines |
-
-
-
-
-
-
-
-
-
- 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
-
-
-
-
-
-
- -------
- 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
-
-
-