As per Relevance of the word resource, we have this rfc below:
Network Working Group CIP Working
Request for Comments: 1190 C. Topolcic,
Obsoletes: IEN-119 October 1990
Experimental Internet Stream Protocol, Version 2 (ST-II
Status of this
This memo defines a revised version of the Internet Stream Protocol
originally defined in IEN-119 [8], based on results from
with the original version, and subsequent requests, discussion,
suggestions for improvements. This is a Limited-Use
Protocol. Please refer to the current edition of the "IAB
Protocol Standards" for the standardization state and status of
protocol. Distribution of this memo is unlimited
1.
This memo defines the Internet Stream Protocol, Version 2 (ST-II),
IP-layer protocol that provides end-to-end guaranteed service
an internet. This specification obsoletes IEN 119 "ST - A
Internet Stream Protocol" written by Jim Forgie in 1979, the
specification of ST. ST-II is not compatible with Version 1 of
protocol, but maintains much of the architecture and philosophy
that version. It is intended to fill in some of the areas
unaddressed, to make it easier to implement, and to support a
range of applications
CIP Working Group [Page 1]
RFC 1190 Internet Stream Protocol October 1990
1.1. Table of
Status of this Memo . . . . . . . . . . . . 1
1. Abstract . . . . . . . . . . . . . . . 1
1.1. Table of Contents . . . . . . . . . . . 2
1.2. List of Figures . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . 7
2.1. Major Differences Between ST and ST-II . . . . 8
2.2. Concepts and Terminology . . . . . . . . . 9
2.3. Relationship Between Applications and ST . . . . 11
2.4. ST Control Message Protocol . . . . . . . . 12
2.5. Flow Specifications . . . . . . . . . . . 14
3. ST Control Message Protocol Functional Description . 17
3.1. Stream Setup . . . . . . . . . . . . . 18
3.1.1. Initial Setup at the Origin . . . . . . . 18
3.1.2. Invoking the Routing Function . . . . . . 19
3.1.3. Reserving Resources . . . . . . . . . . 19
3.1.4. Sending CONNECT Messages . . . . . . . . 20
3.1.5. CONNECT Processing by an Intermediate Agent . . 22
3.1.6. Setup at the Targets . . . . . . . . . 23
3.1.7. ACCEPT Processing by an Intermediate Agent . . 24
3.1.8. ACCEPT Processing by the Origin . . . . . . 26
3.1.9. Processing a REFUSE Message . . . . . . . 27
3.2. Data Transfer . . . . . . . . . . . . . 30
3.3. Modifying an Existing Stream . . . . . . . . 31
3.3.1. Adding a Target . . . . . . . . . . . 31
3.3.2. The Origin Removing a Target . . . . . . . 33
3.3.3. A Target Deleting Itself . . . . . . . . 35
3.3.4. Changing the FlowSpec . . . . . . . . . 36
3.4. Stream Tear Down . . . . . . . . . . . . 36
3.5. Exceptional Cases . . . . . . . . . . . 37
3.5.1. Setup Failure due to CONNECT Timeout . . . . 37
3.5.2. Problems due to Routing Inconsistency . . . . 38
3.5.3. Setup Failure due to a Routing Failure . . . 39
3.5.4. Problems in Reserving Resources . . . . . . 41
3.5.5. Setup Failure due to ACCEPT Timeout . . . . 41
3.5.6. Problems Caused by CHANGE Messages . . . . . 42
3.5.7. Notification of Changes Forced by Failures . . 42
3.6. Options . . . . . . . . . . . . . . . 44
3.6.1. HID Field Option . . . . . . . . . . . 44
3.6.2. PTP Option . . . . . . . . . . . . . 44
3.6.3. FDx Option . . . . . . . . . . . . . 45
3.6.4. NoRecovery Option . . . . . . . . . . 46
3.6.5. RevChrg Option . . . . . . . . . . . 46
3.6.6. Source Route Option . . . . . . . . . . 46
3.7. Ancillary Functions . . . . . . . . . . . 48
3.7.1. Failure Detection . . . . . . . . . . 48
3.7.1.1. Network Failures . . . . . . . . . . 48
3.7.1.2. Detecting ST Stream Failures . . . . . . 49
3.7.1.3. Subset . . . . . . . . . . . . . 51
CIP Working Group [Page 2]
RFC 1190 Internet Stream Protocol October 1990
3.7.2. Failure Recovery . . . . . . . . . . . 51
3.7.2.1. Subset . . . . . . . . . . . . . 55
3.7.3. A Group of Streams . . . . . . . . . . 56
3.7.3.1. Group Name Generator . . . . . . . . 57
3.7.3.2. Subset . . . . . . . . . . . . . 57
3.7.4. HID Negotiation . . . . . . . . . . . 58
3.7.4.1. Subset . . . . . . . . . . . . . 64
3.7.5. IP Encapsulation of ST . . . . . . . . . 64
3.7.5.1. IP Multicasting . . . . . . . . . . 65
3.7.6. Retransmission . . . . . . . . . . . 66
3.7.7. Routing . . . . . . . . . . . . . . 67
3.7.8. Security . . . . . . . . . . . . . 67
3.8. ST Service Interfaces . . . . . . . . . . 68
3.8.1. Access to Routing Information . . . . . . 69
3.8.2. Access to Network Layer Resource Reservation . 70
3.8.3. Network Layer Services Utilized . . . . . . 71
3.8.4. IP Services Utilized . . . . . . . . . 71
3.8.5. ST Layer Services Provided . . . . . . . 72
4. ST Protocol Data Unit Descriptions . . . . . . . 75
4.1. Data Packets . . . . . . . . . . . . . 76
4.2. ST Control Message Protocol Descriptions . . . . 77
4.2.1. ST Control Messages . . . . . . . . . . 79
4.2.2. Common SCMP Elements . . . . . . . . . 80
4.2.2.1. DetectorIPAddress . . . . . . . . . 80
4.2.2.2. ErroredPDU . . . . . . . . . . . . 80
4.2.2.3. FlowSpec & RFlowSpec . . . . . . . . 81
4.2.2.4. FreeHIDs . . . . . . . . . . . . 84
4.2.2.5. Group & RGroup . . . . . . . . . . 85
4.2.2.6. HID & RHID . . . . . . . . . . . . 86
4.2.2.7. MulticastAddress . . . . . . . . . . 86
4.2.2.8. Name & RName . . . . . . . . . . . 87
4.2.2.9. NextHopIPAddress . . . . . . . . . . 88
4.2.2.10. Origin . . . . . . . . . . . . . 88
4.2.2.11. OriginTimestamp . . . . . . . . . . 89
4.2.2.12. ReasonCode . . . . . . . . . . . . 89
4.2.2.13. RecordRoute . . . . . . . . . . . 94
4.2.2.14. SrcRoute . . . . . . . . . . . . 95
4.2.2.15. Target and TargetList . . . . . . . . 96
4.2.2.16. UserData . . . . . . . . . . . . 98
4.2.3. ST Control Message PDUs . . . . . . . . 99
4.2.3.1. ACCEPT . . . . . . . . . . . . . 100
4.2.3.2. ACK . . . . . . . . . . . . . . 102
4.2.3.3. CHANGE-REQUEST . . . . . . . . . . 103
4.2.3.4. CHANGE . . . . . . . . . . . . . 104
4.2.3.5. CONNECT . . . . . . . . . . . . . 105
4.2.3.6. DISCONNECT . . . . . . . . . . . . 110
4.2.3.7. ERROR-IN-REQUEST . . . . . . . . . . 111
4.2.3.8. ERROR-IN-RESPONSE . . . . . . . . . 112
4.2.3.9. HELLO . . . . . . . . . . . . . 113
4.2.3.10. HID-APPROVE . . . . . . . . . . . 114
4.2.3.11. HID-CHANGE-REQUEST . . . . . . . . . 115
CIP Working Group [Page 3]
RFC 1190 Internet Stream Protocol October 1990
4.2.3.12. HID-CHANGE . . . . . . . . . . . . 116
4.2.3.13. HID-REJECT . . . . . . . . . . . . 118
4.2.3.14. NOTIFY . . . . . . . . . . . . . 120
4.2.3.15. REFUSE . . . . . . . . . . . . . 122
4.2.3.16. STATUS . . . . . . . . . . . . . 124
4.2.3.17. STATUS-RESPONSE . . . . . . . . . . 126
4.3. Suggested Protocol Constants . . . . . . . . 127
5. Areas Not Addressed . . . . . . . . . . . . 131
6. Glossary . . . . . . . . . . . . . . . 135
7. References . . . . . . . . . . . . . . . 143
8. Security Considerations. . . . . . . . . . . 144
9. Authors' Addresses . . . . . . . . . . . . 145
Appendix 1. Data Notations . . . . . . . . . . 147
1.2. List of
Figure 1. Protocol Relationships . . . . . . . . . 6
Figure 2. Topology Used in Protocol Exchange Diagrams . . 16
Figure 3. Virtual Link Identifiers for SCMP Messages . . 16
Figure 4. HIDs Assigned for ST User Packets . . . . . 18
Figure 5. Origin Sending CONNECT Message . . . . . . 21
Figure 6. CONNECT Processing by an Intermediate Agent . . 22
Figure 7. CONNECT Processing by the Target . . . . . . 24
Figure 8. ACCEPT Processing by an Intermediate Agent . . 25
Figure 9. ACCEPT Processing by the Origin . . . . . . 26
Figure 10. Sending REFUSE Message . . . . . . . . . 28
Figure 11. Routing Around a Failure . . . . . . . . 29
Figure 12. Addition of Another Target . . . . . . . . 32
Figure 13. Origin Removing a Target . . . . . . . . 34
Figure 14. Target Deleting Itself . . . . . . . . . 35
Figure 15. CONNECT Retransmission after a Timeout . . . . 38
Figure 16. Processing NOTIFY Messages . . . . . . . . 43
Figure 17. Source Routing Option . . . . . . . . . 47
Figure 18. Typical HID Negotiation (No Multicasting) . . . 60
Figure 19. Multicast HID Negotiation . . . . . . . . 61
Figure 20. Multicast HID Re-Negotiation . . . . 62
Figure 21. ST Header . . . . . . . . . . . . . 75
Figure 22. ST Control Message Format . . . . . . . . 77
Figure 23. ErroredPDU . . . . . . . . . . . . . 80
Figure 24. FlowSpec & RFlowSpec . . . . . . . . . . 81
Figure 25. FreeHIDs . . . . . . . . . . . . . . 85
Figure 26. Group & RGroup . . . . . . . . . . . . 85
Figure 27. HID & RHID . . . . . . . . . . . . . 86
Figure 28. MulticastAddress . . . . . . . . . . . 86
Figure 29. Name & RName . . . . . . . . . . . . 87
Figure 30. NextHopIPAddress . . . . . . . . . . . 88
CIP Working Group [Page 4]
RFC 1190 Internet Stream Protocol October 1990
Figure 31. Origin . . . . . . . . . . . . . . 88
Figure 32. OriginTimestamp . . . . . . . . . . . 89
Figure 33. ReasonCode . . . . . . . . . . . . . 89
Figure 34. RecordRoute . . . . . . . . . . . . . 94
Figure 35. SrcRoute . . . . . . . . . . . . . . 95
Figure 36. Target . . . . . . . . . . . . . . 97
Figure 37. TargetList . . . . . . . . . . . . . 97
Figure 38. UserData . . . . . . . . . . . . . . 98
Figure 39. ACCEPT Control Message . . . . . . . . . 101
Figure 40. ACK Control Message . . . . . . . . . . 102
Figure 41. CHANGE-REQUEST Control Message . . . . . . 103
Figure 42. CHANGE Control Message . . . . . . . . . 105
Figure 43. CONNECT Control Message . . . . . . . . . 109
Figure 44. DISCONNECT Control Message . . . . . . . . 110
Figure 45. ERROR-IN-REQUEST Control Message . . . . . . 111
Figure 46. ERROR-IN-RESPONSE Control Message . . . . . 112
Figure 47. HELLO Control Message . . . . . . . . . 113
Figure 48. HID-APPROVE Control Message . . . . . . . 114
Figure 49. HID-CHANGE-REQUEST Control Message . . . . . 115
Figure 50. HID-CHANGE Control Message . . . . . . . . 117
Figure 51. HID-REJECT Control Message . . . . . . . . 119
Figure 52. NOTIFY Control Message . . . . . . . . . 121
Figure 53. REFUSE Control Message . . . . . . . . . 123
Figure 54. STATUS Control Message . . . . . . . . . 125
Figure 55. STATUS-RESPONSE Control Message . . . . . . 126
Figure 56. Transmission Order of Bytes . . . . . . . 147
Figure 57. Significance of Bits . . . . . . . . . . 147
CIP Working Group [Page 5]
RFC 1190 Internet Stream Protocol October 1990
+--------------------+
| Conference Control |
+--------------------+
|
+-------+ +-------+ |
| Video | | Voice | | +-----+ +------+ +-----+ +-----+
| Appl | | Appl | | | SNMP| |Telnet| | FTP | ... | |
+-------+ +-------+ | +-----+ +------+ +-----+ +-----+
| | | | | | |
V V | | | | | ------------
+-----+ +-----+ | | | | |
| PVP | | NVP | | | | | |
+-----+ +-----+ + | | | |
| \ | \ \ | | | |
| +-----|--+-----+ | | | |
| Appl.|control V V V V
| ST data | +-----+ +-------+ +-----+
| & control| | UDP | | TCP | ... | |
| | +-----+ +-------+ +-----+
| /| / | \ / / | / /|
|\ / | +------+--|--\-----+-/--|--- ... -+ / |
| \ / | | | \ / | / |
| \ / | | | \ +----|--- ... -+ | -----------
| \ / | | | \ / | |
| V | | | V | |
| +------+ | | | +------+ | +------+ |
| | SCMP | | | | | ICMP | | | IGMP | |
| +------+ | | | +------+ | +------+ |
| | | | | | | | |
V V V V V V V V
+-----------------+ +-----------------------------------+
| STream protocol |->| Internet Protocol |
+-----------------+ +-----------------------------------+
| \ / |
| \ / |
| X | ------------
| / \ |
| / \ |
VV
+----------------+ +----------------+
| (Sub-) Network |...| (Sub-) Network | (Sub-)
| Protocol | | Protocol |
+----------------+ +----------------+
Figure 1. Protocol
CIP Working Group [Page 6]
RFC 1190 Internet Stream Protocol October 1990
2.
ST has been developed to support efficient delivery of streams
packets to either single or multiple destinations in
requiring guaranteed data rates and controlled delay characteristics
The motivation for the original protocol was that IP [2] [15] did
provide the delay and data rate characteristics necessary to
voice applications
ST is an internet protocol at the same layer as IP, see Figure 1.
differs from IP in that IP, as originally envisioned, did not
routers (or intermediate systems) to maintain state
describing the streams of packets flowing through them.
incorporates the concept of streams across an internet.
intervening ST entity maintains state information for each
that passes through it. The stream state includes
information, including multicast support for efficiency, and
information, which allows network or link bandwidth and queues to
assigned to a specific stream. This pre-allocation of
allows data packets to be forwarded with low delay, low overhead,
a low probability of loss due to congestion. The characteristics
a stream, such as the number and location of the endpoints, and
bandwidth required, may be modified during the lifetime of
stream. This allows ST to give a real time application
guaranteed and predictable communication characteristics it requires
and is a good vehicle to support an application whose
requirements are relatively predictable
ST proved quite useful in several early experiments that
voice conferences in the Internet. Since that time, ST has also
used to support point-to-point streams that include both video
voice. Recently, multimedia conferencing applications have
developed that need to exchange real-time voice, video, and
data in a multi-site conferencing environment.
conferencing across an internet is an application for which
provides ideal support. Simulation and wargaming applications [14]
also place similar requirements on the communication system.
applications may include scientific visualization between a number
workstations and one or more remote supercomputers, and
collection and distribution of real-time sensor data from
sensor platforms. ST may also be useful to support activities
are currently supported by IP, such as bulk file transfer using TCP
Transport protocols above ST include the Packet Video Protocol (PVP
[5] and the Network Voice Protocol (NVP) [4], which are end-to-
protocols used directly by applications. Other transport
protocols that may be used over ST include TCP [16], VMTP [3], etc
They provide the user interface, flow control, and packet ordering
This specification does not describe these higher layer protocols
CIP Working Group [Page 7]
RFC 1190 Internet Stream Protocol October 1990
2.1. Major Differences Between ST and ST-
ST-II supports a wider variety of applications than did
original ST. The differences between ST and ST-II are
straight forward yet provide great improvements. Four of the
notable differences are
1 ST-II is decoupled from the Access Controller (AC).
AC, as well as providing a rudimentary access
function, also served as a centralized repository
distributor of the conference information. If an AC
necessary, it should be an entity in a higher
protocol. A large variety of applications such
conferencing, distributed simulations, and wargaming
be run without an explicit AC
2 The basic stream construct of ST-II is a directed
carrying traffic away from a source to all
destinations, rather than the original ST's
structure. For example, a conference is composed of
number of such trees, one for traffic from
participant. Although there are more (simplex) streams
ST-II, each is much simpler to manage, so the aggregate
much simpler. This change has a minimal impact on
application
3 ST-II defines a number of the robustness and
mechanisms that were left undefined in the original
specification. In case of a network or ST Agent failure
a stream may optionally be repaired automatically (i.e.,
without intervention from the user or the application
using a pruned depth first search starting at the ST
immediately preceding the failure
4 ST-II does not make an inherent distinction
streams connecting only two communicants and streams
an arbitrary number of communicants
This memo is the specification for the ST-II Protocol.
there should be no ambiguity between the original ST
and the specification herein, the protocol is simply called
hereafter
ST is the protocol used by ST entities to exchange information
The same protocol is used for communication among all ST entities
whether they communicate with a higher layer protocol or
ST packets between attached networks
The remainder of this section gives a brief overview of the
Protocol. Section 3 (page 17) provides a detailed description
the operations required by the protocol. Section 4 (page 75)
provides descriptions of the ST Protocol Data Units
CIP Working Group [Page 8]
RFC 1190 Internet Stream Protocol October 1990
between ST entities. Issues that have not yet been
addressed are presented in Section 5 (page 131). A glossary
list of references are in Sections 6 (page 135) and 7 (page 143),
respectively
This memo also defines "subsets" of ST that can be implemented.
subsetted implementation does not have full ST functionality,
it can interoperate with other similarly
implementations, or with a full implementation, in a
and consistent manner. This approach allows an implementation
be built and provide service with minimum effort, and gives it
immediate and well defined growth path
2.2. Concepts and
The ST packet header is not constrained to be compatible with
IP packet header, except for the IP Version Number (the first
bits) that is used to distinguish ST packets (IP Version 5)
IP packets (IP Version 4). The ST packets, or protocol data
(PDUs), can be encapsulated in IP either to provide
(possibly with degraded service) across portions of an
that do not provide support for ST, or to allow access to
such as security that are not provided directly by ST
An internet entity that implements the ST Protocol is called
"ST Agent". We refer to two kinds of ST agents: "host
agents", also called "host agents" and "intermediate ST agents",
also called "intermediate agents". The ST agents functioning
hosts are sourcing or sinking data to a higher layer protocol
application, while ST agents functioning as intermediate
are forwarding data between directly attached networks.
distinction is not part of the protocol, but is used
conceptual purposes only. Indeed, a given ST agent may
simultaneously performing both host and intermediate roles.
ST agent should be capable of delivering packets to a higher
protocol. Every ST agent can replicate ST data packets
necessary for multi-destination delivery, and is able to
packets whether received from a network interface or a
layer protocol. There are no other kinds of ST agents
ST provides applications with an end-to-end flow oriented
across an internet. This service is implemented using
called "streams". ST data packets are not considered to
totally independent as are IP data packets. They are
only as part of a point-to-point or point-to-multi- point stream
ST creates a stream during a setup phase before data
transmitted. During the setup phase, routes are selected
internetwork resources are reserved. Except for explicit
to the stream, the routes remain in effect until the stream
explicitly torn down
CIP Working Group [Page 9]
RFC 1190 Internet Stream Protocol October 1990
An ST stream is
o the set of paths that data generated by an
entity traverses on its way to its peer
entity(s) that receive it
o the resources allocated to support that transmission
data,
o the state information that is maintained describing
transmission of data
Each stream is identified by a globally unique "Name";
Section 4.2.2.8 (page 87). The Name is specified in ST
operations, but is not used in ST data packets. A set of
may be related as members of a larger aggregate called a "group".
A group is identified by a "Group Name"; see Section 3.7.3 (
56).
The end-users of a stream are called the "participants" in
stream. Data travels in a single direction through any
stream. The host agent that transmits the data into the stream
called the "origin", and the host agents that receive the data
called the "targets". Thus, for any stream one participant is
origin and the others are the targets
A stream is "multi-destination simplex" since data travels
it in only one direction: from the origin to the targets.
stream can be viewed as a directed tree in which the origin is
root, all the branches are directed away from the root toward
targets, which are the leaves. A "hop" is an edge of that tree
The ST agent that is on the end of an edge in the direction
the origin is called the "previous-hop ST agent", or
"previous-hop". The ST agents that are one hop away from
previous-hop ST agent in the direction toward the targets
called the "next-hop ST agents", or the "next-hops". It
possible that multiple edges between a previous-hop and
next-hops are actually implemented by a network level
group
Packets travel across a hop for one of two purposes: data
control. For ST data packet handling, hops are marked by "
IDentifiers" (HIDs) used for efficient forwarding instead of
stream's Name. A HID is negotiated among several agents so
data forwarding can be done efficiently on both a point-to-
and multicast basis. All control message exchange is done on
point-to-point basis between a pair of agents. For
message handling, Virtual Link Identifiers are used to
dispatch the control messages to the proper stream's
machine
CIP Working Group [Page 10]
RFC 1190 Internet Stream Protocol October 1990
ST requires routing decisions to be made at several points in
stream setup and management process. ST assumes that
appropriate routing algorithm exists to which ST has access;
Section 3.8.1 (page 69). However, routing is considered to be
separate issue. Thus neither the routing algorithm nor
implementation is specified here. A routing algorithm may
to minimize the number of hops to the target(s), or it may be
intelligent and attempt to minimize the total internet
consumed. ST operates equally well with any reasonable
algorithm. The availability of a source routing option does
eliminate the need for an appropriate routing algorithm in
agents
2.3. Relationship Between Applications and
It is the responsibility of an ST application entity to
information among its peers, usually via IP, as necessary
determine the structure of the communication before
the ST stream. This includes
o identifying the participants
o determining which are targets for which origins
o selecting the characteristics of the data flow between
origin and its target(s),
o specifying the protocol that resides above ST
o identifying the Service Access Point (SAP), port,
socket relevant to that protocol at every participant,
o ensuring security, if necessary
The protocol layer above ST must pass such information down to
ST protocol layer when creating a stream
ST uses a flow specification, abbreviated herein as "FlowSpec",
describe the required characteristics of a stream. Included
bandwidth, delay, and reliability parameters.
parameters may be included in the future in an extensible manner
The FlowSpec describes both the desired values and their
allowable values. The ST agents thus have some freedom
allocating their resources. The ST agents accumulate
that describes the characteristics of the chosen path and
that information to the origin and the targets of the stream
ST stream setup control messages carry some information that
not specifically relevant to ST, but is passed through
interface to the protocol that resides above ST. The "
CIP Working Group [Page 11]
RFC 1190 Internet Stream Protocol October 1990
protocol identifier" ("NextPcol") allows ST to demultiplex
to a number of possible higher layer protocols. The
associated with each participant allows the higher layer
to further demultiplex to a specific application entity.
UserData parameter is provided; see Section 4.2.2.16 (page 98).
2.4. ST Control Message
ST agents create and manage a stream using the ST Control
Protocol (SCMP). Conceptually, SCMP resides immediately above
(as does ICMP above IP) but is an integral part of ST.
messages are used to
o create streams
o refuse creation of a stream
o delete a stream in whole or in part
o negotiate or change a stream's parameters
o tear down parts of streams as a result of router
network failures, or transient routing inconsistencies
o reroute around network or component failures
SCMP follows a request-response model. SCMP reliability
ensured through use of retransmission after timeout; see
3.7.6 (page 66).
An ST application that will transmit data requests its local
agent, the origin, to create a stream. While only the
requests creation of a stream, all the ST agents from the
to the targets participate in its creation and management.
a stream is simplex, each participant that wishes to transmit
must request that a stream be created
An ST agent that receives an indication that a stream is
created must
1 negotiate a HID with the previous-hop identifying
stream
2 map the list of targets onto a set of next-hop ST
through the routing function
3 reserve the local and network resources required
support the stream
CIP Working Group [Page 12]
RFC 1190 Internet Stream Protocol October 1990
4 update the FlowSpec,
5 propagate the setup information and partitioned
list to the next-hop ST agents
When a target receives the setup message, it must inquire from
specified application process whether or not it is willing
accept the stream, and inform the origin accordingly
Once a stream is established, the origin can safely send data.
and its implementations are optimized to allow fast and
forwarding of data packets by the ST agents using the HIDs,
at the cost of adding overhead to stream creation and management
Specifically, the forwarding decisions, that is, determining
set of next-hop ST agents to which a data packet belonging to
particular stream will be sent, are made during the stream
phase. The shorthand HIDs are negotiated at that time, not
to reduce the data packet header size, but to access
the stream's forwarding information. When possible, network-
multicast is used to forward a data packet to multiple next-hop
agents across a network. Note that when network-layer
is used, all members of the multicast group must participate
the negotiation of a common HID
An established stream can be modified by adding or
targets, or by changing the network resources allocated to it.
stream may be torn down by either the origin or the targets.
target can remove itself from a stream leaving the
unaffected. The origin can similarly remove any subset of
targets from its stream leaving the remainder unaffected.
origin can also remove all the targets from the stream
eliminate the stream in its entirety
A stream is monitored by the involved ST agents. If they detect
failure, they can attempt recovery. In general, this
tearing down part of the stream and rebuilding it to bypass
failed component(s). The rebuilding always occurs from the
side of the failure. The origin can optionally specify
recovery is to be attempted automatically by intermediate
agents or whether a failure should immediately be reported to
origin. If automatic recovery is selected but an
agent determines it cannot effect the repair, it propagates
failure information backward until it reaches an agent that
effect repair. If the failure information propagates back to
origin, then the application can decide if it should abort
reattempt the recovery operation
CIP Working Group [Page 13]
RFC 1190 Internet Stream Protocol October 1990
Although ST supports an arbitrary connection structure,
recognize that certain stream topologies will be common
justify special features, or options, which allow for
support. These include
o streams with only a single target (see Section 3.6.2 (
44)),
o pairs of streams to support full duplex
between two points (see Section 3.6.3 (page 45)).
These features allow the most frequently occurring topologies
be supported with less setup delay, with fewer control messages
and with less overhead than the more general situations
2.5. Flow
Real time data, such as voice and video, have
characteristics and make specific demands of the networks
must transfer it. Specifically, the data may be transmitted
packets of a constant size that are produced at a constant rate
Alternatively, the bandwidth may vary, due either to
packet size or rate, with a predefined maximum, and perhaps
non-zero minimum. The variation may also be predictable based
some model of how the data is generated. Depending on
equipment used to generate the data, the packet size and rate
be negotiable. Certain applications, such as voice,
packets at the given rate only some of the time. The
that support real time data must add minimal delay and
variance, but it is expected that they will be non-zero
The FlowSpec is used for three purposes. First, it is used in
setup message to specify the desired and minimal packet size
rate required by the origin. This information is used by
agents when they attempt to reserve the resources in
intervening networks. Second, when the setup message reaches
target, the FlowSpec contains the packet size and rate that
actually obtained along the path from the origin, and the
mean delay and delay variance expected for data packets along
path. This information is used by the target to determine if
wishes to accept the connection. The target may reduce
resources if it wishes to do so and if the possibility is
available. Third, if the target accepts the connection,
returns the updated FlowSpec to the origin, so that the origin
decide if it still wishes to participate in the stream with
characteristics that were actually obtained
CIP Working Group [Page 14]
RFC 1190 Internet Stream Protocol October 1990
When the data transmitted by stream users is generated at
rates, including bursts of varying rate and duration, there is
opportunity to provide service to more subscribers by
guaranteed service for the average data rate of each stream,
reserving additional network capacity, shared among all streams
to service the bursts. This concept has been recognized by
voice network providers leading to the principle of time
speech interpolation (TASI) in which only the talkspurts of
speech conversation are transmitted, and, during silence periods
the circuit can be used to send the talkspurts of
conversations. The FlowSpec is intended to assist algorithms
perform similar kinds of functions. We do not propose
algorithms here, but rather expect that this will be an area
experimentation. To allow for experiments, and a range of
that application traffic might be characterized, a "DutyFactor"
included in the FlowSpec and we expect that a "burst descriptor
will also be needed
The FlowSpec will need to be revised as experience is gained
connections involving numerous participants using multiple
across heterogeneous internetworks. We feel a change of
FlowSpec does not necessarily require a new version of ST, it
requires the FlowSpec version number be updated and software
manage the new FlowSpec to be distributed. We further
that if the change to the FlowSpec involves additional
for improved operation, such as a burst descriptor, that it
added to the end of the FlowSpec and that the current
be maintained so that obsolete software can be used to process
current parameters with minimum modifications
CIP Working Group [Page 15]
RFC 1190 Internet Stream Protocol October 1990
**** ****
* * ST Agent 1 * * +---+
* *------- o ---------* *-------+ B |
* * * * +---+
* * ****
+---+ * * |
| | * * |
| A +---------* * o ST Agent 3
| | * * |
+---+ * * |
* * ***
* * * * +---+
* * ST Agent 2 * *-------+ C |
* *------- o --------* * +---+
* * * *
**** * *
* *
+---+ * * +---+
| E +--------* *-------+ D |
+---+ * * +---+
***
Figure 2. Topology Used in Protocol Exchange
**** ST Agent 1 ****
* +--+---14--- o -----15--+----+--44---+---+
* | +-+--11--- -----16--+-+ * | B |
* | | * * |+-+--45---+---+
* | | * *++*
+---+ * | | * 34 ||32
| +----4----+--+ | * ||
| A +----6----+----+ * o ST Agent 3
| +----5----+---+ * |
+---+ * | * | 33
* | * ST *+*
* | * Agent * | *
* | * 2 -----24-+--+ * +---+
* +--+--23--- o -----25-+-----+--54---+ C |
* * -----26-+---+ * +---+
**** -----27-+-+ | *
* | | *
+---+ * | | * +---+
| E +---74---+-+ +-+--64---+ D |
+---+ * * +---+
***
Figure 3. Virtual Link Identifiers for SCMP
CIP Working Group [Page 16]
RFC 1190 Internet Stream Protocol October 1990
3. ST Control Message Protocol Functional
This section contains a functional description of the ST
Message Protocol (SCMP); Section 4 (page 75) specifies the formats
the control message PDUs. We begin with a description of
setup. Mechanisms used to deal with the exceptional cases are
presented. Complications due to options that an application or a
agent may select are then detailed. Once a stream has
established, the data transfer phase is entered; it is described
Once the data transfer phase has been completed, the stream must
torn down and resources released; the control messages used
perform this function are presented. The resources or
of a stream may be changed during the lifetime of the stream;
procedures to make changes are described. Finally, the
concludes with a description of some ancillary functions, such
failure detection and recovery, HID negotiation, routing, security
etc
To help clarify the SCMP exchanges used to setup and maintain
streams, we have included a series of figures in this section.
protocol interactions in the figures assume the topology shown
Figure 2. The figures, taken together
o Create a stream from an application at A to three peers at B
C and D
o Add a peer at E
o Disconnect peers B and C,
o D drops out of the stream
Other figures illustrate exchanges related to failure recovery
In order to make the dispatch function within SCMP more uniform
efficient, each end of a hop is assigned, by the agent at that end,
Virtual Link Identifier that uniquely (within that agent)
the hop and associates it with a particular stream's
machine(s). The identifier at the end of a link that is sending
message is called the Sender Virtual Link Identifier (SVLId);
at the receiving end is called the Receiver Virtual Link
(RVLId). Whenever one agent sends a control message for the other
receive, the sender will place the receiver's identifier into
RVLId field of the message and its own identifier in the SVLId field
When a reply to the message is sent, the values in SVLId and
fields will be reversed, reflecting the fact the sender and
roles are reversed. VLIds with values zero through three
received and should not be assigned in response to CONNECT messages
Figure 3 shows the hops that will be used in the examples
summarizes the VLIds that will be assigned to them
CIP Working Group [Page 17]
RFC 1190 Internet Stream Protocol October 1990
Similarly, Figure 4 summarizes the HIDs that will eventually
negotiated as the stream is created
**** ST Agent 1 ****
* +>+--1200-> o -------->+--->+-3600->+---+
* ^ * * * | B |
* | * * +->+-6000->+---+
* | * *+**
+---+ * | * ^
| +-------->+-->+ * |
| A | * * o St Agent 3
| +-------->+-->+ * ^
+---+ * | * | 4801
* | * *+*
* V * ST Agent 2 * ^ * +---+
* +>+--2400-> o ------->+->+->+-4800->+ C |
**** * | * 4801 +---+
* | *
+---+ * V * +---+
| E +<-4800--+<-+->+-4800->+ D |
+---+ * * 4801 +---+
***
Figure 4. HIDs Assigned for ST User
Some of the diagrams that follow form a progression. For example
the steps required initially to establish a connection are
across five figures. Within a progression, the actions on the
diagram are numbered 1.1, 1.2, etc.; within the second diagram
are numbered 2.1, 2.2, etc. Points where control leaves one
to enter another are identified with a continuation arrow "-->>",
are continued with "[a.b] >>-->" in the other diagram. The number
brackets shows the label where control left the earlier diagram.
reception of simple acknowledgments, e.g., ACKs, in one figure
another is omitted for clarity
3.1. Stream
This section presents a description of stream setup assuming
everything succeeds -- HIDs are approved, any required
are available, and the routing is correct
3.1.1. Initial Setup at the
As described in Section 2.3 (page 11), the application
collected the information necessary to determine
CIP Working Group [Page 18]
RFC 1190 Internet Stream Protocol October 1990
participants in the communication before passing it to the
ST agent at the origin. The host ST agent will take
information, allocate a Name for the stream (see
4.2.2.8 (page 87)), and create a stream
3.1.2. Invoking the Routing
An ST agent that is setting up a stream invokes a
function to find a path to reach each of the targets
in the TargetList. This is similar to the routing decision
IP. However, in this case the route is to a multitude
targets rather than to a single destination
The set of next-hops that an ST agent would select is
necessarily the same as the set of next hops that IP
select given a number of independent IP datagrams to the
destinations. The routing algorithm may attempt to
parameters other than the number of hops that the packets
take, such as delay, local network bandwidth consumption,
total internet bandwidth consumption
The result of the routing function is a set of next-hop
agents and the parameters of the intervening network(s).
latter permit the ST agent to determine whether the
network has the resources necessary to support the level
service requested in the FlowSpec
3.1.3. Reserving
The intent of ST is to provide a guaranteed level of service
reserving internet resources for a stream during a setup
rather than on a per packet basis. The relevant resources
not only the forwarding information maintained by the
agents, but also packet switch processor bandwidth and
space, and network bandwidth and multicast group identifiers
Reservation of these resources can help to increase
reliability and decrease the delay and delay variance
which data packets are delivered. The FlowSpec contains
the information needed by the ST agent to allocate
necessary resources. When and how these resources
allocated depends on the details of the networks involved,
is not specified here
If an ST agent must send data across a network to a
next-hop ST agent, then only the point-to-point bandwidth
to be reserved. If the agent must send data to multiple next
hop agents across one network and network layer multicasting
not available, then bandwidth must be reserved for all of them
This will allow the ST agent
CIP Working Group [Page 19]
RFC 1190 Internet Stream Protocol October 1990
use replication to send a copy of the data packets to
next-hop agent
If multicast is supported, its use will decrease the
that the ST agent must expend when forwarding packets and
reduces the bandwidth required since one copy can be
by all next-hop agents. However, the setup phase is
complicated. A network multicast address must be
that contains all those next-hop agents, the sender must
access to that address, the next-hop agents must be informed
the address so they can join the multicast group identified
it (see Section 4.2.2.7 (page 86)), and a common HID must
negotiated
The network should consider the bandwidth and
requirements to determine the amount of packet
processing bandwidth and buffer space to reserve for
stream. In addition, the membership of a stream in a Group
affect the resources that have to be allocated; see
3.7.3 (page 56).
Few networks in the Internet currently offer
reservation, and none that we know of offer reservation of
the resources specified here. Only the Terrestrial
Network (TWBNet) [7] and the Atlantic Satellite
(SATNET) [9] offer(ed) bandwidth reservation. Multicasting
more widely supported. No network provides for the
of packet switch processing bandwidth or buffer space. We
that future networks will be designed to better
protocols like ST
Effects similar to reservation of the necessary resources
be obtained even when the network cannot provide direct
for the reservation. Certainly if total reservations are
small fraction of the overall resources, such as packet
processing bandwidth, buffer space, or network bandwidth,
the desired performance can be honored if the degree
confidence is consistent with the requirements as stated in
FlowSpec. Other solutions can be designed for
networks
3.1.4. Sending CONNECT
A VLId and a proposed HID must be selected for each next-
agent. The control packets for the next-hop must carry
VLId in the SVLId field. The data packets transmitted in
stream to the next-hop must carry the HID in the ST Header
The ST agent sends a CONNECT message to each of the ST
identified by the routing function. Each CONNECT
contains the VLId, the proposed HID (the HID Field option
CIP Working Group [Page 20]
RFC 1190 Internet Stream Protocol October 1990
must be set, see Section 3.6.1 (page 44)), an updated FlowSpec
and a TargetList. In general, the HID, FlowSpec,
TargetList will depend on both the next-hop and the
network. Each TargetList is a subset of the received (
original) TargetList, identifying the targets that are to
reached through the next-hop to which the CONNECT message
being sent. Note that a CONNECT message to a single next-
might have to be fragmented into multiple CONNECTs if
single CONNECT is too large for the intervening network's MTU
fragmentation is performed by further dividing the TargetList
If multiple next-hops are to be reached through a network
supports network level multicast, a different CONNECT
must nevertheless be sent to each next-hop since each will
a different TargetList; see Section 4.2.3.5 (page 105).
However, since an identical copy of each ensuing data
will reach each member of the multicast group, all the
messages must propose the same HID. See Section 3.7.4 (
58) for a detailed discussion on HID selection
In the example of Figure 2, the routing function might
that B is reachable via Agent 1 and C and D are reachable
Agent 2. Thus A would create two CONNECT messages, one
for Agents 1 and 2, as illustrated in Figure 5. Assuming
the proposed HIDs are available in the receiving agents,
would each send a responding HID-APPROVE back to Agent A
Application Agent A Agent 1 Agent 2
1.1. (open B,C,D
1.2. +-> (routing to B,C,D
1.3. +->(reserve resources from A to Agent 1)
|
1.4. | +-> CONNECT B --------->>
|
|
1.5. +->(reserve resources from A to Agent 2)
1.6. +-> CONNECT C,D ------------------>>
Figure 5. Origin Sending CONNECT
CIP Working Group [Page 21]
RFC 1190 Internet Stream Protocol October 1990
3.1.5. CONNECT Processing by an Intermediate
An ST agent receiving a CONNECT message should, assuming
errors, quickly select a VLId and respond to the previous-
with either an ACK, a HID-REJECT, or a HID-APPROVE message,
is appropriate. This message must identify the CONNECT
which it corresponds by including the CONNECT's
number in its Reference field. Note that the VLId that
agent selects is placed in the SVLId of the response, and
previous-hop's VLId (which is contained in the SVLId of
CONNECT) is copied into the RVLId of the response. If
agent is not a target, it must then invoke the
function, reserve resources, and send a CONNECT message(s)
its next-hop(s), as described in Sections 3.1.2-4 (pages 19-
20).
Agent A Agent 1 Agent
[1.4] >>-> CONNECT B -------->+--+
|
2.1. | (routing to B
|
2.2. V +->(reserve resources from 1 to B
2.3. +<- HID-APPROVE <------+
2.4. +-> CONNECT B ---------->>
Agent A Agent 2 Agent
[1.6] >>-> CONNECT C,D ------>+-+
|
2.5. | (routing to C,D
|
2.6. V +-->(reserve resources from 2 to C
2.7. +<- HID-APPROVE <------+ |
2.8. | +-> CONNECT C ---------->>
|
|
|
| Agent
2.9. +->(reserve resources from 2 to D
2.10. +-> CONNECT D ---------->>
Figure 6. CONNECT Processing by an Intermediate
CIP Working Group [Page 22]
RFC 1190 Internet Stream Protocol October 1990
The resources listed as Desired in a received FlowSpec may
correspond to those actually reserved in either the ST
itself or in the network(s) used to reach the next-
agent(s). As long as the reserved resources are sufficient
meet the specified Limits, the copy of the FlowSpec sent to
next-hop must have the Desired resources updated to reflect
resources that were actually obtained. For example,
Desired bandwidth might be reduced because the network to
next-hop could not provide all of the desired bandwidth. Also
the delay and delay variance are appropriately increased,
the link MTU may require that the DesPDUBytes field be reduced
(The minimum requirements that the origin had entered into
FlowSpec Limits fields cannot be altered by the intermediate
target agents.)
3.1.6. Setup at the
An ST agent that is the target of a CONNECT, whether from
intermediate ST agent, or directly from the origin host
agent, must respond first (assuming no errors) with either
HID-REJECT or HID-APPROVE. After inquiring from the
application process whether or not it is willing to accept
connection, the agent must also respond with either an
or a REFUSE
In particular, the application must be presented
parameters from the CONNECT, such as the Name, FlowSpec
Options, and Group, to be used as a basis for its decision
The application is identified by a combination of the
field and the SAP field in the (usually) single
Target of the TargetList. The contents of the SAP field
specify the "port" or other local identifier for use by
protocol layer above the host ST layer. Subsequently
data packets will carry a short hand identifier (the HID)
can be mapped into this information and be used for
delivery
The responses to the CONNECT message are sent to the previous
hop from which the CONNECT was received. An ACCEPT
the Name of the stream and the updated FlowSpec. Note that
application might have reduced the desired level of service
the received FlowSpec before accepting it. The target must
send the ACCEPT until HID negotiation has been
completed
Since the ACCEPT or REFUSE message must be acknowledged by
previous-hop, it is assigned a new Reference number that
be returned in the ACK. The CONNECT to which the ACCEPT
REFUSE is a reply is identified by placing the CONNECT'
Reference number in the LnkReference field of the ACCEPT
REFUSE
CIP Working Group [Page 23]
RFC 1190 Internet Stream Protocol October 1990
Agent 1 Agent B Application
3.1. (proc B listening
[2.4] >>-> CONNECT B ---------->+------------------+
| |
3.2. V (proc B accepts
3.3. +<- HID-APPROVE <--------+ |
|
3.4. (wait until HID negotiated) <---+
3.5. <<--+<- ACCEPT B <-----------+
Agent 2 Agent C Application
3.6. (proc C listening
[2.8] >>-> CONNECT C ---------->+------------------+
| |
3.7. V (proc C accepts
3.8. +<- HID-APPROVE <--------+ |
|
3.9. (wait until HID negotiated) <---+
3.10. <<--+<- ACCEPT C <-----------+
Agent 2 Agent D Application
3.11. (proc D listening
[2.10] >>-> CONNECT D ---------->+------------------+
| |
3.12. V (proc D accepts
3.13. +<- HID-APPROVE <--------+ |
|
3.14. (wait until HID negotiated) <---+
3.15. <<--+<- ACCEPT D <-----------+
Figure 7. CONNECT Processing by the
3.1.7. ACCEPT Processing by an Intermediate
When an intermediate ST agent receives an ACCEPT, it
verifies that the message is a response to an earlier CONNECT
If not, it responds to the next-hop ST agent with an ERROR-IN
REPLY (LnkRefUnknown) message. Otherwise, it responds to
next-hop ST agent with an ACK, and
CIP Working Group [Page 24]
RFC 1190 Internet Stream Protocol October 1990
the ACCEPT message to the previous-hop along the same
traced by the CONNECT but in the reverse direction toward
origin. The ACCEPT should not be propagated until all
negotiations with the next-hop agent(s) have been
completed
The FlowSpec is included in the ACCEPT message so that
origin and intermediate ST agents can gain access to
information that was accumulated as the CONNECT traversed
internet. Note that the resources, as specified in
FlowSpec in the ACCEPT message, may differ from the
that were reserved by the agent when the CONNECT
Agent A Agent 1 Agent
+<-+<- ACCEPT B <-------<< [3.5]
V |
4.1. (wait for ACCEPTS) V
4.2. V +-> ACK --------------->+
4.3. (wait until HID negotiated)<-+
V
4.4. <<--+<-- ACCEPT B <---------+
Agent A Agent 2 Agent
+<-+<- ACCEPT C <------<< [3.10]
| |
| V
4.5. | +-> ACK --------------->+
|
|
|
| Agent
+<-+<- ACCEPT D <------<< [3.15]
V |
4.6. (wait for ACCEPTS) V
4.7. V +-> ACK --------------->+
4.8. (wait until HID negotiated)<-+
V
4.9. <<--+<- ACCEPT C <----------+
|
|
4.10. <<--+<- ACCEPT D <----------+
Figure 8. ACCEPT Processing by an Intermediate
CIP Working Group [Page 25]
RFC 1190 Internet Stream Protocol October 1990
originally processed. However, the agent does not adjust
reservation in response to the ACCEPT. It is expected that
excess resource allocation will be released for use by
stream or datagram traffic through an explicit CHANGE
initiated by the application at the origin if it does not
to be charged for any excess resource allocations
3.1.8. ACCEPT Processing by the
The origin will eventually receive an ACCEPT (or REFUSE
ERROR-IN-REQUEST) message from each of the targets. As
ACCEPT is received, the application should be notified of
target and the resources that were successfully allocated
the path to it, as specified in the FlowSpec contained in
ACCEPT message. The application may then use the
to either adopt or terminate the portion of the stream to
target. When ACCEPTs (or failures) from all targets have
received at the origin, the application is notified that
setup is complete, and that data may be sent
Application A Agent A Agent 1 Agent 2
+<-- ACCEPT B <--------<< [4.4]
|
V
5.1. +--> ACK ----------------->+
|
V
5.2. +<-- (inform A of B's FlowSpec
| +<-- ACCEPT C <----------------<< [4.9]
| |
| V
5.3. | +--> ACK ------------------------->+
| |
| V
5.4. +<-- (inform A of C's FlowSpec
| +<-- ACCEPT D <----------------<< [4.10]
| |
| V
5.5. | +--> ACK ------------------------->+
| |
| V
5.6. +<-- (inform A of D's FlowSpec
5.7. (wait until HIDs negotiated
5.8. (inform A open to B,C,D
Figure 9. ACCEPT Processing by the
CIP Working Group [Page 26]
RFC 1190 Internet Stream Protocol October 1990
There are several pieces of information contained in
FlowSpec that the application must combine before sending
through the stream. The PDU size should be computed from
minimum value of the DesPDUBytes field from all ACCEPTs and
protocol layers above ST should be informed of the limit.
is expected that the next higher protocol layer above ST
segment its PDUs accordingly. Note, however, that the MTU
decrease over the life of the stream if new targets
subsequently added. Whether the MTU should be increased
targets are dropped from a stream is left for further study
The available bandwidth and packet rate limits must also
combined. In this case, however, it may not be possible
select a pair of values that may be used for all paths, e.g.,
one path may have selected a low rate of large packets
another selected a high rate of small packets. The
may remedy the situation by either tearing down the stream
dropping some participants, or creating a second stream
After any differences have been resolved (or some targets
been deleted by the application to permit resolution),
application at the origin should send a CHANGE message
release any excess resources along paths to those targets
exceed the resolved parameters for the stream, thereby
the costs that will be incurred by the stream
3.1.9. Processing a REFUSE
REFUSE messages are used to indicate a failure to reach
application at a target; they are propagated toward the
of a stream. They are used in three situations
1 during stream setup or expansion to indicate that
is no satisfactory path from an ST agent to a target
2 when the application at the target either does
exist does not wish to be a participant, or wants
cease being a participant,
3 when a failure has been detected and the agents
trying to find a suitable path around the failure
The cases are distinguished by the ReasonCode field and
agent receiving a REFUSE message must examine that field
order to determine the proper action to be taken.
particular, if the ReasonCode indicates that the
message reached the target then the REFUSE should be
back to the origin, releasing resources as appropriate
the way. If the ReasonCode indicates
CIP Working Group [Page 27]
RFC 1190 Internet Stream Protocol October 1990
the CONNECT message did not reach the target then
intermediate (origin) ST agent(s) should check for
routes to the target before propagating the REFUSE back
hop toward the origin. This implies that an agent must
track of the next-hops that it has tried, on a target by
basis, in order not to get caught in a loop
An ST agent that receives a REFUSE message must acknowledge
by sending an ACK to the next-hop. The REFUSE must also
propagated back to the previous-hop ST agent. Note that the
agent may not have any information about the target
Appl. Agent A Agent 2 Agent
(proc E NOT listening
1. (add E
2. +----->+-> CONNECT E ---------->+->+
| |
V |
3. +<-- ACK <---------------+ |
4. (routing to E
5. (reserve resources 2 to E
6. +--> CONNECT E --------->+
|
|
