ParmValueBad 45 A received control PDU contains an
invalid parameter value.
Name Value Meaning
---------------- ----- ---------------------------------------
PcolIdUnknown 46 A received control PDU contains an
unknown next-higher layer protocol
identifier.
ProtocolError 47 A protocol error was detected.
PTPError 48 Multiple targets were specified
for a stream created with the PTP
option.
RefUnknown 49 A received control PDU contains an
unknown Reference.
RestartLocal 50 The local ST agent has recently
restarted.
RemoteRestart 51 The remote ST agent has recently
restarted.
RetransTimeout 52 An acknowledgment to a control
message has not been received
after several retransmissions.
RouteBack 53 The routing function indicates
that the route to the next-hop is
through the same interface as the
previous-hop and is not the
previous-hop.
RouteInconsist 54 A routing inconsistency has been
detected, e.g., a route loop.
RouteLoop 55 A CONNECT was received that
specified an existing target.
SAPUnknown 56 A received control PDU contains an
unknown next-higher layer SAP
(port).
STAgentFailure 57 An ST agent failure has been
detected.
StreamExists 58 A stream with the given Name or
HID already exists.
StreamPreempted 59 The stream has been preempted by
one with a higher precedence.
Name Value Meaning
---------------- ----- ---------------------------------------
STVerBad 60 A received PDU is not ST Version
2.
TooManyHIDs 61 Attempt to add more HIDs to a
stream than the implementation
supports.
TruncatedCtl 62 A received control PDU is shorter
than expected.
TruncatedPDU 63 A received ST PDU is shorter than
the ST Header indicates.
UserDataSize 64 The UserData parameter is too
large to permit a control message
to fit into a network's MTU.
4.2.2.13. RecordRoute
The RecordRoute parameter (PCode = 11) may be used to
request that the route between the origin and a target be
recorded and returned to the agent specified in the
DetectorIPAddress field.
FreeOffset is the offset to the position where the next
next-hop IP address should be inserted. It is initialized
to four (4) and incremented by four each time an agent
inserts its IP address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 11 | PBytes | 0 | FreeOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34. RecordRoute
4.2.2.14. SrcRoute
The SrcRoute parameter is used, in the Target structure
shown in Figure 36, to specify the IP addresses of the ST
agents through which the stream to the target should pass.
There are two forms of the option, distinguished by the
PCode.
With loose source route (PCode = 18) each ST agent first
examines the first next-hop IP address in the option. If
the address is (one of) the address of the current ST agent,
that entry is removed, and the PBytes field reduced by four
(4). If the resulting PBytes field contains 4 (i.e., there
are no more next-hop IP addresses) the parameter is removed
from the Target. In either case, the Target's TargetBytes
field and the TargetList's PBytes field must be reduced
accordingly. The ST agent then routes toward the first
next-hop IP address in the option, if one exists, or toward
the target otherwise. Note that the target's IP address is
not included as the last entry in the list.
With a strict source route (PCode = 19) each ST agent first
examines the first next-hop IP address in the option. If
the address is not (one of) the address of the current ST
agent, a routing error has occurred and should be reported
with the appropriate reason code. Otherwise that entry is
removed, and the PBytes field reduced by four (4). If the
resulting PBytes field contains 4 (i.e., there are no more
next-hop IP addresses) the parameter is removed from the
Target. In either case, the Target's TargetBytes field and
the TargetList's PBytes field must be reduced accordingly.
The ST agent then routes toward the first next-hop IP
address in the option, if one exists, or toward the target
otherwise. Note that the target's IP address is not
included as the last entry in the list.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 4+4*N | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35. SrcRoute
Since it is possible that a single hop between ST agents is
actually composed of multiple IP hops using IP
encapsulation, it might be necessary to also specify an IP
source routing option. Two additional PCodes are used in
this case. See [15] for a description of IP routing
options.
An IP Loose Source Route (PCode = 16) indicates that PDUs
for the next-hop ST agent should be encapsulated in IP and
that the IP datagram should contain an IP Loose Source Route
constructed from the list of IP router addresses contained
in this option.
An IP Strict Source Route (PCode = 17) is similarly used
when the corresponding IP Strict Source Route option should
be constructed.
Consequently, the "routing parameter" may consist of a
sequence of one or more separate parameters with PCodes 16,
17, 18, or 19.
4.2.2.15. Target and TargetList
Several control messages use a parameter called TargetList
(PCode = 20), which contains information about the targets
to which the message pertains. For each Target in the
TargetList, the information includes the IP addresses of the
target, the SAP applicable to the next higher layer
protocol, the length of the SAP (SAPBytes), and zero or more
optional SrcRoute parameters; see Section 4.2.2.14 (page
95). Consequently, a Target structure can be of variable
length. Each entry has the format shown in Figure 36.
The optional SrcRoute parameter is only meaningful in a
CONNECT messages; if present in other messages, they are
ignored. Note that the presence of SrcRoute parameter(s)
reduces the number of Targets that can be contained in a
TargetList since the maximum size of a TargetList is 256
bytes. Consequently an implementation should be prepared to
accept multiple TargetLists in a single message.
TargetIPAddress is the IP Address of the Target.
TargetBytes is the length of the Target structure,
beginning with the TargetIPAddress and including any
SrcRoute Parameter(s).
SAPBytes is the length of the SAP, excluding any padding
required to maintain 32-bit alignment. I.e.,
there would be no padding required for SAPs with lengths
of 2, 6, etc., bytes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetBytes | SAPBytes | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+-+
: SAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SrcRoute Parameter(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36. Target
We assume that the ST agents must know the maximum packet
size of the networks to which they are connected (the MTU),
and those maximum sizes will restrict the number of targets
that can be specified in control messages. We feel that
this is not a serious drawback. High bandwidth networks
such as the Ethernet or the Terrestrial Wideband network
support packet sizes large enough to allow well over one
hundred targets to be specified, and we feel that
conferences with a larger number of participants will not
occur for quite some time. Furthermore, we expect that
future higher bandwidth networks will allow even larger
packet sizes. It may be desirable to send ST voice data
packets in individual B-ISDN ATM cells, which are small, but
network services on ATM will provide "adaptation layers" to
implement network-level fragmentation that may be used to
carry larger ST control messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 20 | PBytes | TargetCount = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Target 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Target N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37. TargetList
If a message must pass across a network whose maximum packet
size is too small, the message must be broken up into
multiple messages, each of which carries part of the
TargetList. The function of the message can still be
performed even if the message is so partitioned. The effect
in this partitioning is to compromise the performance, but
still allows proper operation. For example, if a CONNECT
message were partitioned, the first CONNECT would establish
the stream, and the rest of the CONNECTs would be processed
as additions to the first. The routing decisions might
suffer, however, since they would be made on partial
information. Nevertheless, the stream would be created.
4.2.2.16. UserData
The UserData parameter (PCode = 21) is an optional parameter
that may be used by the next higher protocol or an
application to convey arbitrary information to its peers.
Note that since the size of control messages is limited by
the smallest MTU in the path to the target(s), the maximum
size of this parameter cannot be specified a priori. If the
parameter is too large for some network's MTU, a
UserDataSize error will occur. The parameter must be padded
to a multiple of 32 bits.
UserBytes specifies the number of valid UserInformation
bytes.
UserInformation is arbitrary data meaningful to the next
higher protocol layer or application.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 21 | PBytes | UserBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserInformation : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38. UserData
4.2.3. ST Control Message PDUs
Each control message is described in a following section. See
Appendix 1 (page 147) for an explanation of the notation.
4.2.3.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. The ACCEPT includes
the FlowSpec that contains the cumulative information that
was calculated by the intervening ST agents as the CONNECT
made its way from the origin to the target, as well as any
modifications made by the application at the target. The
ACCEPT is relayed by the ST agents from the target to the
origin along the path established by the CONNECT but in the
reverse direction. The ACCEPT must be acknowledged with an
ACK at each hop.
The FlowSpec is not modified on this trip from the target
back to the origin. Since the cumulative FlowSpec
information can be different for different targets, no
attempt is made to combine the ACCEPTs from the various
targets. The TargetList included in each ACCEPT contains
the IP address of only the target that issued the ACCEPT.
Any SrcRoute parameters in the TargetList are ignored.
Since an ACCEPT might be the first response from a next-hop
on a control link (due to network reordering), the SVLId
field may be the first source of the Virtual Link Identifier
to be used in the RVLId field of subsequent control messages
sent to that next-hop.
When the FDx option has been selected to setup a second
stream in the reverse direction, the ACCEPT will contain
both RFlowSpec and RName parameters. Each agent should
update the state tables for the reverse stream with this
information.
TSR (bits 14 and 15) specifies the target's response for
the use of data packet timestamps; see Section 4 (page
76). Its values and semantics are:
00 Not implemented.
01 No timestamps are permitted.
10 Timestamps must always be present.
11 Timestamps may optionally be present.
Reference contains a number assigned by the agent sending
the ACCEPT for use in the acknowledging ACK.
LnkReference is the Reference number from the
corresponding CONNECT or CHANGE.
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 |TSR| TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RFlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! RName Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39. ACCEPT Control Message
4.2.3.2. ACK
ACK (OpCode = 2) is used to acknowledge a request. The
Reference in the header is the Reference number of the
control message being acknowledged.
Since a ACK might be the first response from a next-hop on a
control link, the SVLId field may be the first source of the
Virtual Link Identifier to be used in the RVLId field of
subsequent control messages sent to that next-hop.
ReasonCode is usually NoError, but other possibilities
exist, e.g., DuplicateIgn.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40. ACK Control Message
4.2.3.3. CHANGE-REQUEST
CHANGE-REQUEST (OpCode = 4) is used by an intermediate or
target agent to request that the origin change the FlowSpec
of an established stream. The CHANGE-REQUEST message is
propagated hop-by-hop to the origin, with an ACK at each
hop.
Any SrcRoute parameters in the targets of the TargetList are
ignored.
G (bit 8) is used to request a global, stream-wide
change; the TargetList parameter may be omitted when the
G bit is specified.
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 |G| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41. CHANGE-REQUEST Control Message
4.2.3.4. CHANGE
CHANGE (OpCode = 3) is used to change the FlowSpec of an
established stream. Parameters are the same as for CONNECT
but the TargetList is not required. The CHANGE message is
processed similarly to the CONNECT message, except that it
travels along the path of an established stream.
If the change to the FlowSpec is in a direction that makes
fewer demands of the involved networks, then the change has
a high probability of success along the path of the
established stream. Each ST agent receiving the CHANGE
message makes the necessary requested changes to the network
resource allocations, and if successful, propagates the
CHANGE message along the established paths. If the change
cannot be made then the ST agent must recover using
DISCONNECT and REFUSE messages as in the case of a network
failure. Note that a failure to change the resources
requested for a specific target(s) should not cause other
targets in the stream to be deleted. The CHANGE must be
ACKed.
If the CHANGE is a result of a CHANGE-REQUEST the
LnkReference field of the CHANGE will contain the value from
the Reference field of the CHANGE-REQUEST.
It is recommended that the origin only have one outstanding
CHANGE per target; if the application requests more that
one to be outstanding at a time, it is the application's
responsibility to deal with any sequencing problems that may
arise.
Any SrcRoute parameters in the targets of the
TargetListParameter are ignored.
G (bit 8) is used to request a global, stream-wide
change; the TargetList parameter may be omitted when the
G bit is specified.
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| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42. CHANGE Control Message
4.2.3.5. CONNECT
CONNECT (OpCode = 5) 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 initial suggestion for a HID. If the stream's
data packets will be sent to some set of next-hop ST agents
by multicast then the CONNECTs to that set must suggest the
same HID. Otherwise, the HIDs in the various CONNECTs can
be different.
The CONNECT message must fit within the maximum allowable
packet size (MTU) for the intervening network. If a CONNECT
message is too large, it must be fragmented into multiple
CONNECT messages by partitioning the TargetList; see Section
4.2 (page 77). Any UserData parameter will be replicated in
each fragment for delivery to all targets.
The next-hop can initially respond with any of the following
five responses:
1 ERROR-IN-REQUEST, which implies that the CONNECT was
not valid and has been ignored,
2 ACK, which implies that the CONNECT with the H bit not
set was valid and is being processed,
3 HID-APPROVE, which implies that the CONNECT with the
H bit set was valid, and the suggested HID can be
used or was deferred,
4 HID-REJECT, which implies that the CONNECT with the H
bit set was valid but the suggested HID cannot be
used and another must be suggested in a subsequent
HID-CHANGE message, or
5 REFUSE, which implies that the CONNECT was valid but
the included list of targets in the REFUSE cannot be
processed for the stated reason.
The next-hop will later relay back either an ACCEPT or
REFUSE from each target not already specified in the REFUSE
of case 5 above (note multiple targets may be included in a
single REFUSE message).
An intermediate ST agent that receives a CONNECT selects the
next-hop ST agents, partitions the TargetList accordingly,
reserves network resources in the direction toward the
next-hop, updating the FlowSpec accordingly (see Section
4.2.2.3 (page 81)), selects a proposed HID for each next-
hop, and sends the resulting CONNECTs.
If the intermediate ST agent that is processing a CONNECT
fails to find a route to a target, then it responds with a
REFUSE with the appropriate reason code. If the next-hop to
a target is by way of the network from which it received the
CONNECT, then it sends a NOTIFY with the appropriate reason
code (RouteBack). In either case, the TargetList specifies
the affected targets. The intermediate ST agent will only
route to and propagate a CONNECT to the targets for which it
does not issue either an ERROR-IN-REQUEST or a REFUSE.
The processing of a received CONNECT message requires care
to avoid routing loops that could result from delays in
propagating routing information among ST agents. If a
received CONNECT contains a new Name, a new stream should be
created (unless the Virtual Link Identifier matches a known
link in which case an ERROR-IN-REQUEST should be sent). If
the Name is known, there are four cases:
1 the Virtual Link Identifier matches and the Target
matches a current Target -- the duplicate target
should be ignored.
2 the Virtual Link Identifier matches but the Target is
new -- the stream should be expanded to include the
new target.
3 the Virtual Link Identifier differs and the Target
matches a current Target -- an ERROR-IN-REQUEST
message should be sent specifying that the target is
involved in a routing loop. If a reroute, the old
path will eventually timeout and send a DISCONNECT;
a subsequent retransmission of the rerouted CONNECT
will then be processed under case 2 above.
4 the Virtual Link Identifier differs but the Target is
new -- a new (instance of the) stream should be
created for the target that is deliberately part of
a loop using a SrcRoute parameter.
Note that the test for a known or matching Target includes
comparing any SrcRoute parameter that might be present.
Option bits are specified by either the origin's service
user or by an intermediate agent, depending on the specific
option. Bits not specified below are currently unspecified,
and should be set to zero (0) by the origin agent and not
changed by other agents unless those agents know their
meaning.
H (bit 8) is used for the HID Field option; see Section
3.6.1 (page 44). It is set to one (1) only if the HID
field contains either zero (when the HID selection is
being deferred), or the proposed HID. This bit is zero
(0) if the HID field does not contain valid data and
should be ignored.
P (bit 9) is used for the PTP option; see Section 3.6.2
(page 44).
S (bit 10) is used for the NoRecovery option; see Section
3.6.4 (page 46).
TSP (bits 14 and 15) specifies the origin's proposal for
the use of data packet timestamps; see Section 4 (page
76). Its values and semantics are:
00 No proposal.
01 Cannot insert timestamps.
10 Must always insert timestamps.
11 Can insert timestamps if requested.
RVLId, the receiver's Virtual Link Identifier, is set to
zero in all CONNECT messages until its value arrives in
the SVLId field of an acknowledgment to the CONNECT.
SVLId, the sender's Virtual Link Identifier, is set to a
value chosen by each hop to facilitate efficient
dispatching of subsequent control messages.
HID is the identifier that will be used with data packets
moving through the stream in the direction from the
origin to the targets. It is a hop-by-hop shorthand
identifier for the stream's Name, and is chosen by each
agent for the branch to the next-hop agents. The
contents of the HID field are only valid, and a HID-
REJECT or HID-APPROVE reply may only be sent, when the
HID Field option (H bit) is set (1). If the HID Field
option is specified and the proposed HID is zero, the
selection of the HID is deferred to the receiving next-
hop agent. If the HID Field option is not set (H bit is
0), then the HID field does not contain valid data and
should be ignored; see Section 3.6.1 (page 44).
TargetList is the list of IP addresses of the target
processes. It is of arbitrary size up to the maximum
allowed for packets traveling across the specific
network.
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 |H|P|S| 0 |TSP| TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId/0 | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Origin Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Group Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MulticastAddress Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RFlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RGroup Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! RHID Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 43. CONNECT Control Message
4.2.3.6. DISCONNECT
DISCONNECT (OpCode = 6) is used by an origin to tear down an
established stream or part of a stream, or by an
intermediate 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.
Note that in the case of a failure it may be advantageous to
retain state information as the stream should be repaired
shortly; see Section 3.7.2 (page 52).
G (bit 8) is used to request a DISCONNECT of all the
stream's targets; the TargetList parameter may be omitted
when the G bit is set (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 = 6 |G| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 44. DISCONNECT Control Message
4.2.3.7. ERROR-IN-REQUEST
ERROR-IN-REQUEST (OpCode = 7) is sent in acknowledgment to a
request in which an error is detected. No action is taken
on the erroneous request and no state information for the
stream is retained. Consequently it is appropriate for the
SVLId to be zero (0). No ACK is expected.
An ERROR-IN-REQUEST is never sent in response to either an
ERROR-IN-REQUEST or an ERROR-IN-RESPONSE; however, the
event should be logged for diagnostic purposes. The
receiver of an ERROR-IN-REQUEST is encouraged to try again
without waiting for a retransmission timeout.
Reference is the Reference number of the erroneous
request.
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 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ErroredPDU :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 45. ERROR-IN-REQUEST Control Message
4.2.3.8. ERROR-IN-RESPONSE
ERROR-IN-RESPONSE (OpCode = 8) is sent in acknowledgment to
a response in which an error is detected. No ACK is
expected. Action taken by the requester and responder will
vary with the nature of the request.
An ERROR-IN-REQUEST is never sent in response to either an
ERROR-IN-REQUEST or an ERROR-IN-RESPONSE; however, the
event should be logged for diagnostic purposes. The
receiver of an ERROR-IN-RESPONSE is encouraged to try again
without waiting for a retransmission timeout.
Reference identifies the erroneous response.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ErroredPDU :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 46. ERROR-IN-RESPONSE Control Message
4.2.3.9. HELLO
HELLO (OpCode = 9) is used as part of the ST failure
detection mechanism; see Section 3.7.1.2 (page 49).
R (bit 8) is used for the Restarted bit.
Reference is non-zero to inform the receiver that an ACK
should be promptly sent so that the sender can update its
round-trip time estimates. If the Reference is zero, no
ACK should be sent.
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 |R| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId/0 | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference/0 | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloTimer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! OriginTimestamp !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 47. HELLO Control Message
4.2.3.10. HID-APPROVE
HID-APPROVE (OpCode = 10) is used by the agent that is
responding to either a CONNECT or HID-CHANGE to agree to
either use the proposed HID or to the addition or deletion
of the specified HID. In all cases but deletion, the newly
approved HID is returned in the HID field; for deletion,
the HID field must be set to zero. The HID-APPROVE is the
acknowledgment of a CONNECT or HID-CHANGE.
The optional FreeHIDs parameter provides the previous-hop
agent with hints about what other HIDs are acceptable in
case a multicast HID is being negotiated; see Section
4.2.2.4 (page 84).
Since a HID-APPROVE might be the first response from a
next-hop on a control link, the SVLId field may be the first
source of the Virtual Link Identifier to be used in the
RVLId field of subsequent control messages sent to that
next-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 = 10 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FreeHIDs Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 48. HID-APPROVE Control Message
4.2.3.11. HID-CHANGE-REQUEST
HID-CHANGE-REQUEST (OpCode = 12) is used by a next-hop agent
that would like, for administrative reasons, to change the
HID that is in use. The receiving previous-hop agent
acknowledges the request by either an ERROR-IN-REQUEST if it
is unwilling to make the requested change, or with a HID-
CHANGE if it can accommodate the request.
A (bit 8) is used to indicate that the specified HID
should be included in the set of HIDs for the specified
Name. When a HID is added, the acknowledging HID-APPROVE
should contain a HID field whose contents is the HID just
added.
D (bit 9) is used to indicate that the specified HID
should be removed in the set of HIDs for the specified
Name. When a HID is deleted, the acknowledging HID-
APPROVE should contain a HID field whose contents is
zero. Note that the Reference field may be used to
determine the HID that has been deleted.
If neither bit is set, the specified HID should replace
that currently in use with the specified Name.
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 |A|D| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 49. HID-CHANGE-REQUEST Control Message
4.2.3.12. HID-CHANGE
HID-CHANGE (OpCode = 11) is used by the agent that issued a
CONNECT and received a HID-REJECT to attempt to negotiate a
suitable HID. The HID in the HID-CHANGE message must be
different from that in the CONNECT, or any previous HID-
CHANGE messages for the given Name. The agent receiving the
HID-CHANGE must respond with a HID-APPROVE if the new HID is
suitable, or a HID-REJECT if it is not. In case of an
error, either an ERROR-IN-REQUEST or a REFUSE may be
returned as an acknowledgment.
Since an agent may send CONNECT messages with the same HID
to several next-hops in order to use multicast data
transfer, any HID-CHANGE must also be sent to the same set
of next-hops. Therefore, a next-hop agent must be prepared
to receive a HID-CHANGE before or after it has sent a HID-
APPROVE response to the CONNECT or a previous HID-CHANGE.
Only the last HID-CHANGE is relevant. The previous-hop
agent will ignore HID-APPROVE or HID-REJECT messages to
previous CONNECT or HID-CHANGE messages.
A DISCONNECT can be sent instead of a HID-CHANGE, or a
REFUSE can be sent instead of a HID-APPROVE or HID-REJECT,
to terminate fatally the HID negotiation and the agent's
knowledge of the stream.
The A and D bits are used to change a HID, e.g., when adding
a new next-hop to a multicast group, in such a way that data
packets that are flowing through the network will not be
mishandled due to a race condition in processing the HID-
CHANGE messages between the previous-hop and its next-hops.
An implementation may choose to limit the number of
simultaneous HIDs associated with a stream, but must allow
at least two.
A (bit 8) is used to indicate that the specified HID
should be included in the set of HIDs for the specified
Name. When a HID is added, the acknowledging HID-APPROVE
should contain a HID field whose contents is the HID just
added.
D (bit 9) is used to indicate that the specified HID
should be removed from the set of HIDs for the specified
Name. When a HID is deleted, the acknowledging HID-
APPROVE should contain a HID field whose contents is
zero. Note that the Reference field may be used to
determine the HID that has been deleted.
If neither bit is set, the specified HID should replace
that currently in use for the specified Name.
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 |A|D| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 50. HID-CHANGE Control Message
4.2.3.13. HID-REJECT
HID-REJECT (OpCode = 13) is used as an acknowledgment that a
CONNECT or HID-CHANGE was received and is being processed,
but means that the HID contained in the CONNECT or HID-
CHANGE is not acceptable. Upon receipt of this message the
agent that issued the CONNECT or HID-CHANGE must now issue a
HID-CHANGE to attempt to find a suitable HID. The HID-
CHANGE can cause another HID-REJECT but eventually the HID-
CHANGE must be acknowledged with a HID-APPROVE to end
successfully the HID negotiation. The agent that issued the
HID-REJECT may not issue an ACCEPT before it has found an
acceptable HID.
Since a HID-REJECT might be the first response from a next-
hop on a control link, the SVLId field may be the first
source of the Virtual Link Identifier to be used in the
RVLId field of subsequent control messages sent to that
next-hop.
Either agent may terminate the negotiation by issuing either
a DISCONNECT or a REROUTE. The agent that issued the HID-
REJECT may issue a REFUSE, or REROUTE at any time after the
HID-REJECT. In this case, the stream cannot be created, the
HID negotiation need not proceed, and the previous-hop need
not transmit any further messages; any further messages
that are received should be ignored.
The optional FreeHIDs parameter provides the previous-hop
agent with hints about what HIDs would have been acceptable;
see Section 4.2.2.4 (page 84).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | RejectedHID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FreeHIDs Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 51. HID-REJECT Control Message
4.2.3.14. NOTIFY
NOTIFY (OpCode = 14) is issued by a an agent to inform other
agents, the origin, or target(s) of events that may be
significant. The action taken by the receiver of a NOTIFY
depends on the ReasonCode. Possible events are suspected
routing problems or resource allocation changes that occur
after a stream has been established. These changes occur
when network components fail and when competing streams
preempt resources previously reserved by a lower precedence
stream. We also anticipate that NOTIFY can be used in the
future when additional resources become available, as is the
case when network components recover or when higher
precedence streams are deleted.
NOTIFY may contain a FlowSpec that reflects that revised
guarantee that can be promised to the stream. NOTIFY may
also identify those targets that are affected by the change.
In this way, NOTIFY is similar to ACCEPT.
NOTIFY may be relayed by the ST agents back to the origin,
along the path established by the CONNECT but in the reverse
direction. It is up to the origin to decide whether a
CHANGE should be submitted.
When NOTIFY is received at the origin, the application
should be notified of the target and the change in resources
allocated along the path to it, as specified in the FlowSpec
contained in the NOTIFY message. The application may then
use the information to either adjust or terminate the
portion of the stream to each affected target.
The NOTIFY may be propagated beyond the previous-hop or
next-hop agent; it must be acknowledged with an ACK.
Reference contains a number assigned by the agent sending
the NOTIFY for use in the acknowledging ACK.
ReasonCode identifies the reason for the notification.
LnkReference, when non-zero, is the Reference number from
a command that is the subject of the notification.
HID is present when the notification is related to a HID.
Name is present when the notification is related to a
stream.
NextHopIPAddress is an optional parameter and contains
the IP address of a suggested next-hop ST agent.
TargetList is present when the notification is related to
one or more targets.
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 = 14 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+