rfc1190.txt

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

      rates, including bursts of varying rate and duration, there is an
      opportunity to provide service to more subscribers by providing
      guaranteed service for the average data rate of each stream, and
      reserving additional network capacity, shared among all streams,
      to service the bursts.  This concept has been recognized by analog
      voice network providers leading to the principle of time assigned
      speech interpolation (TASI) in which only the talkspurts of a
      speech conversation are transmitted, and, during silence periods,
      the circuit can be used to send the talkspurts of other
      conversations.  The FlowSpec is intended to assist algorithms that
      perform similar kinds of functions.  We do not propose such
      algorithms here, but rather expect that this will be an area for
      experimentation.  To allow for experiments, and a range of ways
      that application traffic might be characterized, a "DutyFactor" is
      included in the FlowSpec and we expect that a "burst descriptor"
      will also be needed.

      The FlowSpec will need to be revised as experience is gained with
      connections involving numerous participants using multiple media
      across heterogeneous internetworks.  We feel a change of the
      FlowSpec does not necessarily require a new version of ST, it only
      requires the FlowSpec version number be updated and software to
      manage the new FlowSpec to be distributed.  We further suggest
      that if the change to the FlowSpec involves additional information
      for improved operation, such as a burst descriptor, that it be
      added to the end of the FlowSpec and that the current parameters
      be maintained so that obsolete software can be used to process the
      current parameters with minimum modifications.

























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


                      ****                      ****
                     *    *     ST Agent 1     *    *       +---+
                    *      *------- o ---------*    *-------+ B |
                    *      *                   *    *       +---+
                    *      *                    ****
      +---+         *      *                     |
      |   |         *      *                     |
      | A +---------*      *                     o ST Agent 3
      |   |         *      *                     |
      +---+         *      *                     |
                    *      *                    ***
                    *      *                   *   *        +---+
                    *      *    ST Agent 2    *     *-------+ C |
                    *      *------- o --------*     *       +---+
                     *    *                   *     *
                      ****                    *     *
                                              *     *
                                 +---+        *     *       +---+
                                 | E +--------*     *-------+ D |
                                 +---+         *   *        +---+
                                                ***

         Figure 2.  Topology Used in Protocol Exchange Diagrams






                      ****     ST Agent 1       ****
                     * +--+---14--- o -----15--+----+--44---+---+
                    *  | +-+--11---   -----16--+-+  *       | B |
                    *  | | *                   * |+-+--45---+---+
                    *  | | *                    *++*
      +---+         *  | | *                  34 ||32
      |   +----4----+--+ | *                     ||
      | A +----6----+----+ *                     o ST Agent 3
      |   +----5----+---+  *                     |
      +---+         *   |  *                     | 33
                    *   |  *       ST           *+*
                    *   |  *      Agent        * | *
                    *   |  *        2 -----24-+--+  *       +---+
                    *   +--+--23--- o -----25-+-----+--54---+ C |
                     *    *           -----26-+---+ *       +---+
                      ****            -----27-+-+ | *
                                              * | | *
                                 +---+        * | | *       +---+
                                 | E +---74---+-+ +-+--64---+ D |
                                 +---+         *   *        +---+
                                                ***

         Figure 3.  Virtual Link Identifiers for SCMP Messages


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


3.      ST Control Message Protocol Functional Description

   This section contains a functional description of the ST Control
   Message Protocol (SCMP); Section 4 (page 75) specifies the formats of
   the control message PDUs.  We begin with a description of stream
   setup.  Mechanisms used to deal with the exceptional cases are then
   presented.  Complications due to options that an application or a ST
   agent may select are then detailed.  Once a stream has been
   established, the data transfer phase is entered; it is described.
   Once the data transfer phase has been completed, the stream must be
   torn down and resources released; the control messages used to
   perform this function are presented.  The resources or participants
   of a stream may be changed during the lifetime of the stream; the
   procedures to make changes are described.  Finally, the section
   concludes with a description of some ancillary functions, such as
   failure detection and recovery, HID negotiation, routing, security,
   etc.

   To help clarify the SCMP exchanges used to setup and maintain ST
   streams, we have included a series of figures in this section.  The
   protocol interactions in the figures assume the topology shown in
   Figure 2.  The figures, taken together,

    o  Create a stream from an application at A to three peers at B,
       C and D,

    o  Add a peer at E,

    o  Disconnect peers B and C, and

    o  D drops out of the stream.

   Other figures illustrate exchanges related to failure recovery.

   In order to make the dispatch function within SCMP more uniform and
   efficient, each end of a hop is assigned, by the agent at that end, a
   Virtual Link Identifier that uniquely (within that agent) identifies
   the hop and associates it with a particular stream's state
   machine(s).  The identifier at the end of a link that is sending a
   message is called the Sender Virtual Link Identifier (SVLId);  that
   at the receiving end is called the Receiver Virtual Link Identifier
   (RVLId).  Whenever one agent sends a control message for the other to
   receive, the sender will place the receiver's identifier into the
   RVLId field of the message and its own identifier in the SVLId field.
   When a reply to the message is sent, the values in SVLId and RVLId
   fields will be reversed, reflecting the fact the sender and receiver
   roles are reversed.  VLIds with values zero through three are
   received and should not be assigned in response to CONNECT messages.
   Figure 3 shows the hops that will be used in the examples and
   summarizes the VLIds that will be assigned to them.




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


   Similarly, Figure 4 summarizes the HIDs that will eventually be
   negotiated as the stream is created.

                      ****     ST Agent 1       ****
                     *  +>+--1200-> o -------->+--->+-3600->+---+
                    *   ^  *                   *    *       | B |
                    *   |  *                   * +->+-6000->+---+
                    *   |  *                    *+**
      +---+         *   |  *                     ^
      |   +-------->+-->+  *                     |
      | A |         *      *                     o St Agent 3
      |   +-------->+-->+  *                     ^
      +---+         *   |  *                     | 4801
                    *   |  *                    *+*
                    *   V  *   ST Agent 2      * ^ *        +---+
                     *  +>+--2400-> o ------->+->+->+-4800->+ C |
                      ****                    *  |  * 4801  +---+
                                              *  |  *
                                 +---+        *  V  *       +---+
                                 | E +<-4800--+<-+->+-4800->+ D |
                                 +---+         *   *  4801  +---+
                                                ***

             Figure 4.  HIDs Assigned for ST User Packets


   Some of the diagrams that follow form a progression.  For example,
   the steps required initially to establish a connection are spread
   across five figures.  Within a progression, the actions on the first
   diagram are numbered 1.1, 1.2, etc.;  within the second diagram they
   are numbered 2.1, 2.2, etc.  Points where control leaves one diagram
   to enter another are identified with a continuation arrow "-->>", and
   are continued with "[a.b] >>-->" in the other diagram.  The number in
   brackets shows the label where control left the earlier diagram.  The
   reception of simple acknowledgments, e.g., ACKs, in one figure from
   another is omitted for clarity.


   3.1.       Stream Setup


      This section presents a description of stream setup assuming that
      everything succeeds -- HIDs are approved, any required resources
      are available, and the routing is correct.


      3.1.1.        Initial Setup at the Origin

         As described in Section 2.3 (page 11), the application has
         collected the information necessary to determine the




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


         participants in the communication before passing it to the host
         ST agent at the origin.  The host ST agent will take this
         information, allocate a Name for the stream (see Section
         4.2.2.8 (page 87)), and create a stream.


      3.1.2.        Invoking the Routing Function

         An ST agent that is setting up a stream invokes a routing
         function to find a path to reach each of the targets specified
         in the TargetList.  This is similar to the routing decision in
         IP.  However, in this case the route is to a multitude of
         targets rather than to a single destination.

         The set of next-hops that an ST agent would select is not
         necessarily the same as the set of next hops that IP would
         select given a number of independent IP datagrams to the same
         destinations.  The routing algorithm may attempt to optimize
         parameters other than the number of hops that the packets will
         take, such as delay, local network bandwidth consumption, or
         total internet bandwidth consumption.

         The result of the routing function is a set of next-hop ST
         agents and the parameters of the intervening network(s).  The
         latter permit the ST agent to determine whether the selected
         network has the resources necessary to support the level of
         service requested in the FlowSpec.


      3.1.3.        Reserving Resources

         The intent of ST is to provide a guaranteed level of service by
         reserving internet resources for a stream during a setup phase
         rather than on a per packet basis.  The relevant resources are
         not only the forwarding information maintained by the ST
         agents, but also packet switch processor bandwidth and buffer
         space, and network bandwidth and multicast group identifiers.
         Reservation of these resources can help to increase the
         reliability and decrease the delay and delay variance with
         which data packets are delivered.  The FlowSpec contains all
         the information needed by the ST agent to allocate the
         necessary resources.  When and how these resources are