rfc1190.txt

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

      The end-users of a stream are called the "participants" in the
      stream.  Data travels in a single direction through any given
      stream.  The host agent that transmits the data into the stream is
      called the "origin", and the host agents that receive the data are
      called the "targets".  Thus, for any stream one participant is the
      origin and the others are the targets.

      A stream is "multi-destination simplex" since data travels across
      it in only one direction:  from the origin to the targets.  A
      stream can be viewed as a directed tree in which the origin is the
      root, all the branches are directed away from the root toward the
      targets, which are the leaves.  A "hop" is an edge of that tree.
      The ST agent that is on the end of an edge in the direction toward
      the origin is called the "previous-hop ST agent", or the
      "previous-hop".  The ST agents that are one hop away from a
      previous-hop ST agent in the direction toward the targets are
      called the "next-hop ST agents", or the "next-hops".  It is
      possible that multiple edges between a previous-hop and several
      next-hops are actually implemented by a network level multicast
      group.

      Packets travel across a hop for one of two purposes:  data or
      control.  For ST data packet handling, hops are marked by "Hop
      IDentifiers" (HIDs) used for efficient forwarding instead of the
      stream's Name.  A HID is negotiated among several agents so that
      data forwarding can be done efficiently on both a point-to-point
      and multicast basis.  All control message exchange is done on a
      point-to-point basis between a pair of agents.  For control
      message handling, Virtual Link Identifiers are used to quickly
      dispatch the control messages to the proper stream's state
      machine.




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


      ST requires routing decisions to be made at several points in the
      stream setup and management process.  ST assumes that an
      appropriate routing algorithm exists to which ST has access; see
      Section 3.8.1 (page 69).  However, routing is considered to be a
      separate issue.  Thus neither the routing algorithm nor its
      implementation is specified here.  A routing algorithm may attempt
      to minimize the number of hops to the target(s), or it may be more
      intelligent and attempt to minimize the total internet resources
      consumed.  ST operates equally well with any reasonable routing
      algorithm.  The availability of a source routing option does not
      eliminate the need for an appropriate routing algorithm in ST
      agents.


   2.3.       Relationship Between Applications and ST

      It is the responsibility of an ST application entity to exchange
      information among its peers, usually via IP, as necessary to
      determine the structure of the communication before establishing
      the ST stream.  This includes:

         o  identifying the participants,

         o  determining which are targets for which origins,

         o  selecting the characteristics of the data flow between any
            origin and its target(s),

         o  specifying the protocol that resides above ST,

         o  identifying the Service Access Point (SAP), port, or
            socket relevant to that protocol at every participant, and

         o  ensuring security, if necessary.

      The protocol layer above ST must pass such information down to the
      ST protocol layer when creating a stream.

      ST uses a flow specification, abbreviated herein as "FlowSpec", to
      describe the required characteristics of a stream.  Included are
      bandwidth, delay, and reliability parameters.  Additional
      parameters may be included in the future in an extensible manner.
      The FlowSpec describes both the desired values and their minimal
      allowable values.  The ST agents thus have some freedom in
      allocating their resources.  The ST agents accumulate information
      that describes the characteristics of the chosen path and pass
      that information to the origin and the targets of the stream.

      ST stream setup control messages carry some information that is
      not specifically relevant to ST, but is passed through the
      interface to the protocol that resides above ST.  The "next



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


      protocol identifier" ("NextPcol") allows ST to demultiplex streams
      to a number of possible higher layer protocols.  The SAP
      associated with each participant allows the higher layer protocol
      to further demultiplex to a specific application entity.  A
      UserData parameter is provided;  see Section 4.2.2.16 (page 98).


   2.4.       ST Control Message Protocol

      ST agents create and manage a stream using the ST Control Message
      Protocol (SCMP).  Conceptually, SCMP resides immediately above ST
      (as does ICMP above IP) but is an integral part of ST.  Control
      messages are used to:

         o  create streams,

         o  refuse creation of a stream,

         o  delete a stream in whole or in part,

         o  negotiate or change a stream's parameters,

         o  tear down parts of streams as a result of router or
            network failures, or transient routing inconsistencies,
            and

         o  reroute around network or component failures.

      SCMP follows a request-response model.  SCMP reliability is
      ensured through use of retransmission after timeout;  see Section
      3.7.6 (page 66).

      An ST application that will transmit data requests its local ST
      agent, the origin, to create a stream.  While only the origin
      requests creation of a stream, all the ST agents from the origin
      to the targets participate in its creation and management.  Since
      a stream is simplex, each participant that wishes to transmit data
      must request that a stream be created.

      An ST agent that receives an indication that a stream is being
      created must:

         1  negotiate a HID with the previous-hop identifying the
            stream,

         2  map the list of targets onto a set of next-hop ST agents
            through the routing function,

         3  reserve the local and network resources required to
            support the stream,




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


         4  update the FlowSpec, and

         5  propagate the setup information and partitioned target
            list to the next-hop ST agents.

      When a target receives the setup message, it must inquire from the
      specified application process whether or not it is willing to
      accept the stream, and inform the origin accordingly.

      Once a stream is established, the origin can safely send data.  ST
      and its implementations are optimized to allow fast and efficient
      forwarding of data packets by the ST agents using the HIDs, even
      at the cost of adding overhead to stream creation and management.
      Specifically, the forwarding decisions, that is, determining the
      set of next-hop ST agents to which a data packet belonging to a
      particular stream will be sent, are made during the stream setup
      phase.  The shorthand HIDs are negotiated at that time, not only
      to reduce the data packet header size, but to access efficiently
      the stream's forwarding information.  When possible, network-layer
      multicast is used to forward a data packet to multiple next-hop ST
      agents across a network.  Note that when network-layer multicast
      is used, all members of the multicast group must participate in
      the negotiation of a common HID.

      An established stream can be modified by adding or deleting
      targets, or by changing the network resources allocated to it.  A
      stream may be torn down by either the origin or the targets.  A
      target can remove itself from a stream leaving the others
      unaffected.  The origin can similarly remove any subset of the
      targets from its stream leaving the remainder unaffected.  An
      origin can also remove all the targets from the stream and
      eliminate the stream in its entirety.

      A stream is monitored by the involved ST agents.  If they detect a
      failure, they can attempt recovery.  In general, this involves
      tearing down part of the stream and rebuilding it to bypass the
      failed component(s).  The rebuilding always occurs from the origin
      side of the failure.  The origin can optionally specify whether
      recovery is to be attempted automatically by intermediate ST
      agents or whether a failure should immediately be reported to the
      origin.  If automatic recovery is selected but an intermediate
      agent determines it cannot effect the repair, it propagates the
      failure information backward until it reaches an agent that can
      effect repair.  If the failure information propagates back to the
      origin, then the application can decide if it should abort or
      reattempt the recovery operation.








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


      Although ST supports an arbitrary connection structure, we
      recognize that certain stream topologies will be common and
      justify special features, or options, which allow for optimized
      support.  These include:

         o  streams with only a single target (see Section 3.6.2 (page
            44)), and

         o  pairs of streams to support full duplex communication
            between two points (see Section 3.6.3 (page 45)).

      These features allow the most frequently occurring topologies to
      be supported with less setup delay, with fewer control messages,
      and with less overhead than the more general situations.


   2.5.       Flow Specifications

      Real time data, such as voice and video, have predictable
      characteristics and make specific demands of the networks that
      must transfer it.  Specifically, the data may be transmitted in
      packets of a constant size that are produced at a constant rate.
      Alternatively, the bandwidth may vary, due either to variable
      packet size or rate, with a predefined maximum, and perhaps a
      non-zero minimum.  The variation may also be predictable based on
      some model of how the data is generated.  Depending on the
      equipment used to generate the data, the packet size and rate may
      be negotiable.  Certain applications, such as voice, produce
      packets at the given rate only some of the time.  The networks
      that support real time data must add minimal delay and delay
      variance, but it is expected that they will be non-zero.

      The FlowSpec is used for three purposes.  First, it is used in the
      setup message to specify the desired and minimal packet size and
      rate required by the origin.  This information is used by ST
      agents when they attempt to reserve the resources in the
      intervening networks.  Second, when the setup message reaches the
      target, the FlowSpec contains the packet size and rate that was
      actually obtained along the path from the origin, and the accrued
      mean delay and delay variance expected for data packets along that
      path.  This information is used by the target to determine if it
      wishes to accept the connection.  The target may reduce reserved
      resources if it wishes to do so and if the possibility is still
      available.  Third, if the target accepts the connection, it
      returns the updated FlowSpec to the origin, so that the origin can
      decide if it still wishes to participate in the stream with the
      characteristics that were actually obtained.







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


      When the data transmitted by stream users is generated at varying