is the minimum MTU of the intervening networks to that target. If the
application has multiple targets then the minimum MTU of the stream
is the smallest MaxMsgSize received from all the ACCEPT messages. It
is the responsibility of the application to segment its PDUs
according to the minimum MaxMsgSize of the stream since no data
fragmentation is supported during the data transfer phase. If a
particular target's MaxMsgSize is unacceptable to an application, it
may disconnect the target from the stream and assume that the target
cannot be supported. When evaluating a particular target's
MaxMsgSize, the application or the application interface will need to
take into account the size of the ST data header.
8.7 IP Encapsulation of ST
ST packets may be encapsulated in IP to allow them to pass through
routers that don't support the ST Protocol. Of course, ST resource
management is precluded over such a path, and packet overhead is
increased by encapsulation, but if the performance is reasonably
predictable this may be better than not communicating at all.
IP-encapsulated ST packets begin with a normal IP header. Most fields
of the IP header should be filled in according to the same rules that
apply to any other IP packet. Three fields of special interest are:
o Protocol is 5, see [RFC1700], to indicate an ST packet is enclosed,
as opposed to TCP or UDP, for example.
o Destination Address is that of the next-hop ST agent. This may or
may not be the target of the ST stream. There may be an intermediate
ST agent to which the packet should be routed to take advantage of
service guarantees on the path past that agent. Such an intermediate
agent would not be on a directly-connected network (or else IP
encapsulation wouldn't be needed), so it would probably not be
listed in the normal routing table. Additional routing mechanisms,
not defined here, will be required to learn about such agents.
o Type-of-Service may be set to an appropriate value for the service
being requested, see [RFC1700]. This feature is not implemented
uniformly in the Internet, so its use can't be precisely defined
here.
IP encapsulation adds little difficulty for the ST agent that
receives the packet. However, when IP encapsulation is performed it
must be done in both directions. To process the encapsulated IP
message, the ST agents simply remove the IP header and proceed with
ST header as usual.
The more difficult part is during setup, when the ST agent must
decide whether or not to encapsulate. If the next-hop ST agent is on
a remote network and the route to that network is through a router
that supports IP but not ST, then encapsulation is required. The
routing function provides ST agents with the route and capability
information needed to support encapsulation.
On forwarding, the (mostly constant) IP Header must be inserted and
the IP checksum appropriately updated.
Applications are informed about the number of IP hops traversed on
the path to each target. The IPHops field of the CONNECT message, see
Section 10.4.4, carries the number of traversed IP hops to the target
application. The field is incremented by each ST agent when IP
encapsulation will be used to reach the next-hop ST agent. The number
of IP hops traversed is returned to the origin in the IPHops field of
the ACCEPT message, Section 10.4.1.
When using IP Encapsulation, the MaxMsgSize field will not reflect
the MTU of the IP encapsulated segments. This means that IP
fragmentation and reassembly may be needed in the IP cloud to support
a message of MaxMsgSize. IP fragmentation can only occur when the MTU
of the IP cloud, less IP header length, is the smallest MTU in a
stream's network path.
8.8 IP Multicasting
If an ST agent must use IP encapsulation to reach multiple next-hops
toward different targets, then either the packet must be replicated
for transmission to each next-hop, or IP multicasting may be used if
it is implemented in the next-hop ST agents and in the intervening IP
routers.
When the stream is established, the collection of next-hop ST agents
must be set up as an IP multicast group. The ST agent must allocate
an appropriate IP multicast address (see Section 10.3.3) and fill
that address in the IPMulticastAddress field of the CONNECT message.
The IP multicast address in the CONNECT message is used to inform the
next-hop ST agents that they should join the multicast group to
receive subsequent PDUs. Obviously, the CONNECT message itself must
be sent using unicast. The next-hop ST agents must be able to receive
on the specified multicast address in order to accept the connection.
If the next-hop ST agent can not receive on the specified multicast
address, it sends a REFUSE message with ReasonCode (BadMcastAddress).
Upon receiving the REFUSE, the upstream agent can choose to retry
with a different multicast address. Alternatively, it can choose to
lose the efficiency of multicast and use unicast delivery.
The following permanent IP multicast addresses have been assigned to
ST:
224.0.0.7 All ST routers (intermediate agents)
224.0.0.8 All ST hosts (agents)
In addition, a block of transient IP multicast addresses, 224.1.0.0 -
224.1.255.255, has been allocated for ST multicast groups. For
instance, the following two functions could be made available:
o AllocateMcastAddr() -> result, McastAddr
o ListenMcastAddr(McastAddr) -> result
o ReleaseMcastAddr(McastAddr) -> result
9. The ST2+ Flow Specification
This section defines the ST2+ flow specification. The flow
specification contains the user application requirements in terms of
quality of service. Its contents are LRM dependent and are
transparent to the ST2 setup protocol. ST2 carries the flow
specification as part of the FlowSpec parameter, which is described
in Section 10.3.1. The required ST2+ flow specification is included
in the protocol only to support interoperability. ST2+ also defines a
"null" flow specification to be used only to support testing.
ST2 is not dependent on a particular flow specification format and it
is expected that other versions of the flow specification will be
needed in the future. Different flow specification formats are
distinguished by the value of the Version field of the FlowSpec
parameter, see Section 10.3.1. A single stream is always associated
with a single flow specification format, i.e., the Version field is
consistent throughout the whole stream. The following Version field
values are defined:
0 - Null FlowSpec /* must be supported */
1 - ST Version 1
2 - ST Version 1.5
3 - RFC1190 FlowSpec
4 - HeiTS FlowSpec
5 - BerKom FlowSpec
6 - RFC1363 FlowSpec
7 - ST2+ FlowSpec /* must be supported */
FlowSpecs version #0 and #7 must be supported by ST2+
implementations. Version numbers in the range 1-6 indicate flow
specifications are currently used in existing ST2 implementations.
Values in the 128-255 range are reserved for private and experimental
use.
In general, a flow specification may support sophisticated flow
descriptions. For example, a flow specification could represent sub-
flows of a particular stream. This could then be used to by a
cooperating application and LRM to forward designated packets to
specific targets based on the different sub-flows. The reserved bits
in the ST2 Data PDU, see Section 10.1, may be used with such a flow
specification to designate packets associated with different sub-
flows. The ST2+ FlowSpec is not so sophisticated, and is intended for
use with applications that generate traffic at a single rate for
uniform delivery to all targets.
9.1 FlowSpec Version #0 - (Null FlowSpec)
The flow specification identified by a #0 value of the Version field
is called the Null FlowSpec. This flow specification causes no
resources to be allocated. It is ignored by the LRMs. Its contents
are never updated. Stream setup takes place in the usual way leading
to successful stream establishment, but no resources are actually
reserved.
The purpose of the Null FlowSpec is that of facilitating
interoperability tests by allowing streams to be built without
actually allocating the correspondent amount of resources. The Null
FlowSpec may also be used for testing and debugging purposes.
The Null FlowSpec comprises the 4-byte FlowSpec parameter only, see
Section 10.3.1. The third byte (Version field) must be set to 0.
9.2 FlowSpec Version #7 - ST2+ FlowSpec
The flow specification identified by a #7 value of the Version field
is the ST2+ FlowSpec, to be used by all ST2+ implementations. It
allows the user applications to express their real-time requirements
in the form of a QoS class, precedence, and three basic QoS
parameters:
o message size,
o message rate,
o end-to-end delay.
The QoS class indicates what kind of QoS guarantees are expected by
the application, e.g., strict guarantees or predictive, see Section
9.2.1. QoS parameters are expressed via a set of values:
o the "desired" values indicate the QoS desired by the application.
These values are assigned by the application and never modified by
the LRM.
o the "limit" values indicate the lowest QoS the application is
willing to accept. These values are also assigned by the application
and never modified by the LRM.
o the "actual" values indicate the QoS that the system is able to
provide. They are updated by the LRM at each node. The "actual"
values are always bounded by the "limit" and "desired" values.
9.2.1 QoS Classes
Two QoS classes are defined:
1 - QOS_PREDICTIVE /* QoSClass field value = 0x01, must be
supported*/
2 - QOS_GUARANTEED /* QoSClass field value = 0x10, optional */
o The QOS_PREDICTIVE class implies that the negotiated QoS may be
violated for short time intervals during the data transfer. An
application has to provide values that take into account the
"normal" case, e.g., the "desired" message rate is the allocated rate
for the transmission. Reservations are done for the "normal" case as
opposite to the peak case required by the QOS_GUARANTEED service
class. This QoS class must be supported by all implementations.
o The QOS_GUARANTEED class implies that the negotiated QoS for the
stream is never violated during the data transfer. An application
has to provide values that take into account the worst possible
case, e.g., the "desired" message rate is the peak rate for the
transmission. As a result, sufficient resources to handle the peak
rate are reserved. This strategy may lead to overbooking of
resources, but it provides strict real-time guarantees. Support of
this QoS class is optional.
If a LRM that doesn't support class QOS_GUARANTEED receives a
FlowSpec containing QOS_GUARANTEED class, it informs the local ST
agent. The ST agent may try different paths or delete the
correspondent portion of the stream as described in Section 5.5.3,
i.e., ReasonCode (FlowSpecError).
9.2.2 Precedence
Precedence is the importance of the connection being established.
Zero represents the lowest precedence. The lowest level is expected
to be used by default. 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.
9.2.3 Maximum Data Size
This parameter is expressed in bytes. It represents the maximum
amount of data, excluding ST and other headers, allowed to be sent in
a messages as part of the stream. The LRM first checks whether it is
possible to get the value desired by the application (DesMaxSize). If
not, it updates the actual value (ActMaxSize) with the available size
unless this value is inferior to the minimum allowed by the
application (LimitMaxSize), in which case it informs the local ST
agent that it is not possible to build the stream along this path.
9.2.4 Message Rate
This parameter is expressed in messages/second. It represents the
transmission rate for the stream. The LRM first checks whether it is
possible to get the value desired by the application (DesRate). If
not, it updates the actual value (ActRate) with the available rate
unless this value is inferior to the minimum allowed by the
application (LimitRate), in which case it informs the local ST agent
that it is not possible to build the stream along this path.
9.2.5 Delay and Delay Jitter
The delay parameter is expressed in milliseconds. It represents the
maximum end-to-end delay for the stream. The LRM first checks whether
it is possible to get the value desired by the application
(DesMaxDelay). If not, it updates the actual value (ActMaxDelay) with
the available delay unless this value is greater than the maximum
delay allowed by the application (LimitMaxDelay), in which case it
informs the local ST agent that it is not possible to build the
stream along this path.
The LRM also updates at each node the MinDelay field by incrementing
it by the minimum possible delay to the next-hop. Information on the
minimum possible delay allows to calculate the maximum end-to-end
delay range, i.e., the time interval in which a data packet can be
received. This interval should not exceed the DesMaxDelayRange value
indicated by the application. The maximum end-to-end delay range is
an upper bound of the delay jitter.
9.2.6 ST2+ FlowSpec Format
The ST2+ FlowSpec has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QosClass | Precedence | 0(unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ActRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesMaxSize | LimitMaxSize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ActMaxSize | DesMaxDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitMaxDelay | ActMaxDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesMaxDelayRange | ActMinDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The ST2+ FlowSpec.
The LRM modifies only "actual" fields, i.e., those beginning with
"Act". The user application assigns values to all other fields.
o QoSClass indicates which of the two defined classes of service
applies. The two classes are: QOS_PREDICTIVE (QoSClass = 1) and
QOS_GUARANTEED (QoSClass = 2).
o Precedence indicates the stream's precedence. Zero represents the
lowest precedence, and should be the default value.
o DesRate is the desired transmission rate for the stream in messages/
second. This field is set by the origin and is not modified by
intermediate agents.
o LimitRate is the minimum acceptable transmission rate in messages/
second. This field is set by the origin and is not modified by
intermediate agents.
o ActRate is the actual transmission rate allocated for the stream in
messages/second. Each agent updates this field with the available
rate unless this value is less than LimitRate, in which case a
REFUSE is generated.
o DesMaxSize is the desired maximum data size in bytes that will be
sent in a message in the stream. This field is set by the origin.
o LimitMaxSize is the minimum acceptable data size in bytes. This
field is set by the origin
o ActMaxSize is the actual maximum data size that may be sent in a
message in the stream. This field is updated by each agent based on
MTU and available resources. If available maximum size is less than
LimitMaxSize, the connection must be refused with ReasonCode
(CantGetResrc).
o DesMaxDelay is the desired maximum end-to-end delay for the stream
in milliseconds. This field is set by the origin.
o LimitMaxDelay is the upper-bound of acceptable end-to-end delay for
the stream in milliseconds. This field is set by the origin.
o ActMaxDelay is the maximum end-to-end delay that will be seen by
data in the stream. Each ST agent adds to this field the maximum
delay that will be introduced by the agent, including transmission
time to the next-hop ST agent. If the actual maximum exceeds
LimitMaxDelay, then the connection is refused with ReasonCode
(CantGetResrc).
o DesMaxDelayRange is the desired maximum delay range that may be
encountered end-to-end by stream data in milliseconds. This value is
set by the application at the origin.
o ActMinDelay is the actual minimum end-to-end delay that will be
encountered by stream data in milliseconds. Each ST agent adds to
this field the minimum delay that will be introduced by the agent,
including transmission time to the next-hop ST agent. Each agent
must add at least 1 millisecond. The delay range for the stream can
be calculated from the actual maximum and minimum delay fields. It
is expected that the range will be important to some applications.
10. ST2 Protocol Data Units Specification
10.1 Data PDU
IP and ST packets can be distinguished by the IP Version Number
field, i.e., the first four (4) bits of the packet; ST has been
assigned the value 5 (see [RFC1700]). There is no requirement for
compatibility between IP and ST packet headers beyond the first four
bits. (IP uses value 4.)
The ST PDUs sent between ST agents consist of an ST Header
encapsulating either a higher layer PDU or an ST Control Message.
Data packets are distinguished from control messages via the D-bit
(bit 8) in the ST header.
The ST Header also includes an ST Version Number, a total length
field, a header checksum, a unique id, and the stream origin 32-bit
IP address. The unique id and the stream origin 32-bit IP address
form the stream id (SID). This is shown in Figure 10. Please refer to
Section 10.6 for an explanation of the notation.
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=3 |D| Pri | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HeaderChecksum | UniqueID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OriginIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: ST Header
o ST is the IP Version Number assigned to identify ST packets. The
value for ST is 5.
o Ver is the ST Version Number. The value for the current ST2+ version
is 3.
o D (bit 8) is set to 1 in all ST data packets and to 0 in all SCMP
control messages.
o Pri (bits 9-11) is the packet-drop priority field with zero (0)
being lowest priority and seven the highest. The field is to be used
as described in Section 3.2.2.
o TotalBytes is the length, in bytes, of the entire ST packet, it
includes the ST Header but does not include any local network
headers or trailers. In general, all length fields in the ST
Protocol are in units of bytes.
o HeaderChecksum covers only the ST Header (12 bytes). The ST Protocol
uses 16-bit checksums here in the ST Header and in each Control
Message. For checksum computation, see Section 8.3.
o UniqueID is the first element of the stream ID (SID). It is locally
unique at the stream origin, see Section 8.1.
o OriginIPAddress is the second element of the SID. It is the 32-bit
IP address of the stream origin, see Section 8.1.
Bits 12-15 must be set to zero (0) when using the flow specifications
defined in this document, see Section 9. They may be set accordingly
when other flow specifications are used, e.g., as described in
[WoHD95].
10.1.1 ST Data Packets
ST packets whose D-bit is non-zero are 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.
10.2 Control PDUs
SCMP control messages are exchanged between neighbor ST agents using
a D-bit of zero (0). The control protocol follows a request-response
model with all requests expecting responses. Retransmission after
timeout (see Section 4.3) 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
is partitioned and a control message per partition is sent (see
Section 5.1.2). All control messages have the following format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: OpCodeSpecificData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ST Control Message Format
o OpCode identifies the type of control message.
o Options is used to convey OpCode-specific variations for a control
message.
o 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 (4).
o 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 (0) 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.
o 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 from the same ST agent. Examples are CONNECT and CHANGE
messages that are first acknowledged hop-by-hop and then lead to an
ACCEPT or REFUSE response from each target.
o 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).
o 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 to be error free before
it is acted upon.
o ReasonCode is set to zero (0 = NoError) in most SCMP messages.
Otherwise, it can be set to an appropriate value to indicate an
error situation as defined in Section 10.5.3.
o OpCodeSpecificData 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 (0) are included to allow the
format to match that of the corresponding request message. The
OpCodeSpecificData may also contain optional parameters. The
specifics of OpCodeSpecificData are defined in Section 10.3.
10.3 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 four
(4) bytes, the parameter is padded with one to three zero (0) bytes.
PBytes is thus always a multiple of four (4). Parameters can be
present in any order.
10.3.1 FlowSpec
The FlowSpec parameter (PCode = 1) is used in several SCMP messages
to convey the ST2 flow specification. The FlowSpec parameter has the
following format:
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 | Version | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec detail :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: FlowSpec Parameter
o the Version field contains the FlowSpec version.
o the FlowSpec detail field contains the flow specification and is
transparent to the ST agent. It is the data structure to be passed
to the LRM. It must be 4-byte aligned.
The Null FlowSpec, see Section 9.1, has no FlowSpec detail field.
PBytes is set to four (4), and Version is set to zero (0). The ST2+
FlowSpec, see Section 9.2, is a 32-byte data structure. PBytes is set
to 36, and Version is set to seven (7).
10.3.2 Group
The Group parameter (PCode = 2) is an optional argument used to
indicate that the stream is a member in the specified group.
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 = 2 | PBytes = 16 | GroupUniqueID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GroupCreationTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GroupInitiatorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relationship | N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Group Parameter
o GroupUniqueID, GroupInitiatorIPAddress, and GroupCreationTime
together form the GroupName field. They are allocated by the group
name generator function, see Section 8.2. GroupUniqueID and
GroupCreationTime are implementation specific and have only local
definitions.
o Relationship has the following format:
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (unused) |S|P|F|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Relationship Field
The B, F, P, S bits correspond to Bandwidth, Fate, Path, and Subnet
resources sharing, see Section 7. A value of 1 indicates that the
relationship exists for this group. All combinations of the four bits
are allowed. Bits 0-11 of the Relationship field are reserved for
future use and must be set to 0.
o N contains a legal value only if the B-bit is set. It is the value
of the N parameter to be used as explained in Section 7.1.1.
10.3.3 MulticastAddress
The MulticastAddress parameter (PCode = 3) is an optional parameter
that is used when using IP encapsulation and setting up an IP
multicast group. This parameter is used to communicate the desired IP
multicast address to next-hop ST agents that should become members of
the group, see Section 8.8.
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 | PBytes = 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPMulticastAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: MulticastAddress
o IPMulticastAddress is the 32-bit IP multicast address to be used to
receive data packets for the stream.
10.3.4 Origin
The Origin parameter (PCode = 4) is used to identify the next higher
protocol, and the SAP being used in conjunction with that 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 = 5 | PBytes | NextPcol |OriginSAPBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: OriginSAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Origin
o 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[RFC1700].
o OriginSAPBytes specifies the length of the OriginSAP, exclusive of
any padding required to maintain 32-bit alignment.
o OriginSAP identifies the origin's SAP associated with the NextPcol
protocol.
Note that the 32-bit IP address of the stream origin is not included
in this parameter because it is always available as part of the ST
header.
10.3.5 RecordRoute
The RecordRoute parameter (PCode = 5) is used to request that the
route between the origin and a target be recorded and delivered to
the user application. The ST agent at the origin (or target)
including this parameter, has to determine the parameter's length,
indicated by the PBytes field. ST agents processing messages
containing this parameter add their receiving IP address in the
position indicated by the FreeOffset field, space permitting. If no
space is available, the parameter is passed unchanged. When included
by the origin, all agents between the origin and the target add their
IP addresses and this information is made available to the
application at the target. When included by the target, all agents
between the target and the origin, inclusive, add their IP addresses
and this information is made available to the application at the
origin.
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 = 5 | PBytes | 0 | FreeOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: RecordRoute
o PBytes is the length of the parameter in bytes. Length is determined
by the agent (target or origin) that first introduces the parameter.
Once set, the length of the parameter remains unchanged.
o FreeOffset indicates the offset, relative to the start of the
parameter, for the next IP address to be recorded. When the
FreeOffset is greater than, or equal to, PBytes the RecordRoute
parameter is full.
o IP Address is filled in, space permitting, by each ST agent
processing this parameter.
10.3.6 Target and TargetList
Several control messages use a parameter called TargetList (PCode =
6), which contains information about the targets to which the message
pertains. For each Target in the TargetList, the information includes
the 32-bit IP address of the target, the SAP applicable to the next
higher layer protocol, and the length of the SAP (SAPBytes).
Consequently, a Target structure can be of variable length. Each
entry has the format shown in Figure 18.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetBytes | SAPBytes | SAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Target
o TargetIPAddress is the 32-bit IP Address of the Target.
o TargetBytes is the length of the Target structure, beginning with
the TargetIPAddress.
o SAPBytes is the length of the SAP, excluding any padding required to
maintain 32-bit alignment.
o SAP may be longer than 2 bytes and it includes a padding when
required. There would be no padding required for SAPs with lengths
of 2, 6, 10, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 6 | PBytes | TargetCount = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: TargetList
10.3.7 UserData
The UserData parameter (PCode = 7) is an optional parameter that may
be used by the next higher protocol or an application to convey
arbitrary information to its peers. This parameter is propagated in
some control messages and its contents have no significance to ST
agents. Note that since the size of control messages is limited by
the smallest MTU in the path to the targets, the maximum size of this
parameter cannot be specified a priori. If the size of this parameter
causes a message to exceed the network MTU, an ST agent behaves as
described in Section 5.1.2. The parameter must be padded to a
multiple of 32 bits.
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 = 7 | PBytes | UserBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserInfo : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: UserData
o UserBytes specifies the number of valid UserInfo bytes.
o UserInfo is arbitrary data meaningful to the next higher protocol
layer or application.
10.3.8 Handling of Undefined Parameters
An ST agent must be able to handle all parameters listed above. To
support possible future uses, parameters with unknown PCodes must
also be supported. If an agent receives a message containing a
parameter with an unknown Pcode value, the agent should handle the
parameter as if it was a UserData parameter. That is, the contents of
the parameter should be ignored, and the message should be
propagated, as appropriate, along with the related control message.
10.4 ST Control Message PDUs
ST Control messages are described in the following section. Please
refer to Section 10.6 for an explanation of the notation.
10.4.1 ACCEPT
ACCEPT (OpCode = 1) is issued by a target as a positive response to a
CONNECT message. It implies that the target is prepared to accept
data from the origin along the stream that was established by the
CONNECT. ACCEPT is also issued as a positive response to a CHANGE
message. It implies that the target accepts the proposed stream
modification.
ACCEPT is relayed by the ST agents from the target to the origin
along the path established by CONNECT (or CHANGE) but in the reverse
direction. ACCEPT must be acknowledged with ACK at each hop.
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 = 1 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxMsgSize | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StreamCreationTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPHops | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: ACCEPT Control Message
o Reference contains a number assigned by the ST agent sending ACCEPT
for use in the acknowledging ACK.
o LnkReference is the Reference number from the corresponding CONNECT
(or CHANGE)
o MaxMsgSize indicates the smallest MTU along the path traversed by
the stream. This field is only set when responding to a CONNECT
request.
o RecoveryTimeout reflects 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. This field
represents what can actually be supported by each participating
agent, and is only set when responding to a CONNECT request.
o StreamCreationTime is the 32- bits system dependent timestamp copied
from the corresponding CONNECT request.
o IPHops is the number of IP encapsulated hops traversed by the
stream. This field is set to zero by the origin, and is incremented
at each IP encapsulating agent.
10.4.2 ACK
ACK (OpCode = 2) is used to acknowledge a request. The ACK message is
not propagated beyond the previous-hop or 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 2 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: ACK Control Message
o Reference is the Reference number of the control message being
acknowledged.
o ReasonCode is usually NoError, but other possibilities exist, e.g.,
DuplicateIgn.
10.4.3 CHANGE
CHANGE (OpCode = 3) is used to change the FlowSpec of an established
stream. The CHANGE message is processed similarly to CONNECT, except
that it travels along the path of an established stream. CHANGE must
be propagated until it reaches the related stream's targets. CHANGE
must be acknowledged with ACK at each hop.
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 = 3 |G|I| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: CHANGE Control Message
o G (bit 8) is used to request a global, stream-wide change; the
TargetList parameter should be omitted when the G bit is specified.
o I (bit 7) is used to indicate that the LRM is permitted to interrupt
and, if needed, break the stream in the process of trying to satisfy
the requested change.
o Reference contains a number assigned by the ST agent sending CHANGE
for use in the acknowledging ACK.
10.4.4 CONNECT
CONNECT (OpCode = 4) requests the setup of a new stream or an
addition to or recovery of an existing stream. Only the origin can
issue the initial set of CONNECTs to setup a stream, and the first
CONNECT to each next-hop is used to convey the SID.
The next-hop initially responds with an ACK, which implies that the
CONNECT was valid and is being processed. The next-hop will later
relay back either an ACCEPT or REFUSE from each target. An
intermediate ST agent that receives a CONNECT behaves as explained in
Section 4.5.
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 = 4 |J N|S| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxMsgSize | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StreamCreationTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPHops | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Origin :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Group :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MulticastAddress :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: CONNECT Control Message
o JN (bits 8 and 9) indicate the join authorization level for the
stream, see Section 4.4.2.
o S (bit 10) indicates the NoRecovery option (Section 4.4.1). When the
S-bit is set (1), the NoRecovery option is specified for the stream.
o Reference contains a number assigned by the ST agent sending CONNECT
for use in the acknowledging ACK.
o MaxMsgSize indicates the smallest MTU along the path traversed by
the stream. This field is initially set to the network MTU of the
agent issues the CONNECT.
o RecoveryTimeout is the nominal number of milliseconds that the
application is willing to wait for failed system component to be
detected and any corrective action to be taken.
o StreamCreationTime is the 32- bits system dependent timestamp
generated by the ST agent issuing the CONNECT.
o IPHops is the number of IP encapsulated hops traversed by the
stream. This field is set to zero by the origin, and is incremented
at each IP encapsulating agent.
10.4.5 DISCONNECT
DISCONNECT (OpCode = 5) is used by an origin to tear down an
established stream or part of a stream, or by an intermediate ST
agent that detects a failure between itself and its previous-hop, as
distinguished by the ReasonCode. The DISCONNECT message specifies the
list of targets that are to be disconnected. An ACK is required in
response to a DISCONNECT message. The DISCONNECT message is
propagated all the way to the specified targets. The targets are
expected to terminate their participation in the stream.
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 = 5 |G| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GeneratorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: DISCONNECT Control Message
o G (bit 8) is used to request a DISCONNECT of all the stream's
targets. TargetList should be omitted when the G-bit is set (1). If
TargetList is present, it is ignored.
o Reference contains a number assigned by the ST agent sending
DISCONNECT for use in the acknowledging ACK.
o ReasonCode reflects the event that initiated the message.
o GeneratorIPAddress is the 32-bit IP address of the host that first
generated the DISCONNECT message.
10.4.6 ERROR
ERROR (OpCode = 6) is sent in acknowledgment to a request in which an
error is detected. No action is taken on the erroneous request. No
ACK is expected. The ERROR message is not propagated beyond the
previous-hop or next-hop ST agent. An ERROR is never sent in response
to another ERROR. The receiver of an ERROR is encouraged to try again
without waiting for a retransmission timeout.
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 = 6 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PDUInError :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: ERROR Control Message
o Reference is the Reference number of the erroneous request.
o ReasonCode indicates the error that triggered the message.
o PDUInError is the PDU in error, beginning with the ST Header. This
parameter is optional. Its length is limited by network MTU, and may
be truncated when too long.
10.4.7 HELLO
HELLO (OpCode = 7) is used as part of the ST failure detection
mechanism, see Section 6.1.
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 = 7 |R| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference = 0 | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloTimer |