RFC 1190
Experimental Internet Stream Protocol: Version 2 (ST-II)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ErroredPDU :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! HID Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! NextHopIPAddress Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 52. NOTIFY Control Message
4.2.3.15. REFUSE
REFUSE (OpCode = 15) 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 agent in response to a CONNECT or CHANGE
either to terminate fatally a failing HID negotiation, 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 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 by the agents from the originating
agent to the origin (or intermediate agent that created the
CONNECT or CHANGE) along the path traced by the CONNECT.
The agent receiving the REFUSE will process it differently
depending on the condition that caused it, as specified in
the ReasonCode field. In some cases, such as if a next-hop
cannot obtain resources, the agent can release any resources
reserved exclusively for transmissions in the stream in
question to the target specified in the TargetList, and the
previous-hop can attempt to find an alternate route. In
some cases, such as a routing failure, the previous-hop
cannot determine where the failure occurred, and must
propagate the REFUSE back to the origin, which can attempt
recovery of the stream by issuing a new CONNECT.
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 agent at the
same time and be easily combined, e.g., have identical
ReasonCodes and parameters.
Since a REFUSE 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.
Reference contains a number assigned by the agent sending
the REFUSE for use in the acknowledging ACK.
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.
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 = 15 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ErroredPDU :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 53. REFUSE Control Message
4.2.3.16. STATUS
STATUS (OpCode = 16) is used to inquire about the existence
of a particular stream identified by either a HID (H bit
set) or Name (Name Parameter present).
When a stream has been identified, a STATUS-RESPONSE is
returned that will contain the specified HID and/or Name but
no other parameters if the specified stream is unknown, or
will otherwise contain the current HID(s), Name, FlowSpec,
TargetList, and possibly Group(s) of the stream. Note that
if a stream has no current HID, the HID field in the
STATUS-RESPONSE will contain zero; it will contain the
first, or only, HID if a valid HID exists; additional valid
HIDs will be returned in HID parameters.
Use of STATUS is intended for diagnostic purposes and to
assist in stream cleanup operations. Note that if both a
HID and Name are specified, but they do not correspond to
the same stream, an ERROR-IN-REQUEST with the appropriate
reason code (InconsistHID) would be returned.
It is possible in cases of multiple failures or network
partitioning for an ST agent to have information about a
stream after the stream has either ceased to exist or has
been rerouted around the agent. When an agent concludes
that a stream has not been used for a period of time and
might no longer be valid, it can probe the stream's
previous-hop or next-hop(s) to see if they believe that the
stream still exists through the interrogating agent. If
not, those hops would reply with a STATUS-RESPONSE that
contains the HID and/or Name but no other parameters;
otherwise, if the stream is still valid, the hops would
reply with the parameters of the stream.
H (bit 8) is used to indicate whether (when 1) or not
(when 0) a HID is present in the HID field.
Q (bit 9) is set to one (1) for remote diagnostic
purposes when the receiving agent should return a
stream's parameters, whether or not the source of the
message is believed to be a previous-hop or next-hop in
the specified stream. Note that this use has potential
for disclosure of sensitive information.
RVLId and SVLId may either or both be zero when STATUS is
used for diagnostic purposes.
(next page on part 6)
