As per Relevance of the word messages, we have this rfc below:
RFC 907
HOST ACCESS PROTOCOL
July 1984
prepared
Defense Advanced Research Projects
1400 Wilson
Arlington, Virginia 22209
Bolt Beranek and Newman
10 Moulton
Cambridge, Massachusetts 02238
RFC 907 Host Access
July 1984
Preface (Status of this Memo
This document specifies the Host Access Protocol (HAP).
Although HAP was originally designed as the network-access
protocol for the DARPA/DCA sponsored Wideband Packet
Network, it is intended that it evolve into a standard
between hosts and packet-switched satellite networks such
SATNET and TACNET (aka MATNET) as well as the Wideband Network
The HAP specification presented here is a minor revision of,
supercedes, the specification presented in Chapter 4 of
Report No. 4469, the "PSAT Technical Report". As such,
details of the current specification are still most
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
(Loopback Request, Link Going Down, and NOP), a "Reason" field
Restart Request control messages, new Unnumbered Response codes
and new values for the setup codes used to manage streams
groups
HAP is an experimental protocol, and will undergo
revision as new capabilities are added and/or different
networks are supported. Implementations of HAP should
performed in coordination with satellite network development
operations personnel
RFC 907 Host Access
July 1984
Table of
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
RFC 907 Host Access
July 1984
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
RFC 907 Host Access
July 1984
1
The Host Access Protocol (HAP) specifies the network-
level communication between an arbitrary computer, called a host
and a packet-switched satellite network. The satellite
provides message delivery services for geographically
hosts: Messages containing data which are meaningful to the
are submitted to the network by an originating (source) host,
are passed transparently through the network to an
destination host. To utilize such services, a host interfaces
the satellite network via an access link to a dedicated packet
switching computer, known as a Satellite Interface
Processor (Satellite IMP or SIMP). HAP defines the
types of control messages and (host-to-host) data messages
may be exchanged over the access link connecting a host and
SIMP. The protocol establishes formats for these messages,
describes procedures for determining when each type of
should be transmitted and what it means when one is received
The term "Interface Message Processor" originates in
ARPANET, where it refers to the ARPANET's packet-switching nodes
SIMPs differ from ARPANET IMPs in that SIMPs form a network
connections to a common multiaccess/broadcast satellite channel
whereas ARPANET IMPs are interconnected by dedicated point-to
point terrestrial communications lines. This
difference between satellite-based and ARPANET-style
results in different mechanisms for the delivery of messages
source to destination hosts and for internal
coordination. Additionally, satellite networks tend to
different type of service options to their connected hosts
do ARPANET-style networks. These options are included in
Host Access Protocol presented here
Several types of Satellite IMPs have been developed on
variety of processors for the support of three different packet
switched satellite networks. The original SIMP was employed
the Atlantic Packet Satellite Network (SATNET). It was
from one of the models of ARPANET IMP, and was implemented on
Honeywell 316 minicomputer. The 316 SIMPs were succeeded
SATNET by SIMPs based on BBN C/30 Communications
hardware. The C/30 SIMPs have also been employed in the
1
RFC 907 Host Access
July 1984
Access Terminal Network (MATNET). The SATNET and MATNET
implement a network-access level protocol known as Host/
Protocol. Host/SATNET Protocol is the precursor to HAP and
documented in Internet Experiment Note (IEN) No. 192.
Wideband Satellite Network, like SATNET, has undergone
evolution in the development of its SIMP hardware and software
The original Wideband Network SIMP is known as the
Satellite IMP, or PSAT, having been implemented on the
Pluribus Multiprocessor. Its successor, the BSAT, is based
the BBN Butterfly Multiprocessor. Both the PSAT and the
communicate with their connected network hosts via HAP
Section 2 presents an overview of HAP. Details of
formats and message exchange procedures are contained in
3 through 10. Further explanation of many of the
addressed in this HAP specification can be found in BBN
No. 4469, the "PSAT Technical Report".
The protocol used to provide sufficiently reliable
exchange over the host-SIMP link is assumed to be transparent
the network-access protocol defined in this document.
of such link-level protocols are ARPANET 1822 local and
host, ARPANET VDH protocol, and HDLC
2
RFC 907 Host Access
July 1984
2
HAP can be characterized as a full duplex
protocol with an optional flow control mechanism. HAP
flow simultaneously in both directions between the SIMP and
host. Transmission is nonreliable in the sense that the
does not provide any guarantee of error-free sequenced delivery
To the extent that this functionality is required on the
link (e.g., non-collocated SIMP and host operating over
communication circuit), it must be supported by the link-
protocol below HAP. The flow control mechanism
independently in each direction except that enabling or
the mechanism applies to both sides of the interface
HAP supports host-to-host communication in two
corresponding to the two types of HAP data messages,
messages and stream messages. Each type of message can be up
approximately 16K bits in length. Datagram messages provide
basic transmission service in the satellite network.
messages transmitted by a host experience a nominal two
hop end-to-end network delay. (Note that this delay, of about 0.6
sec excluding access link delay, is associated with
transmission between hosts on different SIMPs. The
delay between hosts on the same SIMP will be much
assuming the destination is not a group address. See Section 3
and 6.2.) A datagram control header, passed to the SIMP by
host along with message text, determines the processing of
message within the satellite network independent of any
exchanges
Stream messages provide a one satellite hop
(approximately 0.3 sec) for volatile traffic, such as speech
which cannot tolerate the delay associated with
transmission. Hosts may also use streams to support high
cycle applications which require guaranteed channel bandwidth
Host streams are established by a setup message exchange
the host and the network prior to the commencement of data flow
Although established host streams can have their
modified by subsequent setup messages while they are in use,
fixed allocation properties of streams relative to
impose rather strict requirements on the source of the
3
RFC 907 Host Access
July 1984
using the stream. Stream traffic arrivals must match the
allocation both in interarrival time and message size
reasonable efficiency is to be achieved. The characteristics
use of datagrams and streams are described in detail in
3 and 4 of this document
Both datagram and stream transmission in the
network use logical addressing. Each host on the network
assigned a permanent 16-bit logical address which is
of the physical port on the SIMP to which it is attached.
16-bit logical addresses are provided in all Host-to-SIMP
SIMP-to-Host data messages
Hosts may also be members of groups. Group addressing
provided primarily to support the multi-destination
required for conferencing applications. Like streams,
addresses are dynamically created and deleted by the use of
messages exchanged between a host and the network. Membership
a group may consist of an arbitrary subset of all the
network hosts. A message addressed to a group address
delivered to all hosts that are members of that group
Although HAP does not guarantee error-free delivery,
control is an important aspect of the protocol design. HAP
control is concerned with both local transfers between a host
its local SIMP and transfers from SIMP-to-SIMP over the
channel. The SIMP offers users a choice of network
protection options based on the network's ability to
send messages over the satellite channel at different
rates. These forward error correction (FEC) options are
to as reliability levels. Three reliability levels (low, medium
and high) are available to the host
In addition to forward error correction, a number
checksum mechanisms are employed in the satellite network to
an error detection capability. A host has an opportunity
sending a message to indicate whether the message should
delivered to its destination or discarded if a data error
detected by the network. Each message received by a host
the network will have a flag indicating whether or not an
was detected in that particular message. A host can decide on
4
RFC 907 Host Access
July 1984
per-message basis whether or not it wants to accept or
transmissions containing data errors
For connection of a host and SIMP in close proximity,
rates due to external noise or hardware failures on the
circuit may reasonably be expected to be much smaller than
best satellite channel error rate. Thus for this case, little
gained by using error detection and retransmission on the
circuit. A 16-bit header checksum is provided, however,
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
optimize performance for both low and high reliability traffic
It is expected that link-level error control procedures (such
HDLC) will be used for this purpose
Datagram and stream messages being presented to the
by a host may not be accepted for a number of reasons:
too low, destination dead, lack of buffers in the source SIMP
etc. The host faces a similar situation with respect to
messages from the SIMP. To permit the receiver of a message
inform the sender of the local disposition of its message,
acceptance/refusal (A/R) mechanism is implemented. The
is the external manifestation of the SIMP's (or host's)
flow and congestion control algorithm. If A/Rs are enabled,
explicit or implicit acceptance or refusal for each message
returned to the host by the SIMP (and conversely). This
the host (or SIMP) to retry refused messages at its
and can provide information useful for optimizing the sending
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
being in one of four priority classes, from priority 3 (highest
through priority 0 (lowest). The priority class is used by
SIMP for arbitrating contention for scarce network
(e.g., channel time). That is, if the network cannot deliver
of the offered messages, high priority messages will be
in preference to low priority messages. In the case
datagrams, priority level is used by the SIMP for
5
RFC 907 Host Access
July 1984
satellite channel reservation requests at the source SIMP
message delivery at the destination SIMP. In the case
streams, priority is associated with the ability of one stream
preempt another stream of lower priority at setup time
While the A/R mechanism allows control of individual
transfers, it does not facilitate regulation of priority flows
Such regulation is handled by passing advisory status
(GOPRI) across the Host-SIMP interface indicating
priorities are currently being accepted. As long as
information, relative to the change in priority status, is
frequently, the sender can avoid originating messages which
sure to be refused
HAP defines both data messages (datagram messages and
messages) and control messages. Data messages are used to
information between network hosts. Control messages
exchanged between a host and the network to manage the
access link. HAP can also be viewed in terms of two
protocol layers, the message layer and the setup layer.
message layer is associated with the transmission of
datagram messages and stream messages. The setup layer
is associated with the establishment, modification, and
of streams and groups. Setup layer exchanges are
implemented as datagrams transmitted between the user host and
internal SIMP "service host."
Every HAP message consists of an integral number of 16-
words. The first several words of the message always
control information and are referred to as the message header
The first word of the message header identifies the type
message which follows. The second word of the message header
a checksum which covers all header information. Any
whose received header checksum does not match the
computed on the received header information must be discarded
The format of the rest of the header depends on the
message type
The formats and use of the individual message types
detailed in the following sections. A common format
is used for this purpose. Words in a message are
6
RFC 907 Host Access
July 1984
starting at zero (i.e., zero is the first word of a
header). Bits within a word are numbered from zero (
significant) to fifteen (most significant). The notation used
identify a particular field location is
{-} [ {-} ] <description
where optional elements in {} are used to specify the (inclusive
upper limit of a range. The reader should refer to these
identifiers for precise field size specifications. Fields
are common to several message types are defined in the
section which uses them. Only the name of the field will
appear in the descriptions in subsequent sections
Link-level protocols used to support HAP can differ in
order in which they transmit the bits constituting HAP messages
For HDLC and ARPANET VDH, each word of a HAP message
transmitted starting with the least significant bit (bit 0)
ending with the most significant bit (bit 15). The words of
message are transmitted from word 0 to word N. For ARPANET 1822
local and distant host interfaces, the order of bit
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
July 1984
3 Datagram
Datagram messages are one of the two types of message
data messages used to support host-to-host communication.
datagram can contain up to 16,384 bits of user data.
messages transmitted by a host to a host on a remote
experience a nominal two satellite hop end-to-end network
(about 0.6 sec), excluding delay on the access links.
network delay is due to the reservation per message
procedure for datagrams which only allocates channel time to
message for the duration of the actual transfer. Since
transfers between permanent hosts on the same SIMP do not
satellite channel scheduling prior to data transmission,
network delay in this case will be much smaller and is
strictly by SIMP processing time. Datagrams sent to
addresses are treated as if they were addressed to remote
and are always sent over the satellite channel. It is
that datagram messages will be used to support the majority
computer-to-computer and terminal-to-computer traffic which
bursty in nature
The format of datagram messages and the purpose of each
the header control fields is described in Figure 1.
8
RFC 907 Host Access
July 1984
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
0[15] Message Class. This bit identifies the message as
data message or a control message
0 = Data
1 = Control
0[14] Loopback Bit. This bit allows the sender of a
to determine if its own messages are being looped back
The host and the SIMP each use different settings
this bit for their transmissions. If a message
with the loopback bit set equal to its outgoing value
then the message has been looped
0 = Sent by
1 = Sent by
9
RFC 907 Host Access
July 1984
0[12-13] Go-Priority. In SIMP-to-Host messages, this
provides advisory information concerning the
priority currently being accepted by the SIMP.
host may optionally choose to provide similar
information to the SIMP
0 = Low
1 = Medium-Low
2 = Medium-High
3 = High
0[9-11] Reserved
0[8] Force Channel Transmission Flag. This flag can be
by the source host to force the SIMP to transmit
message over the satellite channel even if the
contains permanent destination and source
addresses corresponding to hosts which are
connected to the same SIMP
0 = Normal
1 = Force channel
0[0-7] Message Number. This field contains the
of the message used by the acceptance/refusal (A/R
mechanism (when enabled). If the message number
zero, A/R is disabled for this specific message.
Section 5 for a detailed description of the A/
mechanism
1[0-15] Header Checksum. This field contains a checksum
covers words 0-5. It is computed as the negation
the 2's-complement sum of words 0-5 (excluding
checksum word itself).
2[0-15] Piggybacked A/R. This field may contain
acceptance/refusal word providing A/R status on
flowing in the opposite direction. Its inclusion
eliminate the need for a separate A/R control
(see Section 5). A value of zero for this word is
to indicate that no piggybacked A/R information
10
RFC 907 Host Access
July 1984
present
3[15] Data Message Type. This bit identifies whether
message is a datagram message or a stream message
0 = Datagram
1 = Stream
3[14] Internet/Local Flag. This flag is set by a source
to specify to a destination host whether the
portion of the message contains a standard DoD
header. This field is passed transparently by
source and destination SIMPs for traffic
external satellite network hosts. This field
examined by internal SIMP hosts (e.g., the
service host) in order to support Internet operation
0 =
1 =
3[13] Discard Flag. This flag allows a source host
instruct the satellite network (including
destination host) what to do with the message when
errors are detected (assuming the header checksum
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,
passed on to the destination host
3[12] Data Error Flag. This flag is used in conjunction
the Discard Flag to indicate to the destination
whether any data errors have been detected in
message prior to transmission over the SIMP-to-
access link. It is used only if Discard Flag = 1.
should be set to zero by the source host
11
RFC 907 Host Access
July 1984
0 = No Data Errors
1 = Data Errors
3[10-11] Time-to-Live Designator. The source host uses
field to specify the maximum time that a
should be allowed to exist within the satellite
before being deleted. Messages may be discarded by
network prior to this maximum elapsed time
0 = 1
1 = 2
2 = 5
3 = 10
The Time-to-Live field is undefined in messages
from a SIMP to a host
3[8-9] Priority. The source host uses this field to
the priority with which the message should be
within the network
0 = Low
1 = Medium-Low
2 = Medium-High
3 = High
The priority of each message is passed to
destination host by the destination SIMP
3[6-7] Reliability. The source host uses this field
specify the basic bit error rate requirement for
data portion of this message. The source SIMP
this field to determine the satellite
transmission parameters required to provide that
error rate
0 = Low
1 = Medium
12
RFC 907 Host Access
July 1984
2 = High
3 =
The Reliability field is undefined in messages
from a SIMP to a host
3[0-5] Reliability Length. This source host uses this
to specify a portion of the user data which should
transmitted at the highest reliability level (
bit error rate). Both the six message header words
the first Reliability Length words of user data will
transmitted at Reliability=2 while the remainder of
user data will be transmitted at whatever
level is specified in field 3[6-7]. The
length mechanism gives the user the ability to
private header information (e.g., IP and TCP headers
at a higher reliability level than the remainder of
data. The Reliability Length field is undefined
messages sent from a SIMP to a host
4[0-15] Destination Host Address. This field contains
satellite network logical address of the
host
5[0-15] Source Host Address. This field contains the
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
July 1984
4 Stream
Stream messages are the second type of message level
messages. As noted in Section 2, streams exist primarily
provide a one satellite hop delay for volatile traffic such
speech. Hosts may also use streams to support high duty
applications which require guaranteed channel bandwidth
Streams must be created before stream messages can flow
host to host. The protocol to accomplish stream creation
described in Section 6.1. Once established, a stream
associated with a recurring channel allocation within
satellite network. This fixed allocation imposes rather
requirements on the host using the stream if efficient
utilization is to be achieved. In particular, stream
must match the stream allocation both in terms of message
and message interarrival time
Within the bounds of its stream allocation, a host
permitted considerable flexibility in how it may use a stream
Although the priority, reliability, and reliability length
each stream message is fixed at stream creation time,
destination logical address can vary from stream message
stream message. A host can, therefore, multiplex a variety
logical flows onto a single host stream. The format of
messages is described in Figure 2.
14
RFC 907 Host Access
July 1984
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
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
the message number field in the datagram message
Moreover, a single message number sequence is used
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
July 1984
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 =
1 = 1
2 =
3 =
3[0-9] Host Stream ID. The service host uses this field
identify the host stream over which the message is
be sent by the SIMP. Host stream IDs are
at stream creation time via host exchanges with
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
data (multiple of 16-bits).
16
RFC 907 Host Access
July 1984
5 Flow Control
The SIMP supports an acceptance/refusal (A/R) mechanism
each direction on the host access link. The A/R mechanism
enabled for the link by the host by setting a bit in the
Complete control message (see Section 8). Each datagram
stream message contains an 8-bit message number used to
the message for flow control purposes. Both the host and
SIMP increment this number modulo 256 in successive messages
transmit. Up to 127 messages may be outstanding in
direction at any time. If the receiver of a message is unable
accept the message, a refusal indication containing the
number of the refused message and the reason for the refusal
returned. The refusal indication may be piggybacked on
messages in the opposite direction over the link or may be
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
message. An acceptance is returned by the receiver to
that the identified message was not refused.
indications returned by the SIMP do not, however, imply
guarantee of delivery or even any assurance that the message
not be intentionally discarded by the network at a later time
They are sent primarily to facilitate buffer management in
host
To reduce the number of A/R messages exchanged, a single A/
indication can be returned for multiple (lower numbered
previously unacknowledged messages. Explicit acceptance
message number N implies implicit acceptance of
messages with numbers N-1, N-2, etc., according to
definition of acceptance outlined above. (Note that
acceptance of message number N does not imply that all of
unacknowledged outstanding messages have been received.)
analogous interpretation of refusal message number allows
receiver of a group of messages to reject them as a
assuming that they all are being refused for the same reason.
a further efficiency measure, HAP permits a block of A/
indications to be aggregated into a single A/R control message
Such a message might be used, for example, to reject a group
17
RFC 907 Host Access
July 1984
messages where the refusal code on each is different
In some circumstances the overhead associated
processing A/R messages may prove unattractive. For these cases
it is possible to disable the A/R mechanism and operate the
interface in a purely discard mode. The ability to effect
on a link basis has already been noted (see Sections 2 and 8).
In addition, messages with sequence number zero are taken
messages for which the A/R mechanism is selectively disabled.
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
A/R indications on data messages (word 2), and for providing A/
information in separate control messages. When separate
messages are used to transmit A/R indications, the format
in Figure 4 applies. Flow control information and
information which cannot be sent as an A/R indication is sent
an Unnumbered Response control message. The format of this
of message is illustrated in Figure 5.
18
RFC 907 Host Access
July 1984
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
[15] Acceptance/Refusal Type. This field identifies
A/R information is an acceptance or a refusal
0 =
1 =
[8-14] Refusal Code. When the Acceptance/Refusal Type = 1,
this field gives the Refusal Code
0 = Priority not being
1 = Source SIMP
2 = Destination SIMP
3 = Destination host
4 = Destination SIMP
5 = Illegal destination host
6 = Destination host access not
7 = Illegal source host
8 = Message lost in access
9 = Nonexistent stream
10 = Illegal source host for stream
11 = Message length too
12 = Stream message too
13 = Illegal control message
14 = Illegal refusal code in A/
15 = Illegal reliability
16 = Destination host
[0-7] A/R Message Number. This field contains the number
19
RFC 907 Host Access
July 1984
the message to which this acceptance/refusal refers
It also applies to all outstanding messages
earlier numbers. Note that this field can never
zero since a message number of zero implies that
A/R mechanism is disabled
20
RFC 907 Host Access
July 1984
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
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
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
July 1984
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
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
5 = Illegal destination host
7 = Illegal source host
9 = Nonexistent stream
10 = Illegal stream
13 = Protocol
15 = Can't implement
0[0-3] Control Message Type = 5 (Unnumbered Response).
1[0-15] Header Checksum. Covers words 0-3.
22
RFC 907 Host Access
July 1984
2[0-15] Response Information. If Response Code is
3, Destination Host
5, Destination Host
7, Source Host
9, Stream ID (right justified
10, Stream ID (right justified
13, Word 0 of offending
15, Word 0 of Loopback Request
3[0-15] Response Information. If Response Code is
3,5,7, or 9.
10, Source Host
13, Word 3 of offending message, or zero
no word 3
15, Word 2 of Loopback Request
23
RFC 907 Host Access
July 1984
6 Setup Level
Setup level protocol is provided to support
establishment, modification, and deletion of groups and
in the packet satellite network. A host wishing to perform
of these generic operations interacts with the network
host (logical address zero). The service host causes
requested action to be carried out and serves as the
between the user and the rest of the network. In the process
implementing the requested action, various network data bases
updated to reflect the current state of the referenced group
stream
The communication between the host and the service host
implemented via special-purpose datagrams called setup messages
Each interaction initiated by a host involves a 3-way
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)
user host returns a Reply Acknowledgment to the service host
This procedure is used to insure reliable transmission
requests and replies. In order to allow more than one
request message from a host to be outstanding, each request
assigned a unique Request ID. The associated Reply
subsequent Reply Acknowledgment are identified by the Request
that they contain. Hosts should generally expect a minimum
of about two satellite round-trip times between the
of a setup Request to the SIMP and the receipt of the
Reply. (Note that the Join Group Request and the Leave
Request require only local communication between a host and
SIMP. The response time for these requests, therefore,
dependent solely on SIMP processing time and should
considerably shorter than two round-trip times.) This
establishes a maximum rate at which changes can be processed
the SIMP. The user should receive a reply to a setup
requiring global communication within 2 seconds and to a
request requiring local communication within 1 second. The
should respond to a SIMP Reply with a Reply Acknowledgment
1 second
24
RFC 907 Host Access
July 1984
Setup exchanges can also be initiated by the SIMP. SIMP
initiated setup messages are used to notify a host of changes
the status of an associated group or stream. Each
involves a 2-way exchange where: (1) the service host sends
Notification to the user host, and (2) the user host returns
Notification Acknowledgment to the service host. In order
allow more than one Notification to be outstanding, each
assigned a unique Notification ID. The
Acknowledgment returned by the user host to the service host
contain the Notification ID
The general format of every setup message is
<DATAGRAM MESSAGE HEADER
<OPTIONAL INTERNET HEADER
The service host accepts setup requests in either Internet
non-Internet format. Replies from the service host will be
the same form as the request, that is, Internet requests
Internet replies, and non-Internet requests get non-
replies
The format of the combined datagram message header and
message header is illustrated in Figure 6. The body of the
messages depends on the particular setup message type.
request and reply messages are described in Section 6.1.
request and reply messages are described in Section 6.2.
simplify the presentation in both of these sections, the
messages are assumed to be exchanged between a local host
SIMP even though Internet group and stream setups are
(see Figure 6). The format of notifications, which consists
only a single word beyond the basic setup header, is shown
Figure 7. Since the SIMP does not retain the optional
header information that can be included in setup requests
Internet notifications are not supported. The format
acknowledgment messages associated with request/reply
notification setups is illustrated in Figure 8.
25
RFC 907 Host Access
July 1984
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
0-5 Datagram Message Header. Each setup message
with the six word datagram message header (see
3).
6-N Internet Header (Optional). These fields,
present, conform to the DoD Standard Internet
(IP). The Internet header size is a minimum of 10
words but can be longer depending on the use
optional IP facilities. (Internet
messages are not supported.)
N+1[8-15] Setup Type. This field determines the type of
message
0 =
1 =
2 =
3 =
N+1[0-7] Setup Code. For requests, this field identifies
26
RFC 907 Host Access
July 1984
Request Type
1 = Create group
2 = Delete group
3 = Join
4 = Leave
5 = Create
6 = Delete
7 = Change stream
8 =
For Replies, this field provides the Reply Code.
of the Reply Codes can be returned to any
request and others are request specific
0 = Group or stream
1 = Group or stream
2 = Group
3 = Group
4 = Stream
5 =
6 = Bad request
7 =
8 = Network
9 = Bad
10 = Group address/stream ID
11 = Not member of group/creator of
12 = Stream priority not being
13 =
14 =
15 = Illegal
16 =
17 = Insufficient network
18 = Requested bandwidth too
19 =
20 =
21 = Maximum messages per slot not consistent
slot
22 = Reply lost in
23 = Illegal reliability
27
RFC 907 Host Access
July 1984
For Notifications, this field contains
Notification Type
0 = Stream
1 = Stream
2 = Stream
3 = Group deleted by
4 = Group deleted by
5 = All streams
6 = All groups
For Acknowledgments, this field contains
Acknowledgment Type
0 = Reply
1 = Notification
N+2[0-15] Setup Checksum. The checksum covers the three
message header words and the setup message body
words. Setups received with bad checksums must
discarded
N+3[0-15] Setup ID. This field is assigned by the host
uniquely identify outstanding requests (Request ID
and by the service host to uniquely
outstanding notifications (Notification ID).
28
RFC 907 Host Access
July 1984
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
0-5 Datagram Message Header (see Section 3).
6[8-15] Setup Type = 3 (Notification).
6[0-7] Notification Type
0 = Stream
1 = Stream
2 = Stream
3 = Group deleted by
4 = Group deleted by
5 = All streams
6 = All groups
7[0-15] Setup Checksum. Covers words 6-9.
8[0-15] Notification ID
9[0-15] Notification Information. This field contains
16-bit group address in the case of a
29
RFC 907 Host Access
July 1984
notification (types 3 and 4) and the 10-bit
stream ID (right justified) in the case of a
notification (types 0-2). This field is zero
Notification Types 5 and 6, which pertain to
streams and groups, respectively
30
RFC 907 Host Access
July 1984
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
0-5 Datagram Message Header
6[8-15] Setup Type = 0 (Acknowledgment).
6[0-7] Acknowledgment Type
0 = Reply
1 = Notification
7[0-15] Setup Checksum. Covers words 6-8.
8[0-15] Setup ID. This is either a Request ID or
Notification ID
31
RFC 907 Host Access
July 1984
6.1 Stream Setup
Hosts use streams to support high duty cycle
and applications requiring a one satellite hop
transmission delay. Host streams must be set up before
data messages can flow. The stream setup messages defined by
are Create Stream Request, Create Stream Reply, Delete
Request, Delete Stream Reply, Change Stream Parameters Request
and Change Stream Parameters Reply. The use of these messages
illustrated in the scenario of exchanges between a host and
local SIMP shown in Figure 9 where the host establishes a stream
sends some data, modifies the stream characteristics, sends
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
local SIMP. Other SIMPs and hosts are essentially unaware of
existence of the stream. Stream messages received by
destination host are, therefore, processed identically
datagram messages. (All SIMPs must, of course, be aware of
channel allocation associated with a host stream in order
perform satellite channel scheduling.) Not illustrated,
implicit in this scenario, are the optional A/R
associated with each of the stream setup messages
32
RFC 907 Host Access
July 1984
Host
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
Host streams have six characteristic properties which
selected at stream setup time. These properties, which apply
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,
host sends the Create Stream Request message illustrated
Figure 10 to the SIMP. After the satellite network has
the Create Stream Request, the SIMP will respond to the host
a Create Stream Reply message formatted as shown in Figure 11.
Assuming that the reply code in the Create Stream Reply is
indicating that the stream has been created successfully,
host may proceed to transmit stream data messages after sending
33
RFC 907 Host Access
July 1984
Reply Acknowledgment
During the lifetime of a stream, the host which created
may decide that some of its six characteristic properties
be modified. All of the properties except the stream
can be modified using the Change Stream Parameters
message. The format of this command is illustrated in Figure 12.
After the network has processed the Change Stream
Request, the SIMP will respond by sending a Change
Parameters Reply to the host with the format shown in Figure 13.
A host requesting a reduced channel allocation should
its sending rate immediately without waiting for receipt of
Change Stream Parameters Reply. A host requesting an
allocation should not proceed to transmit according to the
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
the stream is no longer needed and the associated
channel allocation can be freed up, the host sends its local
a Delete Stream Request message formatted as indicated in
14. After the network has processed the Delete Stream Request
the SIMP will respond by sending a Delete Stream Reply to
host with the format shown in Figure 15.
34
RFC 907 Host Access
July 1984
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
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 maximum number of stream messages that will
be delivered to the SIMP by the host for
in one stream slot
9[10-11] Interval. This field specifies the interval,
number of 21.2 ms frames, between stream slots
35
RFC 907 Host Access
July 1984
0 = 1
1 = 2
2 = 4
3 = 8
As an example, an interval of 4 frames corresponds
an allocation of Slot Size words every 85 ms
9[8-9] Priority. This field specifies the priority at
all messages in the host stream should be handled
0 = Low
1 = Medium Low
2 = Medium High
3 = High
9[6-7] Reliability. This field specifies the basic bit
error rate requirement for the data portion of
messages in the host stream
0 = Low
1 = Medium
2 = High
3 =
9[0-5] Reliability Length. This field specifies how
words beyond the stream message header should
transmitted at maximum reliability for all
in the host stream
10[0-15] Slot Size. This field specifies the slot size
16-bit words of stream message text. Stream
header words are excluded from this count. The
can partition this allocation on a slot-by-slot
among a variable number of messages as long as
maximum number of messages per slot does not
MAX MES
36
RFC 907 Host Access
July 1984
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
0-5 Datagram Message Header
6[8-15] Setup Type = 2 (Reply).
6[0-7] Reply Code
0 = Stream
8 = Network
12 = Stream priority not being
17 = Insufficient network
18 = Requested bandwidth too
21 = Maximum messages per slot not
with slot
22 = Reply lost in
23 = Illegal reliability
7[0-15] Setup Checksum. Covers words 6-9.
8[0-15] Request ID
37
RFC 907 Host Access
July 1984
9[10-15] Reserved
9[0-9] Host Stream ID. This field contains a host
ID assigned by the network. It must be included
all stream data messages sent by the host to
the SIMP to associate the message with stored
characteristics and the reserved satellite
time
38
RFC 907 Host Access
July 1984
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
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] 