As per Relevance of the word destination, we have this rfc below:
Network Working Group W.
Request for Comments: 1221
Updates: RFC 907 April 1991
Host Access Protocol (HAP) Specification - Version 2
Status of this
This memo describes the Host Access Protocol implemented in
Terrestrial Wideband Network (TWBNET). It obsoletes most but not
of RFC 907. This memo provides information for the
community. It does not specify an Internet standard.
of this memo is unlimited
This memo specifies the Host Access Protocol (HAP). HAP is a
layer (OSI Layer 3 lower) access protocol that was first
about a decade ago for the DARPA/DCA sponsored Wideband
Satellite Network (WBNET), the precursor of the current
Wideband Network (TWBNET). This version of the
obsoletes references [1] and [2] in addition to most of RFC 907.
HAP is a developmental protocol, and will be revised as
capabilities are added and unused features are eliminated or revised
One reason that HAP is being revised now is that, unlike the
WBNET's satellite channel, the TWBNET's T1 fiber links are not
broadcast medium. This has prompted some changes to the
that will permit greater efficiency in a mesh topology network
Another cause of revision is the need to make HAP able to support
variety of OSI layer 3 upper protocols, such as DECNET Phase V, ST
and CLNP, where before only Internet Protocol (IP) was used
Appendix B describes how backward compatibility with the older IP
only version of HAP is achieved. A third cause of protocol
is the desire to simplify interaction between ST2 protocol (RFC 1190)
agents and the TWBNET. This has mainly affected the way
setup errors are handled. These changes are expected to be
compatible. Appendix A describes two capabilities that may be
to HAP in the future
One of the protocol enhancements, "Group Streams", described
reference [2] has been eliminated. There are no known
that use the feature. As described in Appendix A, a new mechanism
to be called "shared streams", capable of providing
capabilities will be implemented if needed. Changes in [2] that
been retained include various query/reply control messages
permit a host to determine what resources it owns (mostly useful
Edmond [Page 1]
RFC 1221 HAP2 April 1991
cleanup following a host reboot or crash).
This document assumes the reader is familiar with DoD
terminology
1.
The Host Access Protocol (HAP) is a network layer protocol (as
X.25). ("Network layer" here means ISO layer 3 lower, the
layer below the DoD Internet Protocol (IP) layer [3] and above
link layer protocol.) HAP defines the different types of host-to
network control messages and host-to-host data messages that may
exchanged over the access link connecting a host and the
packet switch node. The protocol establishes formats for
messages, and describes procedures for determining when each type
message should be transmitted and what it means when one is received
HAP has been implemented in the wide-area network called
Terrestrial Wideband Network (TWBNET) [5] and in the routers
other hosts that connect to TWBNET. The packet switch nodes
compose the TWBNET are called Wideband Packet Switches (WPS).
Both the precursor to HAP, the Host/SATNET Protocol [6], used in
Atlantic Packet Satellite Network (SATNET) and the Mobile
Terminal Network (MATNET [7]), and HAP, used in the original
Satellite Network (WBNET) [8], were originally designed to
efficient access to the single satellite channel each network used
connect all sites. The HAP protocol designers reflected some of
peculiarities of the single satellite channel environment in the
protocol itself. The current Terrestrial Wideband Network (TWBNET
utilizes T1-speed fiber connections between sites. Future
and TWBNET may use a combination of terrestrial connections
satellite connections, and may have more than one of each. The
protocol has been changed to accommodate these extensions
Section 2 presents an overview of HAP. Details of HAP formats
message exchange procedures are contained in Sections 3 through 10.
Further explanation of some of the topics addressed in this
specification can be found in reference [1].
Any protocol employed to provide sufficiently reliable
exchange over the Host-WPS link is assumed to be transparent to
protocol defined in this document. Examples of such link-
protocols are ARPANET 1822 local and distant host [9], ARPANET
protocol [9], and HDLC
Edmond [Page 2]
RFC 1221 HAP2 April 1991
2.
HAP can be characterized as a full duplex, nonreliable protocol
an optional flow control mechanism. HAP messages flow
in both directions between the WPS and the host. Transmission
nonreliable in the sense that the protocol does not provide
guarantee of error-free sequenced delivery. If error-free
on the host's access link is required, it must be provided by
link layer protocol below HAP. (Use of link layer protocols for
purpose is not within the scope of this document.) HAP's
control mechanism operates independently in each direction, but
choice to enable flow control or not applies to both
together
HAP supports host-to-host communication in two modes corresponding
the two types of HAP data messages, datagram messages and
messages. Each type of message can be up to 2048 octets in length
The basic transmission service in the network is datagram service
Datagrams are variable length, unsequenced, independent, and
is not guaranteed. The HAP header of each datagram determines
processing of the message
On this datagram service base a "stream" service is built.
service provides network bandwidth guarantees, but requires
setup and teardown operations to allocate and deallocate
resources. Stream traffic is best suited for continuous
traffic, but may also be used to obtain the lowest possible
delay. Host streams are established by a setup message
between the host and the network prior to the commencement of
flow. Although established host streams can have
characteristics modified by subsequent setup messages while they
in use, the fixed allocation properties of streams relative
datagrams impose rather strict requirements on the source of
traffic using the stream. Stream traffic arrivals must match
stream allocation both in interarrival time and message size
reasonable efficiency is to be achieved. The characteristics and
of datagrams and streams are described in detail in Sections 3 and 4
of this document
Both datagram and stream transmission in the network use
addressing. Each host on the network is assigned a permanent 16-
logical address which is independent of the physical port on the
to which it is attached. These 16-bit logical addresses are
in all Host-to-WPS and WPS-to-Host data messages
HAP supports multicast addressing via "groups". Multicast
is provided primarily to support the multi-destination
required for conferencing applications. Group addresses
Edmond [Page 3]
RFC 1221 HAP2 April 1991
dynamically created and deleted by the use of setup
exchanged between a host and the WPS. Membership in a group may
any arbitrary subset of the network hosts. A message addressed to
group address is delivered to all hosts that are members of
group, except the sender. Once a multicast address has been created
any member host may use that address, not just the creator
Although HAP does not guarantee error-free delivery, error control
an important aspect of the protocol design. HAP error control
concerned with both local transfers between a host and its local
and transfers through the network to the destination(s). The
offers users a choice of network error protection options based
the network's ability to selectively send messages over
transmission media at different forward error correction (FEC) rates
These FEC options are referred to as reliability levels.
reliability levels (low, medium-low, medium-high, and high)
available. The precise error rate provided by each reliability
is not specified
Various checksum and CRC mechanisms are employed in the network
provide an error detection capability. A host has an
when sending a message to indicate whether the message should
delivered to its destination or discarded if a data error is
by the network. Each message received by a host from the
will have a flag indicating whether or not an error was detected
that particular message. A host can decide on a per-message
whether or not it wants to accept or discard transmissions
data errors
For connection of a host and WPS in close proximity, error rates
to external noise or hardware failures on the access circuit
reasonably be expected to be much smaller than the best network
circuit error rates. Thus for this case, little is gained by
error detection and retransmission on the access circuit. A 16-
header checksum is provided, however, to ensure that WPSen do not
on incorrect control information. For relatively long distances
noisy connections, retransmissions over the access circuit may
required to optimize performance for both low and high
traffic. It is expected that link layer error control
(such as HDLC with retransmission) will be used for this purpose,
use of a reliable link layer protocol is not within the scope of
document
Each datagram message submitted to the WPS by a host is marked
being in one of three priority classes, from priority 2 (highest
through priority 0 (lowest). The priority class is used by the
for arbitrating contention for scarce network resources (e.g.,
bandwidth). That is, if the network cannot deliver all of
Edmond [Page 4]
RFC 1221 HAP2 April 1991
offered messages, high priority messages will be delivered
preference to low priority messages. Priority level affects
order of access to intersite link bandwidth and the order of
delivery at the destination WPS
Each stream message also has three priority classes, from priority 2
(highest) through priority 0 (lowest). In addition,
themselves have three precedence classes, from precedence 2 (highest
through precedence 0. A stream of higher precedence can preempt
stream of lower precedence at setup time. Stream message
provides a mechanism for a low-bandwidth host to receive a high
bandwidth stream and selectively discard messages marked as
important by the sender. Stream message priority does not affect
order of delivery of stream messages between the source and
destination
Datagram and stream messages being presented to the WPS by a host
not be accepted for a number of reasons: priority too low
destination dead, lack of buffers in the source WPS, etc. The
faces a similar situation with respect to handling messages from
WPS. To permit the receiver of a message to inform the sender of
local disposition of its message, an acceptance/refusal (A/R
mechanism is implemented. The mechanism is the
manifestation of the WPS's (or host's) internal flow and
control algorithm. If A/Rs are enabled, an explicit or
acceptance or refusal for each message is returned to the host by
WPS (and conversely). This allows the host (or WPS) to retry
messages at its discretion and can provide information useful
optimizing the sending of subsequent messages when the reason
refusals is also provided. The A/R mechanism can be disabled
provide a "pure discard" interface. The host's choice to use the A/
mechanism or not does not limit its ability to send and
messages to any other hosts
While the A/R mechanism allows control of individual
transfers, it does not facilitate regulation of priority flows.
regulation is handled by passing advisory status information (GOPRI
across the Host-WPS interface indicating which priorities
currently being accepted. As long as this information, relative
the change in priority status, is passed frequently, the sender
avoid originating messages which are sure to be refused
HAP defines both data messages (datagram messages and
messages) and link control messages. Data messages are used to
information between hosts on the network. Link control messages
exchanged between a host and the WPS to manage the local access link
Allocation of network resources, such as streams and groups,
Edmond [Page 5]
RFC 1221 HAP2 April 1991
accomplished via an exchange of datagram messages, called Setups
between the user host and an agent inside the WPS called the "
Agent." Setups are used to reserve, allocate, modify, free,
deallocate network resources. Each allocated resource has a
identifier which, when placed in an appropriate field in a
header, allows that message to use the resource. E.g., after
exchange of Setups to create a group address, a message may be
to the group by placing the group address in the destination field
that message. The Service Agent also permits a host to inquire
resources it owns
Every HAP message consists of an integral number of 16-bit
(i.e., an even number of octets). The first several words of
message always contain control information and are referred to as
message header. The first word of the message header identifies
type of message which follows. The second word of the message
is a checksum which covers all header information. Any message
received header checksum does not match the checksum computed on
received header information must be discarded. The format of
rest of the header depends on the specific message type
The formats and use of the individual message types are detailed
the following sections. A common format description is used for
purpose. Words in a message are numbered starting at zero (i.e.,
zero is the first word of a message header). Bits within a word
numbered from zero (most significant) to fifteen (least significant).
The notation used to identify a particular field location is
{-} [ {-} ] <description
where optional elements in {} are used to specify the (inclusive
upper limit of a range. The reader should refer to these
identifiers for precise field size specifications. Fields which
common to several message types are defined in the first
which uses them. Only the name of the field will usually appear
the descriptions in subsequent sections
Link-level protocols used to support HAP can differ in the order
which they transmit the bits constituting HAP messages. The words
the message are transmitted from word 0 to word N
3. Datagram
Datagrams are one of the two message types provided by HAP,
described in the previous section. Because network resources are
reserved in advance for datagram traffic, delivery of
traffic is subject to greater delivery delays and delay variance
stream traffic, and is subject to flow and congestion controls
Edmond [Page 6]
RFC 1221 HAP2 April 1991
Datagram priority determines which packets are delivered or
when network resources do not permit handling all of the
traffic. It is expected that datagram messages will be used
support the majority of computer-to-computer and terminal-to-
traffic which is bursty in nature
The format of datagram messages and the purpose of each of the
control fields is described in Figure 1.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| 0 | F| MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 0|IL| D| E| PRI | TTL | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | PROTOCOL ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
7-N : DATA :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DATAGRAM
Figure 1
0[0] Message Class. This bit identifies the message as
data message or a control message
0 = Data
1 = Control
0[1] Loopback indicator. This bit allows the sender of
message to determine if its own messages are
looped back. The host and the WPS each use
settings of this bit for their transmissions. If
message arrives with the loopback bit set equal to
Edmond [Page 7]
RFC 1221 HAP2 April 1991
outgoing value, then the message has been looped
0 = Sent by
1 = Sent by
0[2-3] Go-Priority. In WPS-to-Host messages, this
provides advisory information concerning the
priority currently being accepted by the WPS. The
may optionally choose to provide similar
information to the WPS
0 = Low
1 = Medium
2 = High
3 = (Reserved.)
0[4-6] Reserved. Must be zero
0[7] Reserved. Must be zero. Formerly used for
diagnostic purposes
0[8-15] Message Number. This field contains the
of the message used by the acceptance/refusal (A/R
mechanism (when enabled). If the message number
zero, A/R is disabled for this specific message.
Section 5 for a detailed description of the A/
mechanism
1[0-15] Header Checksum. The checksum is the 2's-complement
the 2's-complement sum of words 0-6 (excluding
checksum word itself).
2[0-15] Piggybacked A/R. This field may contain
acceptance/refusal word providing A/R status on
flowing in the opposite direction. Its inclusion
eliminate the need for a separate A/R control
(see Section 5). A value of zero for this word is
to indicate that no piggybacked A/R information
present
3[0] Data Message Type. This bit identifies whether
message is a datagram message or a stream message
0 = Datagram
1 = Stream
3[1] IL flag. Obsolete. Must be zero. (See Appendix B.)
Edmond [Page 8]
RFC 1221 HAP2 April 1991
3[2] Discard Flag. This flag allows a source host
instruct the network (including the destination host
what to do with the message when data errors
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,
passed on to the destination host
3[3] Data Error Flag. This flag is used in conjunction
the Discard Flag to indicate to the destination
whether any data errors have been detected in
message prior to transmission over the destination'
WPS-to-Host access link. It is used only if
Flag = 1. It should be set to zero by the source host
0 = No Data Errors
1 = Data Errors
3[4-5] Priority. The source host uses this field to
the priority with which the message should be
within the network
0 = Low
1 = Medium
2 = High
3 = (Reserved.)
The priority of each message is passed to
destination host by the destination WPS
3[6-7] Time-to-Live Designator. The source host uses
field to specify the maximum time that a message
be allowed to exist within the network before
deleted. Elapsed time begins when the message has
received by the WPS from the source host (or is sent
a WPS agent) and is last checked when the message
queued for transmission out the I/O interface to
destination host. If a message is multicast, each
is treated separately
0 = 1
1 = 2
2 = 5
3 = 10
Edmond [Page 9]
RFC 1221 HAP2 April 1991
3[8-9] Reliability. The source host uses this field
specify the basic bit error rate requirement for
data portion of this message. The source WPS uses
field to determine the trunk circuit
parameters and forward error correction level
to provide that bit error rate
0 = Low
1 = Medium-Low
2 = Medium-High
3 = High
3[10-15] Reliability Length. The source host uses this field
specify a portion of the user data which should
transmitted at the highest reliability level (
bit error rate). Both the HAP message header words
the first 2*<Reliability Length> octets of user
will be transmitted at high reliability while
remainder of the user data will be transmitted
whatever reliability level is specified in field 3[8-
9]. The reliability length mechanism gives the
the ability to transmit private header
(e.g., IP and TCP headers) at a higher
level than the remainder of the data
4[0-15] Destination Host Address. This field contains
network logical address of the destination host
5[0-15] Source Host Address. This field contains the
logical address of the source host
6[0-15] Protocol ID. This field specifies the next
level protocol. Protocol identifiers are
administratively, except 0 which is reserved, and
not part of this specification. See reference [10].
7-N Data. This field contains up to 16,384 bits (2048
octets) of user data, and must be an even number
octets
4. Stream
Stream messages are the second message type provided by HAP,
described in Section 2. Streams provide guaranteed bandwidth
the source and destination(s), and provide the minimum delivery
and delay variance available in the network. Streams are
for volatile traffic, such as speech, and for support of high
cycle applications that require throughput guarantees
Edmond [Page 10]
RFC 1221 HAP2 April 1991
Streams must be created before stream messages can flow from host
host. The protocol to accomplish stream creation is described
Section 6.1. Once established, a stream is allocated
network resources, such as bandwidth. Within the bounds of
stream allocation, a host is permitted considerable flexibility
how it may use the stream. Although the time to live, reliability
and reliability length of each stream message is fixed at
setup time, the destination logical address can vary from
message to stream message
A host can, therefore, multiplex a variety of logical flows onto
single stream, as long as the stream was set up to reach all
destination hosts. The format of stream messages is described
Figure 2.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| 0 | MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 1|IL| D| E| PRI | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | PROTOCOL ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
7-N : DATA :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
STREAM
Figure 2
0[0] Message Class = 0 (Data Message).
0[1] Loopback indicator
0[2-3] Go-Priority
Edmond [Page 11]
RFC 1221 HAP2 April 1991
0[4-7] Reserved
0[8-15] Message Number. This field serves the same purpose
the message number field in the datagram message
Moreover, a single message number sequence is used
both datagram and stream messages (see Section 5).
1[0-15] Header Checksum. (See datagram checksum
description.)
2[0-15] Piggybacked A/R
3[0] Data Message Type = 1 (Stream).
3[1] IL flag. Obsolete. Must be zero
3[2] Discard Flag
3[3] Data Error Flag
3[4-5] Stream message priority. Note that all stream
have priority over any datagram message. Priority
not affect the order of stream message delivery
0 = Low
1 = Medium
2 = High
3 =
3[6-15] Stream ID. The WPS uses this field to identify
preallocated network resources (bandwidth allocations
queues, buffers, etc.) to use for delivery of
message. Streams and their identifying numbers (
IDs) are established by an explicit Create
request (see Section 6.1).
4[0-15] Destination Host Address
5[0-15] Source Host Address
6[0-15] Protocol ID
7-N Data. This field contains up to 16,384 bits (2048
octets) of user data, and must be an even number
octets
Edmond [Page 12]
RFC 1221 HAP2 April 1991
5. Flow Control
The WPS supports an acceptance/refusal (A/R) mechanism in
direction on the host access link. The A/R mechanism is enabled
the link by the host by setting a bit in the Restart Complete
message (see Section 8). Each datagram and stream message
an 8-bit message number used to identify the message for flow
purposes. When the A/R mechanism is enabled, the message number
incremented modulo 256 in successive messages, skipping over
number zero (zero indicates that A/R's are disabled for
message). Up to 127 messages may be outstanding (awaiting
or refusal) in each direction. If the receiver of a message
unable to accept the message, a refusal indication containing
message number of the refused message and the reason for the
is returned. The refusal indication may be piggybacked on
messages in the opposite direction over the link or may be sent in
separate control message in the absence of reverse data traffic
Acceptance indications are returned in a similar manner,
piggybacked on data messages or in a separate control message.
acceptance is returned by the receiver to indicate that
identified message was received from the host access link and was
refused. Acceptance indications returned by the WPS are not an end
to-end acknowledgement and do not imply any guarantee of delivery
the destination host(s), or even any assurance that the message
not be intentionally discarded by the network. They are
primarily to facilitate buffer management in the host
To reduce the number of A/R messages exchanged, a single A/
indication can be returned for multiple (lower numbered)
unacknowledged messages. Explicit acceptance of message number
implies implicit acceptance of outstanding messages with numbers N-1,
N-2, etc., according to the definition of acceptance outlined above
Analogous interpretation of the refusal message number allows
receiver of a group of messages to reject them as a group when
all are being refused for the same reason. As a further
measure, HAP permits aggregation of any mix of A/R indications into
single A/R control message. Such a message might be used,
example, to reject a group of messages where the refusal code on
is different
In some circumstances the overhead associated with processing A/
messages may prove unattractive. For these cases, it is possible
disable the A/R mechanism and operate the HAP interface in a
discard mode. The ability to effect this on a link basis has
been noted (see Sections 2 and 8). In addition, messages
sequence number zero are taken as messages for which the A/
mechanism is selectively disabled. To permit critical feedback,
Edmond [Page 13]
RFC 1221 HAP2 April 1991
when operating in discard mode, HAP defines an "Unnumbered Response
control message. Flow control information, and other
which cannot be sent as an A/R indication, is sent in an
Response control message. The format of this type of message
illustrated in Figure 5.
The format shown in Figure 3 is used both for A/R indications
are piggybacked on data messages (word 2), and for aggregated A/
information in A/R control messages. The format of A/R
messages is shown in Figure 4.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|AR| REFUSAL CODE | A/R MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
ACCEPTANCE/REFUSAL
Figure 3
[0] Acceptance/Refusal Type. This field identifies
A/R information is an acceptance or a refusal
0 =
1 =
[1-7] Refusal Code. When the Acceptance/Refusal Type = 1,
this field gives the Refusal Code
0 = Priority not being
1 = Source WPS
2 = Destination WPS
3 = Destination host
4 = Destination WPS
5 = Illegal destination host
6 = Destination host access not
7 = Illegal source host
8 = Message lost in access
9 = Invalid stream
10 = Illegal source host for stream
11 = Message length too
12 = Stream message too
13 = Illegal control message
14 = Illegal refusal code in A/
15 = Can't implement
Edmond [Page 14]
RFC 1221 HAP2 April 1991
16 = Destination host
17 = Delivery
18 = Odd byte length packet (not allowed
19 = Invalid stream time-to-live
20 = "Reliability length" exceeds message
[8-15] A/R Message Number. This field contains the number
the message to which this acceptance/refusal refers
It also applies to all outstanding messages
earlier numbers. Note that this field can never
zero since a message number of zero implies that
A/R mechanism is disabled
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| 0 | LENGTH | 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
2-N : A/R's :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
ACCEPTANCE/REFUSAL
Figure 4
0[0] Message Class = 1 (Control Message).
0[1] Loopback indicator
0[2-3] Go-Priority
0[4-7] Reserved
0[8-11] Message Length. This field contains the total
of this message in words (N+1).
0[12-15] Control Message Type = 1 (Acceptance/Refusal).
1[0-15] Header Checksum. The checksum is the 2's-complement
the 2's-complement sum of words 0-N (excluding
checksum word itself).
Edmond [Page 15]
RFC 1221 HAP2 April 1991
2[0-15] Acceptance/Refusal Word
3-N Additional Acceptance/Refusal Words (optional).
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| 0 | RES-CODE | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
UNNUMBERED
Figure 5
0[0] Message Class = 1 (Control Message).
0[1] Loopback indicator
0[2-3] Go-Priority
0[4-7] Reserved
0[8-11] Response Code
3 = Destination
5 = Illegal destination host
7 = Illegal source host
9 = Nonexistent stream
10 = Illegal stream
13 = Protocol
15 = Can't implement
0[12-15] Control Message Type = 5 (Unnumbered Response).
1[0-15] Header Checksum. The checksum is the 2's-complement
the 2's-complement sum of words 0-3 (excluding
checksum word itself).
2[0-15] Response Information. If Response Code is
Edmond [Page 16]
RFC 1221 HAP2 April 1991
3: Destination Host
5: Destination Host
7: Source Host
9: Stream ID (right justified
10: Stream ID (right justified
13: Word 0 of offending
15: Word 0 of Loopback Request
3[0-15] Response Information. If Response Code is
3,5,7, or 9:
10: Source Host
13: Word 3 of offending message, or 0 if no word 3
15: Word 2 of Loopback Request
6. The Service
Allocation of network resources, such as streams and groups,
accomplished via an exchange of datagram messages, called
messages, between the user host and the Service Agent (
address zero). Setup operations include reserving, allocating
modifying, freeing, and deallocating resources. The Service
causes the requested action to be carried out and serves as
intermediary between the user and the rest of the network. In
process of implementing the requested action, various network
bases are updated to reflect the current state of the
resource. The Service Agent also permits a host to inquire
resources it owns using Information Request and Information
messages
A setup interaction initiated by a host involves a 3-way
where: (1) the requesting host sends a Setup Request to the
Agent, (2) the Service Agent returns a Setup Reply to the
host, and (3) the requesting host returns a Setup Acknowledgment
the Service Agent. This procedure is used to ensure
transmission of Setup Requests and Replies. In order to allow
than one Setup Request message from a host to be outstanding,
Request is assigned a unique Request ID. The associated Reply
subsequent Acknowledgment are identified by the Request ID that
contain. The requesting host should receive a reply to a
request within 3 seconds. The actual delay will depend on the
of the request and the topology of the network. For simple networks
the delay will often be less than one second. The requesting
should respond to a Reply with a Setup Acknowledgment within
second
Setup exchanges initiated by the Service Agent involve a two-
exchange where: (1) the Service Agent sends a Notification
Edmond [Page 17]
RFC 1221 HAP2 April 1991
affected hosts, and (2) the hosts return a Setup Acknowledgment
the Service Agent. Notifications are used to inform a host
changes in the status of a network resource. In order to allow
than one Notification to be outstanding, each is assigned a
Notification ID. The Setup Acknowledgment returned by the
host to the Service Agent must contain the Notification ID. The
should respond within one second
An information query is initiated by a host and involves a two-
exchange where: (1) the host sends an Information Request message
the Service Agent, and (2) the Service Agent sends back
Information Reply. There is no acknowledgment mechanism, since
request does not change any resource allocation. Furthermore,
there is an error in the request, only one response will be sent
the WPS, and the WPS will make no effort to check for or
lost responses. It is the responsibility of the host to wait
certain amount of time and then determine that an
information request has been lost and to resend it. (The
necessary to answer such a request is usually much less than
second.) The WPS will return the message ID of the
request in the information reply message
The general format of all Service Agent messages is
<DATAGRAM MESSAGE HEADER
The Protocol ID field in the datagram message header must
HAP_PROTO_SETUP (1) (see Appendix C) for messages sent to the
Agent and will be HAP_PROTO_SETUP in messages received from
Service Agent. The Service Agent does not recognize or support
of other higher level protocols (e.g., IP), in setup messages,
will discard messages containing such headers
Illustrations of message formats below show only the Service
Header header and message body and do not include the
message header. As a reminder that the datagram header is
included, word offsets are prefixed with an "S".
The format of the Service Agent Header is illustrated in Figure 6.
The body of the message will depend on the particular message type
Stream Request and Reply messages are described in Section 6.1.
Group Request and Reply messages are described in Section 6.2.
format of Notifications is described in Section 6.3, and
Acknowledgments are described in Section 6.4. Information
and Reply messages are described in Section 6.5.
Edmond [Page 18]
RFC 1221 HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | MESSAGE TYPE | CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | MESSAGE ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
SERVICE AGENT
Figure 6
S0[0-7] Message Type. This field determines the type
message
0 = Setup
1 = Setup
2 = Setup
3 =
4 = Information
5 = Information
S0[8-15] Code. For Setup Requests, this field identifies
request type
1 = Create group (multicast)
2 = Delete group
3 = Join
4 = Leave
5 = Create
6 = Delete
7 = Change
8 = Create shared
9 = Delete all streams owned by this
10 = Add member to
11 = Remove member from
For Setup Replies, this field provides the Reply Code
Some of the Reply Codes can be returned to any
request and others are request specific
0 = Group or stream
1 = Group or stream
2 = Host added to
3 = Host deleted from
4 = Stream
Edmond [Page 19]
RFC 1221 HAP2 April 1991
5 = (Reserved
6 = Request type invalid or
7 = (Reserved
8 = Network
9 = Bad group
10 = Group address/stream ID
11 = Not member of group/not creator of
12 = Stream precedence not being
13 = (Reserved
14 = (Reserved
15 = (Reserved
16 = Unable to add all the new
17 = Insufficient network
18 = Requested bandwidth too
19 = (Reserved
20 = (Reserved
21 = Maximum messages per interval too
22 = Reply lost in
23 = Illegal priority or precedence
24 = Invalid address
For Notifications, this field contains the
Type. (See Section 6.3.)
For Setup Acknowledgments, this field contains
Acknowledgment Type. (See Section 6.4.)
For Information Requests, this field contains
request type. (See Section 6.5.)
For Information Replies, this field contains the
type. (See Section 6.5.)
S1[0-15] Checksum. The checksum is the 2's-complement of
2's-complement sum of the words in the Service
Header (excluding the checksum word itself) and
message body. Messages received with bad
must be discarded
S2[0-15] Message ID. This field is assigned by the host
uniquely identify outstanding requests (Request ID)
by the Service Agent to uniquely identify
notifications (Notification ID).
6.1. Stream Setup
Streams provide a means of reserving network resources for
delivery of traffic at a specified maximum throughput to a
Edmond [Page 20]
RFC 1221 HAP2 April 1991
list of recipients. Traffic sent via a stream has priority over
non-stream traffic, and is delivered with the minimum end-to-
delay possible. Hosts use streams to support applications that
predictable traffic loads (such as packet voice or video or
continuous media traffic) or that require minimum transmission
and lowest delay variance. Streams are typically used for
flows of moderate to long duration, where the cost of performing
stream Setup is acceptable
Streams must be set up before stream data messages can flow.
stream setup messages, each of which has a Request and a Reply,
Create Stream, Delete Stream, Change Stream, and Delete All Streams
(Create Shared Stream Request is a planned future addition to
protocol.) The use of these messages is illustrated in the
of exchanges between a host and the Service Agent shown in Figure 7
where the host establishes a stream, sends some data, modifies
stream characteristics, sends some more data, and finally closes
the stream. Not illustrated, but implicit in this scenario, are
optional A/R indications associated with each of the stream
messages
Service
Host Agent
Create Stream Request ---------->
Create Stream Reply <----------
Reply Acknowledgment ---------->
Stream Messages --------------------->
: :
Change Stream Request ---------->
Change Stream Reply <----------
Reply Acknowledgment ---------->
Stream Messages --------------------->
: :
Delete Stream Request ---------->
Delete Stream Reply <----------
Reply Acknowledgment ---------->
STREAM
Figure 7
Streams have eight characteristic properties which are selected
stream setup time. These properties are: (1) data words per
interval, (2) time interval, (3) reliability, (4) reliability length
(5) precedence, (6) maximum messages per interval, (7) the list
recipients, and (8) the set of other streams with which this
shares resources. To establish a stream, the host sends the
Edmond [Page 21]
RFC 1221 HAP2 April 1991
Stream Request message (Figure 8) to the Service Agent. After
network has processed the Create Stream Request, the Service
will reply with a Create Stream Reply message (Figure 9). If
reply code in the Create Stream Reply indicates that the stream
been created successfully, the host may proceed to transmit
data messages after sending a Reply Acknowledgment
During the lifetime of a stream, the host which created it may
that some of its characteristic properties should be modified.
but one of the properties can be modified using the Change
Request message (Figure 10). The one property that cannot be
is whether or not the stream is willing to share its resources
other streams. After the network has processed the Change
Request, the Service Agent will respond by sending a Change
Reply (Figure 11) to the host. A host requesting a reduced
allocation should decrease its sending rate immediately
waiting for receipt of the Change Stream Reply. A host requesting
increased allocation should not proceed to transmit according to
new set of parameters without first having received a Reply
indicating that the requested change has taken effect
When the host no longer needs the stream it created, it should
stop sending traffic via the stream and then send the Service Agent
Delete Stream Request message (Figure 12). After the network
processed the Delete Stream Request, the Service Agent will
by sending a Delete Stream Reply (Figure 13) to the host
If the host has crashed or restarted, it may no longer know
streams it owns. The host may use an Information Request (
Section 6.5) to determine what streams it owns, or the host may use
Delete All Streams Request (Figure 14) to discard whatever
resources it may own. The format for the Delete All Streams Reply
shown in Figure 15.
Note that streams, like all other resources allocated by the
Agent, may be reclaimed by the network if unused. Currently, if
traffic is sent to a stream in a 6 minute interval, and if the
of the steam is down or unreachable, the stream may be deleted
Edmond [Page 22]
RFC 1221 HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | MAX MES | PRE | INT | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | DATA WORDS PER INTERVAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | INTERVAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | 0 | ADDRESS LIST LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
S7-SN : DESTINATION ADDRESS LIST :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CREATE STREAM
Figure 8
S0[0-7] Setup Type = 1 (Request).
S0[8-15] Request Type = 5 (Create Stream).
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID
S3[0-3] Maximum Messages Per Interval (1-15). This
specifies the maximum number of stream messages
host will deliver to the WPS in any single
interval
S3[4-5] Precedence. This field specifies the precedence of
stream. When there are insufficient network
to support all the requested streams, requests
higher precedence streams will preempt existing
precedence streams, and requests for streams
insufficient precedence will be rejected.
precedence is recommended as the default choice
Edmond [Page 23]
RFC 1221 HAP2 April 1991
0 = Low
1 = Medium
2 = High
S3[6-7] Interval. This field specifies the interval,
multiples of 21.22 milliseconds. (For
compatibility only. New applications should use 3.
Use of this field to specify an interval is
phased out.)
0 = 21.22
1 = 42.44
2 = 84.88
3 = use interval in word S
S3[8-9] Reliability. This field specifies the basic bit-
rate requirement for the data portion of all
in the stream. The exact error rate obtained by
choice is not specified
0 = Low
1 = Medium-Low
2 = Medium-High
3 = High
S3[10-15] Reliability Length. This field specifies how
words beyond the stream message header should
transmitted at maximum reliability for all messages
the host stream
S4[0-15] Data words per interval. This field specifies
maximum number of 16-bit words of this stream's
the network will need to carry during each interval
not counting HAP stream message header words.
stream data may be carried in however many messages (
to MAX MES) in each interval the host chooses
S5[0-15] Interval (125 microsecond units). This field
the time interval over which the
interval> data in messages will be sent.
backward compatibility, an interval of 0 selects
interval of 169.76 milliseconds. This field is
unless the INT field is 3.
S6[0-7] Reserved. Must be zero
S6[8-15] Destination address list length. This field
the number of entries in the Destination Address
Edmond [Page 24]
RFC 1221 HAP2 April 1991
field. Allowed values are 1-8.
S7-SN Destination address list. This list must specify,
least indirectly, all the intended recipients of
stream's traffic. At least one destination
must be supplied. Any valid network address
specifically including group addresses, may be
(except the Service Agent's address, 0). Messages
in the stream are not limited to using the
addresses listed. E.g., if the list consists of
group address G, and host A is a member of G, a
message may be sent to A, which was not in the list
Caution: Group membership is only evaluated at setup time.
in group membership do not cause the stream to be modified
Caution: Stream creation involves allocation of specific
resources along specific routes for delivery of that traffic.
stream message sent to hosts other than those specified via
will probably be undeliverable. A stream message to a group
that has gained new members since the stream's last Setup may
undeliverable to the new members
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | 0 | STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | 0 | ADDRESS LIST LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
S5-SN : ADDRESS LIST :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CREATE STREAM
Figure 9
S0[0-7] Setup Type = 2 (Reply).
Edmond [Page 25]
RFC 1221 HAP2 April 1991
S0[8-15] Reply Code. Any reply other than "Stream created
means the stream was not created
0 = Stream
8 = Network
12 = Stream precedence not being
17 = Insufficient network
18 = Requested bandwidth too
21 = Max. messages per interval too
22 = Reply lost in
23 = Illegal precedence
24 = Invalid destination address in
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID
S3[0-5] Reserved. Must be zero
S3[6-15] Stream ID. This field contains a stream ID assigned
the network. It must be included in all stream
messages sent by the host to allow the WPS to
the message with stored stream characteristics and
resources reserved for that stream's traffic
S4[0-5] Reserved. Must be zero
S4[6-15] Address list length. The number of entries in
Address List field
S5-SN Address list. This contains the destination
from the Create Stream Request that were invalid
unreachable. Unreachable destinations are listed as
group if every member of the group was unreachable,
individually otherwise; i.e., group addresses
expanded and the unreachable members are included
the list. The list of unreachable destinations will
truncated, if needed, to limit this Reply to a single
maximum length HAP message
Edmond [Page 26]
RFC 1221 HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | 0 | STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | MAX MES | PRE | INT | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | DATA WORDS PER INTERVAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | INTERVAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S7 | 0 | ADDRESS LIST LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
S8-SN : DESTINATION ADDRESS LIST :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CHANGE STREAM
Figure 10
S0[0-7] Setup Type = 1 (Request).
S0[8-15] Request Type = 7 (Change Stream).
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID
S3[0-5] Reserved. Must be zero
S3[6-15] Stream ID
S4[0-3] New Maximum Messages Per Interval
S4[4-5] New Precedence
S4[6-7] New Interval selection
S4[8-9] New Reliability
Edmond [Page 27]
RFC 1221 HAP2 April 1991
S4[10-15] New Reliability Length
S5[0-15] New Data Words Per Interval
S6[0-15] New Interval (ignored unless INT = 3).
S7[0-7] Reserved. Must be zero
S7[8-15] Destination Address List length. This field
the number of entries in the new Destination
List. Allowed values are 0-8. Use zero (indicating
addresses in the list) to avoid changing the list
recipient hosts
S8-SN New Destination Address List. The new, complete,
of recipient hosts. Membership of group addresses
evaluated at setup execution time. Subsequent
in group membership do not cause the stream to
modified. Note that using the same destination
list in the Change Stream Request as was used in
Create Stream Request can result in a change in
list of recipient hosts if membership in a group
changed
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | 0 | ADDRESS LIST LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
S4-SN : ADDRESS LIST :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CHANGE STREAM
Figure 11
S0[0-7] Setup Type = 2 (Reply).
Edmond [Page 28]
RFC 1221 HAP2 April 1991
S0[8-15] Reply Code. The number in parentheses indicates
processing phase at the time of the error (see
below). Phase zero and phase one errors leave
stream unchanged; errors from later phases may
the stream partially modified
4 = Stream
8 = (1) Network
10 = (0) Stream ID
11 = (0) Not creator of
12 = (0) Stream precedence not being
16 = (3) Unable to add all the new
17 = (2) Insufficient network
18 = (2) Requested bandwidth too
21 = (0) Maximum messages per interval too
22 = (2) Reply lost in
23 = (0) Illegal precedence
24 = (0) Invalid destination address in
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID
S3[0-5] Reserved. Must be zero
S3[6-15] Address list length. This field specifies the
of addresses in the Address List
S4-SN Address list. This contains the destination
from the Change Stream Request that were invalid (
0 errors) or unreachable (phase 3 errors).
destinations are listed as a group if every member
the group was unreachable, or individually otherwise
i.e., group addresses are expanded and the
members are included in the list. The list
unreachable destinations will be truncated, if needed
to limit this Reply to a single, maximum length
message
Caution: The Change Stream Reply will indicate failure if
aspect of the requested changes did not occur. However,
stream may have been partially modified. Processing is
in the following phases
0: check for invalid requests
1: drop former recipients that are not in the latest list
2: increase or decrease the stream's bandwidth
(decreases are normally successful);
3: extend the stream to any new recipients
Edmond [Page 29]
RFC 1221 HAP2 April 1991
If phase 2 fails, phase 3 is not performed, the Reply Code
indicate an error and the stream parameters will be unchanged
If phase 3 fails, the Address List will contain the destinations
if any, from the latest list that the stream does not reach
Phase 1 only fails if the stream has been suspended (
Notifications) or the WPS is experiencing network
problems
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | 0 | STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DELETE STREAM
Figure 12
S0[0-7] Setup Type = 1 (Request).
S0[8-15] Request Type = 6 (Delete Stream).
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID
S3[0-5] Reserved. Must be zero
S3[6-15] Stream ID
Edmond [Page 30]
RFC 1221 HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DELETE STREAM
Figure 13
S0[0-7] Setup Type = 2 (Reply).
S0[8-15] Reply Code. If the request was valid, the
Agent will have marked the stream for deletion even
the stream resources have not actually been
yet
1 = Stream
10 = Stream ID
11 = Not creator of
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 9 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DELETE ALL STREAMS
Figure 14
S0[0-7] Setup Type = 1 (Request).
S0[8-15] Request Type = 9 (Delete All Streams).
Edmond [Page 31]
RFC 1221 