_-_early_VOIP_prototype_-_Lincoln_Lab,_signed_by_John_Makhoul.jpg/250px-Voice_over_Stream_Protocol_(ST)_-_early_VOIP_prototype_-_Lincoln_Lab,_signed_by_John_Makhoul.jpg){kind=small}
_-_early_VOIP_prototype_-_Lincoln_Lab,_signed_by_John_Makhoul.jpg/2000px-Voice_over_Stream_Protocol_(ST)_-_early_VOIP_prototype_-_Lincoln_Lab,_signed_by_John_Makhoul.jpg)
Community hub
0 subscribers8 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Internet Stream Protocol.
Nothing was collected or created yet.
Internet Stream Protocol
View on Wikipediafrom Wikipedia
_-_early_VOIP_prototype_-_Lincoln_Lab,_signed_by_John_Makhoul.jpg)
The Internet Stream Protocol (ST) is a family of experimental protocols first defined in Internet Experiment Note IEN-119 in 1979,[1] and later substantially revised in RFC 1190 (ST-II) and RFC 1819 (ST2+).[2][3][4] The protocol uses the version number 5 in the version field of the Internet Protocol header, but was never known as IPv5. The successor to IPv4 was thus named IPv6 to eliminate any possible confusion about the actual protocol in use.
History
[edit]The Internet Stream Protocol family was never introduced for public use, but many of the concepts available in ST are similar to later Asynchronous Transfer Mode protocols and can be found in Multiprotocol Label Switching (MPLS). They also presaged voice over IP.
ST arose as the transport protocol of the Network Voice Protocol, a pioneering computer network protocol for transporting human speech over packetized communications networks, first implemented in December 1973 by Internet researcher Danny Cohen of the Information Sciences Institute (ISI) as part of ARPA's Network Secure Communications (NSC) project.[5]
First specified in 1979, ST was envisioned as a connection-oriented complement to IPv4, operating on the same level, but using a different header format from that used for IP datagrams. According to IEN-119,[1] its concepts were formulated by Danny Cohen, Estil Hoversten, and James W. Forgie. The protocol was notable for introducing the concepts of packetized voice (as used by voice over IP), a talkspurt (a continuous segment of speech between silent intervals), and specified delay and drop-rate requirements for packet services. It was implemented in the Voice Funnel.
Its second version, known variously as ST-II or ST2, was drafted by Claudio Topolcic and others in 1987 and specified in 1990.[3] It was implemented in the Terrestrial Wideband Network and its successor, the Defense Simulation Internet, where it was used extensively for distributed simulations and videoconferencing. This version later formed the core technology for transporting voice calls and other real-time streams within Canada's Iris Digital Communications System.
The final version of ST2, which was also known as ST2+, was drafted by the IETF ST2 Working group[6][7] and published in 1995 as RFC 1819. ST2 distinguishes its own packets with an Internet Protocol version number 5, although it was never known as IPv5.[4]
ST uses the same IP address structure and the same link layer protocol number (EtherType 0x800) as IP.
In datagram mode, ST packets could be encapsulated with IP headers using protocol number 5.[8]
References
[edit]- ^ a b James Forgie (1979). "IEN-119: ST – A Proposed Internet Stream Protocol".
- ^ "ST, Internet Stream Protocol". Network Sorcery, Inc. Archived from the original on 2012-03-05. Retrieved 2012-06-09.
- ^ a b C. Topolcic, ed. (October 1990). Experimental Internet Stream Protocol, Version 2 (ST-II). Network Working Group. doi:10.17487/RFC1190. RFC 1190. Obsolete. Obsoleted by RFC 1819.
- ^ a b L. Delgrossi; L. Berger, eds. (August 1995). Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+. Network Working Group. doi:10.17487/RFC1819. RFC 1819. Historic. Obsoletes RFC 1190 and IEN 119.
- ^ D. Cohen (November 1977). Specifications for the Network Voice Protocol (NVP). IETF. doi:10.17487/RFC0741. RFC 741. Status Unknown.
- ^ "IETF ST2 Working Group (Concluded March, 1996)". Retrieved 2025-08-13.
- ^ "IETF ST2 Status Pages (Concluded)". Retrieved 2025-08-13.
- ^ "Protocol Numbers". Iana.org. Retrieved 2012-06-05.
Bibliography
[edit]- Cohen, D., "Specifications for the Network Voice Protocol", Technical Report ISI/RR-75-39, USC/Information Sciences Institute, Marina del Rey, CA (Mar 1976).
- Cohen, D., "A Network Voice Protocol NVP-II" and "Sample NVP/ST Scenarios" (unpublished memorandums), USC/Information Sciences Institute, Marina del Rey, CA (Apr 1981).
- Topolcic, C., Park, P., Draft of "Proposed Changes to the Experimental Internet Stream Protocol (ST)", BBN Laboratories, Cambridge, MA (Apr 1987).
Internet Stream Protocol
View on Grokipediafrom Grokipedia
The Internet Stream Protocol (ST) is a family of experimental network protocols designed to enable efficient, real-time delivery of multimedia data streams, such as voice and video, over packet-switched internets by providing end-to-end resource reservations, guaranteed data rates, and controlled delay characteristics.[1] Initially proposed in 1979, ST operates as a connection-oriented protocol at the internet layer, supporting both unicast and multicast transmissions through simplex streams directed to single or multiple destinations, while integrating with IP via a distinct protocol number (5) and version identifier (5).[2]
The protocol's development began with the original ST specification in Internet Experiment Note (IEN) 119, authored by James W. Forgie at Bolt Beranek and Newman (BBN), which emphasized abbreviated packet headers for efficiency and pre-stream negotiation of traffic parameters to ensure quality of service (QoS) for applications like speech conferencing.[1] This was followed by ST-II in RFC 1190 (1990), which introduced enhancements such as improved multicast support via directed trees, a robust Stream Control Message Protocol (SCMP) for reliable setup and teardown, and mechanisms for dynamic resource adjustment and failure recovery, decoupling it from earlier dependencies like access controllers.[2] The final iteration, ST2+ in RFC 1819 (1995), refined these elements further by the IETF ST2 Working Group, adding features like FlowSpec negotiation for QoS classes (e.g., predictive or guaranteed service), group-based bandwidth sharing, and interoperability improvements based on implementation experience, while maintaining its experimental status.[3]
Although never advanced to Internet Standard due to challenges in scalability and the emergence of alternatives like RSVP (Resource Reservation Protocol), ST pioneered concepts in real-time internet transport and resource management that influenced subsequent multimedia protocols.[3] Its use of IP version 5 highlighted early efforts to extend IP for specialized services, but it saw limited deployment and was eventually superseded by more flexible approaches in modern IP networks.[2]
Introduction
Overview
The Internet Stream Protocol (ST) is an experimental network protocol suite developed to enable the transmission of real-time, multicast packet streams over IP networks, particularly for continuous media such as audio and video. It encompasses variants including the original ST defined in 1979, ST-II in 1990, and ST2+ in 1995, each building on the prior to provide end-to-end resource reservation for guaranteed performance in packet-switched environments.[1][2][3] Unlike traditional best-effort protocols, ST operates at the IP layer to support applications requiring predictable delivery, such as voice conferencing and multimedia streams.[2] At its core, ST defines "streams" as unidirectional flows of packets from a source to one or more destinations, organized as simplex paths or multicast trees with explicit timing constraints to mimic real-time delivery. These streams involve resource allocation during setup, including bandwidth reservation and delay bounds, to ensure sustained data rates and controlled latency dispersion essential for time-sensitive data like speech talkspurts.[1][3] Control mechanisms manage stream establishment, modification, and teardown, allowing dynamic adjustments such as adding targets or altering flow specifications without disrupting ongoing transmission.[2] In contrast to unicast protocols like TCP, which prioritize reliability through error correction and retransmissions, ST emphasizes multicast efficiency and real-time guarantees without built-in reliability, accepting potential packet loss to minimize delay.[2][3] Originating in the late 1970s as an extension to IP for ARPA-funded research on packet voice, ST served as a precursor to contemporary streaming protocols by pioneering network-layer support for multimedia over internets.[1]Design Goals
The Internet Stream Protocol Version 2 (ST-II) was primarily designed to support continuous media streams, such as audio and video, by providing end-to-end guaranteed service with controlled data rates and delays suitable for real-time applications like voice and video conferencing.[2] This focus addressed the limitations of existing protocols like UDP, which offered only best-effort datagram delivery without mechanisms for ensuring timeliness or consistency in packet streams.[2] By prioritizing low latency and jitter control, ST-II aimed to deliver packets with predictable timing, minimizing dispersion through specified parameters in its FlowSpec, such as limits on delay and accumulated delay variance.[4] A key objective was to enable efficient multicast for group communications, utilizing directed trees and network-layer multicast capabilities to support one-to-many data transmission without redundant bandwidth usage.[5] This was complemented by resource reservation requirements, which allocated bandwidth and buffer space during stream setup to guarantee quality-of-service (QoS) in bandwidth-constrained networks, reducing congestion and packet loss risks.[6] Unlike UDP's lack of reservation, ST-II's approach ensured dedicated resources for streams, enhancing reliability for time-sensitive data.[2] ST-II emphasized simplicity in its architecture over comprehensive reliability features, accepting potential packet loss in favor of timeliness to better serve real-time needs.[7] Control messages relied on retransmission rather than end-to-end acknowledgments, and data forwarding used lightweight host identifiers to streamline processing, positioning ST-II as a lightweight alternative to more complex protocols while still providing essential QoS guarantees.[6]History
Early Development
The Internet Stream Protocol (ST) originated in 1979 as an experimental effort to support real-time data streaming, particularly for voice communications, in packet-switched networks. Proposed by James W. Forgie at MIT Lincoln Laboratory under the ARPA Internet Program, it extended the Internet Protocol to provide guaranteed bandwidth and bounded delay for continuous streams, addressing limitations of datagram-based delivery for applications like speech conferencing.[1] The initial prototype, known as ST or ST1, was developed for testing on wideband networks such as SATNET, focusing on audio streaming experiments to evaluate flow control and traffic management for packet voice. These early tests emphasized packet timing mechanisms to limit end-to-end delay to under 250 milliseconds and reduce jitter through receiver-side smoothing buffers, ensuring natural conversational flow at data rates of 40-50% of peak capacity for typical speech.[1] In the late 1980s, the protocol evolved into ST2 through collaborative work by the CIP Working Group, incorporating IP encapsulation (using protocol number 5) and multicast capabilities for broader internet testing across diverse environments. Key contributors included Steve Deering, whose research on IP multicast at Xerox PARC influenced the integration of network-layer multicast trees to support multi-destination streams.[2] A primary challenge in this evolution was synchronizing real-time streams over heterogeneous networks with varying capacities and delays; ST2 addressed this via FlowSpec parameters for resource reservation, timestamp negotiation, and pre-allocation of bandwidth to maintain low packet variance and prevent congestion.[2]Standardization Efforts
The initial formalization of the Internet Stream Protocol within the IETF occurred through efforts leading to the publication of RFC 1190 in October 1990, which defined Version 2 (ST-II) as an experimental protocol for providing end-to-end guaranteed service at the IP layer.[8] This document, authored by Claudio Topolcic, built on earlier experimental work and was developed by the IETF's CIP Working Group, marking the protocol's entry into the standardization process without a dedicated working group at that stage.[8] In 1993, the IETF chartered the Stream Protocol Version 2 (ST2) Working Group to refine and clarify the ST-II specification, addressing issues such as interoperability, error correction, and resource management for audio-visual applications.[9] The group produced RFC 1819 in August 1995, specifying ST2+ as a revised experimental protocol that introduced enhancements including authentication mechanisms (e.g., via ReasonCode for authentication failures) for improved security and dynamic stream modifications through CHANGE messages for better flow control.[10] Key contributors to this effort included editors Lou Berger and Luigi Delgrossi, with input from IETF participants like Bob Braden, who influenced related resource reservation discussions.[10][11] Despite these advancements, ST2 maintained experimental status due to limited widespread deployment, as the rapid growth of the best-effort Internet model and the emergence of competing technologies like RSVP favored simpler, soft-state approaches over ST2's hard-state reservations.[11] Active development concluded with the ST2 Working Group's closure following the 1995 RFC, and no further standards-track updates were pursued by the late 1990s.[12]Technical Specifications
Protocol Architecture
The Internet Stream Protocol (ST), encompassing versions such as ST-II and ST2+, operates as a network-layer protocol designed to provide guaranteed quality-of-service (QoS) for real-time data streams, positioned parallel to the Internet Protocol (IP) at version 5. It employs a layered model consisting of a data transfer component (ST) for simplex packet flows and a control component (Stream Control Message Protocol, or SCMP) for reliable stream management over unreliable networks. This architecture integrates seamlessly with IP by utilizing the same addressing scheme and supporting encapsulation within IP packets (using protocol number 5) to traverse non-ST-aware routers, ensuring compatibility without requiring a full TCP-like transport stack.[8][10] Core components include stream setup, initiated by the origin host through SCMP control messages that propagate hop-by-hop to reserve resources along the path; a data plane that forwards user data packets efficiently using pre-negotiated identifiers; and endpoint management, where origins create streams and targets can accept, refuse, or dynamically join/leave via SCMP primitives. Routers and hosts act as ST agents, maintaining per-stream state to enforce reservations, while the Local Resource Manager (LRM) at each agent handles allocation of bandwidth and buffers. This setup supports unidirectional simplex streams from a single origin to multiple targets, avoiding the overhead of bidirectional connections.[8][10] The protocol accommodates both unicast and multicast topologies through tree-shaped paths, with multicast optimized via network-layer group addresses (e.g., IP multicast ranges like 224.1.0.0–224.1.255.255) where available, reducing bandwidth duplication. Streams are identified by globally unique Stream IDs (SIDs), combining origin address and a host-generated identifier for fast forwarding without full address lookups. Interaction with underlying networks involves ST agents in routers selecting paths via integrated routing functions, negotiating hop identifiers for efficiency, and ensuring end-to-end guarantees across heterogeneous subnets supporting resource reservation.[8][10]Key Mechanisms
The Internet Stream Protocol Version 2 (ST2) employs a resource reservation mechanism that establishes end-to-end streams through a series of control packets, primarily the CONNECT message, which propagates from the stream origin to the designated targets along the intended path. This setup invokes the Local Resource Manager (LRM) at each intermediate node to allocate specific resources, such as bandwidth for data transmission and buffer space to handle varying network conditions, based on a Flow Specification (FlowSpec) that defines the required quality of service parameters like maximum packet size, transmission rate, and priority.[3] Once reservations are confirmed via ACCEPT messages returning to the origin, the stream becomes active, ensuring guaranteed delivery without overcommitment of resources at any hop.[3] For efficient multicast delivery to multiple receivers, ST2 constructs a source-specific routing tree during the initial CONNECT phase, where each node forwards the request to its neighbors toward the targets using an integrated routing function that avoids cycles and minimizes path redundancy. Pruning is achieved through DROP or DISCONNECT control packets, which remove unnecessary branches when targets leave the group, while joining algorithms enable dynamic additions via JOIN messages that extend the tree to new receivers without disrupting existing flows, thereby optimizing bandwidth usage in group communications.[3] Timing and synchronization in ST2 are managed through embedded timestamps in data packets, which indicate the intended transmission time relative to the stream's creation, allowing receivers to reconstruct the original timing and buffer content accordingly. The FlowSpec further specifies maximum end-to-end delay and delay jitter tolerances, enabling applications to control playback rates and mitigate variations introduced by network queuing or transmission delays, thus supporting smooth real-time rendering of continuous media like audio or video.[3] Error handling in ST2 prioritizes timeliness over reliability, deliberately omitting retransmissions to avoid introducing additional delays in real-time streams; instead, it tolerates occasional packet loss as inherent to best-effort networks, with applications expected to implement forward error correction (FEC) at higher layers if needed for enhanced robustness. Control messages such as REFUSE or ERROR report failures like resource unavailability or path disruptions, prompting the origin to reroute or terminate the stream, while reason codes provide diagnostic details without attempting recovery within the protocol itself.[3]Message Formats
The Internet Stream Protocol (ST) employs distinct message formats for control and data transmission to manage real-time streams with resource reservations. Control messages handle stream setup, modification, and teardown, while data messages carry the payload with minimal overhead. These formats evolved across versions, with ST-II (defined in RFC 1190) introducing hop-by-hop identifiers and ST2+ (defined in RFC 1819) simplifying structures by removing such identifiers and adding authentication support.[8][10] Control messages in ST begin with a common header that includes an 8-bit OpCode to identify the type, a 16-bit TotalBytes field for the message length (padded to multiples of 4 bytes), a 16-bit Reference for transaction sequencing, a 16-bit LnkReference to link related requests, the sender's 32-bit IP address, and a 16-bit checksum for integrity.[8][10] Key types include the INVITE equivalent, implemented as CONNECT (OpCode 4 or 5 depending on version), which initiates stream setup by specifying targets, flow specifications, and options like no-recovery flags.[8][10] ACCEPT (OpCode 1) confirms setup with a similar header plus a 32-bit StreamCreationTime timestamp, while REFUSE (OpCode 11 or 15) rejects or terminates streams, including an 8-bit ReasonCode (e.g., for resource unavailability or flow mismatch).[8][10] The stream ID (SID) in ST2+ is a 48-bit identifier formed by combining the 32-bit origin IP address with a 16-bit unique identifier, uniquely identifying streams globally across messages. In ST-II, streams are identified by a 16-bit hop-by-hop ID (HID) in data packets. Sequence numbers appear as monotonically increasing 16-bit references in control headers to ensure ordering. In ST-II, timestamps in data packets use a 64-bit NTP-style format if the T flag is set. ST2+ control PDUs employ 32-bit timestamps for stream creation time.[8][10] Flags in the header, such as the S-bit for disabling recovery or N-bit for no-recovery modes, provide options for stream behavior.[8][10] Data packets in ST prioritize low latency with a compact structure. In ST-II, the header is 8 bytes, comprising a 4-bit version (2), 3-bit priority, 16-bit TotalBytes, 16-bit hop-by-hop ID (HID, reserved values 0-3), and 16-bit checksum, followed by optional 64-bit timestamps if flagged.[8] ST2+ extends this to a 12-byte header, including a protocol ID, version, 3-bit priority for discard decisions (RTP-like), 16-bit length, 16-bit UniqueID and 32-bit origin IP address (forming the 48-bit SID), and checksum, with payload type indicators left to higher layers for application-specific data.[10] This design adapts RTP-inspired fields for ST, minimizing overhead to 12 bytes while supporting encapsulation in IP (protocol number 5).[8][10] Variations between ST-II and ST2+ reflect refinements for efficiency and security. ST-II includes HID fields for per-hop stream identification in multicast trees, absent in ST2+ to reduce complexity.[8][10] ST2+ introduces authentication fields in control messages, such as join authorization levels (0-2) via J/N-bits, to enhance security over ST-II's optional mechanisms, while both versions maintain backward-compatible OpCode structures for core types like CONNECT, ACCEPT, and REFUSE.[10]| Field | Size (bits) | Description | ST-II Specifics | ST2+ Specifics |
|---|---|---|---|---|
| OpCode | 8 | Message type (e.g., 1=ACCEPT, 4=CONNECT) | Includes HID-APPROVE (10) | Includes JOIN (8), JOIN-REJECT (9) |
| TotalBytes | 16 | Total length in bytes | Padded to 4-byte multiples | Same, with SID integration |
| Reference | 16 | Sequence for ordering | Monotonic per sender | Transaction uniqueness |
| SID | 48 (ST2+); 16 (HID in ST-II data) | Global stream identifier | 16-bit HID in data; 80-bit Name in control | 16-bit UniqueID + 32-bit origin IP |
| Timestamp | 64 (ST-II data); 32 (ST2+ control) | Synchronization (NTP-style) | 64-bit in data packets if T-bit set | 32-bit in control PDUs |
| Flags (e.g., S-bit) | Variable | Options like no-recovery | H-bit for HID, P-bit for PTP | N-bit for no-recovery, J/N for auth |
| Checksum | 16 | Header integrity | Covers entire packet | Same, minimal overhead focus |