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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 Host Access Protocol
July 1984 Specification
address.
51
RFC907 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
RFC907 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
RFC907 Host Access Protocol
July 1984 Specification
address.
54
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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
RFC907 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 |