rfc1819.txt

RFC 的详细文档！

   and 4 is called downstream, the direction towards the Origin node
   upstream. ST agents that are one hop away from a given node are
   called previous-hops in the upstream, and next-hops in the downstream
   direction.

   Streams are maintained using SCMP messages. Typical SCMP messages are
   CONNECT and ACCEPT to build a stream, DISCONNECT and REFUSE to close
   a stream, CHANGE to modify the quality of service associated with a
   stream, and JOIN to request to be added to a stream.

   Each ST agent maintains state information describing the streams
   flowing through it. It can actively gather and distribute such
   information. It can recognize failed neighbor ST agents through the
   use of periodic HELLO message exchanges. It can ask other ST agents
   about a particular stream via a STATUS message. These ST agents then
   send back a STATUS-RESPONSE message. NOTIFY messages can be used to
   inform other ST agents of significant events.

   ST2 offers a wealth of functionalities for stream management. Streams
   can be grouped together to minimize allocated resources or to process
   them in the same way in case of failures. During audio conferences,
   for example, only a limited set of participants may talk at once.
   Using the group mechanism, resources for only a portion of the audio
   streams of the group need to be reserved. Using the same concept, an
   entire group of related audio and video streams can be dropped if one
   of them is preempted.

1.5.2  Data Transmission

   Data transfer in ST2 is simplex in the downstream direction. Data
   transport through streams is very simple. ST2 puts only a small
   header in front of the user data. The header contains a protocol
   identification that distinguishes ST2 from IP packets, an ST2 version



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


   number, a priority field (specifying a relative importance of streams
   in cases of conflict), a length counter, a stream identification, and
   a checksum. These elements form a 12-byte header.

   Efficiency is also achieved by avoiding fragmentation and reassembly
   on all agents. Stream establishment yields a maximum message size for
   data packets on a stream. This maximum message size is communicated
   to the upper layers, so that they provide data packets of suitable
   size to ST2.

   Communication with multiple next-hops can be made even more efficient
   using MAC Layer multicast when it is available. If a subnet supports
   multicast, a single multicast packet is sufficient to reach all
   next-hops connected to this subnet. This leads to a significant
   reduction of the bandwidth requirements of a stream. If multicast is
   not provided, separate packets need to be sent to each next-hop.

   As ST2 relies on reservation, it does not contain error correction
   mechanisms features for data exchange such as those found in TCP. It
   is assumed that 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. Also, 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 when
   needed.

1.5.3  Flow Specification

   As part of establishing a connection, SCMP handles the negotiation of
   quality-of-service parameters for a stream. In ST2 terminology, these
   parameters form a flow specification (FlowSpec) which is associated
   with the stream. Different versions of FlowSpecs exist, see
   [RFC1190], [DHHS92] and [RFC1363], and can be distinguished by a
   version number.  Typically, they contain parameters such as average
   and maximum throughput, end-to-end delay, and delay variance of a
   stream. SCMP itself only provides the mechanism for relaying the
   quality-of-service parameters.

   Three kinds of entities participate in the quality-of-service
   negotiation: application entities on the origin and target sites as
   the service users, ST agents, and local resource managers (LRM). The
   origin application supplies the initial FlowSpec requesting a
   particular service quality. Each ST agent which obtains the FlowSpec
   as part of a connection establishment message, it presents the local
   resource manager with it. ST2 does not determine how resource
   managers make reservations and how resources are scheduled according
   to these reservations; ST2, however, assumes these mechanisms as its



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


   basis.

   An example of the FlowSpec negotiation procedure is illustrated in
   Figure 4. Depending on the success of its local reservations, the LRM
   updates the FlowSpec fields and returns the FlowSpec to the ST agent,
   which passes it downstream as part of the connection message.
   Eventually, the FlowSpec is communicated to the application at the
   target which may base its accept/reject decision for establishing the
   connection on it and may finally also modify the FlowSpec. If a
   target accepts the connection, the (possibly modified) FlowSpec is
   propagated back to the origin which can then calculate an overall
   service quality for all targets. The application entity at the origin
   may later request a CHANGE to adjust reservations.

                 Origin                 Router               Target 1
                +------+      1a       +------+      1b      +------+
                |      |-------------->|      |------------->|      |
                +------+               +------+              +------+
                 ^  | ^                                          |
                 |  | |                    2                     |
                 |  | +------------------------------------------+
                 +  +
 +-------------+  \  \             +-------------+       +-------------+
 |Max Delay: 12|   \  \            |Max Delay: 12|       |Max Delay: 12|
 |-------------|    \  \           |-------------|       |-------------|
 |Min Delay:  2|     \  \          |Min Delay:  5|       |Min Delay:  9|
 |-------------|      \  \         |-------------|       |-------------|
 |Max Size:4096|       +  +        |Max Size:2048|       |Max Size:2048|
 +-------------+       |  |        +-------------+       +-------------+
    FlowSpec           |  | 1
                       |  +---------------+
                       |                  |
                       |                  V
                     2 |               +------+
                       +---------------|      |
                                       +------+
                                       Target 2
                                   +-------------+
                                   |Max Delay: 12|
                                   |-------------|
                                   |Min Delay:  4|
                                   |-------------|
                                   |Max Size:4096|
                                   +-------------+

        Figure 4:  Quality-of-Service Negotiation with FlowSpecs





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


1.6  Outline of This Document

   This document contains the specification of the ST2+ version of the
   ST2 protocol. In the rest of the document, whenever the terms "ST" or
   "ST2" are used, they refer to the ST2+ version of ST2.

   The document is organized as follows:

o   Section 2 describes the ST2 user service from an application point
    of view.

o   Section 3 illustrates the ST2 data transfer protocol, ST.

o   Section 4 through Section 8 specify the ST2 setup protocol, SCMP.

o   the ST2 flow specification is presented in Section 9.

o   the formats of protocol elements and PDUs are defined in Section 10.

2.  ST2 User Service Description

   This section describes the ST user service from the high-level point
   of view of an application. It defines the ST stream operations and
   primitive functions. It specifies which operations on streams can be
   invoked by the applications built on top of ST and when the ST
   primitive functions can be legally executed. Note that the presented
   ST primitives do not specify an API. They are used here with the only
   purpose of illustrating the service model for ST.

2.1  Stream Operations and Primitive Functions

   An ST application at the origin may create, expand, reduce, change,
   send data to, and delete a stream. When a stream is expanded, new
   targets are added to the stream; when a stream is reduced, some of
   the current targets are dropped from it. When a stream is changed,
   the associated quality of service is modified.

   An ST application at the target may join, receive data from, and
   leave a stream. This translates into the following stream operations:

o   OPEN: create new stream [origin], CLOSE: delete stream [origin],

o   ADD: expand stream, i.e., add new targets to it [origin],

o   DROP: reduce stream, i.e., drop targets from it [origin],

o   JOIN: join a stream [target], LEAVE: leave a stream [target],




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


o   DATA: send data through stream [origin],

o   CHG: change a stream's QoS [origin],

   Each stream operation may require the execution of several primitive
   functions to be completed. For instance, to open a new stream, a
   request is first issued by the sender and an indication is generated
   at one or more receivers; then, the receivers may each accept or
   refuse the request and the correspondent indications are generated at
   the sender. A single receiver case is shown in Figure 5 below.

                Sender             Network             Receiver
                  |                   |                   |
     OPEN.req     |                   |                   |
                  |-----------------> |                   |
                  |                   |-----------------> |
                  |                   |                   | OPEN.ind
                  |                   |                   | OPEN.accept
                  |                   |<----------------- |
                  |<----------------- |                   |
  OPEN.accept-ind |                   |                   |
                  |                   |                   |

           Figure 5: Primitives for the OPEN Stream Operation



























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


   Table 1 defines the ST service primitive functions associated to each
   stream operation. The column labelled "O/T" indicates whether the
   primitive is executed at the origin or at the target.

           +===================================================+
           |Primitive      | Descriptive                   |O/T|
           |===================================================|
           |OPEN.req       | open a stream                 | O |
           |OPEN.ind       | connection request indication | T |
           |OPEN.accept    | accept stream                 | T |
           |OPEN.refuse    | refuse stream                 | T |
           |OPEN.accept-ind| connection accept indication  | O |
           |OPEN.refuse-ind| connection refuse indication  | O |
           |ADD.req        | add targets to stream         | O |
           |ADD.ind        | add request indication        | T |
           |ADD.accept     | accept stream                 | T |
           |ADD.refuse     | refuse stream                 | T |
           |ADD.accept-ind | add accept indication         | O |
           |ADD.refuse-ind | add refuse indication         | O |
           |JOIN.req       | join a stream                 | T |
           |JOIN.ind       | join request indication       | O |
           |JOIN.reject    | reject a join                 | O |