diff options
Diffstat (limited to 'doc/rfc/rfc907.txt')
| -rw-r--r-- | doc/rfc/rfc907.txt | 4581 |
1 files changed, 4581 insertions, 0 deletions
diff --git a/doc/rfc/rfc907.txt b/doc/rfc/rfc907.txt new file mode 100644 index 0000000..5629e57 --- /dev/null +++ b/doc/rfc/rfc907.txt @@ -0,0 +1,4581 @@ + + + + + + + + + + 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 + + |