rfc1819.txt

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

                              Table 1: ST Primitives

2.2  State Diagrams

   It is not sufficient to define the set of ST stream operations. It is
   also necessary to specify when the operations can be legally
   executed.  For this reason, a set of states is now introduced and the
   transitions from one state to the others are specified. States are
   defined with respect to a single stream. The previously defined



Delgrossi & Berger, Editors   Experimental                     [Page 21]

RFC 1819              ST2+ Protocol Specification            August 1995


   stream operations can be legally executed only from an appropriate
   state.

   An ST agent may, with respect to an ST stream, be in one of the
   following states:

o   IDLE: the stream has not been created yet.

o   PENDING: the stream is in the process of being established.

o   ACTIVE: the stream is established and active.

o   ADDING: the stream is established. A stream expansion is underway.

o   CHGING: the stream is established. A stream change is underway.

   Previous experience with ST has lead to limits on stream operations
   that can be executed simultaneously. These restrictions are:


   1.  A single ADD or CHG operation can be processed at one time. If
       an ADD or CHG is already underway, further requests are queued
       by the ST agent and handled only after the previous operation
       has been completed. This also applies to two subsequent
       requests of the same kind, e.g., two ADD or two CHG operations.
       The second operation is not executed until the first one has
       been completed.

   2.  Deleting a stream, leaving a stream, or dropping targets from a
       stream is possible only after stream establishment has been
       completed. A stream is considered to be established when all
       the next-hops of the origin have either accepted or refused the
       stream.  Note that stream refuse is automatically forced after
       timeout if no reply comes from a next-hop.

   3.  An ST agent forwards data only along already established paths
       to the targets, see also Section 3.1. A path is considered to
       be established when the next-hop on the path has explicitly
       accepted the stream. This implies that the target and all other
       intermediate ST agents are ready to handle the incoming data
       packets. In no cases an ST agent will forward data to a
       next-hop ST agent that has not explicitly accepted the stream.
       To be sure that all targets receive the data, an application
       should send the data only after all paths have been
       established, i.e., the stream is established.






Delgrossi & Berger, Editors   Experimental                     [Page 22]

RFC 1819              ST2+ Protocol Specification            August 1995


   4.  It is allowed to send data from the CHGING and ADDING states.
       While sending data from the CHGING state, the quality of
       service to the targets affected by the change should be assumed
       to be the more restrictive quality of service. When sending
       data from the ADDING state, the targets that receive the data
       include at least all the targets that were already part of the
       stream at the time the ADD operation was invoked.

   The rules introduced above require ST agents to queue incoming
   requests when the current state does not allow to process them
   immediately. In order to preserve the semantics, ST agents have to
   maintain the order of the requests, i.e., implement FIFO queuing.
   Exceptionally, the CLOSE request at the origin and the LEAVE request
   at the target may be immediately processed: in these cases, the queue
   is deleted and it is possible that requests in the queue are not
   processed.

   The following state diagrams define the ST service. Separate diagrams
   are presented for the origin and the targets.

   The symbol (a/r)* indicates that all targets in the target list have
   explicitly accepted or refused the stream, or refuse has been forced
   after timeout. If the target list is empty, i.e., it contains no
   targets, the (a/r)* condition is immediately satisfied, so the empty
   stream is created and state ESTBL is entered.

   The separate OPEN and ADD primitives at the target are for conceptual
   purposes only. The target is actually unable to distinguish between
   an OPEN and an ADD. This is reflected in Figure 7 and Table 3 through
   the notation OPEN/ADD.





















Delgrossi & Berger, Editors   Experimental                     [Page 23]

RFC 1819              ST2+ Protocol Specification            August 1995


                        +------------+
                        |            |<-------------------+
            +---------->|    IDLE    |-------------+      |
            |           |            |    OPEN.req |      |
            |           +------------+             |      |
 CLOSE.req  |      CLOSE.req ^   ^ CLOSE.req       V      | CLOSE.req
            |                |   |            +---------+ |
            |                |   |            | PENDING |-|-+ JOIN.reject
            |                |   -------------|         |<|-+
            |    JOIN.reject |                +---------+ |
            |    DROP.req +----------+             |      |
            |       +-----|          |             |      |
            |       |     |  ESTDL   | OPEN.(a/r)* |      |
            |       +---->|          |<------------+      |
            |             +----------+                    |
            |              |  ^  |  ^                     |
            |              |  |  |  |                     |
       +----------+ CHG.req|  |  |  | Add.(a/r)*    +----------+
       |          |<-------+  |  |  +-------------- |          |
       |  CHGING  |           |  |                  |  ADDING  |
       |          |-----------+  +----------------->|          |
       +----------+ CHG.(a/r)*         JOIN.ind     +----------+
           |   ^                         ADD.req        |   ^
           |   |                                        |   |
           +---+                                        +---+
           DROP.req                                    DROP.req
           JOIN.reject                                 JOIN.reject

                  Figure 6: ST Service at the Origin

                 +--------+
                 |        |-----------------------+
                 |  IDLE  |                       |
                 |        |<---+                  | OPEN/ADD.ind
                 +--------+    | CLOSE.ind        | JOIN.req
                     ^         | OPEN/ADD.refuse  |
                     |         | JOIN.refect-ind  |
         CLOSE.ind   |         |                  V
         DROP.ind    |         |             +---------+
         LEAVE.req   |         +-------------|         |
                     |                       | PENDING |
                 +-------+                   |         |
                 |       |                   +---------+
                 | ESTBL |    OPEN/ADD.accept     |
                 |       |<-----------------------+
                 +-------+

                     Figure 7: ST Service at the Target



Delgrossi & Berger, Editors   Experimental                     [Page 24]

RFC 1819              ST2+ Protocol Specification            August 1995


2.3  State Transition Tables

   Table 2 and Table 3 define which primitives can be processed from
   which states and the possible state transitions.

+======================================================================+
|Primitive      |IDLE|    PENDING    |  ESTBL |    CHGING  |    ADDING |
|======================================================================|
|OPEN.req       | ok | -             | -      | -          | -         |
|OPEN.accept-ind| -  |if(a,r)*->ESTBL| -      | -          | -         |
|OPEN.refuse-ind| -  |if(a,r)*->ESTBL| -      | -          | -         |
|ADD.req        | -  | queued        |->ADDING| queued     | queued    |
|ADD.accept-ind | -  | -             | -      | -          |if(a,r)*   |
|               | -  | -             | -      | -          |->ESTBL    |
|ADD.refuse-ind | -  | -             | -      | -          |if(a,r)*   |
|               | -  | -             | -      | -          |->ESTBL    |
|JOIN.ind       | -  | queued        |->ADDING| queued     |queued     |
|JOIN.reject    | -  | OK            | ok     | ok         | ok        |
|DATA.req       | -  | -             | ok     | ok         | ok        |
|CHG.req        | -  | queued        |->CHGING| queued     |queued     |
|CHG.accept-ind | -  | -             | -      |if(a,r)*    | -         |
|               | -  | -             | -      |->ESTBL     | -         |
|CHG.refuse.ind | -  | -             | -      |if(a,r)*    | -         |
|               | -  | -             | -      |->ESTBL     | -         |
|DROP.req       | -  | -             | ok     | ok         | ok        |
|LEAVE.ind      | -  | OK            | ok     | ok         | ok        |
|CLOSE.req      | -  | OK            | ok     | ok         | ok        |
+----------------------------------------------------------------------+
                Table 2: Primitives and States at the Origin

             +======================================================+
             | Primitive       |   IDLE    |  PENDING   |   ESTBL   |
             |======================================================|
             | OPEN/ADD.ind    | ->PENDING | -          | -         |
             | OPEN/ADD.accept | -         | ->ESTBL    | -         |
             | OPEN/ADD.refuse | -         | ->IDLE     | -         |
             | JOIN.req        | ->PENDING | -          | -         |
             | JOIN.reject-ind |-          | ->IDLE     | -         |
             | DATA.ind        | -         | -          | ok        |
             | CHG.ind         | -         | -          | ok        |
             | CHG.accept      | -         | -          | ok        |
             | DROP.ind        | -         | ok         | ok        |
             | LEAVE.req       | -         | ok         | ok        |
             | CLOSE.ind       | -         | ok         | ok        |
             | CHG.ind         | -         | -          | ok        |
             +------------------------------------------------------+
                Table 3: Primitives and States at the Target




Delgrossi & Berger, Editors   Experimental                     [Page 25]

RFC 1819              ST2+ Protocol Specification            August 1995


3.  The ST2 Data Transfer Protocol

   This section presents the ST2 data transfer protocol, ST. First, data
   transfer is described in Section 3.1, then, the data transfer
   protocol functions are illustrated in Section 3.2.

3.1  Data Transfer with ST

   Data transmission with ST is unreliable. An application is not
   guaranteed that the data reaches its destinations and ST makes no
   attempts to recover from packet loss, e.g., due to the underlying
   network. However, if the data reaches its destination, it should do
   so according to the quality of service associated with the stream.

   Additionally, ST may deliver data corrupted in transmission. Many
   types of real-time data, such as digital audio and video, require
   partially correct delivery only. In many cases, retransmitted packets
   would arrive too late to meet their real-time delivery requirements.
   On the other hand, depending on the data encoding and the particular
   application, a small number of errors in stream data are acceptable.
   In any case, reliability can be provided by layers on top of ST2 if
   needed.

   Also, no data fragmentation is supported during the data transfer
   phase. The application is expected to segment its data PDUs according
   to the minimum MTU over all paths in the stream. The application
   receives information on the MTUs relative to the paths to the targets
   as part of the ACCEPT message, see Section 8.6. The minimum MTU over
   all paths can be calculated from the MTUs relative to the single
   paths. ST agents silently discard too long data packets, see also
   Section 5.1.1.

   An ST agent forwards the data only along already established paths to
   targets. A path is considered to be established once the next-hop ST
   agent on the path sends an ACCEPT message, see Section 2.2. This
   implies that the target and all other intermediate ST agents on the
   path to the target are ready to handle the incoming data packets. In
   no cases will an ST agent forward data to a next-hop ST agent that
   has not explicitly accepted the stream.

   To be reasonably sure that all targets receive the data with the
   desired quality of service, an application should send the data only
   after the whole stream has been established. Depending on the local
   API, an application may not be prevented from sending data before the
   completion of stream setup, but it should be aware that the data
   could be lost or not reach all intended targets. This behavior may
   actually be desirable to applications, such as those application that
   have multiple targets which can each process data as soon as it is