attached networks; an ST host is an ST agent that is
connected to a single network or is not permitted to pass
traffic between attached networks. Note that the range of
these multicasts is normally just the attached local
network, limited by setting the IP time-to-live field to 1
(see [6]).
3.7.6. Retransmission
The ST Control Message Protocol is made reliable through use of
retransmission when an expected acknowledgment is not received
in a timely manner. The problem of when to send a
retransmission has been studied for protocols such as TCP [2]
[10] [11]. The problem should be simpler for ST since control
messages usually only have to travel a single hop and they do
not contain very much data. However, the algorithms developed
for TCP are sufficiently simple that their use is recommended
for ST as well; see [2]. An implementor might, for example,
choose to keep statistics separately for each
neighboring ST agent, or combined into a single statistic for
an attached network.
Estimating the packet round-trip time (RTT) is a key function
in reliable transport protocols such as TCP. Estimation must
be dynamic, since congestion and resource contention result in
varying delays. If RTT estimates are too low, packets will be
retransmitted too frequently, wasting network capacity. If RTT
estimates are too high, retransmissions will be delayed
reducing network throughput when transmission errors occur.
Article [11] identifies problems that arise when RTT estimates
are poor, outlines how RTT is used and how retransmission
timeouts (RTO) are estimated, and surveys several ways that RTT
and RTO estimates can be improved.
Note the HELLO/ACK mechanism described in Section 3.7.1.2 (page
49) can give an estimate of the RTT and its variance. These
estimates are also important for use with the delay and delay
variance entries in the FlowSpec.
3.7.7. Routing
ST requires access to routing information in order to select a
path from an origin to the destination(s). However, routing is
considered to be a separate issue and neither the routing
algorithm nor its implementation is specified here. ST should
operate equally well with any reasonable routing algorithm.
While ST may be capable of using several types of information
that are not currently available, the minimal information
required is that provided by IP, namely the ability to find an
interface and next hop router for a specified IP destination
address and Type of Service. Methods to make more information
available and to use it are left for further study. For
initial ST implementations, any routing information that is
required but not automatically provided will be assumed to be
manually configured into the ST agents.
3.7.8. Security
The ST Protocol by itself does not provide security services.
It is more vulnerable to misdelivery and denial of service than
IP since the ST Header only carries a 16-bit HID for
identification purposes. Any information, such as source and
destination addresses, which a higher-layer protocol might use
to detect misdelivery are the responsibility of either the
application or higher-layer protocol.
ST is less prone to traffic analysis than IP since the only
identifying information contained in the ST Header is a hop-
by-hop identifier (HID). However, the use of a HID is also
what makes ST more vulnerable to denial of service since an ST
agent has no reliable way to detect when bogus traffic is
injected into, and thus consumes bandwidth from, a user's
stream. Detection can be enhanced through use of per-interface
forwarding tables and verification of local network source and
destination addresses.
We envision that applications that require security services
will use facilities, such as the Secure Digital Networking
System (SDNS) layer 3 Security Protocol (SP3/D) [19] [20]. In
such an environment, ST PDUs would first be encapsulated in an
IP Header, using IP Protocol 5 (ST) as described in Section
3.7.5 (page 64). These IP datagrams would then be secured
using SP3/D, which results in another IP Protocol 5 PDU that
can be passed between ST agents.
This memo does not specify how an application invokes security
services.
3.8. ST Service Interfaces
ST has several interfaces to other modules in a communication
system. ST provides its services to applications or transport-
level protocols through its "upper" interface (or SAP). ST in
turn uses the services provided by network layers, management
functions (e.g., address translation and routing), and IP. The
interfaces to these modules are described in this section in the
form of subroutine calls. Note that this does not mean that an
implementation must actually be implemented as subroutines, but is
instead intended to identify the information to be passed between
the modules.
In this style of outlining the module interfaces, the information
passed into a module is shown as arguments to the subroutine call.
Return information and/or success/failure indications are listed
after the arrow ("->") that follows the subroutine call. In
several cases, a list of values must either be passed to or
returned from a module interface. Examples include a set of
target addresses, or the mappings from a target list to a set of
next hop addresses that span the route to the originally listed
targets. When such a list is appropriate, the values repeated for
each list element are bracketed and an asterisk is added to
indicate that zero, one, or many list elements can be passed
across the interface (e.g., "<target>*" means zero, one, or more
targets).
3.8.1. Access to Routing Information
The design of routing functions that can support a variety of
resource management algorithms is difficult. In this section
we suggest a set of preliminary interfaces suitable for use in
initial experiments. We expect that these interfaces will
change as we gain more insight into how routing, resource
allocation, and decision making elements are best divided.
Routing functions are required to identify the set of potential
routes to each destination site. The routing functions should
make some effort to identify routes that are currently
available and that meet the resource requirements. However,
these properties need not be confirmed until the actual
resource allocation and connection setup propagation are
performed.
The minimum capability required of the interface to routing is
to identify the network interface and next hop toward a given
target. We expect that the traditional routing table will need
to be extended to include information that ST requires such as
whether or not a next hop supports ST, and, if so, whether or
not IP encapsulation (see Section 3.7.5 (page 64)) is required
to communicate with it. In particular, host entries will be
required for hosts that can only support ST through
encapsulation because the IP software either is not capable of
demultiplexing datagrams based on the IP Version Number field,
or the application interface only supports access to raw IP
datagrams. This interface is illustrated by the function:
FindNextHop( destination, TOS )
-> result, < interface, next hop, ST-capable,
MustEncapsulate >*
However, the resource management functions can best tradeoff
among alternative routes when presented with a matrix of all
potential routes. The matrix entry corresponding to a
destination and a next hop would contain the estimated
characteristics of the corresponding pathway. Using this
representation, the resource management functions can quickly
determine the next hop sets that cover the entire destination
list, and compare the various parameters of the tradeoff
between the guarantees that can be promised by each set. An
interface that returns a compressed matrix, listing the
suitable routes by next hop and the destinations reachable
through each, is illustrated by the function:
FindNextHops( < destination >*, TOS )
-> result, < destination, < interface, next hop,
ST-capable, MustEncapsulate >* >*
We hope that routing protocols will be available that propagate
additional metrics of bandwidth, delay, bit/burst error rate,
and whether a router has ST capability. However, propagating
this information in a timely fashion is still a key research
issue.
3.8.2. Access to Network Layer Resource Reservation
The resources required to reach the next-hops associated with
the chosen routes must be allocated. These allocations will
generally be requested and released incrementally. As the
next-hop elements for the routes are chosen, the network
resources between the current node and the next-hops must be
allocated. Since the resources are not guaranteed to be
available -- a network or node further down the path might have
failed or needed resources might have been allocated since the
routing decisions where made -- some of these allocations may
have to be released, another route selected, and a new
allocation requested.
There are four basic interface functions needed for the network
resource allocator. The first checks to see if the required
resources are available, returning the likelihood that an
ensuing resource allocation will succeed. A probability of 0%
indicates the resources are not available or cannot promise to
meet the required guarantees. Low probabilities indicate that
most of the resource has been allocated or that there is a lot
of contention for using the resource. This call does not
actually reserve the resources:
ResourceProbe( requirements )
-> likelihood
Another call reserves the resources:
ResourceReserve( requirements )
-> result, reservation_id
The third call adjusts the resource guarantees:
ResourceAdjust( reservation_id, new requirements )
-> result
The final call allows the resources to be released:
ResourceRelease( reservation_id )
-> result
3.8.3. Network Layer Services Utilized
ST requires access to the usual network layer functions to send
and receive packets and to be informed of network status
information. In addition, it requires functions to enable and
disable reception of multicast packets. Such functions might
be defined as:
JoinLocalGroup( network level group-address )
-> result, multicast_id
LeaveLocalGroup( network level group-address )
-> result
RecvNet( SAP )
-> result, src, dst, len, BufPTR )
SendNet( src, dst, SAP, len, BufPTR )
-> result
GetNotification( SAP )
-> result, infop
3.8.4. IP Services Utilized
Since ST packets might be sent or received using IP
encapsulation, IP level routines to join and leave multicast
groups are required in addition to the usual services defined
in the IP specification (see the IP specification [2] [15] and
the IP multicast specification [6] for details).
JoinHostGroup( IP level group-address, interface )
-> result, multicast_id
LeaveHostGroup( IP level group-address, interface )
-> result
GET_SRCADDR( remote IP addr, TOS )
-> local IP address
SEND( src, dst, prot, TOS, TTL, BufPTR, len, Id, DF,
opt )
-> result
RECV( BufPTR, prot )
-> result, src, dst, SpecDest, TOS, len, opt
GET_MAXSIZES( local, remote, TOS )
-> MMS_R, MMS_S
ADVISE_DELIVPROB( problem, local, remote, TOS )
-> result
SEND_ICMP( src, dst, TOS, TTL, BufPTR, len, Id, DF, opt )
-> result
RECV_ICMP( BufPTR )
-> result, src, dst, len, opt
3.8.5. ST Layer Services Provided
Interface to the ST layer services may be modeled using a set
of subroutine calls (but need not be implemented as such).
When the protocol is implemented as part of an operating
system, these subroutines may be used directly by a higher
level protocol processing layer.
These subroutines might also be provided through system service
calls to provide a raw interface for use by an application.
Often, this will require further adaptation to conform with the
idiom of the particular operating system. For example, 4.3 BSD
UNIX (TM) provides sockets, ioctls and signals for network
programming.
open( connect/listen, SAPBytes, local SAP, local host,
account, authentication info, < foreign host,
SAPBytes, foreign SAP, options >*, flow spec,
precedence, group name, optional parameters )
-> result, id, stream name, < foreign host,
foreign SAPBytes, foreign SAP, result, flow spec,
rname, optional parameters >*
Note that an open by a target in "listen mode" may cause ST to
create a state block for the stream to facilitate rendezvous.
add( id, SAPBytes, local SAP, local host, < foreign host,
SAPBytes, foreign SAP, options >*, flow spec,
precedence, group name, optional parameters )
-> result, < foreign host, foreign SAPBytes,
foreign SAP, result,
flow spec, rname, optional parameters >*
send( id, buffer address, byte count, priority )
-> result, next send time, burst send time
recv( id, buffer address, max byte count )
-> result, byte count
recvsignal( id )
-> result, signal, info
receivecontrol( id )
-> result, id, stream name, < foreign host,
foreign SAPBytes, foreign SAP, result, flow spec,
rname, optional parameters >*
sendcontrol( id, flow spec, precedence, options,
< foreign host, SAPBytes, foreign SAP, options >*)
-> result, < foreign host, foreign SAPBytes,
foreign SAP, result, flow spec, rname,
optional parameters >*
change( id, flow spec, precedence, options,
< foreign host, SAPBytes, foreign SAP, options >*)
-> result, < foreign host, foreign SAPBytes,
foreign SAP, result, flow spec, rname,
optional parameters >*
close( id, < foreign host, SAPBytes, foreign SAP >*,
optional parameters )
-> result
status( id/stream name/group name )
-> result, account, group name, protocol,
< stream name, < foreign host, SAPbytes,
foreign SAP, state, options, flow spec,
routing info, rname >*, precedence, options >*
creategroup( members* )
-> result, group name
deletegroup( group name, members* )
-> result
[This page intentionally left blank.]
4. ST Protocol Data Unit Descriptions
The ST PDUs sent between ST agents consist of an ST Header
ncapsulating either a higher layer PDU or an ST Control Message.
Since ST operates as an extension of IP, the packet arrives at the
same network service access point that IP uses to receive IP
datagrams, e.g., ST would use the same ethertype (0x800) as does IP.
The two types of packets are distinguished by the IP Version Number
field (the first four bits of the packet); IP currently uses a value
of 4, while ST has been assigned the value 5 [18]. There is no
requirement for compatibility between IP and ST packet headers beyond
the first four bits.
The ST Header also includes an ST Version Number, a total length
field, a header checksum, and a HID, as shown in Figure 21. See
Appendix 1 (page 147) for an explanation of the notation.
ST is the IP Version Number assigned to identify ST packets. The
value for ST is 5.
Ver is the ST Version Number. This document defines ST Version 2.
Pri is the priority of the packet. It is used in data packets to
indicate those packets to drop if a stream is exceeding its
allocation. Zero is the lowest priority and 7 the highest.
T (bit 11) is used to indicate that a Timestamp is present
following the ST Header but before any next higher layer protocol
data. The Timestamp is not permitted on ST Control Messages
(which may use the OriginTimestamp option).
Bits 12 through 15 are spares and should be set to 0.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ST=5 | Ver=2 | Pri |T| Bits | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HID | HeaderChecksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Timestamp -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21. ST Header
TotalBytes is the length, in bytes, of the entire ST packet, it
includes the ST Header and optional Timestamp but does not include
any local network headers or trailers. In general, all length
fields in the ST Protocol are in units of bytes.
HID is the 16-bit hop-by-hop stream identifier. It is an
abbreviation for the Name of the stream and is used both to reduce
the packet header length and, by the receiver of the data packet,
to make the forwarding function more efficient. Control Messages
have a HID value of zero. HIDs are negotiated by the next-hop and
previous-hop agents to make the abbreviation unique. It is used
here in the ST Header and in various Control Messages. HID values
1-3 are reserved for future use.
HeaderChecksum covers only the ST Header and Timestamp, if
present. The ST Protocol uses 16-bit checksums here in the ST
Header and in each Control Message. The standard Internet
checksum algorithm is used: "The checksum field is the 16-bit
one's complement of the one's complement sum of all 16-bit words
in the header. For purposes of computing the checksum, the value
of the checksum field is zero." See [1] [12] [15] for suggestions
for efficient checksum algorithms.
Timestamp is an optional timestamp inserted into data packets by
the origin. It is only present when the T bit, described above,
is set (1). Its use is negotiated at connection setup time; see
Sections 4.2.3.5 (page 108) and 4.2.3.1 (page 100). The Timestamp
has the NTP format; see [13].
4.1. Data Packets
ST packets whose HID is not zero to three are user data packets.
Their interpretation is a matter for the higher layer protocols
and consequently is not specified here. The data packets are not
protected by an ST checksum and will be delivered to the higher
layer protocol even with errors.
ST agents will not pass data packets over a new hop whose setup is
not complete, i.e., a HID must have been negotiated and either an
ACCEPT or REFUSE has been received for all targets specified in
the CONNECT.
4.2. ST Control Message Protocol Descriptions
ST Control Messages are between a previous-hop agent and its
next-hop agent(s) using a HID of zero. The control protocol
follows a request-response model with all requests expecting
responses. Retransmission after timeout (see Section 3.7.6 (page
66)) 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
(usually a TargetList) is partitioned and a control message per
partition is sent. All control messages have the following
format:
OpCode identifies the type of control message. Each is
described in detail in following sections.
Options is used to convey OpCode-specific variations for a
control message.
TotalBytes is the length of the control message, in bytes,
including all OpCode specific fields and optional parameters.
The value is always divisible by four.
RVLId is used to convey the Virtual Link Identifier of the
receiver of the control message, when known, or zero in the
case of an initial CONNECT or diagnostic message. The RVLId is
intended to permit efficient dispatch to the portion of a
stream's state machine containing information about a specific
operation in progress over the link. RVLId values 1-3 are
reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Options | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
: OpCode Specific Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22. ST Control Message Format
SVLId is used to convey the Virtual Link Identifier of the
sender of the control message. Except for ERROR-IN-REQUEST and
diagnostic messages, it must never be zero. SVLId values 1-3
are reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49).
Reference is a transaction number. Each sender of a request
control message assigns a Reference number to the message that
is unique with respect to the stream. The Reference number is
used by the receiver to detect and discard duplicates. Each
acknowledgment carries the Reference number of the request
being acknowledged. Reference zero is never used, and
Reference numbers are assumed to be monotonically increasing
with wraparound so that the older-than and more-recent-than
relations are well defined.
LnkReference contains the Reference field of the request
control message that caused this request control message to be
created. It is used in situations where a single request leads
to multiple "responses". Examples are CONNECT and CHANGE
messages that must be acknowledged hop-by-hop and will also
lead to an ACCEPT or REFUSE from each target in the TargetList.
SenderIPAddress is the 32-bit IP address of the network
interface that the ST agent used to send the control message.
This value changes each time the packet is forwarded by an ST
agent (hop-by-hop).
Checksum is the checksum of the control message. Because the
control messages are sent in packets that may be delivered with
bits in error, each control message must be checked before it
is acted upon; see Section 4 (page 76).
OpCode Specific Data contains any additional information that
is associated with the control message. It depends on the
specific control message and is explained further below. In
some response control messages, fields of zero are included to
allow the format to match that of the corresponding request
message. The OpCode Specific Data may also contain any of the
optional Parameters defined in Section 4.2.2 (page 80).
4.2.1. ST Control Messages
The CONNECT and CHANGE messages are used to establish or modify
branches in the stream. They propagate in the direction from
the origin toward the targets. They are end-to-end messages
created by the origin. They propagate all the way to the
targets, and require ERROR-IN-REQUEST, ACK, HID-REJECT, HID-
APPROVE, ACCEPT, or REFUSE messages in response. The CONNECT
message is the stream setup message. The CHANGE message is
used to change the characteristics of an established stream.
The CONNECT message is also used to add one or more targets to
an existing stream and during recovery of a broken stream.
Both messages have a TargetList parameter and are processed
similarly.
The DISCONNECT message is used to tear down streams or parts of
streams. It propagates in the direction from the origin toward
the targets. It is either used as an end-to-end message
generated by the origin that is used to completely tear down a
stream, or is generated by an intermediate ST agent that
preempts a stream or detects the failure of its previous-hop
agent or network in the stream. In the latter case, it is used
to tear down the part of the stream from the failure to the
targets, thus the message propagates all the way to the
targets.
The REFUSE message is sent by a target to refuse to join or
remove itself from a stream; in these cases, it is an end-to-
end message. An intermediate ST agent issues a REFUSE if it
cannot find a route to a target, can only find a route to a
target through the previous-hop, preempts a stream, or detects
a failure in a next-hop ST agent or network. In all cases a
REFUSE propagates in the direction toward the origin.
The ACCEPT message is an end-to-end message generated by a
target and is used to signify the successful completion of the
setup of a stream or part of a stream, or the change of the
FlowSpec. There are no other messages that are similar to it.
The following sections contain descriptions of common fields
and parameters, followed by descriptions of the individual
control messages, both listed in alphabetical order. A brief
description of the use of the control message is given. The
packet format is shown graphically.
4.2.2. Common SCMP Elements
Several fields and parameters (referred to generically as
"elements") are common to two or more PDUs. They are described
in detail here instead of repeating their description several
times. In many cases, the presence of a parameter is optional.
To permit the parameters to be easily defined and parsed, each
is identified with a PCode byte that is followed by a PBytes
byte indicating the length of the parameter in bytes (including
the PCode, PByte, and any padding bytes). If the length of the
information is not a multiple of 4 bytes, the parameter is
padded with one to three zero (0) bytes. PBytes is thus always
a multiple of four. Parameters can be present in any order.
4.2.2.1. DetectorIPAddress
Several control messages contain the DetectorIPAddress
field. It is used to identify the agent that caused the
first instance of the message to be generated, i.e., before
it was propagated. It is copied from the received message
into the copy of the message that is to be propagated to a
previous-hop or next-hop. It use is primarily diagnostic.
4.2.2.2. ErroredPDU
The ErroredPDU parameter (PCode = 1) is used for diagnostic
purposes to encapsulate a received ST PDU that contained an
error. It may be included in the ERROR-IN-REQUEST, ERROR-
IN-RESPONSE, or REFUSE messages. It use is primarily
diagnostic.
PDUBytes indicates how many bytes of the PDUInError are
actually present.
ErrorOffset contains the number of bytes into the errored
PDU to the field containing the error. At least as much
of the PDU in error must be included to
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 1 | PBytes | PDUBytes | ErrorOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PDUInError : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23. ErroredPDU
include the field or parameter identified by ErrorOffset;
an ErrorOffset of zero would imply a problem with the IP
Version Number or ST Version Number fields.
PDUInError is the PDU in error, beginning with the ST
Header.
4.2.2.3. FlowSpec & RFlowSpec
The FlowSpec is used to convey stream service requirements
end-to-end. We expect that other versions of FlowSpec will
be needed in the future, which may or may not be subsets or
supersets of the version described here. PBytes will allow
new constraints to be added to the end without having to
simultaneously update all implementations in the field.
Implementations are expected to be able to process in a
graceful manner a Version 4 (or higher) structure that has
more elements than shown here.
The FlowSpec parameter (PCode = 2) is used in several
messages to convey the FlowSpec.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | PBytes | Version = 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DutyFactor | ErrorRate | Precedence | Reliability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tradeoffs | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitOnCost | LimitOnDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitOnPDUBytes | LimitOnPDURate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinBytesXRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AccdMeanDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AccdDelayVariance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesPDUBytes | DesPDURate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24. FlowSpec & RFlowSpec
The RFlowSpec parameter (PCode = 12) is used in conjunction
with the FDx option to convey the FlowSpec that is to be
used in the reverse direction.
Version identifies the version of the FlowSpec. Version
3 is defined here.
DutyFactor is the estimated proportion of the time that
the requested bandwidth will actually be in use. Zero is
taken to represent 256 and signify a duty factor of 1.
Other values are to be divided by 256 to yield the duty
factor.
ErrorRate expresses the error rate as the negative
exponent of 10 in the error rate. One (1) represents a
bit error rate of 0.1 and 10 represents 0.0000000001.
Precedence is the precedence of the connection being
established. Zero represents the lowest precedence.
Note that non-zero values of this parameter should be
subject to authentication and authorization checks, which
are not specified here. In general, the distinction
between precedence and priority is that precedence
specifies streams that are permitted to take previously
committed resources from another stream, while priority
identifies those PDUs that a stream is most willing to
have dropped when the stream exceeds its guaranteed
limits.
Reliability is modified by each intervening ST agent as a
measure of the probability that a given offered data
packet will be forwarded and not dropped. Zero is taken
to represent 256 and signify a probability of 1. Other
values are to be divided by 256 to yield the probability.
Tradeoffs is incompletely defined at this time. Bits
currently specified are as follows:
The most significant bit in the field, bit 0 in the
Figure 24, when one (1) means that each ST agent must
"implement" all constraints in the FlowSpec even if
they are not shown in the figure, e.g., when the
FlowSpec has been extended. When zero (0), unknown
constraints may be ignored.
The second most significant bit in the field, bit 1,
when one (1) means that one or more constraints are
unknown and have been ignored. When zero (0), all
constraints are known and have been processed.
The third most significant bit in the field, bit 2, is
used for RevChrg; see Section 3.6.5 (page 46).
Other bits are currently unspecified, and should be
set to zero (0) by the origin ST agent and not changed
by other agents unless those agents know their
meaning.
RecoveryTimeout specifies the nominal number of
milliseconds that the application is willing to wait for
a failed system component to be detected and any
corrective action to be taken.
LimitOnCost specifies the maximum cost that the origin is
willing to expend. A value of zero indicates that the
application is not willing to incur any direct charges
for the resources used by the stream. The meaning of
non-zero values is left for further study.
LimitOnDelay specifies the maximum end-to-end delay, in
milliseconds, that can be tolerated by the origin.
LimitOnPDUBytes is the smallest packet size, in terms of
ST-user data bytes, that can be tolerated by the origin.
LimitOnPDURate is the lowest packet rate that can be
tolerated by the origin, expressed as tenths of a packet
per second.
MinBytesXRate is the minimum bandwidth that can be
tolerated by the origin, expressed as a product of bytes
and tenths of a packet per second.
AccdMeanDelay is modified by each intervening ST agent.
This provides a means of reporting the total expected
delay, in milliseconds, for a data packet. Note that it
is implicitly assumed that the requested mean delay is
zero and there is no limit on the mean delay, so there
are no parameters to specify these explicitly.
AccdDelayVariance is also modified by each intervening ST
agent as a measure, in milliseconds squared, of the
packet dispersion. This quantity can be used by the
target or origin in determining whether the resulting
stream has an adequate quality of service to support the
application. Note that it is implicitly assumed that the
requested delay variance is zero and there is no limit on
the delay variance, so there are no parameters to specify
these explicitly.
DesPDUBytes is the desired PDU size in bytes. This is
not necessarily the same as the minimum necessary PDU
size. This value may be made smaller by intervening ST
agents so long as it is not made smaller than
LimitOnPDUBytes. The *PDUBytes limits measure the size
of the PDUs of next-higher protocol layer, i.e., the user
information contained in a data packet. An ST agent must
account for both the ST Header (including possible IP
encapsulation) and any local network headers and trailers
when comparing a network's MTU with *PDUBytes. In an
ACCEPT message, the value of this field will be no larger
than the MTU of the path to the specified target.
DesPDURate is the requested PDU rate, expressed as tenths
of a packet per second. This value may be made smaller
by intervening ST agents so long as it is not made
smaller than LimitOnPDURate.
It is expected that the next parameter to be added to the
FlowSpec will be a Burst Descriptor. This parameter will
describe the burstiness of the offered traffic. For
example, this may include the simple average rate, peak
rate and variance values, or more complete descriptions
that characterize the distribution of expected burst
rates and their expected duration. The nature of the
algorithms that deal with the traffic's burstiness and
the information that needs to be described by this
parameter will be subjects of further experimentation.
It is expected that a new FlowSpec with Version = 4 will
be defined that looks like Version 3 but has a Burst
Descriptor parameter appended to the end.
4.2.2.4. FreeHIDs
The FreeHIDs parameter (PCode = 3) is used to communicate to
the previous-hop suggestions for a HID. It consists of
BaseHID and FreeHIDBitMask fields. Experiments will
determine how long the mask should be for practical use of
this parameter. The parameter (if implemented) should be
included in all HID-REJECTs, and in HID-APPROVEs that are
linked to a multicast CONNECT, e.g., one containing the
MulticastAddress parameter.
BaseHID was the suggested value in a HID-CHANGE or
CONNECT. BaseHID is chosen to be the suggested HID value
to insure that the masks from multiple FreeHIDs
parameters will overlap.
FreeHIDBitMask identifies available HID values as
follows. Bit 0 in the FreeHIDBitMask corresponds to a
HID with a value equal to BaseHID with the 5 least
significant bits set to zero, bit 1 corresponds to that
value + 1, etc. This alignment of the mask on a 32-bit
boundary is used so that masks from several FreeHIDs
parameters might more easily be combined using a bit-wise
AND function to find a free HID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 3 | 4+4*N | BaseHID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FreeHIDBitMask :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25. FreeHIDs
4.2.2.5. Group & RGroup
The Group parameter (PCode = 4) is an optional argument
used only for the creation of a stream. This parameter
contains a GroupName; the GroupName may be the same as the
Name of one of the group's streams. In addition, there
may be some number of <SubGroupId, Relation> tuples that
describe the meaning of the grouping and the relation
between the members of the group. The forms of grouping
are for further study.
The RGroup parameter (PCode = 13) is an optional argument
used only for the creation of a stream in the reverse
direction that is a member of a Group; see the FDx
option, Section 3.6.3 (page 45). This parameter has the
same format as the Group parameter.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 12+4*N | !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
! GroupName !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubGroupId | Relation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubGroupId | Relation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26. Group & RGroup
A GroupName has the same format as a Name; see Figure 29.
4.2.2.6. HID & RHID
The HID parameter (PCode = 5) is used in the NOTIFY message
when the notification is related to a HID, and possibly in
the STATUS-RESPONSE message to convey additional HIDs that
are valid for a stream when there are more than one. It
consists of the PCode and PBytes bytes prepended to a HID;
HIDs were described in Section 4 (page 76).
The RHID parameter (PCode = 14) is used in conjunction with
the FDx option to convey the HID that is to be used in the
reverse direction. It consists of the PCode and PBytes
bytes prepended to a HID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 4 | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27. HID & RHID
4.2.2.7. MulticastAddress
The MulticastAddress parameter (PCode = 6) is an optional
parameter that is used, when setting up a network level
multicast group, to communicate an IP and/or local network
multicast address to the next-hop agents that should become
members of the group.
LocalNetBytes is the length of the Local Net Multicast
Address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 6 | PBytes | LocalNetBytes | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Local Net Multicast Address : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28. MulticastAddress
IP Multicast Address is described in [6]. This field is
zero (0) if no IP multicast address is known or is
applicable. The block of addresses 224.1.0.0 -
224.1.255.255 has been allocated for use by ST.
Local Net Multicast Address is the multicast address to
be used on the local network. It corresponds to the IP
Multicast Address when the latter is non-zero.
4.2.2.8. Name & RName
Each stream is uniquely (i.e., globally) identified by a
Name. A Name is created by the origin host ST agent and is
composed of 1) a 16-bit number chosen to make the Name
unique within the agent, 2) the IP address of the origin ST
agent, and 3) a 32-bit timestamp. If the origin has
multiple IP addresses, then any that can be used to reach
target may be used in the Name. The intent is that the
<Unique ID, IP Address> tuple be unique for the lifetime of
the stream. It is suggested that to increase robustness a
Unique ID value not be reused for a period of time on the
order of 5 minutes.
The Timestamp is included both to make the Name unique over
long intervals (e.g., forever) for purposes of network
management and accounting/billing, and to protect against
failure of an ST agent that causes knowledge of active
Unique IDs to be lost. The assumption is that all ST agents
have access to some "clock". If this is not the case, the
agent should have access to some form of non-volatile memory
in which it can store some number that at least gets
incremented per restart.
The Name parameter (PCode = 7) is used in most control
messages to identify a stream.
The RName parameter (PCode = 15) is used in conjunction with
the FDx option to convey the Name of the reverse stream in
an ACCEPT message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 12 | Unique ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29. Name & RName
4.2.2.9. NextHopIPAddress
The NextHopIPAddress parameter (PCode = 8) is an optional
parameter of NOTIFY (RouteBack) or REFUSE (RouteInconsist or
RouteLoop) and contains the IP address of a suggested next-
hop ST agent.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 8 | 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30. NextHopIPAddress
4.2.2.10. Origin
The Origin parameter (PCode = 9) is used to identify the
origin of the stream, the next higher protocol, and the SAP
being used in conjunction with that protocol.
NextPcol is an 8-bit field used in demultiplexing
operations to identify the protocol to be used above ST.
The values of NextPcol are in the same number space as
the IP Header's Protocol field and are consequently
defined in the Assigned Numbers RFC[18].
OriginSAPBytes specifies the length of the OriginSAP,
exclusive of any padding required to maintain 32-bit
alignment.
OriginIPAddress is (one of) the IP address of the origin.
OriginSAP identifies the origin's SAP associated with the
NextPcol protocol.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 9 | PBytes | NextPcol |OriginSAPBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OriginIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: OriginSAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31. Origin
4.2.2.11. OriginTimestamp
The OriginTimestamp parameter (PCode = 10) is used to
indicate the time at which the control message was sent.
The units and format of the timestamp is that defined in the
NTP protocol specification [13]. Note that discontinuities
over leap seconds are expected.
Note that the time synchronization implied by the use of
such a parameter is the subject of systems management
functions not described in this memo, e.g., NTP.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 10 | 12 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Timestamp -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32. OriginTimestamp
4.2.2.12. ReasonCode
Several errors may occur during protocol processing. All ST
error codes are taken from a single number space. The
currently defined values and their meaning is presented in
the list below. Note that new error codes may be defined
from time to time. All implementations are expected to
handle new codes in a graceful manner. If an unknown
ReasonCode is encountered, it should be assumed to be fatal.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33. ReasonCode
Name Value Meaning
---------------- ----- ---------------------------------------
AcceptTimeout 2 An Accept has not been
acknowledged.
AccessDenied 3 Access denied.
AckUnexpected 4 An unexpected ACK was received.
ApplAbort 5 The application aborted the stream
abnormally.
ApplDisconnect 6 The application closed the stream
normally.
AuthentFailed 7 The authentication function
failed.
CantGetResrc 8 Unable to acquire (additional)
resources.
CantRelResrc 9 Unable to release excess
resources.
CksumBadCtl 10 A received control PDU has a bad
message checksum.
CksumBadST 11 A received PDU has a bad ST Header
checksum.
DropExcdDly 12 A received PDU was dropped because
it could not be processed within
the delay specification.
DropExcdMTU 13 A received PDU was dropped because
its size exceeds the MTU.
DropFailAgt 14 A received PDU was dropped because
of a failed ST agent.
DropFailHst 15 A received PDU was dropped because
of a host failure.
DropFailIfc 16 A received PDU was dropped because
of a broken interface.
DropFailNet 17 A received PDU was dropped because
of a network failure.
Name Value Meaning
---------------- ----- ---------------------------------------
DropLimits 18 A received PDU was dropped because
it exceeds the resource limits for
its stream.
DropNoResrc 19 A received PDU was dropped due to
no available resources (including
precedence).
DropNoRoute 20 A received PDU was dropped because
of no available route.
DropPriLow 21 A received PDU was dropped because
it has a priority too low to be
processed.
DuplicateIgn 22 A received control PDU is a
duplicate and is being
acknowledged.
DuplicateTarget 23 A received control PDU contains a
duplicate target, or an attempt to
add an existing target.
ErrorUnknown 1 An error not contained in this
list has been detected.
failure N/A An abbreviation used in the text
for any of the more specific
errors: DropFailAgt, DropFailHst,
DropFailIfc, DropFailNet,
IntfcFailure, NetworkFailure,
STAgentFailure, FailureRecovery.
FailureRecovery 24 A notification that recovery is
being attempted.
FlowVerBad 25 A received control PDU has a
FlowSpec Version Number that is
not supported.
GroupUnknown 26 A received control PDU contains an
unknown Group Name.
HIDNegFails 28 HID negotiation failed.
HIDUnknown 29 A received control PDU contains an
unknown HID.
Name Value Meaning
---------------- ----- ---------------------------------------
InconsistHID 30 An inconsistency has been detected
with a stream Name and
corresponding HID.
InconsistGroup 31 An inconsistency has been detected
with the streams forming a group.
IntfcFailure 32 A network interface failure has
been detected.
InvalidHID 33 A received ST PDU contains an
invalid HID.
InvalidSender 34 A received control PDU has an
invalid SenderIPAddress field.
InvalidTotByt 35 A received control PDU has an
invalid TotalBytes field.
LnkRefUnknown 36 A received control PDU contains an
unknown LnkReference.
NameUnknown 37 A received control PDU contains an
unknown stream Name.
NetworkFailure 38 A network failure has been
detected.
NoError 0 No error has occurred.
NoRouteToAgent 39 Cannot find a route to an ST
agent.
NoRouteToDest 40 Cannot find a route to the
destination.
NoRouteToHost 41 Cannot find a route to a host.
NoRouteToNet 42 Cannot find a route to a network.
OpCodeUnknown 43 A received control PDU has an
invalid OpCode field.
PCodeUnknown 44 A received control PDU has a
parameter with an invalid PCode.