📄 rfc907.txt
字号:
present.
3[15] Data Message Type. This bit identifies whether the
message is a datagram message or a stream message.
0 = Datagram Message
1 = Stream Message
3[14] Internet/Local Flag. This flag is set by a source host
to specify to a destination host whether the data
portion of the message contains a standard DoD Internet
header. This field is passed transparently by the
source and destination SIMPs for traffic between
external satellite network hosts. This field is
examined by internal SIMP hosts (e.g., the network
service host) in order to support Internet operation.
0 = Internet
1 = Local
3[13] Discard Flag. This flag allows a source host to
instruct the satellite network (including the
destination host) what to do with the message when data
errors are detected (assuming the header checksum is
correct).
0 = Discard message if data errors detected.
1 = Don't discard message if data errors detected.
The value of this flag, set by the source host, is
passed on to the destination host.
3[12] Data Error Flag. This flag is used in conjunction with
the Discard Flag to indicate to the destination host
whether any data errors have been detected in the
message prior to transmission over the SIMP-to-Host
access link. It is used only if Discard Flag = 1. It
should be set to zero by the source host.
11
RFC 907 Host Access Protocol
July 1984 Specification
0 = No Data Errors Detected
1 = Data Errors Detected
3[10-11] Time-to-Live Designator. The source host uses this
field to specify the maximum time that a message
should be allowed to exist within the satellite network
before being deleted. Messages may be discarded by the
network prior to this maximum elapsed time.
0 = 1 seconds
1 = 2 seconds
2 = 5 seconds
3 = 10 seconds
The Time-to-Live field is undefined in messages sent
from a SIMP to a host.
3[8-9] Priority. The source host uses this field to specify
the priority with which the message should be handled
within the network.
0 = Low Priority
1 = Medium-Low Priority
2 = Medium-High Priority
3 = High Priority
The priority of each message is passed to the
destination host by the destination SIMP.
3[6-7] Reliability. The source host uses this field to
specify the basic bit error rate requirement for the
data portion of this message. The source SIMP uses
this field to determine the satellite channel
transmission parameters required to provide that bit
error rate.
0 = Low Reliability
1 = Medium Reliability
12
RFC 907 Host Access Protocol
July 1984 Specification
2 = High Reliability
3 = Reserved
The Reliability field is undefined in messages sent
from a SIMP to a host.
3[0-5] Reliability Length. This source host uses this field
to specify a portion of the user data which should be
transmitted at the highest reliability level (lowest
bit error rate). Both the six message header words and
the first Reliability Length words of user data will be
transmitted at Reliability=2 while the remainder of the
user data will be transmitted at whatever reliability
level is specified in field 3[6-7]. The reliability
length mechanism gives the user the ability to transmit
private header information (e.g., IP and TCP headers)
at a higher reliability level than the remainder of the
data. The Reliability Length field is undefined in
messages sent from a SIMP to a host.
4[0-15] Destination Host Address. This field contains the
satellite network logical address of the destination
host.
5[0-15] Source Host Address. This field contains the satellite
network logical address of the source host.
6-N Data. This field contains up to 16,384 bits (1024 16-
bit words) of user data.
13
RFC 907 Host Access Protocol
July 1984 Specification
4 Stream Messages
Stream messages are the second type of message level data
messages. As noted in Section 2, streams exist primarily to
provide a one satellite hop delay for volatile traffic such as
speech. Hosts may also use streams to support high duty cycle
applications which require guaranteed channel bandwidth.
Streams must be created before stream messages can flow from
host to host. The protocol to accomplish stream creation is
described in Section 6.1. Once established, a stream is
associated with a recurring channel allocation within the
satellite network. This fixed allocation imposes rather strict
requirements on the host using the stream if efficient channel
utilization is to be achieved. In particular, stream messages
must match the stream allocation both in terms of message size
and message interarrival time.
Within the bounds of its stream allocation, a host is
permitted considerable flexibility in how it may use a stream.
Although the priority, reliability, and reliability length of
each stream message is fixed at stream creation time, the
destination logical address can vary from stream message to
stream message. A host can, therefore, multiplex a variety of
logical flows onto a single host stream. The format of stream
messages is described in Figure 2.
14
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| XXXX | MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 1|IL| D| E| TTL | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2 . STREAM MESSAGE
0[15] Message Class = 0 (Data Message).
0[14] Loopback Bit.
0[12-13] Go-Priority.
0[8-11] Reserved.
0[0-7] Message Number. This field serves the same purpose as
the message number field in the datagram message.
Moreover, a single message number sequence is used for
both datagram and stream messages (see Section 5).
1[0-15] Header Checksum. Covers Words 0-5.
2[0-15] Piggybacked A/R.
15
RFC 907 Host Access Protocol
July 1984 Specification
3[15] Data Message Type = 1 (Stream).
3[14] Internet/Local Flag.
3[13] Discard Flag.
3[12] Data Error Flag.
3[10-11] Time-to-live Designator.
0 = Reserved
1 = 1 second
2 = Reserved
3 = Reserved
3[0-9] Host Stream ID. The service host uses this field to
identify the host stream over which the message is to
be sent by the SIMP. Host stream IDs are established
at stream creation time via host exchanges with their
network service host (see Section 6.1).
4[0-15] Destination Host Address.
5[0-15] Source Host Address.
6-N Data. This field contains up to 16,000 bits of user
data (multiple of 16-bits).
16
RFC 907 Host Access Protocol
July 1984 Specification
5 Flow Control Messages
The SIMP supports an acceptance/refusal (A/R) mechanism in
each direction on the host access link. The A/R mechanism is
enabled for the link by the host by setting a bit in the Restart
Complete control message (see Section 8). Each datagram and
stream message contains an 8-bit message number used to identify
the message for flow control purposes. Both the host and the
SIMP increment this number modulo 256 in successive messages they
transmit. Up to 127 messages may be outstanding in each
direction at any time. If the receiver of a message is unable to
accept the message, a refusal indication containing the message
number of the refused message and the reason for the refusal is
returned. The refusal indication may be piggybacked on data
messages in the opposite direction over the link or may be sent
in a separate control message in the absence of reverse traffic.
Acceptance indications are returned in a similar manner,
either piggybacked on data messages or in a separate control
message. An acceptance is returned by the receiver to indicate
that the identified message was not refused. Acceptance
indications returned by the SIMP do not, however, imply a
guarantee of delivery or even any assurance that the message will
not be intentionally discarded by the network at a later time.
They are sent primarily to facilitate buffer management in the
host.
To reduce the number of A/R messages exchanged, a single A/R
indication can be returned for multiple (lower numbered)
previously unacknowledged messages. Explicit acceptance of
message number N implies implicit acceptance of outstanding
messages with numbers N-1, N-2, etc., according to the
definition of acceptance outlined above. (Note that explicit
acceptance of message number N does not imply that all of the
unacknowledged outstanding messages have been received.) An
analogous interpretation of refusal message number allows the
receiver of a group of messages to reject them as a group
assuming that they all are being refused for the same reason. As
a further efficiency measure, HAP permits a block of A/R
indications to be aggregated into a single A/R control message.
Such a message might be used, for example, to reject a group of
17
RFC 907 Host Access Protocol
July 1984 Specification
messages where the refusal code on each is different.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -