rfc1819.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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.
   Data packets are delivered with the quality of service associated
   with the stream.

   Data packets contain a globally unique stream identifier that
   indicates which stream they belong to. The stream identifier is also
   known by the setup protocol, which uses it during stream
   establishment. The data transfer protocol for ST2, known simply as
   ST, is completely defined by this document.