setup protocol as well. At stream establishment time, the setup
protocol builds, at each agent traversed by the stream, an entry into
its local database containing stream information. The SID can be used
as a reference into this database, to obtain quickly the necessary
replication and forwarding information.
Stream IDentifiers are intended to be used to make the packet
forwarding task most efficient. The time-critical operation is an
intermediate ST agent receiving a packet from the previous-hop ST
agent and forwarding it to the next-hop ST agents.
The format of data PDUs including the SID is defined in Section 10.1.
Stream IDentifier generation is discussed in Section 8.1.
3.2.2 Packet Discarding based on Data Priority
ST provides a well defined quality of service to its applications.
However, there may be cases where the network is temporarily
congested and the ST agents have to discard certain packets to
minimize the overall impact to other streams. The ST protocol
provides a mechanism to discard data packets based on the Priority
field in the data PDU, see Section 10.1. The application assigns each
data packet with a discard-priority level, carried into the Priority
field. ST agents will attempt to discard lower priority packets first
during periods of network congestion. Applications may choose to send
data at multiple priority levels so that less important data may be
discarded first.
4. SCMP Functional Description
ST agents create and manage streams using the ST Control Message
Protocol (SCMP). Conceptually, SCMP resides immediately above ST (as
does ICMP above IP). SCMP follows a request-response model. SCMP
messages are made reliable through the use of retransmission after
timeout.
This section contains a functional description of stream management
with SCMP. To help clarify the SCMP exchanges used to setup and
maintain ST streams, we include an example of a simple network
topology, represented in Figure 8. Using the SCMP messages described
in this section it will be possible for an ST application to:
o Create a stream from A to the peers at B, C and D,
o Add a peer at E,
o Drop peers B and C, and
o Let F join the stream
o Delete the stream.
+---------+ +---+
| |----| B |
+---------+ +----------+ | | +---+
| |------| Router 1 |---| Subnet2 |
| | +----------+ | |
| | | |
| | +---------+
| | |
| Subnet1 | |
| | +----------+
| | | Router 3 |
+---+ | | +----------+
| A |---| | +----------+ |
+---+ | |----| Router 2 | |
| | +----------+ |
+---------+ | |
| |
| +----------+ +---+
+----------| |----| C |
| | +---+
+---------+ | Subnet3 |
+---+ | | +---+ | | +---+
| F |---| Subnet4 |---| E |--| |----| D |
+---+ | | +---+ +----------+ +---+
+---------+
Figure 8: Sample Topology for an ST Stream
We first describe the possible types of stream in Section 4.1;
Section 4.2 introduces SCMP control message types; SCMP reliability
is discussed in Section 4.3; stream options are covered in Section
4.4; stream setup is presented in Section 4.5; Section 4.6
illustrates stream modification including stream expansion,
reduction, changes of the quality of service associated to a stream.
Finally, stream deletion is handled in Section 4.7.
4.1 Types of Streams
SCMP allows for the setup and management of different types of
streams. Streams differ in the way they are built and the information
maintained on connected targets.
4.1.1 Stream Building
Streams may be built in a sender-oriented fashion, receiver-oriented
fashion, or with a mixed approach:
o in the sender-oriented fashion, the application at the origin
provides the ST agent with the list of receivers for the stream. New
targets, if any, are also added from the origin.
o in the receiver-oriented approach, the application at the origin
creates an empty stream that contains no targets. Each target then
joins the stream autonomously.
o in the mixed approach, the application at the origin creates a
stream that contains some targets and other targets join the stream
autonomously.
ST2 provides stream options to support sender-oriented and mixed
approach steams. Receiver-oriented streams can be emulated through
the use of mixed streams. The fashion by which targets may be added
to a particular stream is controlled via join authorization levels.
Join authorization levels are described in Section 4.4.2.
4.1.2 Knowledge of Receivers
When streams are built in the sender-oriented fashion, all ST agents
will have full information on all targets down stream of a particular
agent. In this case, target information is relayed down stream from
agent-to-agent during stream set-up.
When targets add themselves to mixed approach streams, upstream ST
agents may or may not be informed. Propagation of information on
targets that "join" a stream is also controlled via join
authorization levels. As previously mentioned, join authorization
levels are described in Section 4.4.2.
This leads to two types of streams:
o full target information is propagated in a full-state stream. For
such streams, all agents are aware of all downstream targets
connected to the stream. This results in target information being
maintained at the origin and at intermediate agents. Operations on
single targets are always possible, i.e., change a certain target,
or, drop that target from the stream. It is also always possible for
any ST agent to attempt recovery of all downstream targets.
o in light-weight streams, it is possible that the origin and other
upstream agents have no knowledge about some targets. This results
in less maintained state and easier stream management, but it limits
operations on specific targets. Special actions may be required to
support change and drop operations on unknown targets, see Section
5.7. Also, stream recovery may not be possible. Of course, generic
functions such as deleting the whole stream, are still possible. It
is expected that applications that will have a large number of
targets will use light-weight streams in order to limit state in
agents and the number of targets per control message.
Full-state streams serve well applications as video conferencing or
distributed gaming, where it is important to have knowledge on the
connected receivers, e.g., to limit who participates. Light-weight
streams may be exploited by applications such as remote lecturing or
playback applications of radio and TV broadcast where the receivers
do not need to be known by the sender. Section 4.4.2 defines join
authorization levels, which support two types of full-state streams
and one type of light-weight stream.
4.2 Control PDUs
SCMP defines the following PDUs (the main purpose of each PDU is also
indicated):
1. ACCEPT to accept a new stream
2. ACK to acknowledge an incoming message
3. CHANGE to change the quality of service associated with
a stream
4. CONNECT to establish a new stream or add new targets to
an existing stream
5. DISCONNECT to remove some or all of the stream's targets
6. ERROR to indicate an error contained in an incoming
message
7. HELLO to detect failures of neighbor ST agents
8. JOIN to request stream joining from a target
9. JOIN-REJECT to reject a stream joining request from a target
10. NOTIFY to inform an ST agent of a significant event
11. REFUSE to refuse the establishment of a new stream
12. STATUS to query an ST agent on a specific stream
13. STATUS-RESPONSE to reply queries on a specific stream
SCMP follows a request-response model with all requests expecting
responses. Retransmission after timeout 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, as described in Section 5.1.2.
CONNECT and CHANGE request messages are answered with ACCEPT messages
which indicate success, and with REFUSE messages which indicate
failure. JOIN messages are answered with either a CONNECT message
indicating success, or with a JOIN-REJECT message indicating failure.
Targets may be removed from a stream by either the origin or the
target via the DISCONNECT and REFUSE messages.
The ACCEPT, CHANGE, CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY
and REFUSE messages must always be explicitly acknowledged:
o with an ACK message, if the message was received correctly and it
was possible to parse and correctly extract and interpret its
header, fields and parameters,
o with an ERROR message, if a syntax error was detected in the header,
fields, or parameters included in the message. The errored PDU may
be optionally returned as part of the ERROR message. An ERROR
message indicates a syntax error only. If any other errors are
detected, it is necessary to first acknowledge with ACK and then
take appropriate actions. For instance, suppose a CHANGE message
contains an unknown SID: first, an ACK message has to be sent, then
a REFUSE message with ReasonCode (SIDUnknown) follows.
If no ACK or ERROR message are received before the correspondent
timer expires, a timeout failure occurs. The way an ST agent should
handle timeout failures is described in Section 5.2.
ACK, ERROR, and STATUS-RESPONSE messages are never acknowledged.
HELLO messages are a special case. If they contain a syntax error, an
ERROR message should be generated in response. Otherwise, no
acknowledgment or response should be generated. Use of HELLO messages
is discussed in Section 6.1.2.
STATUS messages containing a syntax error should be answered with an
ERROR message. Otherwise, a STATUS-RESPONSE message should be sent
back in response. Use of STATUS and STATUS-RESPONSE are discussed in
Section 8.4.
4.3 SCMP Reliability
SCMP is made reliable through the use of retransmission when a
response is not received in a timely manner. The ACCEPT, CHANGE,
CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY, and REFUSE messages
all must be answered with an ACK message, see Section 4.2. In
general, when sending a SCMP message which requires an ACK response,
the sending ST agent needs to set the Toxxxx timer (where xxxx is the
SCMP message type, e.g., ToConnect). If it does not receive an ACK
before the Toxxxx timer expires, the ST agent should retransmit the
SCMP message. If no ACK has been received within Nxxxx
retransmissions, then a SCMP timeout condition occurs and the ST
agent enters its SCMP timeout recovery state. The actions performed
by the ST agent as the result of the SCMP timeout condition differ
for different SCMP messages and are described in Section 5.2.
For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the
sending ST agent also expects a response back (ACCEPT/REFUSE,
CONNECT/JOIN- REJECT) after ACK has been received. For these cases,
the ST agent needs to set the ToxxxxResp timer after it receives the
ACK. (As before, xxxx is the initiating SCMP message type, e.g.,
ToConnectResp). If it does not receive the appropriate response back
when ToxxxxResp expires, the ST agent updates its state and performs
appropriate recovery action as described in Section 5.2. Suggested
constants are given in Section 10.5.4.
The timeout and retransmission algorithm is implementation dependent
and it is outside the scope of this document. Most existing
algorithms are based on an estimation of the Round Trip Time (RTT)
between two agents. Therefore, SCMP contains a mechanism, see Section
8.5, to estimate this RTT. Note that the timeout related variable
names described above are for reference purposes only, implementors
may choose to combine certain variables.
4.4 Stream Options
An application may select among some stream options. The desired
options are indicated to the ST agent at the origin when a new stream
is created. Options apply to single streams and are valid during the
whole stream's lifetime. The options chosen by the application at the
origin are included into the initial CONNECT message, see Section
4.5.3. When a CONNECT message reaches a target, the application at
the target is notified of the stream options that have been selected,
see Section 4.5.5.
4.4.1 No Recovery
When a stream failure is detected, an ST agent would normally attempt
stream recovery, as described in Section 6.2. The NoRecovery option
is used to indicate that ST agents should not attempt recovery for
the stream. The protocol behavior in the case that the NoRecovery
option has been selected is illustrated in Section 6.2. The
NoRecovery option is specified by setting the S-bit in the CONNECT
message, see Section 10.4.4. The S-bit can be set only by the origin
and it is never modified by intermediate and target ST agents.
4.4.2 Join Authorization Level
When a new stream is created, it is necessary to define the join
authorization level associated with the stream. This level determines
the protocol behavior in case of stream joining, see Section 4.1 and
Section 4.6.3. The join authorization level for a stream is defined
by the J-bit and N-bit in the CONNECT message header, see Section
10.4.4. One of the following authorization levels has to be
selected:
o Level 0 - Refuse Join (JN = 00): No targets are allowed to join this
stream.
o Level 1 - OK, Notify Origin (JN = 01): Targets are allowed to join
the stream. The origin is notified that the target has joined.
o Level 2 - OK (JN = 10): Targets are allowed to join the stream. No
notification is sent to the stream origin.
Some applications may choose to maintain tight control on their
streams and will not permit any connections without the origin's
permission. For such streams, target applications may request to be
added by sending an out-of-band, i.e., via regular IP, request to the
origin. The origin, if it so chooses, can then add the target
following the process described in Section 4.6.1.
The selected authorization level impacts stream handling and the
state that is maintained for the stream, as described in Section 4.1.
4.4.3 Record Route
The RecordRoute option can be used to request the route between the
origin and a target be recorded and delivered to the application.
This option may be used while connecting, accepting, changing, or
refusing a stream. The results of a RecordRoute option requested by
the origin, i.e., as part of the CONNECT or CHANGE messages, are
delivered to the target. The results of a RecordRoute option
requested by the target, i.e., as part of the ACCEPT or REFUSE
messages, are delivered to the origin.
The RecordRoute option is specified by adding the RecordRoute
parameter to the mentioned SCMP messages. The format of the
RecordRoute parameter is shown in Section 10.3.5. When adding this
parameter, the ST agent at the origin must determine the number of
entries that may be recorded as explained in Section 10.3.5.
4.4.4 User Data
The UserData option can be used by applications to transport
application specific data along with some SCMP control messages. This
option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and
REFUSE messages. The format of the UserData parameter is shown in
Section 10.3.7. This option may be included by the origin, or the
target, by adding the UserData parameter to the mentioned SCMP
messages. This option may only be included once per SCMP message.
4.5 Stream Setup
This section presents a description of stream setup. For simplicity,
we assume that everything succeeds, e.g., any required resources are
available, messages are properly delivered, and the routing is
correct. Possible failures in the setup phase are handled in Section
5.2.
4.5.1 Information from the Application
Before stream setup can be started, the application has to collect
the necessary information to determine the characteristics for the
connection. This includes identifying the participants and selecting
the QoS parameters of the data flow. Information passed to the ST
agent by the application includes:
o the list of the stream's targets (Section 10.3.6). The list may be
empty (Section 4.5.3.1),
o the flow specification containing the desired quality of service for
the stream (Section 9),
o information on the groups in which the stream is a member, if any
(Section 7),
o information on the options selected for the stream (Section 4.4).
4.5.2 Initial Setup at the Origin
The ST agent at the origin then performs the following operations:
o allocates a stream ID (SID) for the stream (Section 8.1),
o invokes the routing function to determine the set of next-hops for
the stream (Section 4.5.2.1),
o invokes the Local Resource Manager (LRM) to reserve resources
(Section 4.5.2.2),
o creates local database entries to store information on the new
stream,
o propagates the stream creation request to the next-hops determined
by the routing function (Section 4.5.3).
4.5.2.1 Invoking the Routing Function
An ST agent that is setting up a stream invokes the routing function
to find the next-hop to reach each of the targets specified by the
target list provided by the application. This is similar to the
routing decision in IP. However, in this case the route is to a
multitude of targets with QoS requirements rather than to a single
destination.
The result of the routing function is a set of next-hop ST agents.
The set of next-hops selected by the routing function is not
necessarily the same as the set of next-hops that IP would select
given a number of independent IP datagrams to the same destinations.
The routing algorithm may attempt to optimize parameters other than
the number of hops that the packets will take, such as delay, local
network bandwidth consumption, or total internet bandwidth
consumption. Alternatively, the routing algorithm may use a simple
route lookup for each target.
Once a next-hop is selected by the routing function, it persists for
the whole stream lifetime, unless a network failure occurs.
4.5.2.2 Reserving Resources
The ST agent invokes the Local Resource Manager (LRM) to perform the
appropriate reservations. The ST agent presents the LRM with
information including:
o the flow specification with the desired quality of service for the
stream (Section 9),
o the version number associated with the flow specification
(Section 9).
o information on the groups the stream is member in, if any
(Section 7),
The flow specification contains information needed by the LRM to
allocate resources. The LRM updates the flow specification contents
information before returning it to the ST agent. Section 9.2.3
defines the fields of the flow specification to be updated by the
LRM.
The membership of a stream in a group may affect the amount of
resources that have to be allocated by the LRM, see Section 7.
4.5.3 Sending CONNECT Messages
The ST agent sends a CONNECT message to each of the next-hop ST
agents identified by the routing function. Each CONNECT message
contains the SID, the selected stream options, the FlowSpec, and a
TargetList. The format of the CONNECT message is defined by Section
10.4.4. In general, the FlowSpec and TargetList depend on both the
next-hop and the intervening network. Each TargetList is a subset of
the original TargetList, identifying the targets that are to be
reached through the next-hop to which the CONNECT message is being
sent.
The TargetList may be empty, see Section 4.5.3.1; if the TargetList
causes a too long CONNECT message to be generated, the CONNECT
message is partitioned as explained in Section 5.1.2. If multiple
next-hops are to be reached through a network that supports network
level multicast, a different CONNECT message must nevertheless be
sent to each next-hop since each will have a different TargetList.
4.5.3.1 Empty Target List
An application at the origin may request the local ST agent to create
an empty stream. It does so by passing an empty TargetList to the
local ST agent during the initial stream setup. When the local ST
agent receives a request to create an empty stream, it allocates the
stream ID (SID), updates its local database entries to store
information on the new stream and notifies the application that
stream setup is complete. The local ST agent does not generate any
CONNECT message for streams with an empty TargetList. Targets may be
later added by the origin, see Section 4.6.1, or they may
autonomously join the stream, see Section 4.6.3.
4.5.4 CONNECT Processing by an Intermediate ST agent
An ST agent receiving a CONNECT message, assuming no errors, responds
to the previous-hop with an ACK. The ACK message must identify the
CONNECT message to which it corresponds by including the reference
number indicated by the Reference field of the CONNECT message. The
intermediate ST agent calls the routing function, invokes the LRM to
reserve resources, and then propagates the CONNECT messages to its
next-hops, as described in the previous sections.
4.5.5 CONNECT Processing at the Targets
An ST agent that is the target of a CONNECT message, assuming no
errors, responds to the previous-hop with an ACK. The ST agent
invokes the LRM to reserve local resources and then queries the
specified application process whether or not it is willing to accept
the connection.
The application is presented with parameters from the CONNECT message
including the SID, the selected stream options, Origin, FlowSpec,
TargetList, and Group, if any, to be used as a basis for its
decision. The application is identified by a combination of the
NextPcol field, from the Origin parameter, and the service access
point, or SAP, field included in the correspondent (usually single
remaining) Target of the TargetList. The contents of the SAP field
may specify the port or other local identifier for use by the
protocol layer above the host ST layer. Subsequently received data
packets will carry the SID, that can be mapped into this information
and be used for their delivery.
Finally, based on the application's decision, the ST agent sends to
the previous-hop from which the CONNECT message was received either
an ACCEPT or REFUSE message. Since the ACCEPT (or REFUSE) message has
to be acknowledged by the previous-hop, it is assigned a new
Reference number that will be returned in the ACK. The CONNECT
message to which ACCEPT (or REFUSE) is a reply is identified by
placing the CONNECT's Reference number in the LnkReference field of
ACCEPT (or REFUSE). The ACCEPT message contains the FlowSpec as
accepted by the application at the target.
4.5.6 ACCEPT Processing by an Intermediate ST agent
When an intermediate ST agent receives an ACCEPT, it first verifies
that the message is a response to an earlier CONNECT. If not, it
responds to the next-hop ST agent with an ERROR message, with
ReasonCode (LnkRefUnknown). Otherwise, it responds to the next-hop ST
agent with an ACK, and propagates the individual ACCEPT message to
the previous-hop along the same path traced by the CONNECT but in the
reverse direction toward the origin.
The FlowSpec is included in the ACCEPT message so that the origin and
intermediate ST agents can gain access to the information that was
accumulated as the CONNECT traversed the internet. Note that the
resources, as specified in the FlowSpec in the ACCEPT message, may
differ from the resources that were reserved when the CONNECT was
originally processed. Therefore, the ST agent presents the LRM with
the FlowSpec included in the ACCEPT message. It is expected that each
LRM adjusts local reservations releasing any excess resources. The
LRM may choose not to adjust local reservations when that adjustment
may result in the loss of needed resources. It may also choose to
wait to adjust allocated resources until all targets in transition
have been accepted or refused.
In the case where the intermediate ST agent is acting as the origin
with respect to this target, see Section 4.6.3.1, the ACCEPT message
is not propagated upstream.
4.5.7 ACCEPT Processing by the Origin
The origin will eventually receive an ACCEPT (or REFUSE) message from
each of the targets. As each ACCEPT is received, the application is
notified of the target and the resources that were successfully
allocated along the path to it, as specified in the FlowSpec
contained in the ACCEPT message. The application may then use the
information to either adopt or terminate the portion of the stream to
each target.
When an ACCEPT is received by the origin, the path to the target is
considered to be established and the ST agent is allowed to forward
the data along this path as explained in Section 2 and in Section
3.1.
4.5.8 REFUSE Processing by the Intermediate ST agent
If an application at a target does not wish to participate in the
stream, it sends a REFUSE message back to the origin with ReasonCode
(ApplDisconnect). An intermediate ST agent that receives a REFUSE
message with ReasonCode (ApplDisconnect) acknowledges it by sending
an ACK to the next-hop, invokes the LRM to adjusts reservations as
appropriate, deletes the target entry from the internal database, and
propagates the REFUSE message back to the previous-hop ST agent.
In the case where the intermediate ST agent is acting as the origin
with respect to this target, see Section 4.6.3.1, the REFUSE message
is only propagated upstream when there are no more downstream agents
participating in the stream. In this case, the agent indicates that
the agent is to be removed from the stream propagating the REFUSE
message with the G-bit set (1).
4.5.9 REFUSE Processing by the Origin
When the REFUSE message reaches the origin, the ST agent at the
origin sends an ACK and notifies the application that the target is
no longer part of the stream and also if the stream has no remaining
targets. If there are no remaining targets, the application may wish
to terminate the stream, or keep the stream active to allow addition
of targets or stream joining as described in Section 4.6.3.
4.5.10 Other Functions during Stream Setup
Some other functions have to be accomplished by an ST agent as
CONNECT messages travel downstream and ACCEPT (or REFUSE) messages
travel upstream during the stream setup phase. They were not
mentioned in the previous sections to keep the discussion as simple
as possible. These functions include:
o computing the smallest Maximum Transmission Unit size over the path
to the targets, as part of the MTU discovery mechanism presented in
Section 8.6. This is done by updating the MaxMsgSize field of the
CONNECT message, see Section 10.4.4. This value is carried back to
origin in the MaxMsgSize field of the ACCEPT message, see Section
10.4.1.
o counting the number of IP clouds to be traversed to reach the
targets, if any. IP clouds are traversed when the IP encapsulation
mechanism is used. This mechanism described in Section 8.7.
Encapsulating agents update the IPHops field of the CONNECT message,
see Section 10.4.4. The resulting value is carried back to origin in
the IPHops field of the ACCEPT message, see Section 10.4.1.
o updating the RecoveryTimeout value for the stream based on what can
the agent can support. This is part of the stream recovery
mechanism, in Section 6.2. This is done by updating the
RecoveryTimeout field of the CONNECT message, see Section 10.4.4.
This value is carried back to origin in the RecoveryTimeout field of
the ACCEPT message, see Section 10.4.1.
4.6 Modifying an Existing Stream
Some applications may wish to modify a stream after it has been
created. Possible changes include expanding a stream, reducing it,
and changing its FlowSpec. The origin may add or remove targets as
described in Section 4.6.1 and Section 4.6.2. Targets may request to
join the stream as described in Section 4.6.3 or, they may decide to
leave a stream as described in Section 4.6.4. Section 4.6.5 explains
how to change a stream's FlowSpec.
As defined by Section 2, an ST agent can handle only one stream
modification at a time. If a stream modification operation is already
underway, further requests are queued and handled when the previous
operation has been completed. This also applies to two subsequent
requests of the same kind, e.g., two subsequent changes to the
FlowSpec.
4.6.1 The Origin Adding New Targets
It is possible for an application at the origin to add new targets to
an existing stream any time after the stream has been established.
Before new targets are added, the application has to collect the
necessary information on the new targets. Such information is passed
to the ST agent at the origin.
The ST agent at the origin issues a CONNECT message that contains the
SID, the FlowSpec, and the TargetList specifying the new targets.
This is similar to sending a CONNECT message during stream
establishment, with the following exceptions: the origin checks that
a) the SID is valid, b) the targets are not already members of the
stream, c) that the LRM evaluates the FlowSpec of the new target to
be the same as the FlowSpec of the existing stream, i.e., it requires
an equal or smaller amount of resources to be allocated. If the
FlowSpec of the new target does not match the FlowSpec of the
existing stream, an error is generated with ReasonCode
(FlowSpecMismatch). Functions to compare flow specifications are
provided by the LRM, see Section 1.4.5.
An intermediate ST agent that is already a participant in the stream
looks at the SID and StreamCreationTime, and verifies that the stream
is the same. It then checks if the intersection of the TargetList and
the targets of the established stream is empty. If this is not the
case, it responds with a REFUSE message with ReasonCode
(TargetExists) that contains a TargetList of those targets that were
duplicates. To indicate that the stream exists, and includes the
listed targets, the ST agent sets to one (1) the E-bit of the REFUSE
message, see Section 10.4.11. The agent then proceeds processing
each new target in the TargetList.
For each new target in the TargetList, processing is much the same as
for the original CONNECT. The CONNECT is acknowledged, propagated,
and network resources are reserved. Intermediate or target ST agents
that are not already participants in the stream behave as in the case
of stream setup (see Section 4.5.4 and Section 4.5.5).
4.6.2 The Origin Removing a Target
It is possible for an application at the origin to remove existing
targets of a stream any time after the targets have accepted the
stream. The application at the origin specifies the set of targets
that are to be removed and informs the local ST agent. Based on this
information, the ST agent sends DISCONNECT messages with the
ReasonCode (ApplDisconnect) to the next-hops relative to the targets.
An ST agent that receives a DISCONNECT message must acknowledge it by
sending an ACK to the previous-hop. The ST agent updates its state
and notifies the LRM of the target deletion so that the LRM can
modify reservations as appropriate. When the DISCONNECT message
reaches the target, the ST agent also notifies the application that
the target is no longer part of the stream. When there are no
remaining targets that can be reached through a particular next-hop,
the ST agent informs the LRM and it deletes the next-hop from its
next-hops set.
SCMP also provides a flooding mechanism to delete targets that joined
the stream without notifying the origin. The special case of target
deletion via flooding is described in Section 5.7.
4.6.3 A Target Joining a Stream
An application may request to join an existing stream. It has to
collect information on the stream including the stream ID (SID) and
the IP address of the stream's origin. This can be done out-of-band,
e.g., via regular IP. The information is then passed to the local ST
agent. The ST agent generates a JOIN message containing the
application's request to join the stream and sends it toward the
stream origin.
An ST agent receiving a JOIN message, assuming no errors, responds
with an ACK. The ACK message must identify the JOIN message to which
it corresponds by including the Reference number indicated by the
Reference field of the JOIN message. If the ST agent is not traversed
by the stream that has to be joined, it propagates the JOIN message
toward the stream's origin. Once a JOIN message has been
acknowledged, ST agents do not retain any state information related
to the JOIN message.
Eventually, an ST agent traversed by the stream or the stream's
origin itself is reached. This agent must respond to a received JOIN
first with an ACK to the ST agent from which the message was
received, then, it issues either a CONNECT or a JOIN-REJECT message
and sends it toward the target. The response to the join request is
based on the join authorization level associated with the stream, see
Section 4.4.2:
o If the stream has authorization level #0 (refuse join):
The ST agent sends a JOIN-REJECT message toward the target with
ReasonCode (JoinAuthFailure).
o If the stream has authorization level #1 (ok, notify origin):
The ST agent sends a CONNECT message toward the target with a
TargetList including the target that requested to join the stream.
This eventually results in adding the target to the stream. When
the ST agent receives the ACCEPT message indicating that the new
target has been added, it does not propagate the ACCEPT message
backwards (Section 4.5.6). Instead, it issues a NOTIFY message
with ReasonCode (TargetJoined) so that upstream agents, including
the origin, may add the new target to maintained state
information. The NOTIFY message includes all target specific
information.
o If the stream has authorization level #2 (ok):
The ST agent sends a CONNECT message toward the target with a
TargetList including the target that requested to join the stream.
This eventually results in adding the target to the stream. When
the ST agent receives the ACCEPT message indicating that the new
target has been added, it does not propagate the ACCEPT message
backwards (Section 4.5.6), nor does it notify the origin. A NOTIFY
message is generated with ReasonCode (TargetJoined) if the target
specific information needs to be propagated back to the origin. An
example of such information is change in MTU, see Section 8.6.
4.6.3.1 Intermediate Agent (Router) as Origin
When a stream has join authorization level #2, see Section 4.4.2, it
is possible that the stream origin is unaware of some targets
participating in the stream. In this case, the ST intermediate agent
that first sent a CONNECT message to this target has to act as the
stream origin for the given target. This includes:
o if the whole stream is deleted, the intermediate agent must
disconnect the target.
o if the stream FlowSpec is changed, the intermediate agent must
change the FlowSpec for the target as appropriate.
o proper handling of ACCEPT and REFUSE messages, without propagation
to upstream ST agents.
o generation of NOTIFY messages when needed. (As described above.)
The intermediate agent behaves normally for all other targets added
to the stream as a consequence of a CONNECT message issued by the
origin.
4.6.4 A Target Deleting Itself
The application at the target may inform the local ST agent that it
wants to be removed from the stream. The ST agent then forms a REFUSE
message with the target itself as the only entry in the TargetList
and with ReasonCode (ApplDisconnect). The REFUSE message is sent back
to the origin via the previous-hop. If a stream has multiple targets
and one target leaves the stream using this REFUSE mechanism, the
stream to the other targets is not affected; the stream continues to
exist.
An ST agent that receives a REFUSE message acknowledges it by sending
an ACK to the next-hop. The target is deleted and the LRM is notified
so that it adjusts reservations as appropriate. The REFUSE message is
also propagated back to the previous-hop ST agent except in the case
where the agent is acting as the origin. In this case a NOTIFY may be
propagated instead, see Section 4.6.3.
When the REFUSE reaches the origin, the origin sends an ACK and
notifies the application that the target is no longer part of the
stream.
4.6.5 Changing a Stream's FlowSpec
The application at the origin may wish to change the FlowSpec of an
established stream. Changing the FlowSpec is a critical operation and
it may even lead in some cases to the deletion of the affected
targets. Possible problems with FlowSpec changes are discussed in
Section 5.6.
To change the stream's FlowSpec, the application informs the ST agent
at the origin of the new FlowSpec and of the list of targets relative
to the change. The ST agent at the origin then issues one CHANGE
message per next-hop including the new FlowSpec and sends it to the
relevant next-hop ST agents. If the G-bit field of the CHANGE message
is set (1), the change affects all targets in the stream.
The CHANGE message contains a bit called I-bit, see Section 10.4.3.
By default, the I-bit is set to zero (0) to indicate that the LRM is
expected to try and perform the requested FlowSpec change without
risking to tear down the stream. Applications that desire a higher
probability of success and are willing to take the risk of breaking
the stream can indicate this by setting the I-bit to one (1).
Applications that require the requested modification in order to
continue operating are expected to set this bit.
An intermediate ST agent that receives a CHANGE message first sends
an ACK to the previous-hop and then provides the FlowSpec to the LRM.
If the LRM can perform the change, the ST agent propagates the CHANGE
messages along the established paths.
If the whole process succeeds, the CHANGE messages will eventually
reach the targets. Targets respond with an ACCEPT (or REFUSE) message
that is propagated back to the origin. In processing the ACCEPT
message on the way back to the origin, excess resources may be
released by the LRM as described in Section 4.5.6. The REFUSE message
must have the ReasonCode (ApplRefused).
SCMP also provides a flooding mechanism to change targets that joined
the stream without notifying the origin. The special case of target
change via flooding is described in Section 5.7.
4.7 Stream Tear Down
A stream is usually terminated by the origin when it has no further
data to send. A stream is also torn down if the application should
terminate abnormally or if certain network failures are encountered.
Processing in this case is identical to the previous descriptions
except that the ReasonCode (ApplAbort, NetworkFailure, etc.) is
different.
When all targets have left a stream, the origin notifies the
application of that fact, and the application is then responsible for
terminating the stream. Note, however, that the application may
decide to add targets to the stream instead of terminating it, or may
just leave the stream open with no targets in order to permit stream
joins.
5. Exceptional Cases
The previous descriptions covered the simple cases where everything
worked. We now discuss what happens when things do not succeed.
Included are situations where messages exceed a network MTU, are
lost, the requested resources are not available, the routing fails or
is inconsistent.
5.1 Long ST Messages
It is possible that an ST agent, or an application, will need to send
a message that exceeds a network's Maximum Transmission Unit (MTU).
This case must be handled but not via generic fragmentation, since
ST2 does not support generic fragmentation of either data or control
messages.
5.1.1 Handling of Long Data Packets
ST agents discard data packets that exceed the MTU of the next-hop
network. No error message is generated. Applications should avoid
sending data packets larger than the minimum MTU supported by a given
stream. The application, both at the origin and targets, can learn
the stream minimum MTU through the MTU discovery mechanism described
in Section 8.6.
5.1.2 Handling of Long Control Packets
Each ST agent knows the MTU of the networks to which it is connected,
and those MTUs restrict the size of the SCMP message it can send. An
SCMP message size can exceed the MTU of a given network for a number
of reasons:
o the TargetList parameter (Section 10.3.6) may be too long;
o the RecordRoute parameter (Section 10.3.5) may be too long.
o the UserData parameter (Section 10.3.7) may be too long;
o the PDUInError field of the ERROR message (Section 10.4.6) may be
too long;
An ST agent receiving or generating a too long SCMP message should:
o break the message into multiple messages, each carrying part of the
TargetList. Any RecordRoute and UserData parameters are replicated
in each message for delivery to all targets. Applications that
support a large number of targets may avoid using long TargetList
parameters, and are expected to do so, by exploiting the stream
joining functions, see Section 4.6.3. One exception to this rule
exists. In the case of a long TargetList parameter to be included in
a STATUS-RESPONSE message, the TargetList parameter is just
truncated to the point where the list can fit in a single message,
see Section 8.4.
o for down stream agents: if the TargetList parameter contains a
single Target element and the message size is still too long, the ST
agent should issue a REFUSE message with ReasonCode
(RecordRouteSize) if the size of the RecordRoute parameter causes
the SCMP message size to exceed the network MTU, or with ReasonCode
(UserDataSize) if the size of the UserData parameter causes the SCMP
message size to exceed the network MTU. If both RecordRoute and
UserData parameters are present the ReasonCode (UserDataSize) should
be sent. For messages generated at the target: the target ST agent
must check for SCMP messages that may exceed the MTU on the complete
target-to-origin path, and inform the application that a too long
SCMP messages has been generated. The format for the error reporting
is a local implementation issue. The error codes are the same as
previously stated.
ST agents generating too long ERROR messages, simply truncate the
PDUInError field to the point where the message is smaller than the
network MTU.
5.2 Timeout Failures
As described in Section 4.3, SCMP message delivery is made reliable
through the use of acknowledgments, timeouts, and retransmission. The
ACCEPT, CHANGE, CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY, and
REFUSE messages must always be acknowledged, see Section 4.2. In
addition, for some SCMP messages (CHANGE, CONNECT, JOIN) the sending
ST agent also expects a response back (ACCEPT/REFUSE, CONNECT/JOIN-
REJECT) after an ACK has been received. Also, the STATUS message must
be answered with a STATUS-RESPONSE message.
The following sections describe the handling of each of the possible
failure cases due to timeout situations while waiting for an
acknowledgment or a response. The timeout related variables, and
their names, used in the next sections are for reference purposes
only. They may be implementation specific. Different implementations
are not required to share variable names, or even the mechanism by
which the timeout and retransmission behavior is implemented.
5.2.1 Failure due to ACCEPT Acknowledgment Timeout
An ST agent that sends an ACCEPT message upstream expects an ACK from
the previous-hop ST agent. If no ACK is received before the ToAccept
timeout expires, the ST agent should retry and send the ACCEPT
message again. After NAccept unsuccessful retries, the ST agent sends
a REFUSE message toward the origin, and a DISCONNECT message toward
the targets. Both REFUSE and DISCONNECT must identify the affected
targets and specify the ReasonCode (RetransTimeout).
5.2.2 Failure due to CHANGE Acknowledgment Timeout
An ST agent that sends a CHANGE message downstream expects an ACK
from the next-hop ST agent. If no ACK is received before the ToChange
timeout expires, the ST agent should retry and send the CHANGE
message again. After NChange unsuccessful retries, the ST agent
aborts the change attempt by sending a REFUSE message toward the
origin, and a DISCONNECT message toward the targets. Both REFUSE and
DISCONNECT must identify the affected targets and specify the
ReasonCode (RetransTimeout).
5.2.3 Failure due to CHANGE Response Timeout
Only the origin ST agent implements this timeout. After correctly
receiving the ACK to a CHANGE message, an ST agent expects to receive
an ACCEPT, or REFUSE message in response. If one of these messages is
not received before the ToChangeResp timer expires, the ST agent at
the origin aborts the change attempt, and behaves as if a REFUSE
message with the E-bit set and with ReasonCode (ResponseTimeout) is
received.
5.2.4 Failure due to CONNECT Acknowledgment Timeout
An ST agent that sends a CONNECT message downstream expects an ACK
from the next-hop ST agent. If no ACK is received before the
ToConnect timeout expires, the ST agent should retry and send the
CONNECT message again. After NConnect unsuccessful retries, the ST
agent sends a REFUSE message toward the origin, and a DISCONNECT
message toward the targets. Both REFUSE and DISCONNECT must identify
the affected targets and specify the ReasonCode (RetransTimeout).
5.2.5 Failure due to CONNECT Response Timeout
Only the origin ST agent implements this timeout. After correctly
receiving the ACK to a CONNECT message, an ST agent expects to
receive an ACCEPT or REFUSE message in response. If one of these
messages is not received before the ToConnectResp timer expires, the
origin ST agent aborts the connection setup attempt, acts as if a
REFUSE message is received, and it sends a DISCONNECT message toward
the targets. Both REFUSE and DISCONNECT must identify the affected
targets and specify the ReasonCode (ResponseTimeout).
5.2.6 Failure due to DISCONNECT Acknowledgment Timeout
An ST agent that sends a DISCONNECT message downstream expects an ACK
from the next-hop ST agent. If no ACK is received before the
ToDisconnect timeout expires, the ST agent should retry and send the
DISCONNECT message again. After NDisconnect unsuccessful retries, the
ST agent simply gives up and it assumes the next-hop ST agent is not
part in the stream any more.
5.2.7 Failure due to JOIN Acknowledgment Timeout
An ST agent that sends a JOIN message toward the origin expects an
ACK from a neighbor ST agent. If no ACK is received before the ToJoin
timeout expires, the ST agent should retry and send the JOIN message
again. After NJoin unsuccessful retries, the ST agent sends a JOIN-
REJECT message back in the direction of the target with ReasonCode
(RetransTimeout).
5.2.8 Failure due to JOIN Response Timeout
Only the target agent implements this timeout. After correctly
receiving the ACK to a JOIN message, the ST agent at the target
expects to receive a CONNECT or JOIN-REJECT message in response. If
one of these message is not received before the ToJoinResp timer
expires, the ST agent aborts the stream join attempt and returns an
error corresponding with ReasonCode (RetransTimeout) to the
application.
Note that, after correctly receiving the ACK to a JOIN message,
intermediate ST agents do not maintain any state on the stream
joining attempt. As a consequence, they do not set the ToJoinResp
timer and do not wait for a CONNECT or JOIN-REJECT message. This is
described in Section 4.6.3.
5.2.9 Failure due to JOIN-REJECT Acknowledgment Timeout
An ST agent that sends a JOIN-REJECT message toward the target
expects an ACK from a neighbor ST agent. If no ACK is received before
the ToJoinReject timeout expires, the ST agent should retry and send