rfc1819.txt

RFC 的详细文档！

   Data packets are delivered with the quality of service associated
   with the stream.

   Data packets contain a globally unique stream identifier that
   indicates which stream they belong to. The stream identifier is also
   known by the setup protocol, which uses it during stream
   establishment. The data transfer protocol for ST2, known simply as
   ST, is completely defined by this document.

1.4.2  Setup Protocol

   The setup protocol is responsible for establishing, maintaining, and
   releasing real-time streams. It relies on the routing function to
   select the paths from the source to the destinations. At each
   host/router on these paths, it presents the flow specification
   associated with the stream to the local resource manager. This causes
   the resource managers to reserve appropriate resources for the
   stream.  The setup protocol for ST2 is called Stream Control Message
   Protocol, or SCMP, and is completely defined by this document.

1.4.3  Flow Specification

   The flow specification is a data structure including the ST2
   applications' QoS requirements. At each host/router, it is used by
   the local resource manager to appropriately handle resources so that
   such requirements are met. Distributing the flow specification to all
   resource managers along the communication paths is the task of the
   setup protocol. However, the contents of the flow specification are
   transparent to the setup protocol, which simply carries the flow
   specification. Any operations on the flow specification, including
   updating internal fields and comparing flow specifications are
   performed by the resource managers.

   This document defines a specific flow specification format that
   allows for interoperability among ST2 implementations. This flow
   specification is intended to support a flow with a single
   transmission rate for all destinations in the stream. Implementations
   may support more than one flow specification format and the means are
   provided to add new formats as they are defined in the future.
   However, the flow specification format has to be consistent



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


   throughout the stream, i.e., it is not possible to use different flow
   specification formats for different parts of the same stream.

1.4.4  Routing Function

   The routing function is an external unicast route generation
   capability. It provides the setup protocol with the path to reach
   each of the desired destinations. The routing function is called on a
   hop-by-hop basis and provides next-hop information. Once a route is
   selected by the routing function, it persists for the whole stream
   lifetime. The routing function may try to optimize based on the
   number of targets, the requested resources, or use of local network
   multicast or bandwidth capabilities. Alternatively, the routing
   function may even be based on simple connectivity information.

   The setup protocol is not necessarily aware of the criteria used by
   the routing function to select routes. It works with any routing
   function algorithm. The algorithm adopted is a local matter at each
   host/router and different hosts/routers may use different algorithms.
   The interface between setup protocol and routing function is also a
   local matter and therefore it is not specified by this document.

   This version of ST does not support source routing. It does support
   route recording. It does include provisions that allow identification
   of ST capable neighbors. Identification of remote ST hosts/routers is
   not specifically addressed.

1.4.5  Local Resource Manager

   At each host/router traversed by a stream, the Local Resource Manager
   (LRM) is responsible for handling local resources. The LRM knows
   which resources are on the system and what capacity they can provide.
   Resources include:

o   CPUs on end systems and routers to execute the application and
    protocol software,

o   main memory space for this software (as in all real-time systems,
    code should be pinned in main memory, as swapping it out would have
    detrimental effects on system performance),

o   buffer space to store the data, e.g., communication packets, passing
    through the nodes,

o   network adapters, and






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


o   transmission networks between the nodes. Networks may be as simple
    as point-to-point links or as complex as switched networks such as
    Frame Relay and ATM networks.

   During stream setup and modification, the LRM is presented by the
   setup protocol with the flow specification associated to the stream.
   For each resource it handles, the LRM is expected to perform the
   following functions:

o   Stream Admission Control: it checks whether, given the flow
    specification, there are sufficient resources left to handle the new
    data stream. If the available resources are insufficient, the new
    data stream must be rejected.

o   QoS Computation: it calculates the best possible performance the
    resource can provide for the new data stream under the current
    traffic conditions, e.g., throughput and delay values are computed.

o   Resource Reservation: it reserves the resource capacities required
    to meet the desired QoS.

   During data transfer, the LRM is responsible for:

o   QoS Enforcement: it enforces the QoS requirements by appropriate
    scheduling of resource access. For example, data packets from an
    application with a short guaranteed delay must be served prior to
    data from an application with a less strict delay bound.

   The LRM may also provide the following additional functions:

o   Data Regulation: to smooth a stream's data traffic, e.g., as with the
    leaky bucket algorithm.

o   Policing: to prevent applications exceed their negotiated QoS, e.g.,
    to send data at a higher rate than indicated in the flow
    specification.

o   Stream Preemption: to free up resources for other streams with
    higher priority or importance.

   The strategies adopted by the LRMs to handle resources are resource-
   dependent and may vary at every host/router. However, it is necessary
   that all LRMs have the same understanding of the flow specification.
   The interface between setup protocol and LRM is a local matter at
   every host and therefore it is not specified by this document. An
   example of LRM is the Heidelberg Resource Administration Technique
   (HeiRAT) [VoHN93].




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


   It is also assumed that the LRM provides functions to compare flow
   specifications, i.e., to decide whether a flow specification requires
   a greater, equal, or smaller amount of resource capacities to be
   reserved.















































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


1.5  ST2 Basic Concepts

   The following sections present at an introductory level some of the
   fundamental ST2 concepts including streams, data transfer, and flow
   specification.

            Hosts Connections...                :      ...and Streams
            ====================                :      ==============
        data       Origin                       :          Origin
       packets +-----------+                    :          +----+
          +----|Application|                    :          |    |
          |    |-----------|                    :          +----+
          +--->| ST Agent  |                    :           |  |
               +-----------+                    :           |  |
                     |                          :           |  |
                     V                          :           |  |
              +-------------+                   :           |  |
              |             |                   :           |  |
+-------------|  Network A  |                   :   +-------+  +--+
|             |             |                   :   |             |
|             +-------------+                   :   |     Target 2|
|                    |     Target 2             :   |     & Router|
|     Target 1       |    and Router            :   |             |
|  +-----------+     |  +-----------+           :   V             V
|  |Application|<-+  |  |Application|<-+        : +----+        +----+
|  |-----------|  |  |  |-----------|  |        : |    |        |    |
+->| ST Agent  |--+  +->| ST Agent  |--+        : +----+        +----+
   +-----------+        +-----------+           :Target 1         |  |
                              |                 :                 |  |
                              V                 :                 |  |
                    +-------------+             :                 |  |
                    |             |             :                 |  |
      +-------------|  Network B  |             :           +-----+  |
      |             |             |             :           |        |
      |             +-------------+             :           |        |
      |    Target 3        |    Target 4        :           |        |
      |  +-----------+     |  +-----------+     :           V        V
      |  |Application|<-+  |  |Application|<-+  :         +----+ +----+
      |  |-----------|  |  |  |-----------|  |  :         |    | |    |
      +->| ST Agent  |--+  +->| ST Agent  |--+  :         +----+ +----+
         +-----------+        +-----------+     :      Target 3 Target 4
                                                :

                         Figure 3: The Stream Concept







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


1.5.1  Streams

   Streams form the core concepts of ST2. They are established between a
   sending origin and one or more receiving targets in the form of a
   routing tree. Streams are uni-directional from the origin to the
   targets. Nodes in the tree represent so-called ST agents, entities
   executing the ST2 protocol; links in the tree are called hops. Any
   node in the middle of the tree is called an intermediate agent, or
   router. An agent may have any combination of origin, target, or
   intermediate capabilities.

   Figure 3 illustrates a stream from an origin to four targets, where
   the ST agent on Target 2 also functions as an intermediate agent. Let
   us use this Target 2/Router node to explain some basic ST2
   terminology: the direction of the stream from this node to Target 3