ST, Internet Stream Protocol

Description Glossary RFCs Publications Obsolete RFCs


Protocol suite: TCP/IP.
Protocol type:Network layer stream protocol and transport layer stream protocol.
Multicast addresses: (routers). (hosts).
IP Version:5.
IP Protocol:5.
MIME subtype:
Working groups:

RFC 1819, pages 6 - 8:

ST2 is an experimental connection-oriented internetworking protocol that operates at the same layer as connectionless IP. It has been developed to support the efficient delivery of data streams to single or multiple destinations in applications that require guaranteed quality of service. ST2 is part of the IP protocol family and serves as an adjunct to, not a replacement for, IP. The main application areas of the protocol are the real-time transport of multimedia data, e.g., digital audio and video packet streams, and distributed simulation/gaming, across internets.

ST2 can be used to reserve bandwidth for real-time streams across network routes. This reservation, together with appropriate network access and packet scheduling mechanisms in all nodes running the protocol, guarantees a well-defined Quality of Service (QoS) to ST2 applications. It ensures that real-time packets are delivered within their deadlines, that is, at the time where they need to be presented. This facilitates a smooth delivery of data that is essential for time- critical applications, but can typically not be provided by best- effort IP communication.

Just like IP, ST2 actually consists of two protocols: ST for the data transport and SCMP, the Stream Control Message Protocol, for all control functions. ST is simple and contains only a single PDU format that is designed for fast and efficient data forwarding in order to achieve low communication delays. SCMP, however, is more complex than IP's ICMP. As with ICMP and IP, SCMP packets are transferred within ST packets.

ST2 is designed to coexist with IP on each node. A typical distributed multimedia application would use both protocols: IP for the transfer of traditional data and control information, and ST2 for the transfer of real-time data. Whereas IP typically will be accessed from TCP or UDP, ST2 will be accessed via new end-to-end real-time protocols. The position of ST2 with respect to the other protocols of the Internet family.

Both ST2 and IP apply the same addressing schemes to identify different hosts. ST2 and IP packets differ in the first four bits, which contain the internetwork protocol version number: number 5 is reserved for ST2 (IP itself has version number 4). As a network layer protocol, like IP, ST2 operates independently of its underlying subnets. Existing implementations use ARP for address resolution, and use the same Layer 2 SAPs as IP.

As a special function, ST2 messages can be encapsulated in IP packets. This is represented as a link between ST2 and IP. This link allows ST2 messages to pass through routers which do not run ST2. Resource management is typically not available for these IP route segments. IP encapsulation is, therefore, suggested only for portions of the network which do not constitute a system bottleneck.

RFC 1819, pages 15, 16 and 17:

An introductory level some of the fundamental ST2 concepts are streams, data transfer, and flow specification:

Streams form the core concepts of ST2. They are established between a sending origin and one or more receiving targets in the form of a routing tree. Streams are uni-directional from the origin to the targets. Nodes in the tree represent so-called ST agents, entities executing the ST2 protocol; links in the tree are called hops. Any node in the middle of the tree is called an intermediate agent, or router. An agent may have any combination of origin, target, or intermediate capabilities.

Streams are maintained using SCMP messages.

Data transfer in ST2 is simplex in the downstream direction. Data transport through streams is very simple. ST2 puts only a small header in front of the user data. The header contains a protocol identification that distinguishes ST2 from IP packets, an ST2 version number, a priority field (specifying a relative importance of streams in cases of conflict), a length counter, a stream identification, and a checksum. These elements form a 12-byte header.

As part of establishing a connection, SCMP handles the negotiation of quality-of-service parameters for a stream. In ST2 terminology, these parameters form a flow specification (FlowSpec) which is associated with the stream. Different versions of FlowSpecs exist, see [RFC1190], [L. Delgrossi, C. Halstrick, R. G. Herrtwich, H. Stuettgen: HeiTP: a Transport Protocol for ST-II, GLOBECOM'92, Orlando (Florida), December 1992.] and [RFC1363], and can be distinguished by a version number. Typically, they contain parameters such as average and maximum throughput, end-to-end delay, and delay variance of a stream. SCMP itself only provides the mechanism for relaying the quality-of-service parameters.

MAC header ST header Data :::
MAC header IP header ST header Data :::

ST Header:

0001020304050607 0809101112131415 1617181920212223 2425262728293031
ST Version D Priority reserved Length
Checksum UniqueID
Origin IPAddress

ST. 4 bits.
The IP Version Number assigned to identify ST packets. The value for ST is 5.

Version. 4 bits.
The ST Version Number. The value for the current ST2+ version is 3.

D. 1 bit.
Set to 1 in all ST data packets and cleared to 0 in all SCMP control messages.

Priority. 3 bits.
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.

reserved. 4 bits.
Must be cleared to zero when using the defined flow specifications. They may be set accordingly when other flow specifications are used.

Length. 16 bits.
The size in bytes of the entire ST packet. This includes the ST Header but does not include any local network headers or trailers. In general, all length fields in the ST Protocol are in units of bytes.

Checksum. 16 bits.
Covers only the 12 bytes of the ST Header. The ST Protocol uses 16-bit checksums here in the ST Header and in each Control Message.

UniqueID. 16 bits.
The first element of the stream ID (SID). It is locally unique at the stream origin.

Origin IPAddress. 32 bits.
The second element of the SID. It is the 32-bit IP address of the stream origin



[RFC 1458] Requirements for Multicast Protocols.

[RFC 1819] Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+.

[RFC 1946] Native ATM Support for ST2+.

[RFC 2383] ST2+ over ATM Protocol Specification - UNI 3.1 Version.

[RFC 4094] Analysis of Existing Quality-of-Service Signaling Protocols.


Obsolete RFCs:

[IEN 119] ST - A Proposed Internet Stream Protocol.

[RFC 1190] Experimental Internet Stream Protocol, Version 2 (ST-II).

Description Glossary RFCs Publications Obsolete RFCs