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: {-} [ {-} ] 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 Protoco