IEN 192
HOST/SATNET PROTOCOL
Bolt Beranek and Newman Inc.
July 1981
Host/SATNET Protocol IEN 192
TABLE OF CONTENTS
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Satellite IMP Implementation Details . . . . . . . . . . . 4
2.1 Initialization . . . . . . . . . . . . . . . . . . . . 5
2.2 Host-to-Satellite IMP Input . . . . . . . . . . . . . . 6
2.3 Satellite IMP-to-Host Output . . . . . . . . . . . . . 8
3. DATAGRAM ACCESS PROTOCOL . . . . . . . . . . . . . . . . . 10
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Types of Service . . . . . . . . . . . . . . . . . . . 11
3.3 Addressing . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Message Length . . . . . . . . . . . . . . . . . . . . 12
3.5 Host/SATNET Flow Control . . . . . . . . . . . . . . . 13
3.6 Status Messages . . . . . . . . . . . . . . . . . . . . 14
3.7 Hello Messages . . . . . . . . . . . . . . . . . . . . 14
3.8 Message Reference Numbers . . . . . . . . . . . . . . . 15
3.9 Initialization . . . . . . . . . . . . . . . . . . . . 15
3.10 Format Errors . . . . . . . . . . . . . . . . . . . . 16
3.11 Loop Detection . . . . . . . . . . . . . . . . . . . . 16
3.12 Piggybacked Control Messages . . . . . . . . . . . . . 17
3.13 Formats . . . . . . . . . . . . . . . . . . . . . . . 17
3.13.1 Control Codes . . . . . . . . . . . . . . . . . . 17
3.13.2 Data Messages . . . . . . . . . . . . . . . . . . 18
3.13.2.1 Type of Service Word . . . . . . . . . . . . . 19
3.13.2.2 Acceptance Status Word . . . . . . . . . . . . 20
3.13.3 ACCEPTED Messages . . . . . . . . . . . . . . . . 21
3.13.4 REFUSED Messages . . . . . . . . . . . . . . . . . 21
3.13.5 STATUS REQUEST Messages . . . . . . . . . . . . . 22
3.13.6 STATUS MESSAGES . . . . . . . . . . . . . . . . . 23
3.13.7 HELLO Message . . . . . . . . . . . . . . . . . . 23
3.13.8 FORMAT ERROR Message . . . . . . . . . . . . . . . 23
3.13.9 RESTART REQUEST Message . . . . . . . . . . . . . 24
3.13.10 RESTART COMPLETE Message . . . . . . . . . . . . 25
4. STREAM ACCESS PROTOCOLS . . . . . . . . . . . . . . . . . 26
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Stream Data Messages . . . . . . . . . . . . . . . . . 27
4.3 Stream Request Replies and Notifications . . . . . . . 28
4.3.1 CREATE . . . . . . . . . . . . . . . . . . . . . . 31
4.3.2 DELETE . . . . . . . . . . . . . . . . . . . . . . 32
4.3.3 JOIN . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.4 LEAVE . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.5 CHANGE . . . . . . . . . . . . . . . . . . . . . . 34
4.4 SATNET Termination and Suspension of Streams . . . . . 35
- i -
Host/SATNET Protocol IEN 192
5. Land Modem Interface . . . . . . . . . . . . . . . . . . . 37
6. Local Host Interface . . . . . . . . . . . . . . . . . . . 37
APPENDIX A. . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1 Table 1 -- Request Codes . . . . . . . . . . . . . . . 38
A.2 Table 2 -- Reply Codes . . . . . . . . . . . . . . . . 38
A.3 Table 3 -- Error Codes in D3 . . . . . . . . . . . . . 39
A.4 Table 4 -- Notification Codes . . . . . . . . . . . . 39
A.5 Table 5 -- SATNET Data Message Types . . . . . . . . . 39
A.6 Table 6 -- SATNET Logical Address Map . . . . . . . . 40
APPENDIX B. . . . . . . . . . . . . . . . . . . . . . . . . 43
B.1 Figure 1. Restart State Diagram . . . . . . . . . . . 43
B.2 Figure 2. General Message Format . . . . . . . . . . 44
B.3 Figure 3. Block DATA Message . . . . . . . . . . . . 45
B.4 Figure 4. Type of Service Word . . . . . . . . . . . 46
B.5 Figure 5. Acceptance Status Word . . . . . . . . . . 46
B.6 Figure 6. ACCEPTED Message . . . . . . . . . . . . . 46
B.7 Figure 7. REFUSED Message . . . . . . . . . . . . . . 46
B.8 Figure 8. STATUS REQUEST Message . . . . . . . . . . 47
B.9 Figure 9. STATUS Message . . . . . . . . . . . . . . 47
B.10 Figure 10. HELLO Message . . . . . . . . . . . . . . 48
B.11 Figure 11. FORMAT ERROR Message . . . . . . . . . . 48
B.12 Figure 12. RESTART REQUEST Message . . . . . . . . . 48
B.13 Figure 13. RESTART COMPLETE Message . . . . . . . . 48
B.14 Figure 14. Stream Data Format . . . . . . . . . . . 49
B.15 Figure 15. Request Message Format . . . . . . . . . 50
B.16 Figure 16. Reply Message Format . . . . . . . . . . 51
B.17 Figure 17. Notification Message Format . . . . . . . 52
B.18 Figure 18. Create Request Words . . . . . . . . . . 53
B.19 Figure 19. Delete, Join, Leave Request Words . . . . 54
- ii -
Host/SATNET Protocol IEN 192
PREFACE
This document describes the current SATNET Host Access
protocol. This supersedes PSPWN #100 (SATNET Host Access
protocol) and PSPWN #104 (Host/SATNET Stream Access protocol).
The differences are:
(1) The initialization state diagram has been
changed so that neither side will enter the
ON state unless both sides of the connecting
transmission line are working.
(2) A "Host type" field was added to the Restart
Request and Restart Complete messages.
(3) The numeric values of some error codes have
been changed, as have the detailed meanings
of some of those codes.
(4) Some Stream Reply Codes have been changed.
(5) Some significant changes have been made to
the information supplied by hosts in Stream
Create and Change request messages.
(6) Hosts must use the acceptance/refusal flow
control strategy in response to data messages
from Satellite IMPs (i.e., this is no longer
an option).
- iii -
Host/SATNET Protocol IEN 192
1. Overview
In determining an appropriate host access protocol, several
factors must be considered. One set of factors concerns
regulation of transfers in either direction across the
host-network interface. A second set of factors concerns actions
associated with the transmission of messages across the network.
While there are several different protocols in existence which
deal with link and network access (e.g., SDLC and X.25), none
satisfies the totality of user services and other factors unique
to SATNET. Thus to allow flexible exploration of access issues,
a special protocol was developed for the network transmission
level. (For implementation convenience, however, an existing
ARPANET link error control protocol was used to provide reliable
interface transfers.)
The network-level access factors include the passing of
type-of-service information such as priority and delay class, the
passing of flow and congestion control information, coordination
of stream data messages with their scheduled times, and
mechanisms for dynamic stream and addressing setups.
The type-of-service information is dealt with by defining an
appropriate field in the message headers. This field currently
consists of eight bits in SATNET: Two bits for message type
(datagram/stream and internet designations), two bits to specify
- 1 -
Host/SATNET Protocol IEN 192
one of four priorities, two bits to specify one of four delay
classes, one bit to specify a holding time choice, and one bit to
specify reliability. The delay class choices presently consist
of one second, five seconds, twenty seconds, and two minutes.
The holding time choice consists of either twice the specified
delay class or two minutes. The reliability choice consists of
"high", which causes channel retransmissions to be used, or
"standard", which inhibits the use of retransmissions and allows
messages with bad data checksums (but good checksums on their
control information) to be delivered to users. Standard
reliability is designed for applications which can tolerate
occasional bit errors, but cannot tolerate lost or out-of-order
packets (e.g. packet speech).
Flow and congestion control information is passed by the use
of two distinct mechanisms. First, status information reflecting
current congestion control is sent in all data and related
control messages; in the absence of other traffic, a special
status message is sent periodically. This information indicates
which priority and delay classes are currently being accepted by
the network.
The second mechanism consists of specific information
concerning the disposition of each data message passed to the
network. Each data message is numbered (modulo 128) by the
- 2 -
Host/SATNET Protocol IEN 192
sending host for identification purposes. Upon receipt, the
network returns an "acceptance" or "refusal" indication to the
host. An acceptance implies the network believes it can deliver
the message to its destination and is proceeding to do so;
delivery, however, is not guaranteed. A refusal means the
network has discarded the message; in this case a refusal subcode
is included to indicate the reason. Messages may be refused
because, for example, the destination is down or does not exist,
because its priority or delay class is not being accepted, or
because of temporary flow control reasons associated with source
or destination buffering. In the latter case the message is
assigned to one of several categories used for subsequent
notification purposes. A bit representing each category is
passed along with the priority-delay class status information in
all messages. When the message is refused the number of the
assigned category is returned to the sender, with the values of
subsequent category status bits indicating when messages of that
category will again be accepted.
In order to minimize message delays and to schedule stream
slots efficiently, the coordination of stream data messages
involves establishment of the correct time window in which the
host should pass each message to the network. The present system
uses explicit accept/refuse messages to accomplish this. Stream
and addressing setups are accomplished by using datagram messages
between the hosts and the network.
- 3 -
Host/SATNET Protocol IEN 192
2. Satellite IMP Implementation Details
For each physical host port the software uses the following
data structures:
Protocol state word,
Category queues,
Host output queue,
Accept/refuse queue (HAQ),
Interface property table,
Last-heard word (LSTHRD).
The protocol state word indicates whether the protocol is in
initialization or running state. If in initialization state, no
messages will be accepted or delivered until the necessary
handshaking procedure, as described below, is completed.
The four category queues are used to store messages that
have been refused by a host. If a host refuses a message and
provides an appropriate category indication, the message will be
stored on the specified category queue until the host indicates
it is willing to accept messages of that category. If a message
reaches its maximum holding time before the host will accept it,
it will be dropped from the queue.
The host output queue is a queue of data messages waiting to
be delivered to the appropriate host. Ordered by urgency, all
messages remain on this queue until they are transferred into the
HAQ just prior to being sent to the host or until their holding
time expires.
- 4 -
Host/SATNET Protocol IEN 192
The HAQ is a storage location for a message that has been
sent to the host and is awaiting an accept or refuse response.
If a response is received, the message is removed from the queue.
If no response is received, the message will be removed when its
maximum holding time has expired.
The interface property table (IPT) is used to indicate any
of the various protocol options selected by a host. One such
option is whether to allow piggybacking of Host/SATNET control
messages. Another option is that the host may decline to do
accept/reject decisions on traffic that it receives from SATNET.
The last-heard word indicates when the host was last heard
from. The host is declared down if it has not been heard from in
a specified time, currently about thirty seconds. The host will
remain down until the necessary handshaking is completed.
2.1 Initialization
Whenever a host or Satellite IMP is restarted, it sends a
RESTART-REQUEST control message to the other party. This message
will be repeated periodically until a RESTART-COMPLETE message is
received from the other party. When the RESTART-COMPLETE message
is received by the first party, it will then also send a
RESTART-COMPLETE message.
- 5 -
Host/SATNET Protocol IEN 192
2.2 Host-to-Satellite IMP Input
For datagram traffic, SATNET accepts variable-length
messages of up to a fixed maximum length (currently 128 16-bit
words). The host prefixes each message with a header which
provides addressing and control information. The control
information specifies priority, desired delivery delay, maximum
holding time, and selection of message control options such as
reliability. Each datagram message from a host is accepted or
rejected by the Satellite IMP according to the current network
loading and other factors. The Satellite IMP always returns a
control message indicating acceptance or refusal.
The message control parameters have the following possible
values: Priority is an integer from zero to three, with three
being the lowest priority and zero the highest. There are four
possible delay classes: 1 second, 5 seconds, 20 seconds, and 120
seconds. There are two possible choices for maximum holding
time: twice the delay class or the maximum system holding time.
Reliability may be either normal or high reliability (zero or
one).
Initially, when a message is offered by a host, a minimal
amount of buffer is requested at high priority, and the header of
the message is copied into this buffer in SATNET internal format.
The information in the header is then presented to the
- 6 -
Host/SATNET Protocol IEN 192
Accept/Reject module. If the message is accepted the additional
buffer needed is obtained, the rest of the message is copied into
the buffer, and an accept message is placed on the accept/reject
notification list (ARN). If the message is rejected, the
appropriate rejection code is placed on the ARN and the buffer
space is freed. It is left for the host to decide whether to
resubmit the message at a later time. The rejection code will
also inform the host of which priority and delay classes are
currently being accepted, to assist the host in making message
offering decisions.
The accept/reject decision is performed as follows: The
first checks are made to ensure a valid source ID, adequate
buffer in the Satellite IMP, and a message size not exceeding the
maximum allowed size. The Satellite IMP must also be in the
In-Sync state to be able to accept the message. For any message
passing these tests, its TTG and priority are calculated, and
used to form its urgency value.
Next a check is made to see if the message can be delivered
to the destination, which involves checking a table of
destination parameters. The Satellite IMP verifies that the
destination Satellite IMP and host are up and are receiving
messages of the same category as the offered message.
- 7 -
Host/SATNET Protocol IEN 192
Although not implemented, the following checks are
considered useful. If the reservation-making queue contains too
much traffic of higher urgency or if the number of free buffers
is below a fixed threshold, the message will be refused. Also, a
maximum buffer usage may be assigned to each host for messages of
each category; messages will be refused if the threshold is
exceeded for messages of the same category.
A stream packet undergoes a different set of checks before
it is accepted by the Satellite IMP. The stream must exist, the
length of the message must not exceed the maximum allowable for
that stream, and there must be room available on the stream queue
for another packet. Also, the offering host must be designated
as a member of that stream.
2.3 Satellite IMP-to-Host Output
Whenever there is an opportunity to send a message to a
host, the Satellite IMP will examine every eligible queue to
determine which message should be sent first. This includes the
host output queue, the four category queues, and the control
message waiting queue (ARN). If ARN is longer than a specified
threshold, sending of control messages will take precedence over
sending of data messages, until the ARN length falls below the
threshold. Otherwise, if piggybacking is allowed, a data message
will be sent to the host with a control message piggybacked. If
- 8 -
Host/SATNET Protocol IEN 192
no piggybacking is allowed, then control messages and data
messages will compete. Competition is always on the basis of
urgency (priority and TTG). A category queue may be ineligible
if the host is not accepting messages of that category. In the
absence of other traffic, a Satellite IMP will send a 'HELLO'
message every second. Once a data message has been selected it
is queued in HAQ and transmitted to the host.
If the host fails to respond in time, the message will be
deleted from HAQ when its holding time expires. If the host
accepts, the message will be removed from HAQ and discarded. If
the host refuses and specifies a category, the message will be
removed from HAQ and placed on the specified category queue. If
the message is refused for urgency reasons, the message will be
requeued on the host output queue.
HAQ, the category queues, the host output queues, and ARN
are all kept ordered by urgency, so that testing for the most
urgent message consists of testing only the first message on each
queue.
- 9 -
Host/SATNET Protocol IEN 192 3. DATAGRAM ACCESS PROTOCOL 3.1 Overview For datagram traffic, SATNET accepts variable-length messages of up to 128 words of data. The source host prefixes each message with a leader which provides addressing and control information. The control information specifies message priority, desired delivery delay, delay at which the message should be discarded if not yet delivered ("maximum holding time"), and selection of one or more message control options. Each datagram message from a source host is accepted or refused by the source Satellite IMP according to current network loading and other factors, with a control message always returned by the source Satellite IMP indicating the acceptance or refusal. Upon acceptance, SATNET then attempts to deliver the message within its specified delay. However, it will continue trying to deliver if late, until its maximum holding time is exceeded. Datagram messages always have at least a two-hop delay (about 0.6 seconds) within SATNET. A lower-level protocol is assumed to provide reliable exchanges of data and control messages on the link connecting a host and Satellite IMP, and is assumed transparent to the protocol defined in this document. The Honeywell 316 Satellite IMPs use the ARPANET VDH protocol for this purpose. The new BBN - 10 -
Host/SATNET Protocol IEN 192
C/30 Satellite IMPs support in addition ARPANET 1822 local host
and distant host protocol.
3.2 Types of Service
The type-of-service fields in the SATNET leader of each
datagram message allows the following choices to be specified to
SATNET for each message:
Priority: 4 choices. This is used in conjunction with
the acceptable delivery delay to arbitrate for SATNET
resources.
Acceptable Delivery Delay: 1 second, 5 seconds, 20
seconds, and 120 seconds.
Holding Time: This is the maximum time an undelivered
message should be held within SATNET before discarding.
There are two choices: (1) twice the specified
delivery delay, or (2) the maximum system holding time
(currently about two minutes).
Reliability: There are two choices, "standard" and
"high". If standard is specified, a satellite channel
acknowledgment is not used for the message, and it is
not retransmitted by the source Satellite IMP in case
of errors; if the packet is received at the destination
Satellite IMP with a good message leader but errors in
- 11 -
Host/SATNET Protocol IEN 192
the data portion of the message, it is marked as such
and delivered to its destination.
If "high" is specified, the message is retransmitted as
many times as necessary until a positive acknowledgment
is received by the source Satellite IMP, up to the
specified message holding time (duplicate copies may be
delivered to the destination host in this case).
3.3 Addressing
SATNET uses logical addressing, with each host assigned a
16-bit permanent address. Each data message sent to SATNET must
contain both a source and destination logical address, and is
delivered to the specified destination(s) with these addresses
unchanged. Table 6 in Appendix A contains the current list of
addresses.
3.4 Message Length
Datagrams may have variable lengths, where these lengths are
integer multiples of 16-bit words. Maximum length of the data
portion of a datagram message is 128 words. The "data portion"
excludes the SATNET leader but includes an internet header if
present.
- 12 -
Host/SATNET Protocol IEN 192 3.5 Host/SATNET Flow Control Each message sent by a host is accepted or refused by the Satellite IMP based upon various network and local congestion and status factors. If accepted, an ACCEPTED control message is returned to the host containing the message ID assigned by the host in the data message leader. If refused, a REFUSED control message is returned containing the message ID and a refusal code C. If the message itself is bad, a FORMAT ERROR control message is returned containing the message ID. The value of C is used to indicate to the host when it should subsequently retry the message. This is accomplished by also sending the host an "acceptance status" word at frequent intervals to inform it of the categories currently being accepted. The host may ignore the category information if it chooses, or map the categories into a smaller subset if convenient. The use of the categories allows the host to retry those messages first which are most likely to be accepted by the Satellite IMP. The "acceptance status" word also contains information indicating which message priorities and delivery delay classes are currently being accepted, allowing the host to also avoid unnecessarily sending new messages which will be refused. The acceptance status word is sent to the host in every data and - 13 -
Host/SATNET Protocol IEN 192
control message from the Satellite IMP; in the absence of regular
traffic, a "Hello" message containing the acceptance status word
is sent once per second.
Hosts must return an explicit acceptance or refusal for each
message received from the Satellite IMP. Note that a "refusal"
by the host is a request to the Satellite IMP to requeue the
message in question and submit it again later. Currently,
refused messages are immediately discarded, so as to eliminate a
line congestion problem seen with the catenet.
3.6 Status Messages
A host can request current status information from SATNET by
sending a "Status Request" control message. The Satellite IMP
will return a status message containing the acceptance status
word, SATNET global time, and an indicator of the current delay
expected for each delivery delay class. (Inclusion of host
status information is still under study.)
3.7 Hello Messages
When it is not sending data or control messages, the
Satellite IMP or host must send a "Hello" control message once
every second. In addition to providing frequent updating of
acceptance status, the hello message allows the receiver to
maintain the up/down status of the sender. The Satellite IMP
- 14 -
Host/SATNET Protocol IEN 192 will do this by resetting a timeout counter whenever anything is received from the host; if the timeout expires, the host will be declared down and the Satellite IMP will begin sending restart messages as described in the next section. The timeout value used by the Satellite IMP is thirty seconds. 3.8 Message Reference Numbers To support message-by-message acknowledgements, each data message is assigned a 7-bit "message reference number" by its sender. Its purpose is to allow referencing of the message in a subsequent acknowledgement (ACCEPTED, REFUSED, or FORMAT ERROR) message. Reference numbers may be assigned in any order, except that a particular number may not be reused until the message it refers to has been acknowledged. All reference numbers are automatically released whenever the Host/SATNET interface is reinitialized. 3.9 Initialization Since the Host/SATNET protocol requires an explicit acknowledgement for each message, the initialization procedure ensures that full two-way communication is possible before allowing either side to begin transmitting data. Whenever a host or a Satellite IMP is restarted, it sends a RESTART REQUEST control message to the other party once every ten seconds until a RESTART COMPLETE is received, at which time it sends a RESTART - 15 -
Host/SATNET Protocol IEN 192
COMPLETE. The procedure in initializing the interface is shown
in Figure 1 in Appendix B.
The initialization action indicated in Figure 1 consists of
flushing all queued control messages waiting to be sent, and of
flushing all received data messages for which an ACCEPTED or
REFUSED message has not already been sent. Note that data
messages waiting to be sent need not be flushed; they can
continue to be queued during the 'waiting' state and their
transmission begun once the 'on' state is entered.
3.10 Format Errors
Whenever an invalid leader field value or message length is
detected in a received message a FORMAT ERROR control message is
returned to the sending host or Satellite IMP. An error code is
returned in this message to indicate the detected condition
(these codes are defined in the Formats section of this document,
section 3.13).
3.11 Loop Detection
To allow a Satellite IMP or host to detect situations in
which the interface may be externally looped (crosspatched), a
Host/Satellite IMP address bit is included in all data and
control messages, identifying the sender of each message.
- 16 -
Host/SATNET Protocol IEN 192 3.12 Piggybacked Control Messages Control messages of the ACCEPT, REFUSE, FORMAT ERROR, and RESTART COMPLETE types may be piggybacked onto data messages by including the control message in the 16-bit "piggyback" field of the data message header. The Satellite Imp interprets all piggybacked control information before examining the rest of the data message, so, for example, a piggybacked RESTART COMPLETE takes effect immediately. 3.13 Formats The general format used for Host/SATNET interface exchanges is shown in Figure 2 (all figures are in Appendix B). The control code always defines the message format; for all except data messages, it also implicitly defines the message length. Exact data message length is assumed to be derived from the host or Satellite IMP interface transfer, and is always an integer multiple of 16-bit words. 3.13.1 Control Codes Each distinct message type is identified by a unique 4-bit control code. Codes currently defined are: - 17 -
Host/SATNET Protocol IEN 192
1 = DATA
2 = ACCEPTED
3 = REFUSED
4 = STATUS REQUEST
5 = STATUS
6 = HELLO
7 = DATA WITH ERRORS
13 = FORMAT ERROR
14 = RESTART REQUEST
15 = RESTART COMPLETE
3.13.2 Data Messages
Figure 3 shows the format for datagram DATA messages (the
width of each word in this and subsequent figures is 16 bits).
Words 1, 2, and 3 are defined by the interface sender (host or
Satellite IMP); words 4, 5, and 6 are defined by the source host.
Word 1, datagram message control word:
- H/S, bit 1: 0 = from Satellite IMP, 1 = from host
- message ID, bits 2-8: defined in Section 3.6
- block length, bits 9-12: the number of 64-word
blocks of data words following the message leader: a
block length of 1 means the message contains between
1 and 64 data words; a length of 2 means 65 and 128
data words, etc. The maximum datagram length is
defined by Section 3.2. A length of 0 means a null
DATA message.
- Control Code, bits 13-16:
1 = DATA (no detected errors)
- 18 -
Host/SATNET Protocol IEN 192
7 = DATA WITH ERRORS -- used only if "standard
reliability" service is designated and one or
more data errors were detected by SATNET in the
data portion of the message. Applies only to
packets delivered by SATNET to hosts.
Word 2, acceptance status: (defined below).
Word 3, piggyback field: This word may contain any
of the one-word control messages defined by codes 2,
3, 13, and 15. A value of zero means the word is not
used.
Word 4, Type of Service Word: (defined below).
Word 5, destination host: a 16-bit SATNET logical
address.
Word 6, source host: a 16-bit SATNET logical
address.
3.13.2.1 Type of Service Word
Figure 4 shows the details of word 4 of datagram DATA
message leaders.
M, bits 1-2: DATA message type;
0 = datagram, internet format
1 = stream, internet format
2 = datagram, local format
3 = stream, local format
- 19 -
Host/SATNET Protocol IEN 192
P, bits 3-4: priority; 0 = highest priority, 3 = lowest.
D, bits 5-6: acceptable delivery delay ("delay class");
delay class value
----------- -----
0 1 second
1 5 seconds
2 20 seconds
3 120 seconds
H, bit 7: holding time; 0 = maximum (120 seconds*),
1 = twice the specified delay class.
R, bit 8: reliability; 0 = high, 1 = standard
3.13.2.2 Acceptance Status Word
Figure 5 shows the details for this word. If the entire
word equals 0, everything is being accepted.
Category bits, bits 1-4: each bit defines the current
acceptance/refusal status for the category corresponding to
the bit number (e.g., bit 3 represents category 3).
0 = accepting for this category
1 = refusing
Delay Class Priority, bits 5-16 (not currently implemented):
each delay class is identified by its position within the
acceptance status word; e.g., bits 14-16 contain information
for delay class 3. The content of each three-bit field is a
binary number defining the current priorities being accepted
for that delay class, interpreted as follows:
- 20 -
Host/SATNET Protocol IEN 192
0 = all priorities accepted
1 = lowest priority (3) not accepted
2 = lowest two priorities (2,3) not accepted
3 = lowest three priorities (1,2,3) not accepted
7 = none accepted
3.13.3 ACCEPTED Messages
Figure 6 shows the format of ACCEPTED messages. (An
acceptance status word, as defined in Figure 5, is always the
second word of this and all other messages.)
H/S, bit 1: same as for Data messages.
Data message ID, bits 2-8: The message ID of the DATA
message being accepted.
Control Code, bits 13-16: ACCEPTED = 2.
3.13.4 REFUSED Messages
Figure 7 shows the format of REFUSED messages.
H/S, bit 1: same as for DATA messages.
Data message ID, bits 2-8: The message ID of the DATA
message being refused.
C, bits 9-12: refusal category. A value of 0 to 4
means a refusal due to temporarily unavailable
resources. Messages refused with category values 1 to
4 will not be accepted until the corresponding category
- 21 -
Host/SATNET Protocol IEN 192
bit in the acceptance status word becomes 0. A
category value of 0 means the refusal is because of the
message priority and/or delay class; acceptance
information for this case is given by the delay class
priority bits in the acceptance status word. Values of
C have the following meanings (acceptance status word
information does not apply to values 8 to 15):
0 = refused for priority/delay class
1 = category 1 refusal
2 = category 2 refusal
3 = category 3 refusal
4 = category 4 refusal
5 = undefined
6 = undefined
7 = undefined
*8 = data length greater than stream length
9 = destination host has been declared in a
"refusing" state
10 = destination host is not reachable
11 = destination host's Satellite IMP is not reachable
12 = unrecognized destination address
13 = destination host access not allowed
14 = illegal source host
*15 = no active stream with that stream ID
*(See Section 4 on stream access)
Control Code, bits 13-16: REFUSED = 3.
3.13.5 STATUS REQUEST Messages
Figure 8 shows the format of STATUS REQUEST messages.
H/S bit 1: same as DATA messages.
Control code, bits 13-16: STATUS REPORT = 4.
- 22 -
Host/SATNET Protocol IEN 192 3.13.6 STATUS MESSAGES Figure 9 shows the format of STATUS messages. Word 1: H/S bit, bit 1 = same as DATA messages. Control Code, bits 13-16: STATUS = 5. Word 2: ACCEPTANCE STATUS Word 3, SATNET global time: current internally synchronized clock time used by Satellite IMPs; unit of time = 10.24 milliseconds, maximum value equals 2{16} -1 units. Words 4-7: current expected delay for the indicated delay class (values to be defined). 3.13.7 HELLO Message Figure 10 shows the status of Hello messages. H/S bit 1: same as DATA messages. Control Code, bits 13-16: HELLO = 6. 3.13.8 FORMAT ERROR Message Figure 11 shows the format of FORMAT ERROR messages. - 23 -
Host/SATNET Protocol IEN 192
H/S bit 1: same as DATA messages.
Error Message ID, bits 2-8: ID of DATA message with
format error (if applicable, otherwise = 0).
Error Code, bits 9-12:
0 = undefined error
1 = data message length exceeds SATNET maximum size
2 = illegal control code
3 = block length disagrees with message length.
4 = illegal control code in piggyback
word of data message.
5 = undefined category value (5-7)
in REFUSED message.
Control Code, bits 13-16: FORMAT ERROR = 13.
Note: Implementation of error codes 2 to 5 is optional; however,
a FORMAT ERROR message should be returned with (at least) error
codes 0 and 1 for illegal conditions.
3.13.9 RESTART REQUEST Message
Figure 12 shows the format of RESTART REQUEST message.
H/S bit 1: same as DATA messages.
Host Type, bits 9-12: presently undefined.
Control Code, bits 13-16: RESTART REQUEST = 14.
- 24 -
Host/SATNET Protocol IEN 192
3.13.10 RESTART COMPLETE Message
Figure 13 shows the format of RESTART COMPLETE
messages.
H/S bit 1: same as DATA messages.
Host Type, bits 9-12: presently undefined.
Control Code, bits 13-16: RESTART COMPLETE = 15.
Note: All Restart Request and Complete messages sent by the
Satellite IMP have bits 9 to 12 set to zero.
- 25 -
Host/SATNET Protocol IEN 192 4. STREAM ACCESS PROTOCOLS 4.1 Overview In addition to datagram message service, SATNET provides a service called 'stream'. A stream is a sort of virtual circuit in which information must be established within Satellite IMP tables for the duration of the stream use. This information maintains an outstanding reservation for the stream, causing channel time to be scheduled at more or less regular intervals specified in the stream setup. This mechanism provides one of the important performance properties of a stream which motivates its use: one-hop for each stream data packet (as opposed to at least two hops for datagrams). Any number of hosts can use the same stream; host membership is accomplished by special Host/SATNET messages. Each stream is identified by a SATNET-assigned Stream ID, which has two distinct functions. The first is to allow Satellite IMPs to identify the transmission properties being used for each stream data message including verification that the sending host is a stream member. The second Stream ID function is its optional use as a destination address in a stream or datagram data message, causing delivery to the Stream ID members. (Its use in datagram messages allows "out of band" signaling messages to be sent while the stream data messages are also being sent.) - 26 -
Host/SATNET Protocol IEN 192
The destination address in a stream data message is not
limited to the Stream ID, however; any SATNET address may be
used. Thus, a host can set up a simplex stream in which it is
the only member, and therefore the only sender, and send messages
to different hosts using the single stream. Or, a set of hosts
can use a single stream in an arbitrarily shared manner
(determined by the hosts) to send to arbitrary destinations.
More typically, a stream would be used by a set of hosts for
voice conferencing, in which the Stream ID would be used as the
destination address. Note that, in all cases of shared use,
hosts must provide a protocol to determine how the stream is
shared. If every member host presented a stream data packet to
its Satellite IMP at the same time, they would all be sent
simultaneously in the satellite channel with resultant
destructive interference. (Note: the addressing use of a Stream
ID is not presently implemented -- only permanent SATNET
addresses, either point or group, are allowed.)
4.2 Stream Data Messages
Stream data messages have the format shown in Figure 14.
The message type (bits 1 and 2 of word H4) may be either 1
(stream data, internet format) or 3 (stream data, local
format).(1) Bits 3 to 16 of word H4 contain a Stream ID,
_________________________________________________________________
(1) Table 5 in Appendix A defines all SATNET message types.
- 27 -
Host/SATNET Protocol IEN 192
assigned by SATNET as described in the next section. The
destination address in word H5 can be any SATNET address. The
source host address in word H6 must be assigned to the Satellite
IMP port used to send the message into SATNET, and must be a
member of the Stream ID.
An ACCEPTED or REFUSED message will be returned by the
Satellite IMP for each stream data message, the same as for
datagrams. Stream data messages will normally always be accepted
unless they are greater than (to be determined) seconds early
relative to the next stream slot time, or the stream is being
preempted by higher priority traffic.
Internal SATNET channel acknowledgments are not used for
stream data messages.
4.3 Stream Request Replies and Notifications
Streams can be used by a Host only by first establishing
certain information within SATNET. The following requests are
used:
CREATE
DELETE
JOIN
LEAVE
CHANGE
Each request is sent by the host, along with supplemental
information, in the data portion of a datagram message to the
- 28 -
Host/SATNET Protocol IEN 192
SATNET Service Host. A Request message is accepted or refused by
the local Satellite IMP the same as any other datagram message;
if accepted it is delivered to an internal host within the local
Satellite IMP which acts on the request, returning a datagram
message reply to the source host indicating its disposition. The
reply always contains a Request ID supplied by the host in its
Request message, allowing the host to relate the response to its
earlier request (more than one Request message may be outstanding
from a host; the maximum number outstanding will be limited
implicitly by the datagram message refusal mechanism).
Figure 15 shows the format used for Request messages, which
are always local datagram (type 2). The Request message priority
PR in header word H4 may be assigned the same as for other
datagram traffic. The source host address must be assigned to
the Satellite IMP port used for the message. The first data word
D1 contains one of the Request Codes defined in Table 1. The
Request ID in word D2 is chosen by the host, and should not be
re-used until a Reply message is received with the same ID to
avoid ambiguity.
Figure 16 shows the format used for Reply messages, which
are always local datagram (type 2). The values of PR and the
Request ID are those used by the host in the Request messages;
the source host address of the Request message is used as the
destination host address. Word D1 contains a Reply Code in bits
- 29 -
Host/SATNET Protocol IEN 192
2 to 16 indicating the action taken on the request; bit 1 is
always zero. The contents of words D3-D6 depends on the Reply
Code; whether used or not, all Reply messages will contain six
data words. Table 2 lists the possible Reply Codes.
In addition to Reply messages, a Notification message may be
sent to a host by SATNET concerning streams for which the host
has previously established membership. The Notification message
format is shown in Figure 17, and is also a local datagram type
message. The notification message priority PS in word H4 is that
assigned to the stream; the Stream ID involved in the
notification is contained in data word D2. A Notification Code
is contained in bits 2 to 16 of word D1; bit 1 of this word is
always set to 1 to distinguish Notification messages from Reply
messages. As in the case of Reply messages a Notification
message always contains words D3 to D6, whose contents depend on
the Notification Code. Table 4 lists the Notification Codes.
(Notifications not implemented.)
Except when a request is refused as a result of information
local to the source Satellite IMP, Notification messages have a
delay of at least one satellite hop (about 0.25 seconds) relative
to the request message, and are initiated at approximately the
same global SATNET time by Satellite IMPs to their involved
hosts. A Reply indicating successful completion of a stream
request requires at least five seconds' delay after receipt of
the request.
- 30 -
Host/SATNET Protocol IEN 192
4.3.1 CREATE
The words used in the data portion of a CREATE request are
shown in Figure 18. Word D3 contains a zero if a new stream is
being requested (the use of non-zero values will be defined in a
later version of the Host/SATNET access protocol). Words D4-D6
contain a Key which is used to authenticate subsequent requests
from any host concerning the stream. Any 48-bit value may be
used, including zero; however, all subsequent Request message
Keys for this stream must equal this Key to be honored.
Words D7-D9 define the parameters to be used for the stream
by SATNET. Ps is the priority to be used for the stream data
messages. Bits 7 to 16 of word D7 indicate the maximum number L
of 16-bit data words which will be sent in any data message using
the stream. The queue length, bits 1-4 of D8, is the maximum
number of messages that may be queued at once awaiting
transmission using the stream. The stream interval is a 24-bit
quantity indicating the time (in ten microsecond units) between
stream messages. The high order eight bits are in D8, bits 9-16,
and the low 16 bits are in D9. A suitable time for messages in
this stream will be computed using the stream interval given.
If the CREATE is honored, Stream Started Reply message will
be returned with the Stream ID assigned by SATNET in word D3
(words D4-D6 are not used). The first stream channel allocation
- 31 -
Host/SATNET Protocol IEN 192
is begun approximately one stream interval I following generation
of the Reply message. If refused, a Stream Creation Refused will
be returned with a reason code in Word D3.
Each CREATE message received with word D3 set to zero will
cause the creation of a new stream (resources permitting),
independently of the Key or other field values contained in the
CREATE message. Note that different streams may use the same
Key; the SATNET-assigned Stream ID supplied by hosts in
subsequent Request messages provides unique referencing to the
stream in question.
4.3.2 DELETE
Figure 19 shows the data words sent in a DELETE Request.
Word D1 contains the DELETE STREAM Request Code; word D2 contains
the host's Request ID (this ID need not relate to any previous
Request message); word D3 contains the Stream ID; words D4-D6
contain the Key.
If the DELETE STREAM request is honored, the stream channel
allocations will be terminated and a Stream Deleted Reply message
will be returned with the Stream ID in word D3; words D4-D6 are
not used. In addition, a Notification message ("Stream Deleted
by Host X") will be sent to all other member hosts, with the
address of the requesting host in D3 (not implemented yet); words
D4-D6 are not used. All Satellite IMP table entries concerning
- 32 -
Host/SATNET Protocol IEN 192
the stream will be cleared and the Stream ID released for re-use.
If the DELETE STREAM request is not honored, a Stream
Deletion Refused Reply will be returned. Word D3 will indicate
why the request was refused. Table 3 indicates the refusal
reasons that can appear in D3.
4.3.3 JOIN
A JOIN Request (not implemented yet) is used by a host to
establish membership in a stream previously created by another
host. (It is the responsibility of the creating host to
distribute the assigned Stream ID and Key to those hosts it
wishes to have participate in the use of the stream.) The format
shown in Figure 19 is used for a JOIN, with the JOIN STREAM
Request Code in word D1.
If the stream exists and the correct Key is supplied, a
Stream Joined Reply message is returned approximately one stream
interval prior to the next scheduled channel allocation for the
stream. Word D3 of the reply message contains the Stream ID;
words D4-D6 contain the parameters currently used for the stream,
formatted according to words D7 to D9 of Figure 5. Also, a
Notification Code 3 Message ("Stream Joined by Host X") is sent
to all other member hosts--word D3 contains the address of the
newly joined host; words D4-D6 are not used.
- 33 -
Host/SATNET Protocol IEN 192
If the JOIN is not honored, a Join Refused Reply message
will be returned with a Table error code as appropriate.
4.3.4 LEAVE
A host may leave a stream of which it is a member by use of
a LEAVE Request (not implemented yet). The format of Figure 19
is again used, with the Request Code = 4. If the stream exists
and the host is entered as a member in Satellite IMP tables, a
Stream Left Reply message will be returned. Note that the Key is
not used for this request. Also, a Notification Code 4 message
("Stream Left by Host X") is sent to all member hosts; word D3
contains the address of the departed host; words D4-D6 are not
used.
A Leave request will always succeed. However, in some cases
it may be impossible to notify other stream members of the event.
If so, a Leave Without Notification Reply message will be
returned. Word D3 will indicate why notification could not be
made.
4.3.5 CHANGE
A host can request changes to the parameters defining a
stream by use of a CHANGE request (not implemented yet). This
message is identical to the CREATE message format of Figure 18,
except that the Request code is set to 5 in word D1 and word D3
- 34 -
Host/SATNET Protocol IEN 192
contains the Stream ID. All parameters of words D7-D9 must be
defined, whether or not their values are being changed -- if
allowed, the parameters will be used to re-define the stream
characteristics just as if they were being supplied in a CREATE
request.
If the changes can be honored, a Stream Changed Reply
message will be returned with the Stream ID in word D3; words
D4-D6 are not used. Also, a Notification code 5 message ("Stream
Changed by Host X") is sent to the other member hosts; word D3
contains the address of the requesting host; words D4-D6 contain
the new parameters.
If the changes cannot be made, a Stream Changes Refused
Reply message is returned to the requesting host, with a reason
code in word D3 (see Table 3).
4.4 SATNET Termination and Suspension of Streams
A stream termination will be initiated by SATNET if (1) a
data message is not sent in the stream by any of the member hosts
for sixty seconds, or (2) if the stream's channel allocation
cannot be honored for N (to be determined) consecutive stream
intervals I due to higher priority traffic (not implemented yet).
If either of these occurs, a Notification code 1 message ("Stream
Deleted by SATNET") will be sent to all member hosts with an
appropriate reason code in word D3; words D4-D6 are not used.
- 35 -
Host/SATNET Protocol IEN 192
All Satellite IMP table entries concerning the stream will be
deleted and the Stream ID released for re-use.
Whenever a stream's channel allocation has not been honored
by SATNET for M (to be determined) consecutive stream intervals I
following the last allocation, a Notification Code 6 message
("Stream Suspended") is sent to all member hosts (M will be much
smaller than N). If the allocations are resumed before N
consecutive non-allocations, a Notification Code 7 message
("Stream Resumed") is sent to all member hosts. (These are not
implemented yet.)
- 36 -
Host/SATNET Protocol IEN 192 5. Land Modem Interface A Satellite IMP communicates with other IMPs and with Very Distant Hosts via communication circuits, such as those provided by the various common carriers (Bell, Western Electric, etc.) The exact nature of the synchronous modems and dedicated full duplex lines varies from site to site. The hardware interface to the modem is the standard BBN IMP-modem interface which is logically identical to the Bell 303 interface with the exception that the mark and space convention is inverted for characters sent to the modem (i.e., binary "one" equals high current). The control lines, however, are not inverted. 6. Local Host Interface Local Host computers interface to the Satellite IMP via a hardware interface which is electrically equivalent to that used in the ARPANET between hosts and IMPs. The electrical specification for this interface appears in BBN Report No. 1822 entitled "Specifications for the Interconnection of a host and an IMP". - 37 -
Host/SATNET Protocol IEN 192 APPENDIX A. A.1 Table 1 -- Request Codes 1 -- Create Stream 2 -- Delete Stream 3 -- Join Stream 4 -- Leave Stream 5 -- Change Stream Parameters A.2 Table 2 -- Reply Codes 1 -- Stream Started 2 -- Stream Deleted 3 -- Stream Joined 4 -- Stream Left 5 -- Stream Changed 6 -- Stream Creation Refused 7 -- Stream Deletion Refused 8 -- Join Refused 9 -- Leave without Notification 10 -- Stream Changes Refused 11 -- Illegal Request Code - 38 -
Host/SATNET Protocol IEN 192 A.3 Table 3 -- Error Codes in D3 0 -- System busy; unable to handle request 1 -- Unimplemented function 2 -- Invalid protection Key 3 -- Not member of stream 4 -- Stream does not exist 5 -- Net trouble 6 -- Insufficient resources to handle request 7 -- Improper format for request 8 -- Channel protocol does not support streams 9 -- Illegal argument in stream request 10 -- Channel access not allowed A.4 Table 4 -- Notification Codes 1 -- Stream Deleted by SATNET 2 -- Stream Deleted by Host X 3 -- Stream Joined by Host X 4 -- Stream Left by Host X 5 -- Stream Changed by Host X 6 -- Stream Suspended 7 -- Stream Resumed A.5 Table 5 -- SATNET Data Message Types 0 -- Datagram, internet format 1 -- Stream data, internet format 2 -- Datagram, local format 3 -- Stream data, local format - 39 -
Host/SATNET Protocol IEN 192
A.6 Table 6 -- SATNET Logical Address Map
0 -- 0 SATNET Service Host
1 -- Etam EXPAK fake host
2 -- Goonhilly EXPAK fake host
3 -- Tanum EXPAK fake host
4 -- Clarksburg EXPAK fake host
5 -- Etam Message Generator/Sink #0
6 -- Etam Message Generator/Sink #1
7 -- Etam Message Generator/Sink #2
8 -- Etam Message Generator/Sink #3
9 -- Goonhilly Message Generator/Sink #0
10 -- Goonhilly Message Generator/Sink #1
11 -- Goonhilly Message Generator/Sink #2
12 -- Goonhilly Message Generator/Sink #3
13 -- Tanum Message Generator/Sink #0
14 -- Tanum Message Generator/Sink #1
15 -- Tanum Message Generator/Sink #2
16 -- Tanum Message Generator/Sink #3
17 -- Clarksburg Message Generator/Sink #0
18 -- Clarksburg Message Generator/Sink #1
19 -- Clarksburg Message Generator/Sink #2
20 -- Clarksburg Message Generator/Sink #3
21 -- Etam Internal Gateway
22 -- Goonhilly Internal Gateway
23 -- Tanum Internal Gateway
24 -- unused
25 -- unused
26 -- unused
27 -- unused
28 -- unused
29 -- unused
30 -- Clarksburg Internal Gateway
31 -- unused
32 -- unused
33 -- unused
34 -- unused
35 -- unused
36 -- unused
37 -- Universal Message Sink (equivalent name)
38 -- Tanum NDRE Gateway
39 -- Clarksburg COMSAT Gateway
40 -- Universal Satellite Echo (equivalent name)
41 -- Etam Monitor Fake Host
42 -- Goonhilly Monitor Fake Host
43 -- Tanum Monitor Fake Host
44 -- Clarksburg Monitor Fake Host
45 -- Etam Packet Core Fake Host
46 -- Goonhilly Packet Core Fake Host
- 40 -
Host/SATNET Protocol IEN 192
47 -- Tanum Packet Core Fake Host
48 -- Clarksburg Packet Core Fake Host
49 -- Etam TTY Fake Host
50 -- Goonhilly TTY Fake Host
51 -- Tanum TTY Fake Host
52 -- Clarksburg TTY Fake Host
53 -- Etam DDT Fake Host
54 -- Goonhilly DDT Fake Host
55 -- Tanum DDT Fake Host
56 -- Clarksburg DDT Fake Host
57 -- unused
58 -- unused
59 -- unused
60 -- Goonhilly UCL Gateway
61 -- Etam BBN Gateway
62 -- Etam Echo Fake Host
63 -- Goonhilly Echo Fake Host
64 -- Tanum Echo Fake Host
65 -- Clarksburg Echo Fake Host
66 -- unused
67 -- unused
68 -- unused
69 -- unused
70 -- unused
71 -- unused
72 -- Raisting External Gateway
73 -- unused
74 -- unused
75 -- unused
76 -- Raisting Internal Gateway
77 -- Raisting Echo Fake Host
78 -- Raisting Monitor Fake Host
79 -- Raisting EXPAK Fake Host
80 -- Raisting Packet Core Fake Host
81 -- Raisting DDT Fake Host
82 -- Raisting TTY Fake Host
83 -- Raisting Message Generator/Sink #0
84 -- Raisting Message Generator/Sink #1
85 -- Raisting Message Generator/Sink #2
86 -- Raisting Message Generator/Sink #3
87 -- unused
88 -- Fucino External Gateway
89 -- unused
90 -- unused
91 -- unused
92 -- Fucino Internal Gateway
93 -- Fucino Echo Fake Host
- 41 -
Host/SATNET Protocol IEN 192
94 -- Fucino Monitor Fake Host
95 -- Fucino EXPAK Fake Host
96 -- Fucino Packet Core Fake Host
97 -- Fucino DDT Fake Host
98 -- Fucino TTY Fake Host
99 -- Fucino Message Generator/Sink #0
100 -- Fucino Message Generator/Sink #1
101 -- Fucino Message Generator/Sink #2
102 -- Fucino Message Generator/Sink #3
103 -- unused
- 42 -
Host/SATNET Protocol IEN 192
+-------+
| |
| OFF |
| |
TO = TIMEOUT +-------+
RR = RESTART REQUEST |
RC = RESTART COMPLETE |INIT & SEND RR
|
V
+-------+
--->| |---------------
/ | | \
| | | \
| | INIT | |
| | |<--- |
\ | | \ |
----| | | |
10 SEC TO +-------+ | |
------- | | |
SEND RR |RCVD RR | |
| ----- | |
|SEND RC | |
V | |
+-------+ | |
-------------->| | | |
/ | | / |
/ --->| |---- |
| / |WAITING| 100 SEC TO |
| | | | -------- |
| \ | | SEND RR |
| ----| | |
| 10 SEC TO +-------+ |
| ------- | |
| SEND RC | |
| |RCVD RC |
| | |
\ V /
\ +-------+ /
---------------| |<--------------
RCVD RR | ON | RCVD RC
------------ | | -----
INIT & SEND RC +-------+ SEND RC
B.1 Figure 1. Restart State Diagram
- 43 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| | CONTROL CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
| |
| |
| |
| |
| |
| |
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.2 Figure 2. General Message Format
- 44 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H3 | PIGGYBACK WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H4 | TYPE OF SERVICE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H5 | DESTINATION HOST(S) ADDRESS |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H6 | SOURCE HOST ADDRESS |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D1 | |
| |
| DATA |
| |
DN | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.3 Figure 3. Block DATA Message
- 45 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H4 | M | P | D | H | R | (unused) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.4 Figure 4. Type of Service Word
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | C | D0 | D1 | D2 | D3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.5 Figure 5. Acceptance Status Word
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| DATA MESSAGE ID | (unused) | CODE = 2 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.6 Figure 6. ACCEPTED Message
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| DATA MESSAGE ID | C | CODE = 3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.7 Figure 7. REFUSED Message
- 46 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| (unused) | CODE = 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.8 Figure 8. STATUS REQUEST Message
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| (unused) | CODE = 5 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H3 | SATNET GLOBAL TIME |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H4 | CURRENT DELAY FOR CLASS 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H5 | CURRENT DELAY FOR CLASS 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H6 | CURRENT DELAY FOR CLASS 2 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H7 | CURRENT DELAY FOR CLASS 3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.9 Figure 9. STATUS Message
- 47 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| (unused) | CODE = 6 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.10 Figure 10. HELLO Message
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| ERROR MESSAGE ID | ERROR CODE | CODE = 13 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.11 Figure 11. FORMAT ERROR Message
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| (unused) | HOST TYPE | CODE = 14 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.12 Figure 12. RESTART REQUEST Message
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| (unused) | HOST TYPE | CODE = 15 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.13 Figure 13. RESTART COMPLETE Message
- 48 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H3 | PIGGYBACK WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H4 | 1 or 3| STREAM ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H5 | DESTINATION HOST(S) ADDRESS |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H6 | SOURCE HOST ADDRESS |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
| |
| (INTERNET HEADER IF TYPE=1) |
| |
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D1 | |
| |
| STREAM DATA |
| |
DN | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.14 Figure 14. Stream Data Format
- 49 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H3 | PIGGYBACK WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H4 |0 or 2 | PR | 0 | 0 | 0 | (unused) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H5 | SATNET SERVICE HOST (CURRENT ADDRESS = 0) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H6 | SOURCE HOST ADDRESS |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
| |
| (INTERNET HEADER IF TYPE=0) |
| |
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D1 | REQUEST CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D2 | REQUEST ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D3 | |
| |
| REQUEST INFORMATION |
| |
DN | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.15 Figure 15. Request Message Format
- 50 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H3 | PIGGYBACK WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H4 |0 or 2 | PR | 0 | 0 | 0 | (unused) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H5 | REQUESTING HOST |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H6 | SATNET SERVICE HOST (CURRENT ADDRESS = 0) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
| |
| (INTERNET HEADER IF TYPE=0) |
| |
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D1 | 0 | REPLY CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D2 | REQUEST ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D3 | |
| |
| REPLY INFORMATION |
| |
D6 | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.16 Figure 16. Reply Message Format
- 51 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H2 | ACCEPTANCE STATUS WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H3 | PIGGYBACK WORD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H4 |0 or 2 | PS | 0 | 0 | 0 | (unused) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H5 | MEMBER HOST |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
H6 | SATNET SERVICE HOST (CURRENT ADDRESS = 0) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
| |
| (INTERNET HEADER IF TYPE=0) |
| |
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D1 | 1 | NOTIFICATION CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D2 | STREAM ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D3 | |
| |
| NOTIFICATION INFORMATION |
| |
D6 | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.17 Figure 17. Notification Message Format
- 52 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D1 | REQUEST CODE = 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D2 | REQUEST ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D3 | STREAM ID = 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D4 | |
| |
D5 | KEY |
| |
D6 | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D7 | (unused) | PS | MAXIMUM DATA LENGTH (L) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D8 | QUEUE LENGTH | (unused) | STREAM INTERVAL (HIGH BITS) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D9 | STREAM INTERVAL (LOW BITS) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.18 Figure 18. Create Request Words
- 53 -
Host/SATNET Protocol IEN 192
MSB LSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| = 2: DELETE |
D1 | REQUEST CODE = 3: JOIN |
| = 4: LEAVE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D2 | REQUEST ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D3 | STREAM ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
D4 | |
| |
D5 | KEY |
| |
D6 | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
B.19 Figure 19. Delete, Join, Leave Request Words
- 54 -
mirror server hosted at Truenetwork, Russian Federation.