RFC 1819
Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: HELLO Control Message o R (bit 8) is used for the Restarted-bit. o HelloTimer represents the time in millisecond since the agent was restarted, modulo the precision of the field. It is used to detect duplicate or delayed HELLO messages.
10.4.8 JOIN JOIN (OpCode = 8) is used as part of the ST steam joining mechanism, see Section 4.6.3. 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 = 8 | 0 | TotalBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference | LnkReference = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | ReasonCode = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GeneratorIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 28: JOIN Control Message o Reference contains a number assigned by the ST agent sending JOIN for use in the acknowledging ACK. o GeneratorIPAddress is the 32-bit IP address of the host that generated the JOIN message. o TargetList is the information associated with the target to be added to the stream.
10.4.9 JOIN-REJECT JOIN-REJECT (OpCode = 9) is used as part of the ST steam joining mechanism, see Section 4.6.3. 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 = 9 | 0 | TotalBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference | LnkReference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | ReasonCode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GeneratorIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: JOIN-REJECT Control Message o Reference contains a number assigned by the ST agent sending the REFUSE for use in the acknowledging ACK. o LnkReference is the Reference number from the corresponding JOIN message. o ReasonCode reflects the reason why the JOIN request was rejected. o GeneratorIPAddress is the 32-bit IP address of the host that first generated the JOIN-REJECT message.
10.4.10 NOTIFY NOTIFY (OpCode = 10) is issued by an ST agent to inform other ST agents of events that may be significant. NOTIFY may be propagated beyond the previous-hop or next-hop ST agent depending on the ReasonCode, see Section 10.5.3; NOTIFY must be acknowledged with an ACK. 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 = 10 | 0 | TotalBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference | LnkReference = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | ReasonCode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DetectorIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxMsgSize | RecoveryTimeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpec : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 30: NOTIFY Control Message o Reference contains a number assigned by the ST agent sending the NOTIFY for use in the acknowledging ACK. o ReasonCode identifies the reason for the notification. o DetectorIPAddress is the 32-bit IP address of the ST agent that detects the event. o MaxMsgSize is set when the MTU of the listed targets has changed (e.g., due to recovery), or when the notification is generated after a successful JOIN. Otherwise it is set to zero (0).
o RecoveryTimeout is set when the notification is generated after a
successful JOIN. Otherwise it is set to zero (0).
o FlowSpec is present when the notification is generated after a
successful JOIN.
o TargetList is present when the notification is related to one or
more targets, or when MaxMsgSize is set
o UserData is present if the notification is generated after a
successful JOIN and the UserData parameter was set in the ACCEPT
message.
10.4.11 REFUSE
REFUSE (OpCode = 11) is issued by a target that either does not wish
to accept a CONNECT message or wishes to remove itself from an
established stream. It might also be issued by an intermediate ST
agent in response to a CONNECT or CHANGE either to terminate a
routing loop, or when a satisfactory next-hop to a target cannot be
found. It may also be a separate command when an existing stream has
been preempted by a higher precedence stream or an ST agent detects
the failure of a previous-hop, next-hop, or the network between them.
In all cases, the TargetList specifies the targets that are affected
by the condition. Each REFUSE must be acknowledged by an ACK.
The REFUSE is relayed back by the ST agents to the origin (or
intermediate ST agent that created the CONNECT or CHANGE) along the
path traced by the CONNECT. The ST agent receiving the REFUSE will
process it differently depending on the condition that caused it, as
specified in the ReasonCode field. No special effort is made to
combine multiple REFUSE messages since it is considered most unlikely
that separate REFUSEs will happen to both pass through an ST agent at
the same time and be easily combined, e.g., have identical
ReasonCodes and parameters.
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 = 11 |G|E|N| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ValidTargetIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: REFUSE Control Message
o G (bit 8) is used to indicate that all targets down stream from the
sender are refusing. It is expected that this will be set most
commonly due to network failures. The TargetList parameter is
ignored or not present when this bit is set, and must be included
when not set.
o E (bit 9) is set by an ST agent to indicate that the request failed
and that the pre-change stream attributes, including resources, and
the stream itself still exist.
o N (bit 10) is used to indicate that no further attempts to recover
the stream should be made. This bit must be set when stream recovery
should not be attempted, even in the case where the target
application has shut down normally (ApplDisconnect).
o Reference contains a number assigned by the ST agent sending the
REFUSE for use in the acknowledging ACK.
o LnkReference is either the Reference number from the corresponding
CONNECT or CHANGE, if it is the result of such a message, or zero
when the REFUSE was originated as a separate command.
o DetectorIPAddress is the 32-bit IP address of the host that first
generated the REFUSE message.
o ValidTargetIPAddress is the 32-bit IP address of a host that is
properly connected as part of the stream. This parameter is only
used when recovering from stream convergence, otherwise it is set to
zero (0).
10.4.12 STATUS
STATUS (OpCode = 12) is used to inquire about the existence of a
particular stream identified by the SID. Use of STATUS is intended
for collecting information from an neighbor ST agent, including
general and specific stream information, and round trip time
estimation. The use of this message type is described in Section 8.4.
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 = 12 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: STATUS Control Message
o Reference contains a number assigned by the ST agent sending STATUS
for use in the replying STATUS-RESPONSE.
o TargetList is an optional parameter that when present indicates that
only information related to the specific targets should be relayed
in the STATUS-RESPONSE.
10.4.13 STATUS-RESPONSE
STATUS-RESPONSE (OpCode = 13) is the reply to a STATUS message. If
the stream specified in the STATUS message is not known, the STATUS-
RESPONSE will contain the specified SID but no other parameters. It
will otherwise contain the current SID, FlowSpec, TargetList, and
possibly Groups of the stream. It the full target list can not fit in
a single message, only those targets that can be included in one
message will be included. As mentioned in Section 10.4.12, it is possible to request information on a specific target. 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 = 13 | 0 | TotalBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference | LnkReference = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | ReasonCode = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpec : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Groups : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 33: STATUS-RESPONSE Control Message o Reference contains a number assigned by the ST agent sending the STATUS. 10.5 Suggested Protocol Constants The ST Protocol uses several fields that must have specific values for the protocol to work, and also several values that an implementation must select. This section specifies the required values and suggests initial values for others. It is recommended that the latter be implemented as variables so that they may be easily changed when experience indicates better values. Eventually, they should be managed via the normal network management facilities. ST uses IP Version Number 5. When encapsulated in IP, ST uses IP Protocol Number 5.
10.5.1 SCMP Messages 1) ACCEPT 2) ACK 3) CHANGE 4) CONNECT 5) DISCONNECT 6) ERROR 7) HELLO 8) JOIN 9) JOIN-REJECT 10) NOTIFY 11) REFUSE 12) STATUS 13) STATUS-RESPONSE 10.5.2 SCMP Parameters 1) FlowSpec 2) Group 3) MulticastAddress 4) Origin 5) RecordRoute 6) TargetList 7) UserData 10.5.3 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. The ReasonCode is an 8-bit field. Following values are defined: 1 NoError No error has occurred. 2 ErrorUnknown An error not contained in this list has been detected. 3 AccessDenied Access denied. 4 AckUnexpected An unexpected ACK was received. 5 ApplAbort The application aborted the stream abnormally. 6 ApplDisconnect The application closed the stream normally. 7 ApplRefused Applications refused requested connection or change. 8 AuthentFailed The authentication function failed. 9 BadMcastAddress IP Multicast address is unacceptable in CONNECT 10 CantGetResrc Unable to acquire (additional) resources.
11 CantRelResrc Unable to release excess resources.
12 CantRecover Unable to recover failed stream.
13 CksumBadCtl Control PDU has a bad message checksum.
14 CksumBadST PDU has a bad ST Header checksum.
15 DuplicateIgn Control PDU is a duplicate and is being
acknowledged.
16 DuplicateTarget Control PDU contains a duplicate target, or an
attempt to add an existing target.
17 FlowSpecMismatch FlowSpec in request does not match
existing FlowSpec.
18 FlowSpecError An error occurred while processing the FlowSpec
19 FlowVerUnknown Control PDU has a FlowSpec Version Number that
is not supported.
20 GroupUnknown Control PDU contains an unknown Group Name.
21 InconsistGroup An inconsistency has been detected with the
streams forming a group.
22 IntfcFailure A network interface failure has been detected.
23 InvalidSender Control PDU has an invalid SenderIPAddress
field.
24 InvalidTotByt Control PDU has an invalid TotalBytes field.
25 JoinAuthFailure Join failed due to stream authorization level.
26 LnkRefUnknown Control PDU contains an unknown LnkReference.
27 NetworkFailure A network failure has been detected.
28 NoRouteToAgent Cannot find a route to an ST agent.
29 NoRouteToHost Cannot find a route to a host.
30 NoRouteToNet Cannot find a route to a network.
31 OpCodeUnknown Control PDU has an invalid OpCode field.
32 PCodeUnknown Control PDU has a parameter with an invalid
PCode.
33 ParmValueBad Control PDU contains an invalid parameter value.
34 PathConvergence Two branches of the stream join during the
CONNECT setup.
35 ProtocolUnknown Control PDU contains an unknown next-higher
layer protocol identifier.
36 RecordRouteSize RecordRoute parameter is too long to permit
message to fit a network's MTU.
37 RefUnknown Control PDU contains an unknown Reference.
38 ResponseTimeout Control message has been acknowledged but not
answered by an appropriate control message.
39 RestartLocal The local ST agent has recently restarted.
40 RestartRemote The remote ST agent has recently restarted.
41 RetransTimeout An acknowledgment has not been received after
several retransmissions.
42 RouteBack Route to next-hop through same interface as
previous-hop and is not previous-hop.
43 RouteInconsist A routing inconsistency has been detected.
44 RouteLoop A routing loop has been detected.
45 SAPUnknown Control PDU contains an unknown next-higher
layer SAP (port).
46 SIDUnknown Control PDU contains an unknown SID.
47 STAgentFailure An ST agent failure has been detected.
48 STVer3Bad A received PDU is not ST Version 3.
49 StreamExists A stream with the given SID already exists.
50 StreamPreempted The stream has been preempted by one with a
higher precedence.
51 TargetExists A CONNECT was received that specified an
existing target.
52 TargetUnknown A target is not a member of the specified
stream.
53 TargetMissing A target parameter was expected and is not
included, or is empty.
54 TruncatedCtl Control PDU is shorter than expected.
55 TruncatedPDU A received ST PDU is shorter than the ST Header
indicates.
56 UserDataSize UserData parameter too large to permit a
message to fit into a network's MTU.
10.5.4 Timeouts and Other Constants
SCMP uses retransmission to effect reliability and thus has several
"retransmission timers". Each "timer" is modeled by an initial time
interval (ToXxx), which may get updated dynamically through
measurement of control traffic, and a number of times (NXxx) to
retransmit a message before declaring a failure. All time intervals
are in units of milliseconds. Note that the variables are described
for reference purposes only, different implementations may not
include the identical variables.
Value Timeout Name Meaning
------------------------------------------------------------------------
500 ToAccept Initial hop-by-hop timeout for acknowledgment of
ACCEPT
3 NAccept ACCEPT retries before failure
500 ToChange Initial hop-by-hop timeout for acknowledgment of
CHANGE
3 NChange CHANGE retries before failure
5000 ToChangeResp End-to-End CHANGE timeout for receipt of ACCEPT
or REFUSE
500 ToConnect Initial hop-by-hop timeout for acknowledgment of
CONNECT
5 NConnect CONNECT retries before failure
5000 ToConnectResp End-to-End CONNECT timeout for receipt of ACCEPT
or REFUSE from targets by origin
500 ToDisconnect Initial hop-by-hop timeout for acknowledgment of
DISCONNECT
3 NDisconnect DISCONNECT retries before failure
500 ToJoin Initial hop-by-hop timeout for acknowledgment of
JOIN
3 NJoin JOIN retries before failure
500 ToJoinReject Initial hop-by-hop timeout for acknowledgment of
JOIN-REJECT
3 NJoinReject JOIN-REJECT retries before failure
5000 ToJoinResp Timeout for receipt of CONNECT or JOIN-REJECT
from origin or intermediate hop
500 ToNotify Initial hop-by-hop timeout for acknowledgment of
NOTIFY
3 NNotify NOTIFY retries before failure
500 ToRefuse Initial hop-by-hop timeout for acknowledgment of
REFUSE
3 NRefuse REFUSE retries before failure
500 ToRetryRoute Timeout for receipt of ACCEPT or REFUSE from
targets during failure recovery
5 NRetryRoute CONNECT retries before failure
1000 ToStatusResp Timeout for receipt of STATUS-RESPONSE
3 NStatus STATUS retries before failure
10000 HelloTimerHoldDown Interval that Restarted bit must be set
after ST restart
5 HelloLossFactor Number of consecutively missed HELLO
messages before declaring link failure
2000 DefaultRecoveryTimeout Interval between successive HELLOs
to/from active neighbors
10.6 Data Notations
The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data with the most
significant octet on the left and the least significant octet on the
right.
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows a
group of octets, the order of transmission of those octets is the
normal order in which they are read in English. For example, in the
following diagram the octets are transmitted in the order they are
numbered.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: Transmission Order of Bytes
Whenever an octet represents a numeric quantity the left most bit in
the diagram is the high order or most significant bit. That is, the
bit labeled 0 is the most significant bit. For example, the following
diagram represents the value 170 (decimal).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Figure 35: Significance of Bits
Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit.
When a multi-octet quantity is transmitted the most significant octet
is transmitted first.
Fields whose length is fixed and fully illustrated are shown with a
vertical bar (|) at the end; fixed fields whose contents are
abbreviated are shown with an exclamation point (!); variable fields
are shown with colons (:). Optional parameters are separated from
control messages with a blank line. The order of parameters is not
meaningful.
11. References
[RFC1071] Braden, R., Borman, D., and C. Partridge,
"Computing the Internet Checksum", RFC 1071,
USC/Information Sciences Institute,
Cray Research, BBN Laboratories, September 1988.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting",
STD 5, RFC 1112, Stanford University, August 1989.
[WoHD95] L. Wolf, R. G. Herrtwich, L. Delgrossi: Filtering Multimedia Data in Reservation-based Networks, Kommunikation in Verteilten Systemen 1995 (KiVS), Chemnitz-Zwickau, Germany, February 1995. [RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989. [Jaco88] Jacobson, V.: Congestion Avoidance and Control, ACM SIGCOMM-88, August 1988. [KaPa87] Karn, P. and C. Partridge: Round Trip Time Estimation, ACM SIGCOMM-87, August 1987. [RFC1141] Mallory, T., and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, BBN, January 1990. [RFC1363] Partridge, C., "A Proposal Flow Specification", RFC 1363, BBN, September 1992. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DARPA, September 1981. [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [RFC1190] Topolcic C., "Internet Stream Protocol Version 2 (ST-II)", RFC 1190, CIP Working Group, October 1990. [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, USC/Information Sciences Institute, MIT, Xerox PARC, June 1994. [VoHN93] C. Vogt, R. G. Herrtwich, R. Nagarajan: HeiRAT: the Heidelberg Resource Administration Technique - Design Philosophy and Goals, Kommunikation In Verteilten Systemen, Munich, Informatik Aktuell, Springer-Verlag, Heidelberg, 1993. [Cohe81] D. Cohen: A Network Voice Protocol NVP-II, University of Southern California, Los Angeles, 1981. [Cole81] R. Cole: PVP - A Packet Video Protocol, University of Southern California, Los Angeles, 1981.
[DeAl92] L. Delgrossi (Ed.) The BERKOM-II Multimedia Transport System, Version 1, BERKOM Working Document, October, 1992. [DHHS92] L. Delgrossi, C. Halstrick, R. G. Herrtwich, H. Stuettgen: HeiTP: a Transport Protocol for ST-II, GLOBECOM'92, Orlando (Florida), December 1992. [Schu94] H. Schulzrinne: RTP: A Transport Protocol for Real-Time Applications. Work in Progress, 1994. 12. Security Considerations Security issues are not discussed in this memo. 13. Acknowledgments and Authors' Addresses Many individuals have contributed to the work described in this memo. We thank the participants in the ST Working Group for their input, review, and constructive comments. George Mason University C3I Center for hosting an interim meeting. Murali Rajagopal for his efforts on ST2+ state machines. Special thanks are due to Steve DeJarnett, who served as working group co-chair until summer 1993. We would also like to acknowledge the authors of [RFC1190]. All authors of [RFC1190] should be considered authors of this document since this document contains much of their text and ideas.
Louis Berger BBN Systems and Technologies 1300 North 17th Street, Suite 1200 Arlington, VA 22209 Phone: 703-284-4651 EMail: lberger@bbn.com Luca Delgrossi Andersen Consulting Technology Park 449, Route des Cretes 06902 Sophia Antipolis, France Phone: +33.92.94.80.92 EMail: luca@andersen.fr Dat Duong BBN Systems and Technologies 1300 North 17th Street, Suite 1200 Arlington, VA 22209 Phone: 703-284-4760 EMail: dat@bbn.com Steve Jackowski Syzygy Communications Incorporated 269 Mt. Hermon Road Scotts Valley, CA 95066 Phone: 408-439-6834 EMail: stevej@syzygycomm.com Sibylle Schaller IBM ENC Broadband Multimedia Communications Vangerowstr. 18 D69020 Heidelberg, Germany Phone: +49-6221-5944553 EMail: schaller@heidelbg.ibm.com