RFC 1190
Experimental Internet Stream Protocol: Version 2 (ST-II)
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", RFC 1071, USC/Information Sciences Institute, Cray Research, BBN Laboratories, September 1988. [2] Braden, R. (ed.), "Requirements for Internet Hosts -- Communication Layers", RFC 1122, USC/Information Sciences Institute, October 1989. [3] Cheriton, D., "VMTP: Versatile Message Transaction Protocol Specification", RFC 1045, 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", RFC 1112, 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", RFC 1141, BBN Communications Corporation, January 1990. [13] Mills, D., "Network Time Protocol (Version 2) Specification and Implementation", RFC 1119, 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", RFC 791, DARPA, September 1981. [16] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [17] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [18] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1060, 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.