rfc1190.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,353 行 · 第 1/5 页

CIP Working Group                                               [Page 5]

RFC 1190                Internet Stream Protocol            October 1990


 +--------------------+
 | 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  |    ... |     | 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 1.  Protocol Relationships









CIP Working Group                                               [Page 6]

RFC 1190                Internet Stream Protocol            October 1990


2.      Introduction

   ST has been developed to support efficient delivery of streams of
   packets to either single or multiple destinations in applications
   requiring guaranteed data rates and controlled delay characteristics.
   The motivation for the original protocol was that IP [2] [15] did not
   provide the delay and data rate characteristics necessary to support
   voice applications.

   ST is an internet protocol at the same layer as IP, see Figure 1.  ST
   differs from IP in that IP, as originally envisioned, did not require
   routers (or intermediate systems) to maintain state information
   describing the streams of packets flowing through them.  ST
   incorporates the concept of streams across an internet.  Every
   intervening ST entity maintains state information for each stream
   that passes through it.  The stream state includes forwarding
   information, including multicast support for efficiency, and resource
   information, which allows network or link bandwidth and queues to be
   assigned to a specific stream.  This pre-allocation of resources
   allows data packets to be forwarded with low delay, low overhead, and
   a low probability of loss due to congestion.  The characteristics of
   a stream, such as the number and location of the endpoints, and the
   bandwidth required, may be modified during the lifetime of the
   stream.  This allows ST to give a real time application the
   guaranteed and predictable communication characteristics it requires,
   and is a good vehicle to support an application whose communications
   requirements are relatively predictable.

   ST proved quite useful in several early experiments that involved
   voice conferences in the Internet.  Since that time, ST has also been
   used to support point-to-point streams that include both video and
   voice.  Recently, multimedia conferencing applications have been
   developed that need to exchange real-time voice, video, and pointer
   data in a multi-site conferencing environment.  Multimedia
   conferencing across an internet is an application for which ST
   provides ideal support.  Simulation and wargaming applications [14]
   also place similar requirements on the communication system.  Other
   applications may include scientific visualization between a number of
   workstations and one or more remote supercomputers, and the
   collection and distribution of real-time sensor data from remote
   sensor platforms.  ST may also be useful to support activities that
   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-end
   protocols used directly by applications.  Other transport layer
   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-II

      ST-II supports a wider variety of applications than did the
      original ST.  The differences between ST and ST-II are fairly
      straight forward yet provide great improvements.  Four of the more
      notable differences are:

         1  ST-II is decoupled from the Access Controller (AC).  The
            AC, as well as providing a rudimentary access control
            function, also served as a centralized repository and
            distributor of the conference information.  If an AC is
            necessary, it should be an entity in a higher layer
            protocol.  A large variety of applications such as
            conferencing, distributed simulations, and wargaming can
            be run without an explicit AC.

         2  The basic stream construct of ST-II is a directed tree
            carrying traffic away from a source to all the
            destinations, rather than the original ST's omniplex
            structure.  For example, a conference is composed of a
            number of such trees, one for traffic from each
            participant.  Although there are more (simplex) streams in
            ST-II, each is much simpler to manage, so the aggregate is
            much simpler.  This change has a minimal impact on the
            application.

         3  ST-II defines a number of the robustness and recovery
            mechanisms that were left undefined in the original ST
            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 Agent
            immediately preceding the failure.

         4  ST-II does not make an inherent distinction between
            streams connecting only two communicants and streams among
            an arbitrary number of communicants.

      This memo is the specification for the ST-II Protocol.  Since
      there should be no ambiguity between the original ST specification
      and the specification herein, the protocol is simply called ST
      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 forward
      ST packets between attached networks.

      The remainder of this section gives a brief overview of the ST
      Protocol.  Section 3 (page 17) provides a detailed description of
      the operations required by the protocol.  Section 4 (page 75)
      provides descriptions of the ST Protocol Data Units exchanged


CIP Working Group                                               [Page 8]

RFC 1190                Internet Stream Protocol            October 1990


      between ST entities.  Issues that have not yet been fully
      addressed are presented in Section 5 (page 131).  A glossary and
      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.  A
      subsetted implementation does not have full ST functionality, but
      it can interoperate with other similarly subsetted
      implementations, or with a full implementation, in a predictable
      and consistent manner.  This approach allows an implementation to
      be built and provide service with minimum effort, and gives it an
      immediate and well defined growth path.


   2.2.       Concepts and Terminology

      The ST packet header is not constrained to be compatible with the
      IP packet header, except for the IP Version Number (the first four
      bits) that is used to distinguish ST packets (IP Version 5) from
      IP packets (IP Version 4).  The ST packets, or protocol data units
      (PDUs), can be encapsulated in IP either to provide connectivity
      (possibly with degraded service) across portions of an internet
      that do not provide support for ST, or to allow access to services
      such as security that are not provided directly by ST.

      An internet entity that implements the ST Protocol is called an
      "ST Agent".  We refer to two kinds of ST agents:  "host ST
      agents", also called "host agents" and "intermediate ST agents",
      also called "intermediate agents".  The ST agents functioning as
      hosts are sourcing or sinking data to a higher layer protocol or
      application, while ST agents functioning as intermediate agents
      are forwarding data between directly attached networks.  This
      distinction is not part of the protocol, but is used for
      conceptual purposes only.  Indeed, a given ST agent may be
      simultaneously performing both host and intermediate roles.  Every
      ST agent should be capable of delivering packets to a higher layer
      protocol.  Every ST agent can replicate ST data packets as
      necessary for multi-destination delivery, and is able to send
      packets whether received from a network interface or a higher
      layer protocol.  There are no other kinds of ST agents.

      ST provides applications with an end-to-end flow oriented service
      across an internet.  This service is implemented using objects
      called "streams".  ST data packets are not considered to be
      totally independent as are IP data packets.  They are transmitted
      only as part of a point-to-point or point-to-multi- point stream.
      ST creates a stream during a setup phase before data is
      transmitted.  During the setup phase, routes are selected and
      internetwork resources are reserved.  Except for explicit changes
      to the stream, the routes remain in effect until the stream is
      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 application
            entity traverses on its way to its peer application
            entity(s) that receive it,

         o  the resources allocated to support that transmission of