Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1819

Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+

Pages: 109
Historic
Obsoletes:  1190
Part 1 of 4 – Pages 1 to 25
None   None   Next

Top   ToC   RFC1819 - Page 1
Network Working Group                                  ST2 Working Group
Request for Comments: 1819           L. Delgrossi and L. Berger, Editors
Obsoletes: 1190, IEN 119                                     August 1995
Category: Experimental


                Internet Stream Protocol Version 2 (ST2)
                 Protocol Specification - Version ST2+

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

IESG NOTE

   This document is a revision of RFC1190. The charter of this effort
   was clarifying, simplifying and removing errors from RFC1190 to
   ensure interoperability of implementations.

   NOTE WELL: Neither the version of the protocol described in this
   document nor the previous version is an Internet Standard or under
   consideration for that status.

   Since the publication of the original version of the protocol, there
   have been significant developments in the state of the art.  Readers
   should note that standards and technology addressing alternative
   approaches to the resource reservation problem are currently under
   development within the IETF.

Abstract

   This memo contains a revised specification of the Internet STream
   Protocol Version 2 (ST2). ST2 is an experimental resource reservation
   protocol intended to provide end-to-end real-time guarantees over an
   internet. It allows applications to build multi-destination simplex
   data streams with a desired quality of service. The revised version
   of ST2 specified in this memo is called ST2+.

   This specification is a product of the STream Protocol Working Group
   of the Internet Engineering Task Force.
Top   ToC   RFC1819 - Page 2
Table of Contents

     1  Introduction                                                   6
             1.1  What is ST2?                                         6
             1.2  ST2 and IP                                           8
             1.3  Protocol History                                     8
             1.3.1  RFC1190 ST and ST2+ Major Differences              9
             1.4  Supporting Modules for ST2                          10
             1.4.1  Data Transfer Protocol                            11
             1.4.2  Setup Protocol                                    11
             1.4.3  Flow Specification                                11
             1.4.4  Routing Function                                  12
             1.4.5  Local Resource Manager                            12
             1.5  ST2 Basic Concepts                                  15
             1.5.1  Streams                                           16
             1.5.2  Data Transmission                                 16
             1.5.3  Flow Specification                                17
             1.6  Outline of This Document                            19

     2  ST2 User Service Description                                  19
             2.1  Stream Operations and Primitive Functions           19
             2.2  State Diagrams                                      21
             2.3  State Transition Tables                             25

     3  The ST2 Data Transfer Protocol                                26
             3.1  Data Transfer with ST                               26
             3.2  ST Protocol Functions                               27
             3.2.1  Stream Identification                             27
             3.2.2  Packet Discarding based on Data Priority          27

     4  SCMP Functional Description                                   28
             4.1  Types of Streams                                    29
             4.1.1  Stream Building                                   30
             4.1.2  Knowledge of Receivers                            30
             4.2  Control PDUs                                        31
             4.3  SCMP Reliability                                    32
             4.4  Stream Options                                      33
             4.4.1  No Recovery                                       33
             4.4.2  Join Authorization Level                          34
             4.4.3  Record Route                                      34
             4.4.4  User Data                                         35
             4.5  Stream Setup                                        35
             4.5.1  Information from the Application                  35
             4.5.2  Initial Setup at the Origin                       35
             4.5.2.1  Invoking the Routing Function                   36
             4.5.2.2  Reserving Resources                             36
             4.5.3  Sending CONNECT Messages                          37
             4.5.3.1  Empty Target List                               37
Top   ToC   RFC1819 - Page 3
             4.5.4  CONNECT Processing by an Intermediate ST agent    37
             4.5.5  CONNECT Processing at the Targets                 38
             4.5.6  ACCEPT Processing by an Intermediate ST agent     38
             4.5.7  ACCEPT Processing by the Origin                   39
             4.5.8  REFUSE Processing by the Intermediate ST agent    39
             4.5.9  REFUSE Processing by the Origin                   39
             4.5.10  Other Functions during Stream Setup              40
             4.6  Modifying an Existing Stream                        40
             4.6.1  The Origin Adding New Targets                     41
             4.6.2  The Origin Removing a Target                      41
             4.6.3  A Target Joining a Stream                         42
             4.6.3.1  Intermediate Agent (Router) as Origin           43
             4.6.4  A Target Deleting Itself                          43
             4.6.5  Changing a Stream's FlowSpec                      44
             4.7  Stream Tear Down                                    45

     5  Exceptional Cases                                             45
             5.1  Long ST Messages                                    45
             5.1.1  Handling of Long Data Packets                     45
             5.1.2  Handling of Long Control Packets                  46
             5.2  Timeout Failures                                    47
             5.2.1  Failure due to ACCEPT Acknowledgment Timeout      47
             5.2.2  Failure due to CHANGE Acknowledgment Timeout      47
             5.2.3  Failure due to CHANGE Response Timeout            48
             5.2.4  Failure due to CONNECT Acknowledgment Timeout     48
             5.2.5  Failure due to CONNECT Response Timeout           48
             5.2.6  Failure due to DISCONNECT Acknowledgment Timeout  48
             5.2.7  Failure due to JOIN Acknowledgment Timeout        48
             5.2.8  Failure due to JOIN Response Timeout              49
             5.2.9  Failure due to JOIN-REJECT Acknowledgment Timeout 49
             5.2.10  Failure due to NOTIFY Acknowledgment Timeout     49
             5.2.11  Failure due to REFUSE Acknowledgment Timeout     49
             5.2.12  Failure due to STATUS Response Timeout           49
             5.3  Setup Failures due to Routing Failures              50
             5.3.1  Path Convergence                                  50
             5.3.2  Other Cases                                       51
             5.4  Problems due to Routing Inconsistency               52
             5.5  Problems in Reserving Resources                     53
             5.5.1  Mismatched FlowSpecs                              53
             5.5.2  Unknown FlowSpec Version                          53
             5.5.3  LRM Unable to Process FlowSpec                    53
             5.5.4  Insufficient Resources                            53
             5.6  Problems Caused by CHANGE Messages                  54
             5.7  Unknown Targets in DISCONNECT and CHANGE            55
Top   ToC   RFC1819 - Page 4
     6  Failure Detection and Recovery                                55
             6.1  Failure Detection                                   55
             6.1.1  Network Failures                                  56
             6.1.2  Detecting ST Agents Failures                      56
             6.2  Failure Recovery                                    58
             6.2.1  Problems in Stream Recovery                       60
             6.3  Stream Preemption                                   62

     7  A Group of Streams                                            63
             7.1  Basic Group Relationships                           63
             7.1.1  Bandwidth Sharing                                 63
             7.1.2  Fate Sharing                                      64
             7.1.3  Route Sharing                                     65
             7.1.4  Subnet Resources Sharing                          65
             7.2  Relationships Orthogonality                         65

     8  Ancillary Functions                                           66
             8.1  Stream ID Generation                                66
             8.2  Group Name Generator                                66
             8.3  Checksum Computation                                67
             8.4  Neighbor ST Agent Identification and
                     Information Collection                           67
             8.5  Round Trip Time Estimation                          68
             8.6  Network MTU Discovery                               68
             8.7  IP Encapsulation of ST                              69
             8.8  IP Multicasting                                     70

     9  The ST2+ Flow Specification                                   71
             9.1  FlowSpec Version #0 - (Null FlowSpec)               72
             9.2  FlowSpec Version #7 - ST2+ FlowSpec                 72
             9.2.1  QoS Classes                                       73
             9.2.2  Precedence                                        74
             9.2.3  Maximum Data Size                                 74
             9.2.4  Message Rate                                      74
             9.2.5  Delay and Delay Jitter                            74
             9.2.6  ST2+ FlowSpec Format                              75

     10  ST2 Protocol Data Units Specification                        77
             10.1  Data PDU                                           77
             10.1.1  ST Data Packets                                  78
             10.2  Control PDUs                                       78
             10.3  Common SCMP Elements                               80
             10.3.1  FlowSpec                                         80
             10.3.2  Group                                            81
             10.3.3  MulticastAddress                                 82
             10.3.4  Origin                                           82
             10.3.5  RecordRoute                                      83
             10.3.6  Target and TargetList                            84
Top   ToC   RFC1819 - Page 5
             10.3.7  UserData                                         85
             10.3.8  Handling of Undefined Parameters                 86
             10.4  ST Control Message PDUs                            86
             10.4.1  ACCEPT                                           86
             10.4.2  ACK                                              88
             10.4.3  CHANGE                                           89
             10.4.4  CONNECT                                          89
             10.4.5  DISCONNECT                                       92
             10.4.6  ERROR                                            93
             10.4.7  HELLO                                            94
             10.4.8  JOIN                                             95
             10.4.9  JOIN-REJECT                                      96
             10.4.10  NOTIFY                                          97
             10.4.11  REFUSE                                          98
             10.4.12  STATUS                                         100
             10.4.13  STATUS-RESPONSE                                100
             10.5  Suggested Protocol Constants                      101
             10.5.1  SCMP Messages                                   102
             10.5.2  SCMP Parameters                                 102
             10.5.3  ReasonCode                                      102
             10.5.4  Timeouts and Other Constants                    104
             10.6  Data Notations                                    105
     11  References                                                  106
     12  Security Considerations                                     108
     13  Acknowledgments and Authors' Addresses                      108
Top   ToC   RFC1819 - Page 6
1.  Introduction

1.1  What is ST2?

   The Internet Stream Protocol, Version 2 (ST2) is an experimental
   connection-oriented internetworking protocol that operates at the
   same layer as connectionless IP. It has been developed to support the
   efficient delivery of data streams to single or multiple destinations
   in applications that require guaranteed quality of service. ST2 is
   part of the IP protocol family and serves as an adjunct to, not a
   replacement for, IP. The main application areas of the protocol are
   the real-time transport of multimedia data, e.g., digital audio and
   video packet streams, and distributed simulation/gaming, across
   internets.

   ST2 can be used to reserve bandwidth for real-time streams across
   network routes. This reservation, together with appropriate network
   access and packet scheduling mechanisms in all nodes running the
   protocol, guarantees a well-defined Quality of Service (QoS) to ST2
   applications. It ensures that real-time packets are delivered within
   their deadlines, that is, at the time where they need to be
   presented.  This facilitates a smooth delivery of data that is
   essential for time- critical applications, but can typically not be
   provided by best- effort IP communication.

                      DATA PATH                         CONTROL PATH
                      =========                         ============
       Upper     +------------------+                     +---------+
       Layer     | Application data |                     | Control |
                 +------------------+                     +---------+
                          |                                    |
                          |                                    V
                          |                     +-------------------+
       SCMP               |                     |   SCMP  |         |
                          |                     +-------------------+
                          |                             |
                          V                             V
            +-----------------------+      +------------------------+
       ST   | ST |                  |      | ST |         |         |
            +-----------------------+      +------------------------+
            D-bit=1                       D-bit=0

                   Figure 1: ST2 Data and Control Path

   Just like IP, ST2 actually consists of two protocols: ST for the data
   transport and SCMP, the Stream Control Message Protocol, for all
   control functions. ST is simple and contains only a single PDU format
   that is designed for fast and efficient data forwarding in order to
Top   ToC   RFC1819 - Page 7
   achieve low communication delays. SCMP, however, is more complex than
   IP's ICMP. As with ICMP and IP, SCMP packets are transferred within
   ST packets as shown in Figure 1.

    +--------------------+
    | Conference Control |
    +--------------------+
   +-------+ +-------+ |
   | Video | | Voice | | +-----+ +------+ +-----+     +-----+ Application
   | Appl  | | Appl  | | | SNMP| |Telnet| | FTP | ... |     |    Layer
   +-------+ +-------+ | +-----+ +------+ +-----+     +-----+
       |        |      |     |        |     |            |
       V        V      |     |        |     |            |   ------------
    +-----+  +-----+   |     |        |     |            |
    | PVP |  | NVP |   |     |        |     |            |
    +-----+  +-----+   +     |        |     |            |
     |   \      | \     \    |        |     |            |
     |    +-----|--+-----+   |        |     |            |
     |     Appl.|control  V  V        V     V            V
     | ST  data |         +-----+    +-------+        +-----+
     | & control|         | UDP |    |  TCP  |    ... | RTP | Transport
     |          |         +-----+    +-------+        +-----+   Layer
     |         /|          / | \       / / |          / /|
     |\       / |  +------+--|--\-----+-/--|--- ... -+ / |
     | \     /  |  |         |   \     /   |          /  |
     |  \   /   |  |         |    \   +----|--- ... -+   |   -----------
     |   \ /    |  |         |     \ /     |             |
     |    V     |  |         |      V      |             |
     | +------+ |  |         |   +------+  |   +------+  |
     | | SCMP | |  |         |   | ICMP |  |   | IGMP |  |    Internet
     | +------+ |  |         |   +------+  |   +------+  |     Layer
     |    |     |  |         |      |      |      |      |
     V    V     V  V         V      V      V      V      V
   +-----------------+  +-----------------------------------+
   | STream protocol |->|      Internet     Protocol        |
   +-----------------+  +-----------------------------------+
                  | \   / |
                  |  \ /  |
                  |   X   |                                  ------------
                  |  / \  |
                  | /   \ |
                  VV     VV
   +----------------+   +----------------+
   | (Sub-) Network |...| (Sub-) Network |                  (Sub-)Network
   |    Protocol    |   |    Protocol    |                     Layer
   +----------------+   +----------------+

                   Figure 2.  Protocol Relationships
Top   ToC   RFC1819 - Page 8
1.2  ST2 and IP

   ST2 is designed to coexist with IP on each node. A typical
   distributed multimedia application would use both protocols: IP for
   the transfer of traditional data and control information, and ST2 for
   the transfer of real-time data. Whereas IP typically will be accessed
   from TCP or UDP, ST2 will be accessed via new end-to-end real-time
   protocols. The position of ST2 with respect to the other protocols of
   the Internet family is represented in Figure 2.

   Both ST2 and IP apply the same addressing schemes to identify
   different hosts. ST2 and IP packets differ in the first four bits,
   which contain the internetwork protocol version number: number 5 is
   reserved for ST2 (IP itself has version number 4). As a network layer
   protocol, like IP, ST2 operates independently of its underlying
   subnets. Existing implementations use ARP for address resolution, and
   use the same Layer 2 SAPs as IP.

   As a special function, ST2 messages can be encapsulated in IP
   packets.  This is represented in Figure 2 as a link between ST2 and
   IP. This link allows ST2 messages to pass through routers which do
   not run ST2.  Resource management is typically not available for
   these IP route segments. IP encapsulation is, therefore, suggested
   only for portions of the network which do not constitute a system
   bottleneck.

   In Figure 2, the RTP protocol is shown as an example of transport
   layer on top of ST2. Others include the Packet Video Protocol (PVP)
   [Cole81], the Network Voice Protocol (NVP) [Cohe81], and others such
   as the Heidelberg Transport Protocol (HeiTP) [DHHS92].

1.3  Protocol History

   The first version of ST was published in the late 1970's and was used
   throughout the 1980's for experimental transmission of voice, video,
   and distributed simulation. The experience gained in these
   applications led to the development of the revised protocol version
   ST2. The revision extends the original protocol to make it more
   complete and more applicable to emerging multimedia environments. The
   specification of this protocol version is contained in Internet RFC
   1190 which was published in October 1990 [RFC1190].

   With more and more developments of commercial distributed multimedia
   applications underway and with a growing dissatisfaction at the
   transmission quality for audio and video over IP in the MBONE,
   interest in ST2 has grown over the last years. Companies have
   products available incorporating the protocol. The BERKOM MMTS
   project of the German PTT [DeAl92] uses ST2 as its core protocol for
Top   ToC   RFC1819 - Page 9
   the provision of multimedia teleservices such as conferencing and
   mailing. In addition, implementations of ST2 for Digital Equipment,
   IBM, NeXT, Macintosh, PC, Silicon Graphics, and Sun platforms are
   available.

   In 1993, the IETF started a new working group on ST2 as part of
   ongoing efforts to develop protocols that address resource
   reservation issues.  The group's mission was to clean up the existing
   protocol specification to ensure better interoperability between the
   existing and emerging implementations. It was also the goal to
   produce an updated experimental protocol specification that reflected
   the experiences gained with the existing ST2 implementations and
   applications. Which led to the specification of the ST2+ protocol
   contained in this document.

1.3.1  RFC1190 ST and ST2+ Major Differences

   The protocol changes from RFC1190 were motivated by protocol
   simplification and clarification, and codification of extensions in
   existing implementations. This section provides a list of major
   differences, and is probably of interest only to those who have
   knowledge of RFC1190. The major differences between the versions are:

o   Elimination of "Hop IDentifiers" or HIDs. HIDs added much complexity
    to the protocol and was found to be a major impediment to
    interoperability. HIDs have been replaced by globally unique
    identifiers called "Stream IDentifiers" or SIDs.

o   Elimination of a number of stream options. A number of options were
    found to not be used by any implementation, or were thought to add
    more complexity than value. These options were removed. Removed
    options include: point-to-point, full-duplex, reverse charge, and
    source route.

o   Elimination of the concept of "subset" implementations. RFC1190
    permitted subset implementations, to allow for easy implementation
    and experimentation. This led to interoperability problems. Agents
    implementing the protocol specified in this document, MUST implement
    the full protocol. A number of the protocol functions are best-
    effort. It is expected that some implementations will make more
    effort than others in satisfying particular protocol requests.

o   Clarification of the capability of targets to request to join a
    steam. RFC1190 can be interpreted to support target requests, but
    most implementors did not understand this and did not add support
    for this capability. The lack of this capability was found to be a
    significant limitation in the ability to scale the number of
    participants in a single ST stream. This clarification is based on
Top   ToC   RFC1819 - Page 10
    work done by IBM Heidelberg.

o   Separation of functions between ST and supporting modules. An effort
    was made to improve the separation of functions provided by ST and
    those provided by other modules. This is reflected in reorganization
    of some text and some PDU formats. ST was also made FlowSpec
    independent, although it does define a FlowSpec for testing and
    interoperability purposes.

o   General reorganization and re-write of the specification. This
    document has been organized with the goal of improved readability
    and clarity. Some sections have been added, and an effort was made
    to improve the introduction of concepts.

1.4  Supporting Modules for ST2

   ST2 is one piece of a larger mosaic. This section presents the
   overall communication architecture and clarifies the role of ST2 with
   respect to its supporting modules.

   ST2 proposes a two-step communication model. In the first step, the
   real-time channels for the subsequent data transfer are built. This
   is called stream setup. It includes selecting the routes to the
   destinations and reserving the correspondent resources. In the second
   step, the data is transmitted over the previously established
   streams.  This is called data transfer. While stream setup does not
   have to be completed in real-time, data transfer has stringent real-
   time requirements. The architecture used to describe the ST2
   communication model includes:

o   a data transfer protocol for the transmission of real-time data
    over the established streams,

o   a setup protocol to establish real-time streams based on the flow
    specification,

o   a flow specification to express user real-time requirements,

o   a routing function to select routes in the Internet,

o   a local resource manager to appropriately handle resources involved
    in the communication.

   This document defines a data protocol (ST), a setup protocol (SCMP),
   and a flow specification (ST2+ FlowSpec). It does not define a
   routing function and a local resource manager. However, ST2 assumes
   their existence.
Top   ToC   RFC1819 - Page 11
   Alternative architectures are possible, see [RFC1633] for an example
   alternative architecture that could be used when implementing ST2.

1.4.1  Data Transfer Protocol

   The data transfer protocol defines the format of the data packets
   belonging to the stream. Data packets are delivered to the targets
   along the stream paths previously established by the setup protocol.
   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
Top   ToC   RFC1819 - Page 12
   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
Top   ToC   RFC1819 - Page 13
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].
Top   ToC   RFC1819 - Page 14
   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.
Top   ToC   RFC1819 - Page 15
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
Top   ToC   RFC1819 - Page 16
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
   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
Top   ToC   RFC1819 - Page 17
   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
Top   ToC   RFC1819 - Page 18
   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
Top   ToC   RFC1819 - Page 19
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],
Top   ToC   RFC1819 - Page 20
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
Top   ToC   RFC1819 - Page 21
   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 |
           |JOIN.reject-ind| join reject indication        | T |
           |DATA.req       | send data                     | O |
           |DATA.ind       | receive data indication       | T |
           |CHG.req        | change stream QoS             | O |
           |CHG.ind        | change request indication     | T |
           |CHG.accept     | accept change                 | T |
           |CHG.refuse     | refuse change                 | T |
           |CHG.accept-ind | change accept indication      | O |
           |CHG.refuse-ind | change refuse indication      | O |
           |DROP.req       | drop targets                  | O |
           |DROP.ind       | disconnect indication         | T |
           |LEAVE.req      | leave stream                  | T |
           |LEAVE.ind      | leave stream indication       | O |
           |CLOSE.req      | close stream                  | O |
           |CLOSE.ind      | close stream indication       | T |
           +---------------------------------------------------+

                              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
Top   ToC   RFC1819 - Page 22
   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.
Top   ToC   RFC1819 - Page 23
   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.
Top   ToC   RFC1819 - Page 24
                        +------------+
                        |            |<-------------------+
            +---------->|    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
Top   ToC   RFC1819 - Page 25
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


(next page on part 2)

Next Section