| 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.
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 = 16 |H|Q| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId/0 | SVLId/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 54. STATUS Control Message
4.2.3.17. STATUS-RESPONSE
STATUS-RESPONSE (OpCode = 17) is the reply to a STATUS
message. If the stream specified in the STATUS message is
not known, the STATUS-RESPONSE will contain the specified
HID and/or Name but no other parameters. It will otherwise
contain the current HID(s), Name, FlowSpec, TargetList, and
possibly Group of the stream. Note that if a stream has no
current HID, the H bit in the STATUS-RESPONSE will be zero.
The HID field will contain the first, or only, HID if a
valid HID exists; additional valid HIDs will be returned in
HID parameters.
H (bit 8) is used to indicate whether (when 1) or not
(when 0) a HID is present in the HID field.
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 = 17 |H|Q| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId/0 | SVLId/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Group Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! HID Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 55. STATUS-RESPONSE Control Message
4.3. Suggested Protocol Constants
The ST Protocol uses several fields that must have specific values
for the protocol to work, and also several values that an
implementation must select. This section specifies the required
values and suggests initial values for others. It is recommended
that the latter be implemented as variables so that they may be
easily changed when experience indicates better values.
Eventually, they should be managed via the normal network
management facilities.
ST uses IP Version Number 5.
When encapsulated in IP, ST uses IP Protocol Number 5.
Value ST Command Message Name Value ST Element Name
------- ----------------------- ------- ---------------------
1 ACCEPT 1 ErroredPDU
2 ACK 2 FlowSpec
3 CHANGE 3 FreeHIDs
4 CHANGE-REQUEST 4 Group
5 CONNECT 5 HID
6 DISCONNECT 6 MulticastAddress
7 ERROR-IN-REQUEST 7 Name
8 ERROR-IN-RESPONSE 8 NextHopIPAddress
9 HELLO 9 Origin
10 HID-APPROVE 10 OriginTimestamp
11 HID-CHANGE 11 RecordRoute
12 HID-CHANGE-REQUEST 12 RFlowSpec
13 HID-REJECT 13 RGroup
14 NOTIFY 14 RHID
15 REFUSE 15 RName
16 STATUS 16 SrcRoute, IP Loose
17 STATUS-RESPONSE 17 SrcRoute, IP Strict
18 SrcRoute, ST Loose
19 SrcRoute, ST Strict
20 TargetList
21 UserData
A good choice for the minimum number of bits in the FreeHIDBitMask
element of the FreeHIDs parameter is not yet known. We suggest a
minimum of 64 bits, i.e., N in Figure 25 has a value of two (2).
HID value zero (0) is reserved for ST Control Messages. HID
values 1-3 are reserved for future use.
VLId value zero (0) may only be used in the RVLId field of an ST
Control Message when the appropriate value has not yet been
received from the other end of the virtual link;' except for an
ERROR-IN-REQUEST or diagnostic message, the SVLId field may never
contain a value of zero except in a diagnostic message. VLId
value 1 is reserved for use with HELLO messages by those agents
whose implementation wishes to have all HELLOs so identified.
VLId values 2-3 are reserved for future use.
The following permanent IP multicast addresses have been assigned
to ST:
224.0.0.7 All ST routers
224.0.0.8 All ST hosts
In addition, a block of transient IP multicast addresses,
224.1.0.0 - 224.1.255.255, has been allocated for ST multicast
groups. Note that in the case of Ethernet, an ST Multicast
address of 224.1.cc.dd maps to an Ethernet Multicast address of
01:00:5E:01:cc:dd (see [6]).
SCMP uses retransmission to effect reliability and thus has
several "retransmission timers". Each "timer" is modeled by an
initial time interval (ToXxx), which gets updated dynamically
through measurement of control traffic, and a number of times
(NXxx) to retransmit a message before declaring a failure. All
time intervals are in units of milliseconds.
Value Timeout Name Meaning
------- ---------------------- ----------------------------------
1000 ToAccept Initial hop-by-hop timeout for
acknowledgment of ACCEPT
3 NAccept ACCEPT retries before failure
1000 ToConnect Initial hop-by-hop timeout for
acknowledgment of CONNECT
5 NConnect CONNECT retries before failure
1000 ToDisconnect Initial hop-by-hop timeout for
acknowledgment of DISCONNECT
3 NDisconnect DISCONNECT retries before
failure
Value Timeout Name Meaning
------- ---------------------- ----------------------------------
1000 ToHIDAck Initial hop-by-hop timeout for
acknowledgment of
HID-CHANGE-REQUEST
3 NHIDAck HID-CHANGE-REQUEST retries
before failure
1000 ToHIDChange Initial hop-by-hop timeout for
acknowledgment of HID-CHANGE
3 NHIDChange HID-CHANGE retries before
failure
1000 ToNotify Initial hop-by-hop timeout for
acknowledgment of NOTIFY
3 NNotify NOTIFY retries before failure
1000 ToRefuse Initial hop-by-hop timeout for
acknowledgment of REFUSE
3 NRefuse REFUSE retries before failure
1000 ToReroute Timeout for receipt of ACCEPT or
REFUSE from targets during
failure recovery
5 NReroute CONNECT retries before failure
5000 ToEnd2End End-to-End timeout for receipt
of ACCEPT or REFUSE from targets
by origin
0 NEnd2End CONNECT retries before failure
Value Parameter Name Meaning
------- ---------------------- ----------------------------------
10 NHIDAbort Number of rejected HID proposals
before aborting the HID
negotiation process
10000 HelloTimerHoldDown Interval that Restarted bit must
be set after ST restart
5 HelloLossFactor Number of consecutively missed
HELLO messages before declaring
link failure
2000 DefaultRecoveryTimeout Interval between successive
HELLOs to/from active neighbors
2 DefaultHelloFactor HELLO filtering function factor
5. Areas Not Addressed
There are a number of issues that will need to be addressed in the
long run but are not addressed here. Some issues are network or
implementation specific. For example, the management of multicast
groups depends on the interface that a network provides to the ST
agent, and an UP/DOWN protocol based on ST HELLO messages depends on
the details of the ST agents. Both these examples may impact the ST
implementations, but we feel it is inappropriate to specify them
here.
In other cases we feel that appropriate solutions are not clear at
this time. The following are examples of such issues:
This document does not include a routing mechanism. We do not feel
that a routing strategy based on minimizing the number of hops from
the source to the destination is necessarily appropriate. An
alternative strategy is to minimize the consumption of internet
resources within some delay constraints. Furthermore, it would be
preferable if the routing function were to provide routes that
incorporated bandwidth, delay, reliability, and perhaps other
characteristics, not just connectivity. This would increase the
likelihood that a selected route would succeed. This requirement
would probably cause the ST agents to exchange more routing
information than currently implemented. We feel that further
research and experimentation will be required before an appropriate
routing strategy is well enough defined to be incorporated into the
ST specification.
Once the bandwidth for a stream has been agreed upon, it is not
sufficient to rely on the origin to transmit traffic at that rate.
The internet should not rely on the origin to operate properly.
Furthermore, even if the origin sources traffic at the agreed rate,
the packets may become aggregated unintentionally and cause local
congestion. There are several approaches to addressing this problem,
such as metering the traffic in each stream as it passes through each
agent. Experimentation is necessary before such a mechanism is
selected.
The interface between the agent and the network is very limited. A
mechanism is provided by which the ST layer can query the network to
determine the likelihood that a stream can be supported. However,
this facility will require practical experience before its
appropriate use is defined.
The simplex tree model of a stream does not easily allow for using
multiple paths to support a greater bandwidth. That is, at any given
point in a stream, the entire incoming bandwidth must be transmitted
to the same next-hop in order to get to some target. If the
bandwidth isn't available along any single path, the stream cannot be
built to that target. It may be the case that the bandwidth is not
available along a single path, but if the data
flow is split along multiple paths, and so multiple next-hops,
sufficient bandwidth would be available. As currently specified, the
ST agent at the point where the multiple flows converge will refuse
the second connection because it can only be interpreted as a routing
failure. A mechanism that allows multiple paths in a stream and can
protect against routing failures has not been defined.
If sufficient bandwidth is not available, both preemption and
rerouting are possible. However, it is not clear when to use one or
the other. As currently specified, an ST agent that cannot obtain
sufficient bandwidth will attempt to preempt lower precedence streams
before attempting to reroute around the bottleneck. This may lead to
an undesirably high number of preemptions. It may be that a higher
precedence stream can be rerouted around lower precedence streams and
still meet its performance requirements, whereas the preempted lower
precedence streams cannot be reconstructed and still meet their
performance requirements. A simple and effective algorithm to allow
a better decision has not been identified.
In case a stream cannot be completed, ST does not report to the
application the nature of the trouble in any great detail.
Specifically, the application cannot determine where the bottleneck
is, whether the problem is permanent or transitory, or the likely
time before the trouble may be resolved. The application can only
attempt to build the stream at some later time hoping that the
trouble has been resolved. Schemes can be envisioned by which
information is relayed back to the application. However, only
practical experience can evaluate the kind of trouble that is most
likely encountered and the nature of information that would be most
useful to the application.
A mechanism is also not defined for cases where a stream cannot be
completed not because of lack of resources but because of an
unexpected failure that results in an ERROR-IN-REQUEST message. An
ERROR-IN-REQUEST message is returned in cases when an ST agent issues
a malformed control message to a neighbor. Such an occurrence is
unexpected and may be caused by a bad or incomplete ST
implementation. In some cases a message, such as a NOTIFY should be
sent to the origin. Such a mechanism is not defined because it is
not clear what information can be extracted and what the origin
should do.
No special action is taken when a target is removed from a stream.
Removing a target may also remove a bottleneck either in bandwidth,
packet rate or packet size, but advantage of this opportunity is not
taken automatically. The application may initiate a change to the
stream's characteristics, but it is not in the best position to do
this because the application may not know the nature of the
bottleneck. The ST layer may have the best information, but a
mechanism to do this may be very complex. As a result, this concept
requires further thought.
An agent simply discards a stream's data packets if it cannot forward
them. The reason may be that the packets are too large or are
arriving at too high a rate. Alternative actions may include an
attempt to do something with the packets, such as fragmenting them,
or to notify the origin of the trouble. Corrective measures may be
too complex, so it may be preferable simply to notify the origin with
a NOTIFY message. However, if the incoming packet rate is causing
congestion, then the NOTIFY messages themselves may cause more
trouble. The nature of the communication has yet to be defined.
The FlowSpec includes a cost field, but its implementation has not
been identified. The units of cost can probably be defined
relatively easily. Cost of bandwidth can probably also be assigned.
It is not clear how cost is assigned to other functions, such as high
precedence or low delay, or how cost of the components of the stream
are combined together. It is clear that the cost to provide services
will become more important in the near future, but it is not clear at
this time how that cost is determined.
A number of parameters of the FlowSpec are intended to be used as
ranges, but some may be useful as discrete values. For example, the
FlowSpec may specify that bandwidth for a stream carrying voice
should be reserved in a range from 16Kbps to 64Kbps because the voice
codec has a variable coding rate. However, the voice codec may be
varied only among certain discrete values, such as 16Kbps, 32Kbps and
64Kbps. A stream that has 48Kbps of bandwidth is no better than one
with 32Kbps. The parameters of the FlowSpec where this may be
relevant should optionally specify discrete values. This is being
considered.
Groups are defined as a way to associate different streams, but the
nature of the association is left for further study. An example of
such an association is to allow streams whose traffic is inherently
not simultaneous to share the same allocated resources. This may
happen for example in a conference that has an explicit floor, such
that only one site can generate video or audio traffic at any given
time. The grouping facility can be implemented based on this
specification, but the implementation of the possible uses of groups
will require new functionality to be added to the ST agents. The
uses for groups and the implementation to support them will be
carried out as experience is gained and the need arises.
We hope that the ST we here propose will act as a vehicle to study
the use and performance of stream oriented services across packet
switched networks.
[This page intentionally left blank.]
6. Glossary
appropriate reason code
This phrase refers to one or perhaps a set of reason codes that
indicate why a particular action is being taken. Typically,
these result from detection of errors or anomalous conditions.
It can also indicate that an application component or agent has
presented invalid parameters.
DefaultRecoveryTimeout
The DefaultRecoveryTimeout is maintained by each ST agent. It
indicates the default time interval to use for sending HELLO
messages.
downstream
The direction in a stream from an origin toward its targets.
element
The fields and parameters of the ST control messages are
collectively called elements.
FlowSpec
The Flow Specification, abbreviated "FlowSpec" is used by an
application to specify required and desired characteristics of
the stream. The FlowSpec specifies bandwidth, delay, and
reliability parameters. Both minimal requirements and desired
characteristics are included. This information is then used to
guide route selection and resource allocation decisions. The
desired vs. required characteristics are used to guide tradeoff
decisions among competing stream requests.
group
A set of related streams can be associated as a group. This is
done by generating a Group Name and assigning it to each of the
related streams. The grouping information can then be used by
the ST agents in making resource management and other control
decisions. For example, when preemption is necessary to
establish a high precedence stream, we can exploit the group
information to minimize the number of stream groups that are
preempted.
Group Name
The Group Name is used to indicate that a collection of streams
are related. A Group Name is structured to ensure that it is
unique across all hosts: it includes the address of the host
where it was generated combined with a unique number generated
by that host. A timestamp is added to ensure that the overall
name is unique over all time. (A Group Name has the same format
as a stream Name.)
HelloLossFactor
The HelloLossFactor is a parameter maintained by each ST agent.
It identifies the expected number of consecutive HELLO messages
typically lost due to transient factors. Thus, an agent will be
assumed to be down after we miss more than HelloLossFactor
messages.
HelloTimer
The HelloTimer is a millisecond timer maintained by each ST
agent. It is included in each HELLO message. It represents the
time since the agent was restarted, modulo the precision of the
field. It is used to detect variations in the delay between the
two agents, by comparing the arrival interval of two HELLO
messages to the difference between their HelloTimer fields.
HelloTimerHoldDown
The HelloTimerHoldDown value is maintained by each ST agent.
When an ST agent is restarted, it will set the "Restarted" bit
in all HELLO messages it sends for HelloTimerHoldDown seconds.
HID
The Hop IDentifier, abbreviated as HID, is a numeric key stored
in the header of each ST packet. It is used by an ST agent to
associate the packet with one of the incoming hops managed by
the agent. It can be used by receiving agent to map to
the set of outgoing next-hops to which the message should be
forwarded. The HID field of an ST packet will generally need to
be changed as it passes through each ST agent since there may be
many HIDs associated with a single stream.
hop
A "hop" refers to the portion of a stream's path between two
neighbor ST agents. It is usually represented by a physical
network. However, a multicast hop can connect a single ST agent
to several next-hop ST agents.
host agents
Synonym for host ST agents.
host ST agents
Host ST agents are ST agents that provide services to higher
layer protocols and applications. The services include methods
for sourcing data from and sinking data to the higher layer or
application, and methods for requesting and modifying streams.
intermediate agents
Synonym for intermediate ST agents.
intermediate ST agents
Intermediate ST agents are ST agents that can forward ST
packets between the networks to which they are attached.
MTU
The abbreviation for Maximum Transmission Unit, which is the
maximum packet size in bytes that can be accepted by a given
network for transmission. ST agents determine the maximum
packet size for a stream so that data written to the stream can
be forwarded through the networks without fragmentation.
multi-destination simplex
The topology and data flow of ST streams are described as being
multi-destination simplex: all data flowing on the stream
originates from a single origin and is passed to one or more
destination targets. Only control information, invisible to the
application program, ever passes in the upstream direction.
NAccept
NAccept is an integer parameter maintained by each ST agent. It
is used to control retransmission of an ACCEPT message. Since
an ACCEPT request is relayed by agents back toward the origin,
it must be acknowledged by each previous-hop agent. If this ACK
is not received within the appropriate timeout interval, the
request will be resent up to NAccept times before giving up.
Name
Generally refers to the name of a stream. A stream Name is
structured to ensure that it is unique across all hosts: it
includes the address of the host where it was generated combined
with a unique number generated at that host. A timestamp is
added to ensure that the overall Name is unique over all time.
(A stream Name has the same format as a Group Name.)
NConnect
NConnect is an integer parameter maintained by each ST agent.
It is used to control retransmission of a CONNECT message. A
CONNECT request must be acknowledged by each next-hop agent as
it is propagated toward the targets. If a HID-ACCEPT,
HID-REJECT, or ACK is not received for the CONNECT between any
two agents within the appropriate timeout interval, the request
will be resent up to NConnect times before giving up.
NDisconnect
NDisconnect is an integer parameter maintained by each ST
agent. It is used to control retransmission of a DISCONNECT
message. A DISCONNECT request must be acknowledged by each
next-hop agent as it is propagated toward the targets. If this
ACK is not received for the DISCONNECT between any two agents
within the appropriate timeout interval, the request will be
resent up to NDisconnect times before giving up.
next protocol identifier
The next protocol identifier is used by a target ST agent to
identify to which of several higher layer protocols it should
pass data packets it receives the network. Examples of higher
layer protocols include the Network Voice Protocol and the
Packet Video Protocol. These higher layer protocols will
typically perform further demultiplexing among multiple
application processes as part of their protocol processing
activities.
next-hop
Synonym for next-hop ST agent.
next-hop ST agent
For each origin or intermediate ST agent managing a stream
there are a set of next-hop ST agents. The intermediate agent
forwards each data packet it receives to all the next-hop ST
agents, which in turn forward the data toward the target host
agent (if the particular next-hop agent is another intermediate
agent) or to the next higher protocol layer at the target (if
the particular next-hop agent is a host agent).
NextPcol
NextPcol is a field in each Target of the CONNECT message used
to convey the next protocol identifier. See definition of next
protocol identifier above for more details.
NHIDAbort
NHIDAbort is an integer parameter maintained by each ST agent.
It is the number of unacceptable HID proposals before an ST
agent aborts the HID negotiation process.
NHIDAck
NHIDAck is an integer parameter maintained by each ST agent.
It is used to control retransmission of HID-CHANGE-REQUEST
messages. HID-CHANGE-REQUEST is sent by an ST agent to the
previous-hop ST agent to request that the HID in use between
those agents be changed. The previous-hop acknowledges the
HID-CHANGE-REQUEST message by sending a HID-CHANGE message. If
the HID-CHANGE is not received within the appropriate timeout
interval, the request will be resent up to NHIDAck times before
giving up.
NHIDChange
NHIDChange is an integer parameter maintained by each ST agent.
It is used to control retransmission of the HID-CHANGE message.
A HID-CHANGE message must be acknowledged by the next-hop agent.
If this ACK is not received within the appropriate timeout
interval, the request will be resent up to NHIDChange times
before giving up.
NRefuse
NRefuse is an integer parameter maintained by each ST agent.
It is used to control retransmission of a REFUSE message. As a
REFUSE request is relayed by agents back toward the origin, it
must be acknowledged by each previous-hop agent. If this ACK is
not received within the appropriate timeout interval, the
request will be resent up to NRefuse times before giving up.
NRetryRoute
NRetryRoute is an integer parameter maintained by each ST
agent. It is used to control route exploration. When an agent
receives a REFUSE message whose ReasonCode indicates that the
originally selected route is not acceptable, the agent should
attempt to find an alternate route to the target. If the agent
has not found a viable route after a maximum of NRetryRoute
choices, it should give up and notify the previous-hop or
application that it cannot find an acceptable path to the
target.
origin
The origin of a stream is the host agent where an application
or higher level protocol originally requested that the stream be
created. The origin specifies the data to be sent through the
stream.
parameter
Parameters are additional values that may be included in
control messages. Parameters are often optional. They are
distinguished from fields, which are always present.
participants
Participants are the end-users of a stream.
PDU
Abbreviation for Protocol Data Unit, defined below.
peer
The term peer is used to refer to entities at the same protocol
layer. It is used here to identify instances of an application
or protocol layer above ST. For example, data is passed through
a stream from an originating peer process to its target peers.
previous-hop
Synonym for previous-hop ST agent.
previous-hop ST agent
The origin or intermediate agent from which an ST agent receives
its data.
protocol data unit
A protocol data unit (PDU) is the unit of data passed to a
protocol layer by the next higher layer protocol or user. It
consists of control information and possibly user data.
RecoveryTimeout
RecoveryTimeout is specified in the FlowSpec of each stream.
The minimum of these values over all streams between a pair of
adjacent agents determines how often those agents must send
HELLO messages to each other in order to ensure that failure of
one of the agents will be detected quickly enough to meet the
guarantee implied by the FlowSpec.
Restarted bit
The Restarted bit is part of the HELLO message. When set, it
indicates that the sending agent was restarted recently (within
the last HelloTimerHoldDown seconds).
round-trip time
The round-trip-time is the time it takes a message to be sent,
delivered, processed, and the acknowledgment received. It
includes both network and processing delays.
RTT
Abbreviation for round-trip-time.
RVLId
Abbreviation for Receiver's Virtual Link Identifier. It
uniquely identifies to the receiver the virtual link, and this
stream, used to send it a message. See definition for Virtual
Link Identifier below.
SAP
Abbreviation for Service Access Point.
SCMP
Abbreviation for ST Control Message Protocol, defined below.
Service Access Point
A point where a protocol service provider makes available the
services it offers to a next higher layer protocol or user.
setup phase
Before data can be transmitted through a stream, the ST agents
must distribute state information about the stream to all agents
along the path(s) to the target(s). This is the setup phase.
The setup phase ends when all the ACCEPT and REFUSE messages
sent by the targets have been delivered to the origin. At this
point, the data transfer phase begins and data can be sent.
Requests to modify the stream can be issued after the setup
phase has ended, i.e., during the data transfer phase without
disrupting the flow of data.
ST agent
An ST agent is an entity that implements the ST Protocol.
ST Control Message Protocol
The ST Control Message Protocol is the subset of the overall ST
Protocol responsible for creation, modification, maintenance,
and tear down of a stream. It also includes support for event
notification and status monitoring.
stream
A stream is the basic object managed by the ST Protocol for
transmission of data. A stream has one origin where data are
generated and one or more targets where the data are received
for processing. A flow specification, provided by the origin
and negotiated among the origin, intermediate, and target ST
agents, identifies the requirements of the application and the
guarantees that can be assured by the ST agents.
subsets
Subsets of the ST Protocol are permitted, as defined in various
sections of this specification. Subsets are defined to allow
simplified implementations that can still effectively
interoperate with more complete implementations without causing
disruption.
SVLId
Abbreviation for Sender's Virtual Link Identifier. It uniquely
identifies to the receiver the virtual link identifier that
should be placed into the RVLId field of all replies sent over
the virtual link for a given stream. See definition for Virtual
Link Identifier below.
target
An ST target is the destination where data supplied by the
origin will be delivered for higher layer protocol or
application processing.
tear down
The tear down phase of a stream begins when the origin indicates
that it has no further data to send and the ST agents through
which the stream passes should dismantle the stream and release
its resources.
ToAccept
ToAccept is a timeout in seconds maintained by each ST agent.
It sets the retransmission interval for ACCEPT messages.
ToConnect
ToConnect is a timeout in seconds maintained by each ST agent.
It sets the retransmission interval a CONNECT messages.
ToDisconnect
ToDisconnect is a timeout in seconds maintained by each ST
agent. It sets the retransmission interval for DISCONNECT
messages.
ToHIDAck
ToHIDAck is a timeout in seconds maintained by each ST agent.
It sets the retransmission interval for HID-CHANGE-REQUEST
messages.
ToHIDChange
ToHIDChange is a timeout in seconds maintained by each ST agent.
It sets the retransmission interval for HID-CHANGE messages.
ToRefuse
ToRefuse is a timeout in seconds maintained by each ST agent.
It sets the retransmission interval for REFUSE messages.
upstream
The direction in a stream from a target toward the origin.
Virtual Link
A virtual link is one edge of the tree describing the path of
data flow through a stream. A separate virtual link is assigned
to each pair of neighbor ST agents, even when multiple next-hops
are be reached through a single network level multicast group.
The virtual link allows efficient demultiplexing of ST Control
Message PDUs received from a single physical link or network.
Virtual Link Identifier
For each ST Control Message sent, the sender provides its own
virtual link identifier and that of the receiver (if known).
Either of these identifiers, combined with the address of the
corresponding host, can be used to identify uniquely the virtual
control link to the agent. However, virtual link identifiers
are chosen by the associated agent so that the agent may
precisely identify the stream, state machine, and other protocol
processing data elements managed by that agent, without regard
to the source of the control message. Virtual link identifiers
are not negotiated, and do not change during the lifetime of a
stream. They are discarded when the stream is torn down.
7. References
[1] Braden, B., Borman, D., and C. Partridge, "Computing the
Internet Checksum", RFC1071, USC/Information Sciences
Institute, Cray Research, BBN Laboratories, September
1988.
[2] Braden, R. (ed.), "Requirements for Internet Hosts --
Communication Layers", RFC1122, USC/Information Sciences
Institute, October 1989.
[3] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
Specification", RFC1045, Stanford University, February 1988.
[4] Cohen, D., "A Network Voice Protocol NVP-II", USC/Information
Sciences Institute, April 1981.
[5] Cole, E., "PVP - A Packet Video Protocol", W-Note 28,
USC/Information Sciences Institute, August 1981.
[6] Deering, S., "Host Extensions for IP Multicasting", RFC1112,
Stanford University, August 1989.
[7] Edmond W., Seo K., Leib M., and C. Topolcic, "The DARPA
Wideband Network Dual Bus Protocol", accepted for presentation
at ACM SIGCOMM '90, September 24-27, 1990.
[8] Forgie, J., "ST - A Proposed Internet Stream Protocol",
IEN 119, M. I. T. Lincoln Laboratory, 7 September 1979.
[9] Jacobs I., Binder R., and E. Hoversten E., "General Purpose
Packet Satellite Network", Proc. IEEE, vol 66, pp 1448-1467,
November 1978.
[10] Jacobson, V., "Congestion Avoidance and Control", ACM
SIGCOMM-88, August 1988.
[11] Karn, P. and C. Partridge, "Round Trip Time Estimation",
ACM SIGCOMM-87, August 1987.
[12] Mallory, T., and A. Kullberg, "Incremental Updating of the
Internet Checksum", RFC1141, BBN Communications
Corporation, January 1990.
[13] Mills, D., "Network Time Protocol (Version 2) Specification
and Implementation", RFC1119, University of Delaware,
September 1989 (Revised February 1990).
[14] Pope, A., "The SIMNET Network and Protocols", BBN
Report No. 7102, BBN Systems and Technologies, July 1989.
[15] Postel, J., ed., "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC791, DARPA, September 1981.
[16] Postel, J., ed., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", RFC793, DARPA,
September 1981.
[17] Postel, J., "User Datagram Protocol", RFC768,
USC/Information Sciences Institute, August 1980.
[18] Reynolds, J., Postel, J., "Assigned Numbers", RFC1060,
USC/Information Sciences Institute, March 1990.
[19] SDNS Protocol and Signaling Working Group, SP3 Sub-Group,
SDNS Secure Data Network System, Security Protocol 3 (SP3),
SDN.301, Rev. 1.5, 1989-05-15.
[20] SDNS Protocol and Signaling Working Group, SP3 Sub-Group,
SDNS Secure Data Network System, Security Protocol 3 (SP3)
Addendum 1, Cooperating Families, SDN.301.1, Rev. 1.2,
1988-07-12.
8. Security Considerations
See section 3.7.8.
9. Authors' Addresses
Stephen Casner
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: (213) 822-1511 x153
EMail: Casner@ISI.Edu
Charles Lynn, Jr.
BBN Systems and Technologies,
a division of Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3367
EMail: CLynn@BBN.Com
Philippe Park
BBN Systems and Technologies,
a division of Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-2892
EMail: ppark@BBN.COM
Kenneth Schroder
BBN Systems and Technologies,
a division of Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3167
EMail: Schroder@BBN.Com
Claudio Topolcic
BBN Systems and Technologies,
a division of Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3874
EMail: Topolcic@BBN.Com
[This page intentionally left blank.]
Appendix 1. Data Notations
The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data with the most
significant octet on the left and the least significant octet on the
right.
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows a
group of octets, the order of transmission of those octets is the
normal order in which they are read in English. For example, in the
following diagram the octets are transmitted in the order they are
numbered.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 56. Transmission Order of Bytes
Whenever an octet represents a numeric quantity the left most bit in
the diagram is the high order or most significant bit. That is, the
bit labeled 0 is the most significant bit. For example, the
following diagram represents the value 170 (decimal).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Figure 57. Significance of Bits
Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit.
When a multi-octet quantity is transmitted the most significant octet
is transmitted first.
Fields whose length is fixed and fully illustrated are shown with a
vertical bar (|) at the end; fixed fields whose contents are
abbreviated are shown with an exclamation point (!); variable fields
are shown with colons (:).
Optional parameters are separated from control messages with a blank
line. The order of any optional parameters is not meaningful.