rfc1819.txt
字号:
1.1 What is ST2?
The Internet Stream Protocol, Version 2 (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.
DATA PATH CONTROL PATH
========= ============
Upper +------------------+ +---------+
Layer | Application data | | Control |
+------------------+ +---------+
| |
| V
| +-------------------+
SCMP | | SCMP | |
| +-------------------+
| |
V V
+-----------------------+ +------------------------+
ST | ST | | | ST | | |
+-----------------------+ +------------------------+
D-bit=1 D-bit=0
Figure 1: ST2 Data and Control Path
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
Delgrossi & Berger, Editors Experimental [Page 6]
RFC 1819 ST2+ Protocol Specification August 1995
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 as shown in Figure 1.
+--------------------+
| Conference Control |
+--------------------+
+-------+ +-------+ |
| Video | | Voice | | +-----+ +------+ +-----+ +-----+ Application
| Appl | | Appl | | | SNMP| |Telnet| | FTP | ... | | Layer
+-------+ +-------+ | +-----+ +------+ +-----+ +-----+
| | | | | | |
V V | | | | | ------------
+-----+ +-----+ | | | | |
| PVP | | NVP | | | | | |
+-----+ +-----+ + | | | |
| \ | \ \ | | | |
| +-----|--+-----+ | | | |
| Appl.|control V V V V V
| ST data | +-----+ +-------+ +-----+
| & control| | UDP | | TCP | ... | RTP | Transport
| | +-----+ +-------+ +-----+ Layer
| /| / | \ / / | / /|
|\ / | +------+--|--\-----+-/--|--- ... -+ / |
| \ / | | | \ / | / |
| \ / | | | \ +----|--- ... -+ | -----------
| \ / | | | \ / | |
| V | | | V | |
| +------+ | | | +------+ | +------+ |
| | SCMP | | | | | ICMP | | | IGMP | | Internet
| +------+ | | | +------+ | +------+ | Layer
| | | | | | | | |
V V V V V V V V V
+-----------------+ +-----------------------------------+
| STream protocol |->| Internet Protocol |
+-----------------+ +-----------------------------------+
| \ / |
| \ / |
| X | ------------
| / \ |
| / \ |
VV VV
+----------------+ +----------------+
| (Sub-) Network |...| (Sub-) Network | (Sub-)Network
| Protocol | | Protocol | Layer
+----------------+ +----------------+
Figure 2. Protocol Relationships
Delgrossi & Berger, Editors Experimental [Page 7]
RFC 1819 ST2+ Protocol Specification August 1995
1.2 ST2 and IP
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 is represented in Figure 2.
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 in Figure 2 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.
In Figure 2, the RTP protocol is shown as an example of transport
layer on top of ST2. Others include the Packet Video Protocol (PVP)
[Cole81], the Network Voice Protocol (NVP) [Cohe81], and others such
as the Heidelberg Transport Protocol (HeiTP) [DHHS92].
1.3 Protocol History
The first version of ST was published in the late 1970's and was used
throughout the 1980's for experimental transmission of voice, video,
and distributed simulation. The experience gained in these
applications led to the development of the revised protocol version
ST2. The revision extends the original protocol to make it more
complete and more applicable to emerging multimedia environments. The
specification of this protocol version is contained in Internet RFC
1190 which was published in October 1990 [RFC1190].
With more and more developments of commercial distributed multimedia
applications underway and with a growing dissatisfaction at the
transmission quality for audio and video over IP in the MBONE,
interest in ST2 has grown over the last years. Companies have
products available incorporating the protocol. The BERKOM MMTS
project of the German PTT [DeAl92] uses ST2 as its core protocol for
Delgrossi & Berger, Editors Experimental [Page 8]
RFC 1819 ST2+ Protocol Specification August 1995
the provision of multimedia teleservices such as conferencing and
mailing. In addition, implementations of ST2 for Digital Equipment,
IBM, NeXT, Macintosh, PC, Silicon Graphics, and Sun platforms are
available.
In 1993, the IETF started a new working group on ST2 as part of
ongoing efforts to develop protocols that address resource
reservation issues. The group's mission was to clean up the existing
protocol specification to ensure better interoperability between the
existing and emerging implementations. It was also the goal to
produce an updated experimental protocol specification that reflected
the experiences gained with the existing ST2 implementations and
applications. Which led to the specification of the ST2+ protocol
contained in this document.
1.3.1 RFC1190 ST and ST2+ Major Differences
The protocol changes from RFC1190 were motivated by protocol
simplification and clarification, and codification of extensions in
existing implementations. This section provides a list of major
differences, and is probably of interest only to those who have
knowledge of RFC1190. The major differences between the versions are:
o Elimination of "Hop IDentifiers" or HIDs. HIDs added much complexity
to the protocol and was found to be a major impediment to
interoperability. HIDs have been replaced by globally unique
identifiers called "Stream IDentifiers" or SIDs.
o Elimination of a number of stream options. A number of options were
found to not be used by any implementation, or were thought to add
more complexity than value. These options were removed. Removed
options include: point-to-point, full-duplex, reverse charge, and
source route.
o Elimination of the concept of "subset" implementations. RFC1190
permitted subset implementations, to allow for easy implementation
and experimentation. This led to interoperability problems. Agents
implementing the protocol specified in this document, MUST implement
the full protocol. A number of the protocol functions are best-
effort. It is expected that some implementations will make more
effort than others in satisfying particular protocol requests.
o Clarification of the capability of targets to request to join a
steam. RFC1190 can be interpreted to support target requests, but
most implementors did not understand this and did not add support
for this capability. The lack of this capability was found to be a
significant limitation in the ability to scale the number of
participants in a single ST stream. This clarification is based on
Delgrossi & Berger, Editors Experimental [Page 9]
RFC 1819 ST2+ Protocol Specification August 1995
work done by IBM Heidelberg.
o Separation of functions between ST and supporting modules. An effort
was made to improve the separation of functions provided by ST and
those provided by other modules. This is reflected in reorganization
of some text and some PDU formats. ST was also made FlowSpec
independent, although it does define a FlowSpec for testing and
interoperability purposes.
o General reorganization and re-write of the specification. This
document has been organized with the goal of improved readability
and clarity. Some sections have been added, and an effort was made
to improve the introduction of concepts.
1.4 Supporting Modules for ST2
ST2 is one piece of a larger mosaic. This section presents the
overall communication architecture and clarifies the role of ST2 with
respect to its supporting modules.
ST2 proposes a two-step communication model. In the first step, the
real-time channels for the subsequent data transfer are built. This
is called stream setup. It includes selecting the routes to the
destinations and reserving the correspondent resources. In the second
step, the data is transmitted over the previously established
streams. This is called data transfer. While stream setup does not
have to be completed in real-time, data transfer has stringent real-
time requirements. The architecture used to describe the ST2
communication model includes:
o a data transfer protocol for the transmission of real-time data
over the established streams,
o a setup protocol to establish real-time streams based on the flow
specification,
o a flow specification to express user real-time requirements,
o a routing function to select routes in the Internet,
o a local resource manager to appropriately handle resources involved
in the communication.
This document defines a data protocol (ST), a setup protocol (SCMP),
and a flow specification (ST2+ FlowSpec). It does not define a
routing function and a local resource manager. However, ST2 assumes
their existence.
Delgrossi & Berger, Editors Experimental [Page 10]
RFC 1819 ST2+ Protocol Specification August 1995
Alternative architectures are possible, see [RFC1633] for an example
alternative architecture that could be used when implementing ST2.
1.4.1 Data Transfer Protocol
The data transfer protocol defines the format of the data packets
belonging to the stream. Data packets are delivered to the targets
along the stream paths previously established by the setup protocol.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -