RFC 1190
Experimental Internet Stream Protocol: Version 2 (ST-II)
4. ST Protocol Data Unit Descriptions The ST PDUs sent between ST agents consist of an ST Header ncapsulating either a higher layer PDU or an ST Control Message. Since ST operates as an extension of IP, the packet arrives at the same network service access point that IP uses to receive IP datagrams, e.g., ST would use the same ethertype (0x800) as does IP. The two types of packets are distinguished by the IP Version Number field (the first four bits of the packet); IP currently uses a value of 4, while ST has been assigned the value 5 [18]. There is no requirement for compatibility between IP and ST packet headers beyond the first four bits. The ST Header also includes an ST Version Number, a total length field, a header checksum, and a HID, as shown in Figure 21. See Appendix 1 (page 147) for an explanation of the notation. ST is the IP Version Number assigned to identify ST packets. The value for ST is 5. Ver is the ST Version Number. This document defines ST Version 2. Pri is the priority of the packet. It is used in data packets to indicate those packets to drop if a stream is exceeding its allocation. Zero is the lowest priority and 7 the highest. T (bit 11) is used to indicate that a Timestamp is present following the ST Header but before any next higher layer protocol data. The Timestamp is not permitted on ST Control Messages (which may use the OriginTimestamp option). Bits 12 through 15 are spares and should be set to 0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ST=5 | Ver=2 | Pri |T| Bits | TotalBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HID | HeaderChecksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- Timestamp -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21. ST Header
TotalBytes is the length, in bytes, of the entire ST packet, it
includes the ST Header and optional Timestamp but does not include
any local network headers or trailers. In general, all length
fields in the ST Protocol are in units of bytes.
HID is the 16-bit hop-by-hop stream identifier. It is an
abbreviation for the Name of the stream and is used both to reduce
the packet header length and, by the receiver of the data packet,
to make the forwarding function more efficient. Control Messages
have a HID value of zero. HIDs are negotiated by the next-hop and
previous-hop agents to make the abbreviation unique. It is used
here in the ST Header and in various Control Messages. HID values
1-3 are reserved for future use.
HeaderChecksum covers only the ST Header and Timestamp, if
present. The ST Protocol uses 16-bit checksums here in the ST
Header and in each Control Message. The standard Internet
checksum algorithm is used: "The checksum field is the 16-bit
one's complement of the one's complement sum of all 16-bit words
in the header. For purposes of computing the checksum, the value
of the checksum field is zero." See [1] [12] [15] for suggestions
for efficient checksum algorithms.
Timestamp is an optional timestamp inserted into data packets by
the origin. It is only present when the T bit, described above,
is set (1). Its use is negotiated at connection setup time; see
Sections 4.2.3.5 (page 108) and 4.2.3.1 (page 100). The Timestamp
has the NTP format; see [13].
4.1. Data Packets
ST packets whose HID is not zero to three are user data packets.
Their interpretation is a matter for the higher layer protocols
and consequently is not specified here. The data packets are not
protected by an ST checksum and will be delivered to the higher
layer protocol even with errors.
ST agents will not pass data packets over a new hop whose setup is
not complete, i.e., a HID must have been negotiated and either an
ACCEPT or REFUSE has been received for all targets specified in
the CONNECT.
4.2. ST Control Message Protocol Descriptions
ST Control Messages are between a previous-hop agent and its
next-hop agent(s) using a HID of zero. The control protocol
follows a request-response model with all requests expecting
responses. Retransmission after timeout (see Section 3.7.6 (page
66)) is used to allow for lost or ignored messages. Control
messages do not extend across packet boundaries; if a control
message is too large for the MTU of a hop, its information
(usually a TargetList) is partitioned and a control message per
partition is sent. All control messages have the following
format:
OpCode identifies the type of control message. Each is
described in detail in following sections.
Options is used to convey OpCode-specific variations for a
control message.
TotalBytes is the length of the control message, in bytes,
including all OpCode specific fields and optional parameters.
The value is always divisible by four.
RVLId is used to convey the Virtual Link Identifier of the
receiver of the control message, when known, or zero in the
case of an initial CONNECT or diagnostic message. The RVLId is
intended to permit efficient dispatch to the portion of a
stream's state machine containing information about a specific
operation in progress over the link. RVLId values 1-3 are
reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Options | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
: OpCode Specific Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22. ST Control Message Format
SVLId is used to convey the Virtual Link Identifier of the
sender of the control message. Except for ERROR-IN-REQUEST and
diagnostic messages, it must never be zero. SVLId values 1-3
are reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49).
Reference is a transaction number. Each sender of a request
control message assigns a Reference number to the message that
is unique with respect to the stream. The Reference number is
used by the receiver to detect and discard duplicates. Each
acknowledgment carries the Reference number of the request
being acknowledged. Reference zero is never used, and
Reference numbers are assumed to be monotonically increasing
with wraparound so that the older-than and more-recent-than
relations are well defined.
LnkReference contains the Reference field of the request
control message that caused this request control message to be
created. It is used in situations where a single request leads
to multiple "responses". Examples are CONNECT and CHANGE
messages that must be acknowledged hop-by-hop and will also
lead to an ACCEPT or REFUSE from each target in the TargetList.
SenderIPAddress is the 32-bit IP address of the network
interface that the ST agent used to send the control message.
This value changes each time the packet is forwarded by an ST
agent (hop-by-hop).
Checksum is the checksum of the control message. Because the
control messages are sent in packets that may be delivered with
bits in error, each control message must be checked before it
is acted upon; see Section 4 (page 76).
OpCode Specific Data contains any additional information that
is associated with the control message. It depends on the
specific control message and is explained further below. In
some response control messages, fields of zero are included to
allow the format to match that of the corresponding request
message. The OpCode Specific Data may also contain any of the
optional Parameters defined in Section 4.2.2 (page 80).
4.2.1. ST Control Messages
The CONNECT and CHANGE messages are used to establish or modify
branches in the stream. They propagate in the direction from
the origin toward the targets. They are end-to-end messages
created by the origin. They propagate all the way to the
targets, and require ERROR-IN-REQUEST, ACK, HID-REJECT, HID-
APPROVE, ACCEPT, or REFUSE messages in response. The CONNECT
message is the stream setup message. The CHANGE message is
used to change the characteristics of an established stream.
The CONNECT message is also used to add one or more targets to
an existing stream and during recovery of a broken stream.
Both messages have a TargetList parameter and are processed
similarly.
The DISCONNECT message is used to tear down streams or parts of
streams. It propagates in the direction from the origin toward
the targets. It is either used as an end-to-end message
generated by the origin that is used to completely tear down a
stream, or is generated by an intermediate ST agent that
preempts a stream or detects the failure of its previous-hop
agent or network in the stream. In the latter case, it is used
to tear down the part of the stream from the failure to the
targets, thus the message propagates all the way to the
targets.
The REFUSE message is sent by a target to refuse to join or
remove itself from a stream; in these cases, it is an end-to-
end message. An intermediate ST agent issues a REFUSE if it
cannot find a route to a target, can only find a route to a
target through the previous-hop, preempts a stream, or detects
a failure in a next-hop ST agent or network. In all cases a
REFUSE propagates in the direction toward the origin.
The ACCEPT message is an end-to-end message generated by a
target and is used to signify the successful completion of the
setup of a stream or part of a stream, or the change of the
FlowSpec. There are no other messages that are similar to it.
The following sections contain descriptions of common fields
and parameters, followed by descriptions of the individual
control messages, both listed in alphabetical order. A brief
description of the use of the control message is given. The
packet format is shown graphically.
4.2.2. Common SCMP Elements
Several fields and parameters (referred to generically as
"elements") are common to two or more PDUs. They are described
in detail here instead of repeating their description several
times. In many cases, the presence of a parameter is optional.
To permit the parameters to be easily defined and parsed, each
is identified with a PCode byte that is followed by a PBytes
byte indicating the length of the parameter in bytes (including
the PCode, PByte, and any padding bytes). If the length of the
information is not a multiple of 4 bytes, the parameter is
padded with one to three zero (0) bytes. PBytes is thus always
a multiple of four. Parameters can be present in any order.
4.2.2.1. DetectorIPAddress
Several control messages contain the DetectorIPAddress
field. It is used to identify the agent that caused the
first instance of the message to be generated, i.e., before
it was propagated. It is copied from the received message
into the copy of the message that is to be propagated to a
previous-hop or next-hop. It use is primarily diagnostic.
4.2.2.2. ErroredPDU
The ErroredPDU parameter (PCode = 1) is used for diagnostic
purposes to encapsulate a received ST PDU that contained an
error. It may be included in the ERROR-IN-REQUEST, ERROR-
IN-RESPONSE, or REFUSE messages. It use is primarily
diagnostic.
PDUBytes indicates how many bytes of the PDUInError are
actually present.
ErrorOffset contains the number of bytes into the errored
PDU to the field containing the error. At least as much
of the PDU in error must be included to
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 1 | PBytes | PDUBytes | ErrorOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PDUInError : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23. ErroredPDU
include the field or parameter identified by ErrorOffset;
an ErrorOffset of zero would imply a problem with the IP
Version Number or ST Version Number fields.
PDUInError is the PDU in error, beginning with the ST
Header.
4.2.2.3. FlowSpec & RFlowSpec
The FlowSpec is used to convey stream service requirements
end-to-end. We expect that other versions of FlowSpec will
be needed in the future, which may or may not be subsets or
supersets of the version described here. PBytes will allow
new constraints to be added to the end without having to
simultaneously update all implementations in the field.
Implementations are expected to be able to process in a
graceful manner a Version 4 (or higher) structure that has
more elements than shown here.
The FlowSpec parameter (PCode = 2) is used in several
messages to convey the FlowSpec.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | PBytes | Version = 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DutyFactor | ErrorRate | Precedence | Reliability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tradeoffs | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitOnCost | LimitOnDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitOnPDUBytes | LimitOnPDURate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinBytesXRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AccdMeanDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AccdDelayVariance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesPDUBytes | DesPDURate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24. FlowSpec & RFlowSpec
The RFlowSpec parameter (PCode = 12) is used in conjunction
with the FDx option to convey the FlowSpec that is to be
used in the reverse direction.
Version identifies the version of the FlowSpec. Version
3 is defined here.
DutyFactor is the estimated proportion of the time that
the requested bandwidth will actually be in use. Zero is
taken to represent 256 and signify a duty factor of 1.
Other values are to be divided by 256 to yield the duty
factor.
ErrorRate expresses the error rate as the negative
exponent of 10 in the error rate. One (1) represents a
bit error rate of 0.1 and 10 represents 0.0000000001.
Precedence is the precedence of the connection being
established. Zero represents the lowest precedence.
Note that non-zero values of this parameter should be
subject to authentication and authorization checks, which
are not specified here. In general, the distinction
between precedence and priority is that precedence
specifies streams that are permitted to take previously
committed resources from another stream, while priority
identifies those PDUs that a stream is most willing to
have dropped when the stream exceeds its guaranteed
limits.
Reliability is modified by each intervening ST agent as a
measure of the probability that a given offered data
packet will be forwarded and not dropped. Zero is taken
to represent 256 and signify a probability of 1. Other
values are to be divided by 256 to yield the probability.
Tradeoffs is incompletely defined at this time. Bits
currently specified are as follows:
The most significant bit in the field, bit 0 in the
Figure 24, when one (1) means that each ST agent must
"implement" all constraints in the FlowSpec even if
they are not shown in the figure, e.g., when the
FlowSpec has been extended. When zero (0), unknown
constraints may be ignored.
The second most significant bit in the field, bit 1,
when one (1) means that one or more constraints are
unknown and have been ignored. When zero (0), all
constraints are known and have been processed.
The third most significant bit in the field, bit 2, is
used for RevChrg; see Section 3.6.5 (page 46).
Other bits are currently unspecified, and should be
set to zero (0) by the origin ST agent and not changed
by other agents unless those agents know their
meaning.
RecoveryTimeout specifies the nominal number of
milliseconds that the application is willing to wait for
a failed system component to be detected and any
corrective action to be taken.
LimitOnCost specifies the maximum cost that the origin is
willing to expend. A value of zero indicates that the
application is not willing to incur any direct charges
for the resources used by the stream. The meaning of
non-zero values is left for further study.
LimitOnDelay specifies the maximum end-to-end delay, in
milliseconds, that can be tolerated by the origin.
LimitOnPDUBytes is the smallest packet size, in terms of
ST-user data bytes, that can be tolerated by the origin.
LimitOnPDURate is the lowest packet rate that can be
tolerated by the origin, expressed as tenths of a packet
per second.
MinBytesXRate is the minimum bandwidth that can be
tolerated by the origin, expressed as a product of bytes
and tenths of a packet per second.
AccdMeanDelay is modified by each intervening ST agent.
This provides a means of reporting the total expected
delay, in milliseconds, for a data packet. Note that it
is implicitly assumed that the requested mean delay is
zero and there is no limit on the mean delay, so there
are no parameters to specify these explicitly.
AccdDelayVariance is also modified by each intervening ST
agent as a measure, in milliseconds squared, of the
packet dispersion. This quantity can be used by the
target or origin in determining whether the resulting
stream has an adequate quality of service to support the
application. Note that it is implicitly assumed that the
requested delay variance is zero and there is no limit on
the delay variance, so there are no parameters to specify
these explicitly.
DesPDUBytes is the desired PDU size in bytes. This is
not necessarily the same as the minimum necessary PDU
size. This value may be made smaller by intervening ST
agents so long as it is not made smaller than
LimitOnPDUBytes. The *PDUBytes limits measure the size
of the PDUs of next-higher protocol layer, i.e., the user
information contained in a data packet. An ST agent must
account for both the ST Header (including possible IP
encapsulation) and any local network headers and trailers
when comparing a network's MTU with *PDUBytes. In an
ACCEPT message, the value of this field will be no larger
than the MTU of the path to the specified target.
DesPDURate is the requested PDU rate, expressed as tenths
of a packet per second. This value may be made smaller
by intervening ST agents so long as it is not made
smaller than LimitOnPDURate.
It is expected that the next parameter to be added to the
FlowSpec will be a Burst Descriptor. This parameter will
describe the burstiness of the offered traffic. For
example, this may include the simple average rate, peak
rate and variance values, or more complete descriptions
that characterize the distribution of expected burst
rates and their expected duration. The nature of the
algorithms that deal with the traffic's burstiness and
the information that needs to be described by this
parameter will be subjects of further experimentation.
It is expected that a new FlowSpec with Version = 4 will
be defined that looks like Version 3 but has a Burst
Descriptor parameter appended to the end.
4.2.2.4. FreeHIDs
The FreeHIDs parameter (PCode = 3) is used to communicate to
the previous-hop suggestions for a HID. It consists of
BaseHID and FreeHIDBitMask fields. Experiments will
determine how long the mask should be for practical use of
this parameter. The parameter (if implemented) should be
included in all HID-REJECTs, and in HID-APPROVEs that are
linked to a multicast CONNECT, e.g., one containing the
MulticastAddress parameter.
BaseHID was the suggested value in a HID-CHANGE or
CONNECT. BaseHID is chosen to be the suggested HID value
to insure that the masks from multiple FreeHIDs
parameters will overlap.
FreeHIDBitMask identifies available HID values as
follows. Bit 0 in the FreeHIDBitMask corresponds to a
HID with a value equal to BaseHID with the 5 least
significant bits set to zero, bit 1 corresponds to that
value + 1, etc. This alignment of the mask on a 32-bit
boundary is used so that masks from several FreeHIDs
parameters might more easily be combined using a bit-wise
AND function to find a free HID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 3 | 4+4*N | BaseHID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FreeHIDBitMask :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25. FreeHIDs
4.2.2.5. Group & RGroup
The Group parameter (PCode = 4) is an optional argument
used only for the creation of a stream. This parameter
contains a GroupName; the GroupName may be the same as the
Name of one of the group's streams. In addition, there
may be some number of <SubGroupId, Relation> tuples that
describe the meaning of the grouping and the relation
between the members of the group. The forms of grouping
are for further study.
The RGroup parameter (PCode = 13) is an optional argument
used only for the creation of a stream in the reverse
direction that is a member of a Group; see the FDx
option, Section 3.6.3 (page 45). This parameter has the
same format as the Group parameter.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 12+4*N | !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
! GroupName !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubGroupId | Relation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubGroupId | Relation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26. Group & RGroup
A GroupName has the same format as a Name; see Figure 29.
4.2.2.6. HID & RHID
The HID parameter (PCode = 5) is used in the NOTIFY message
when the notification is related to a HID, and possibly in
the STATUS-RESPONSE message to convey additional HIDs that
are valid for a stream when there are more than one. It
consists of the PCode and PBytes bytes prepended to a HID;
HIDs were described in Section 4 (page 76).
The RHID parameter (PCode = 14) is used in conjunction with
the FDx option to convey the HID that is to be used in the
reverse direction. It consists of the PCode and PBytes
bytes prepended to a HID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 4 | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27. HID & RHID
4.2.2.7. MulticastAddress
The MulticastAddress parameter (PCode = 6) is an optional
parameter that is used, when setting up a network level
multicast group, to communicate an IP and/or local network
multicast address to the next-hop agents that should become
members of the group.
LocalNetBytes is the length of the Local Net Multicast
Address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 6 | PBytes | LocalNetBytes | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Local Net Multicast Address : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28. MulticastAddress
IP Multicast Address is described in [6]. This field is
zero (0) if no IP multicast address is known or is
applicable. The block of addresses 224.1.0.0 -
224.1.255.255 has been allocated for use by ST.
Local Net Multicast Address is the multicast address to
be used on the local network. It corresponds to the IP
Multicast Address when the latter is non-zero.
4.2.2.8. Name & RName
Each stream is uniquely (i.e., globally) identified by a
Name. A Name is created by the origin host ST agent and is
composed of 1) a 16-bit number chosen to make the Name
unique within the agent, 2) the IP address of the origin ST
agent, and 3) a 32-bit timestamp. If the origin has
multiple IP addresses, then any that can be used to reach
target may be used in the Name. The intent is that the
<Unique ID, IP Address> tuple be unique for the lifetime of
the stream. It is suggested that to increase robustness a
Unique ID value not be reused for a period of time on the
order of 5 minutes.
The Timestamp is included both to make the Name unique over
long intervals (e.g., forever) for purposes of network
management and accounting/billing, and to protect against
failure of an ST agent that causes knowledge of active
Unique IDs to be lost. The assumption is that all ST agents
have access to some "clock". If this is not the case, the
agent should have access to some form of non-volatile memory
in which it can store some number that at least gets
incremented per restart.
The Name parameter (PCode = 7) is used in most control
messages to identify a stream.
The RName parameter (PCode = 15) is used in conjunction with
the FDx option to convey the Name of the reverse stream in
an ACCEPT message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 12 | Unique ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29. Name & RName
4.2.2.9. NextHopIPAddress
The NextHopIPAddress parameter (PCode = 8) is an optional
parameter of NOTIFY (RouteBack) or REFUSE (RouteInconsist or
RouteLoop) and contains the IP address of a suggested next-
hop ST agent.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 8 | 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30. NextHopIPAddress
4.2.2.10. Origin
The Origin parameter (PCode = 9) is used to identify the
origin of the stream, the next higher protocol, and the SAP
being used in conjunction with that protocol.
NextPcol is an 8-bit field used in demultiplexing
operations to identify the protocol to be used above ST.
The values of NextPcol are in the same number space as
the IP Header's Protocol field and are consequently
defined in the Assigned Numbers RFC [18].
OriginSAPBytes specifies the length of the OriginSAP,
exclusive of any padding required to maintain 32-bit
alignment.
OriginIPAddress is (one of) the IP address of the origin.
OriginSAP identifies the origin's SAP associated with the
NextPcol protocol.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 9 | PBytes | NextPcol |OriginSAPBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OriginIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: OriginSAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31. Origin
4.2.2.11. OriginTimestamp
The OriginTimestamp parameter (PCode = 10) is used to
indicate the time at which the control message was sent.
The units and format of the timestamp is that defined in the
NTP protocol specification [13]. Note that discontinuities
over leap seconds are expected.
Note that the time synchronization implied by the use of
such a parameter is the subject of systems management
functions not described in this memo, e.g., NTP.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 10 | 12 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Timestamp -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32. OriginTimestamp
4.2.2.12. ReasonCode
Several errors may occur during protocol processing. All ST
error codes are taken from a single number space. The
currently defined values and their meaning is presented in
the list below. Note that new error codes may be defined
from time to time. All implementations are expected to
handle new codes in a graceful manner. If an unknown
ReasonCode is encountered, it should be assumed to be fatal.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33. ReasonCode
Name Value Meaning
---------------- ----- ---------------------------------------
AcceptTimeout 2 An Accept has not been
acknowledged.
AccessDenied 3 Access denied.
AckUnexpected 4 An unexpected ACK was received.
ApplAbort 5 The application aborted the stream
abnormally.
ApplDisconnect 6 The application closed the stream
normally.
AuthentFailed 7 The authentication function
failed.
CantGetResrc 8 Unable to acquire (additional)
resources.
CantRelResrc 9 Unable to release excess
resources.
CksumBadCtl 10 A received control PDU has a bad
message checksum.
CksumBadST 11 A received PDU has a bad ST Header
checksum.
DropExcdDly 12 A received PDU was dropped because
it could not be processed within
the delay specification.
DropExcdMTU 13 A received PDU was dropped because
its size exceeds the MTU.
DropFailAgt 14 A received PDU was dropped because
of a failed ST agent.
DropFailHst 15 A received PDU was dropped because
of a host failure.
DropFailIfc 16 A received PDU was dropped because
of a broken interface.
DropFailNet 17 A received PDU was dropped because
of a network failure.
Name Value Meaning
---------------- ----- ---------------------------------------
DropLimits 18 A received PDU was dropped because
it exceeds the resource limits for
its stream.
DropNoResrc 19 A received PDU was dropped due to
no available resources (including
precedence).
DropNoRoute 20 A received PDU was dropped because
of no available route.
DropPriLow 21 A received PDU was dropped because
it has a priority too low to be
processed.
DuplicateIgn 22 A received control PDU is a
duplicate and is being
acknowledged.
DuplicateTarget 23 A received control PDU contains a
duplicate target, or an attempt to
add an existing target.
ErrorUnknown 1 An error not contained in this
list has been detected.
failure N/A An abbreviation used in the text
for any of the more specific
errors: DropFailAgt, DropFailHst,
DropFailIfc, DropFailNet,
IntfcFailure, NetworkFailure,
STAgentFailure, FailureRecovery.
FailureRecovery 24 A notification that recovery is
being attempted.
FlowVerBad 25 A received control PDU has a
FlowSpec Version Number that is
not supported.
GroupUnknown 26 A received control PDU contains an
unknown Group Name.
HIDNegFails 28 HID negotiation failed.
HIDUnknown 29 A received control PDU contains an
unknown HID.
Name Value Meaning
---------------- ----- ---------------------------------------
InconsistHID 30 An inconsistency has been detected
with a stream Name and
corresponding HID.
InconsistGroup 31 An inconsistency has been detected
with the streams forming a group.
IntfcFailure 32 A network interface failure has
been detected.
InvalidHID 33 A received ST PDU contains an
invalid HID.
InvalidSender 34 A received control PDU has an
invalid SenderIPAddress field.
InvalidTotByt 35 A received control PDU has an
invalid TotalBytes field.
LnkRefUnknown 36 A received control PDU contains an
unknown LnkReference.
NameUnknown 37 A received control PDU contains an
unknown stream Name.
NetworkFailure 38 A network failure has been
detected.
NoError 0 No error has occurred.
NoRouteToAgent 39 Cannot find a route to an ST
agent.
NoRouteToDest 40 Cannot find a route to the
destination.
NoRouteToHost 41 Cannot find a route to a host.
NoRouteToNet 42 Cannot find a route to a network.
OpCodeUnknown 43 A received control PDU has an
invalid OpCode field.
PCodeUnknown 44 A received control PDU has a
parameter with an invalid PCode.
ParmValueBad 45 A received control PDU contains an
invalid parameter value.
Name Value Meaning
---------------- ----- ---------------------------------------
PcolIdUnknown 46 A received control PDU contains an
unknown next-higher layer protocol
identifier.
ProtocolError 47 A protocol error was detected.
PTPError 48 Multiple targets were specified
for a stream created with the PTP
option.
RefUnknown 49 A received control PDU contains an
unknown Reference.
RestartLocal 50 The local ST agent has recently
restarted.
RemoteRestart 51 The remote ST agent has recently
restarted.
RetransTimeout 52 An acknowledgment to a control
message has not been received
after several retransmissions.
RouteBack 53 The routing function indicates
that the route to the next-hop is
through the same interface as the
previous-hop and is not the
previous-hop.
RouteInconsist 54 A routing inconsistency has been
detected, e.g., a route loop.
RouteLoop 55 A CONNECT was received that
specified an existing target.
SAPUnknown 56 A received control PDU contains an
unknown next-higher layer SAP
(port).
STAgentFailure 57 An ST agent failure has been
detected.
StreamExists 58 A stream with the given Name or
HID already exists.
StreamPreempted 59 The stream has been preempted by
one with a higher precedence.
Name Value Meaning
---------------- ----- ---------------------------------------
STVerBad 60 A received PDU is not ST Version
2.
TooManyHIDs 61 Attempt to add more HIDs to a
stream than the implementation
supports.
TruncatedCtl 62 A received control PDU is shorter
than expected.
TruncatedPDU 63 A received ST PDU is shorter than
the ST Header indicates.
UserDataSize 64 The UserData parameter is too
large to permit a control message
to fit into a network's MTU.
4.2.2.13. RecordRoute
The RecordRoute parameter (PCode = 11) may be used to
request that the route between the origin and a target be
recorded and returned to the agent specified in the
DetectorIPAddress field.
FreeOffset is the offset to the position where the next
next-hop IP address should be inserted. It is initialized
to four (4) and incremented by four each time an agent
inserts its IP address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 11 | PBytes | 0 | FreeOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34. RecordRoute
4.2.2.14. SrcRoute
The SrcRoute parameter is used, in the Target structure
shown in Figure 36, to specify the IP addresses of the ST
agents through which the stream to the target should pass.
There are two forms of the option, distinguished by the
PCode.
With loose source route (PCode = 18) each ST agent first
examines the first next-hop IP address in the option. If
the address is (one of) the address of the current ST agent,
that entry is removed, and the PBytes field reduced by four
(4). If the resulting PBytes field contains 4 (i.e., there
are no more next-hop IP addresses) the parameter is removed
from the Target. In either case, the Target's TargetBytes
field and the TargetList's PBytes field must be reduced
accordingly. The ST agent then routes toward the first
next-hop IP address in the option, if one exists, or toward
the target otherwise. Note that the target's IP address is
not included as the last entry in the list.
With a strict source route (PCode = 19) each ST agent first
examines the first next-hop IP address in the option. If
the address is not (one of) the address of the current ST
agent, a routing error has occurred and should be reported
with the appropriate reason code. Otherwise that entry is
removed, and the PBytes field reduced by four (4). If the
resulting PBytes field contains 4 (i.e., there are no more
next-hop IP addresses) the parameter is removed from the
Target. In either case, the Target's TargetBytes field and
the TargetList's PBytes field must be reduced accordingly.
The ST agent then routes toward the first next-hop IP
address in the option, if one exists, or toward the target
otherwise. Note that the target's IP address is not
included as the last entry in the list.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 4+4*N | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35. SrcRoute
Since it is possible that a single hop between ST agents is
actually composed of multiple IP hops using IP
encapsulation, it might be necessary to also specify an IP
source routing option. Two additional PCodes are used in
this case. See [15] for a description of IP routing
options.
An IP Loose Source Route (PCode = 16) indicates that PDUs
for the next-hop ST agent should be encapsulated in IP and
that the IP datagram should contain an IP Loose Source Route
constructed from the list of IP router addresses contained
in this option.
An IP Strict Source Route (PCode = 17) is similarly used
when the corresponding IP Strict Source Route option should
be constructed.
Consequently, the "routing parameter" may consist of a
sequence of one or more separate parameters with PCodes 16,
17, 18, or 19.
4.2.2.15. Target and TargetList
Several control messages use a parameter called TargetList
(PCode = 20), which contains information about the targets
to which the message pertains. For each Target in the
TargetList, the information includes the IP addresses of the
target, the SAP applicable to the next higher layer
protocol, the length of the SAP (SAPBytes), and zero or more
optional SrcRoute parameters; see Section 4.2.2.14 (page
95). Consequently, a Target structure can be of variable
length. Each entry has the format shown in Figure 36.
The optional SrcRoute parameter is only meaningful in a
CONNECT messages; if present in other messages, they are
ignored. Note that the presence of SrcRoute parameter(s)
reduces the number of Targets that can be contained in a
TargetList since the maximum size of a TargetList is 256
bytes. Consequently an implementation should be prepared to
accept multiple TargetLists in a single message.
TargetIPAddress is the IP Address of the Target.
TargetBytes is the length of the Target structure,
beginning with the TargetIPAddress and including any
SrcRoute Parameter(s).
SAPBytes is the length of the SAP, excluding any padding
required to maintain 32-bit alignment. I.e.,
there would be no padding required for SAPs with lengths
of 2, 6, etc., bytes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetBytes | SAPBytes | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+-+
: SAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SrcRoute Parameter(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36. Target
We assume that the ST agents must know the maximum packet
size of the networks to which they are connected (the MTU),
and those maximum sizes will restrict the number of targets
that can be specified in control messages. We feel that
this is not a serious drawback. High bandwidth networks
such as the Ethernet or the Terrestrial Wideband network
support packet sizes large enough to allow well over one
hundred targets to be specified, and we feel that
conferences with a larger number of participants will not
occur for quite some time. Furthermore, we expect that
future higher bandwidth networks will allow even larger
packet sizes. It may be desirable to send ST voice data
packets in individual B-ISDN ATM cells, which are small, but
network services on ATM will provide "adaptation layers" to
implement network-level fragmentation that may be used to
carry larger ST control messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 20 | PBytes | TargetCount = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Target 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Target N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37. TargetList
If a message must pass across a network whose maximum packet
size is too small, the message must be broken up into
multiple messages, each of which carries part of the
TargetList. The function of the message can still be
performed even if the message is so partitioned. The effect
in this partitioning is to compromise the performance, but
still allows proper operation. For example, if a CONNECT
message were partitioned, the first CONNECT would establish
the stream, and the rest of the CONNECTs would be processed
as additions to the first. The routing decisions might
suffer, however, since they would be made on partial
information. Nevertheless, the stream would be created.
4.2.2.16. UserData
The UserData parameter (PCode = 21) is an optional parameter
that may be used by the next higher protocol or an
application to convey arbitrary information to its peers.
Note that since the size of control messages is limited by
the smallest MTU in the path to the target(s), the maximum
size of this parameter cannot be specified a priori. If the
parameter is too large for some network's MTU, a
UserDataSize error will occur. The parameter must be padded
to a multiple of 32 bits.
UserBytes specifies the number of valid UserInformation
bytes.
UserInformation is arbitrary data meaningful to the next
higher protocol layer or application.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 21 | PBytes | UserBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserInformation : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38. UserData
4.2.3. ST Control Message PDUs
Each control message is described in a following section. See
Appendix 1 (page 147) for an explanation of the notation.
(next page on part 5)
