tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 1190

 
 
 

Experimental Internet Stream Protocol: Version 2 (ST-II)

Part 6 of 6, p. 125 to 148
Prev RFC Part

 


prevText      Top       Page 125 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  OpCode = 16  |H|Q|     0     |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            RVLId/0            |            SVLId/0            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |             HID/0             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 54.  STATUS Control Message

Top       Page 126 
         4.2.3.17.        STATUS-RESPONSE

            STATUS-RESPONSE (OpCode = 17) is the reply to a STATUS
            message.  If the stream specified in the STATUS message is
            not known, the STATUS-RESPONSE will contain the specified
            HID and/or Name but no other parameters.  It will otherwise
            contain the current HID(s), Name, FlowSpec, TargetList, and
            possibly Group of the stream.  Note that if a stream has no
            current HID, the H bit in the STATUS-RESPONSE will be zero.
            The HID field will contain the first, or only, HID if a
            valid HID exists; additional valid HIDs will be returned in
            HID parameters.

               H (bit 8) is used to indicate whether (when 1) or not
               (when 0) a HID is present in the HID field.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  OpCode = 17  |H|Q|     0     |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            RVLId/0            |            SVLId/0            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |             HID/0             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                       FlowSpec Parameter                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                        Group Parameter                        :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         HID Parameter                         !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      TargetList Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 55.  STATUS-RESPONSE Control Message

Top       Page 127 
   4.3.       Suggested Protocol Constants

      The ST Protocol uses several fields that must have specific values
      for the protocol to work, and also several values that an
      implementation must select.  This section specifies the required
      values and suggests initial values for others.  It is recommended
      that the latter be implemented as variables so that they may be
      easily changed when experience indicates better values.
      Eventually, they should be managed via the normal network
      management facilities.

      ST uses IP Version Number 5.

      When encapsulated in IP, ST uses IP Protocol Number 5.


       Value  ST Command Message Name       Value     ST Element Name
      ------- -----------------------      ------- ---------------------

         1    ACCEPT                          1    ErroredPDU
         2    ACK                             2    FlowSpec
         3    CHANGE                          3    FreeHIDs
         4    CHANGE-REQUEST                  4    Group
         5    CONNECT                         5    HID
         6    DISCONNECT                      6    MulticastAddress
         7    ERROR-IN-REQUEST                7    Name
         8    ERROR-IN-RESPONSE               8    NextHopIPAddress
         9    HELLO                           9    Origin
        10    HID-APPROVE                    10    OriginTimestamp
        11    HID-CHANGE                     11    RecordRoute
        12    HID-CHANGE-REQUEST             12    RFlowSpec
        13    HID-REJECT                     13    RGroup
        14    NOTIFY                         14    RHID
        15    REFUSE                         15    RName
        16    STATUS                         16    SrcRoute, IP Loose
        17    STATUS-RESPONSE                17    SrcRoute, IP Strict
                                             18    SrcRoute, ST Loose
                                             19    SrcRoute, ST Strict
                                             20    TargetList
                                             21    UserData


      A good choice for the minimum number of bits in the FreeHIDBitMask
      element of the FreeHIDs parameter is not yet known.  We suggest a
      minimum of 64 bits, i.e., N in Figure 25 has a value of two (2).


      HID value zero (0) is reserved for ST Control Messages.  HID
      values 1-3 are reserved for future use.

Top       Page 128 
      VLId value zero (0) may only be used in the RVLId field of an ST
      Control Message when the appropriate value has not yet been
      received from the other end of the virtual link;' except for an
      ERROR-IN-REQUEST or diagnostic message, the SVLId field may never
      contain a value of zero except in a diagnostic message.  VLId
      value 1 is reserved for use with HELLO messages by those agents
      whose implementation wishes to have all HELLOs so identified.
      VLId values 2-3 are reserved for future use.


      The following permanent IP multicast addresses have been assigned
      to ST:

         224.0.0.7    All ST routers
         224.0.0.8    All ST hosts

      In addition, a block of transient IP multicast addresses,
      224.1.0.0 - 224.1.255.255, has been allocated for ST multicast
      groups.  Note that in the case of Ethernet, an ST Multicast
      address of 224.1.cc.dd maps to an Ethernet Multicast address of
      01:00:5E:01:cc:dd (see [6]).


      SCMP uses retransmission to effect reliability and thus has
      several "retransmission timers".  Each "timer" is modeled by an
      initial time interval (ToXxx), which gets updated dynamically
      through measurement of control traffic, and a number of times
      (NXxx) to retransmit a message before declaring a failure.  All
      time intervals are in units of milliseconds.


       Value   Timeout  Name                      Meaning
      ------- ---------------------- ----------------------------------

        1000  ToAccept               Initial hop-by-hop timeout for
                                     acknowledgment of ACCEPT

           3  NAccept                ACCEPT retries before failure

        1000  ToConnect              Initial hop-by-hop timeout for
                                     acknowledgment of CONNECT

           5  NConnect               CONNECT retries before failure

        1000  ToDisconnect           Initial hop-by-hop timeout for
                                     acknowledgment of DISCONNECT

          3   NDisconnect            DISCONNECT retries before
                                     failure

Top       Page 129 
       Value   Timeout  Name                      Meaning
      ------- ---------------------- ----------------------------------

        1000  ToHIDAck               Initial hop-by-hop timeout for
                                     acknowledgment of
                                     HID-CHANGE-REQUEST

           3  NHIDAck                HID-CHANGE-REQUEST retries
                                     before failure

        1000  ToHIDChange            Initial hop-by-hop timeout for
                                     acknowledgment of HID-CHANGE

           3  NHIDChange             HID-CHANGE retries before
                                     failure

        1000  ToNotify               Initial hop-by-hop timeout for
                                     acknowledgment of NOTIFY

           3  NNotify                NOTIFY retries before failure

        1000  ToRefuse               Initial hop-by-hop timeout for
                                     acknowledgment of REFUSE

           3  NRefuse                REFUSE retries before failure

        1000  ToReroute              Timeout for receipt of ACCEPT or
                                     REFUSE from targets during
                                     failure recovery

           5  NReroute               CONNECT retries before failure

        5000  ToEnd2End              End-to-End timeout for receipt
                                     of ACCEPT or REFUSE from targets
                                     by origin

           0  NEnd2End               CONNECT retries before failure

Top       Page 130 
       Value   Parameter  Name                    Meaning
      ------- ---------------------- ----------------------------------

          10  NHIDAbort              Number of rejected HID proposals
                                     before aborting the HID
                                     negotiation process

       10000  HelloTimerHoldDown     Interval that Restarted bit must
                                     be set after ST restart

           5  HelloLossFactor        Number of consecutively missed
                                     HELLO messages before declaring
                                     link failure

        2000  DefaultRecoveryTimeout Interval between successive
                                     HELLOs to/from active neighbors

           2  DefaultHelloFactor     HELLO filtering function factor

Top       Page 131 
5.      Areas Not Addressed

   There are a number of issues that will need to be addressed in the
   long run but are not addressed here.  Some issues are network or
   implementation specific.  For example, the management of multicast
   groups depends on the interface that a network provides to the ST
   agent, and an UP/DOWN protocol based on ST HELLO messages depends on
   the details of the ST agents.  Both these examples may impact the ST
   implementations, but we feel it is inappropriate to specify them
   here.

   In other cases we feel that appropriate solutions are not clear at
   this time.  The following are examples of such issues:

   This document does not include a routing mechanism.  We do not feel
   that a routing strategy based on minimizing the number of hops from
   the source to the destination is necessarily appropriate.  An
   alternative strategy is to minimize the consumption of internet
   resources within some delay constraints.  Furthermore, it would be
   preferable if the routing function were to provide routes that
   incorporated bandwidth, delay, reliability, and perhaps other
   characteristics, not just connectivity.  This would increase the
   likelihood that a selected route would succeed.  This requirement
   would probably cause the ST agents to exchange more routing
   information than currently implemented.  We feel that further
   research and experimentation will be required before an appropriate
   routing strategy is well enough defined to be incorporated into the
   ST specification.

   Once the bandwidth for a stream has been agreed upon, it is not
   sufficient to rely on the origin to transmit traffic at that rate.
   The internet should not rely on the origin to operate properly.
   Furthermore, even if the origin sources traffic at the agreed rate,
   the packets may become aggregated unintentionally and cause local
   congestion.  There are several approaches to addressing this problem,
   such as metering the traffic in each stream as it passes through each
   agent.  Experimentation is necessary before such a mechanism is
   selected.

   The interface between the agent and the network is very limited.  A
   mechanism is provided by which the ST layer can query the network to
   determine the likelihood that a stream can be supported.  However,
   this facility will require practical experience before its
   appropriate use is defined.

   The simplex tree model of a stream does not easily allow for using
   multiple paths to support a greater bandwidth.  That is, at any given
   point in a stream, the entire incoming bandwidth must be transmitted
   to the same next-hop in order to get to some target.  If the
   bandwidth isn't available along any single path, the stream cannot be
   built to that target.  It may be the case that the bandwidth is not
   available along a single path, but if the data

Top       Page 132 
   flow is split along multiple paths, and so multiple next-hops,
   sufficient bandwidth would be available.  As currently specified, the
   ST agent at the point where the multiple flows converge will refuse
   the second connection because it can only be interpreted as a routing
   failure.  A mechanism that allows multiple paths in a stream and can
   protect against routing failures has not been defined.

   If sufficient bandwidth is not available, both preemption and
   rerouting are possible.  However, it is not clear when to use one or
   the other.  As currently specified, an ST agent that cannot obtain
   sufficient bandwidth will attempt to preempt lower precedence streams
   before attempting to reroute around the bottleneck.  This may lead to
   an undesirably high number of preemptions.  It may be that a higher
   precedence stream can be rerouted around lower precedence streams and
   still meet its performance requirements, whereas the preempted lower
   precedence streams cannot be reconstructed and still meet their
   performance requirements.  A simple and effective algorithm to allow
   a better decision has not been identified.

   In case a stream cannot be completed, ST does not report to the
   application the nature of the trouble in any great detail.
   Specifically, the application cannot determine where the bottleneck
   is, whether the problem is permanent or transitory, or the likely
   time before the trouble may be resolved.  The application can only
   attempt to build the stream at some later time hoping that the
   trouble has been resolved.  Schemes can be envisioned by which
   information is relayed back to the application.  However, only
   practical experience can evaluate the kind of trouble that is most
   likely encountered and the nature of information that would be most
   useful to the application.

   A mechanism is also not defined for cases where a stream cannot be
   completed not because of lack of resources but because of an
   unexpected failure that results in an ERROR-IN-REQUEST message.  An
   ERROR-IN-REQUEST message is returned in cases when an ST agent issues
   a malformed control message to a neighbor.  Such an occurrence is
   unexpected and may be caused by a bad or incomplete ST
   implementation.  In some cases a message, such as a NOTIFY should be
   sent to the origin.  Such a mechanism is not defined because it is
   not clear what information can be extracted and what the origin
   should do.

   No special action is taken when a target is removed from a stream.
   Removing a target may also remove a bottleneck either in bandwidth,
   packet rate or packet size, but advantage of this opportunity is not
   taken automatically.  The application may initiate a change to the
   stream's characteristics, but it is not in the best position to do
   this because the application may not know the nature of the
   bottleneck.  The ST layer may have the best information, but a

Top       Page 133 
   mechanism to do this may be very complex.  As a result, this concept
   requires further thought.

   An agent simply discards a stream's data packets if it cannot forward
   them.  The reason may be that the packets are too large or are
   arriving at too high a rate.  Alternative actions may include an
   attempt to do something with the packets, such as fragmenting them,
   or to notify the origin of the trouble.  Corrective measures may be
   too complex, so it may be preferable simply to notify the origin with
   a NOTIFY message.  However, if the incoming packet rate is causing
   congestion, then the NOTIFY messages themselves may cause more
   trouble.  The nature of the communication has yet to be defined.

   The FlowSpec includes a cost field, but its implementation has not
   been identified.  The units of cost can probably be defined
   relatively easily.  Cost of bandwidth can probably also be assigned.
   It is not clear how cost is assigned to other functions, such as high
   precedence or low delay, or how cost of the components of the stream
   are combined together.  It is clear that the cost to provide services
   will become more important in the near future, but it is not clear at
   this time how that cost is determined.

   A number of parameters of the FlowSpec are intended to be used as
   ranges, but some may be useful as discrete values.  For example, the
   FlowSpec may specify that bandwidth for a stream carrying voice
   should be reserved in a range from 16Kbps to 64Kbps because the voice
   codec has a variable coding rate.  However, the voice codec may be
   varied only among certain discrete values, such as 16Kbps, 32Kbps and
   64Kbps.  A stream that has 48Kbps of bandwidth is no better than one
   with 32Kbps.  The parameters of the FlowSpec where this may be
   relevant should optionally specify discrete values.  This is being
   considered.

   Groups are defined as a way to associate different streams, but the
   nature of the association is left for further study.  An example of
   such an association is to allow streams whose traffic is inherently
   not simultaneous to share the same allocated resources.  This may
   happen for example in a conference that has an explicit floor, such
   that only one site can generate video or audio traffic at any given
   time.  The grouping facility can be implemented based on this
   specification, but the implementation of the possible uses of groups
   will require new functionality to be added to the ST agents.  The
   uses for groups and the implementation to support them will be
   carried out as experience is gained and the need arises.

   We hope that the ST we here propose will act as a vehicle to study
   the use and performance of stream oriented services across packet
   switched networks.

Top       Page 134 
                   [This page intentionally left blank.]

Top       Page 135 
6.      Glossary

   appropriate reason code
      This phrase refers to one or perhaps a set of reason codes that
      indicate why a particular action is being taken.  Typically,
      these result from detection of errors or anomalous conditions.
      It can also indicate that an application component or agent has
      presented invalid parameters.

   DefaultRecoveryTimeout
      The DefaultRecoveryTimeout is maintained by each ST agent.  It
      indicates the default time interval to use for sending HELLO
      messages.

   downstream
      The direction in a stream from an origin toward its targets.

   element
      The fields and parameters of the ST control messages are
      collectively called elements.

   FlowSpec
      The Flow Specification, abbreviated "FlowSpec" is used by an
      application to specify required and desired characteristics of
      the stream.  The FlowSpec specifies bandwidth, delay, and
      reliability parameters.  Both minimal requirements and desired
      characteristics are included.  This information is then used to
      guide route selection and resource allocation decisions.  The
      desired vs. required characteristics are used to guide tradeoff
      decisions among competing stream requests.

   group
      A set of related streams can be associated as a group.  This is
      done by generating a Group Name and assigning it to each of the
      related streams.  The grouping information can then be used by
      the ST agents in making resource management and other control
      decisions.  For example, when preemption is necessary to
      establish a high precedence stream, we can exploit the group
      information to minimize the number of stream groups that are
      preempted.

   Group Name
      The Group Name is used to indicate that a collection of streams
      are related.  A Group Name is structured to ensure that it is
      unique across all hosts:  it includes the address of the host
      where it was generated combined with a unique number generated
      by that host.  A timestamp is added to ensure that the overall
      name is unique over all time.  (A Group Name has the same format
      as a stream Name.)

Top       Page 136 
   HelloLossFactor
      The HelloLossFactor is a parameter maintained by each ST agent.
      It identifies the expected number of consecutive HELLO messages
      typically lost due to transient factors.  Thus, an agent will be
      assumed to be down after we miss more than HelloLossFactor
      messages.

   HelloTimer
      The HelloTimer is a millisecond timer maintained by each ST
      agent.  It is included in each HELLO message.  It represents the
      time since the agent was restarted, modulo the precision of the
      field.  It is used to detect variations in the delay between the
      two agents, by comparing the arrival interval of two HELLO
      messages to the difference between their HelloTimer fields.

   HelloTimerHoldDown
      The HelloTimerHoldDown value is maintained by each ST agent.
      When an ST agent is restarted, it will set the "Restarted" bit
      in all HELLO messages it sends for HelloTimerHoldDown seconds.

   HID
      The Hop IDentifier, abbreviated as HID, is a numeric key stored
      in the header of each ST packet.  It is used by an ST agent to
      associate the packet with one of the incoming hops managed by
      the agent.  It can be used by receiving agent to map to
      the set of outgoing next-hops to which the message should be
      forwarded.  The HID field of an ST packet will generally need to
      be changed as it passes through each ST agent since there may be
      many HIDs associated with a single stream.

   hop
      A "hop" refers to the portion of a stream's path between two
      neighbor ST agents.  It is usually represented by a physical
      network.  However, a multicast hop can connect a single ST agent
      to several next-hop ST agents.

   host agents
      Synonym for host ST agents.

   host ST agents
      Host ST agents are ST agents that provide services to higher
      layer protocols and applications.  The services include methods
      for sourcing data from and sinking data to the higher layer or
      application, and methods for requesting and modifying streams.

   intermediate agents
      Synonym for intermediate ST agents.

   intermediate ST agents
      Intermediate ST agents are ST agents that can forward ST
      packets between the networks to which they are attached.

Top       Page 137 
   MTU
      The abbreviation for Maximum Transmission Unit, which is the
      maximum packet size in bytes that can be accepted by a given
      network for transmission.  ST agents determine the maximum
      packet size for a stream so that data written to the stream can
      be forwarded through the networks without fragmentation.

   multi-destination simplex
      The topology and data flow of ST streams are described as being
      multi-destination simplex:  all data flowing on the stream
      originates from a single origin and is passed to one or more
      destination targets.  Only control information, invisible to the
      application program, ever passes in the upstream direction.

   NAccept
      NAccept is an integer parameter maintained by each ST agent.  It
      is used to control retransmission of an ACCEPT message.  Since
      an ACCEPT request is relayed by agents back toward the origin,
      it must be acknowledged by each previous-hop agent.  If this ACK
      is not received within the appropriate timeout interval, the
      request will be resent up to NAccept times before giving up.

   Name
      Generally refers to the name of a stream.  A stream Name is
      structured to ensure that it is unique across all hosts: it
      includes the address of the host where it was generated combined
      with a unique number generated at that host.  A timestamp is
      added to ensure that the overall Name is unique over all time.
      (A stream Name has the same format as a Group Name.)

   NConnect
      NConnect is an integer parameter maintained by each ST agent.
      It is used to control retransmission of a CONNECT message.  A
      CONNECT request must be acknowledged by each next-hop agent as
      it is propagated toward the targets.  If a HID-ACCEPT,
      HID-REJECT, or ACK is not received for the CONNECT between any
      two agents within the appropriate timeout interval, the request
      will be resent up to NConnect times before giving up.

   NDisconnect
      NDisconnect is an integer parameter maintained by each ST
      agent.  It is used to control retransmission of a DISCONNECT
      message.  A DISCONNECT request must be acknowledged by each
      next-hop agent as it is propagated toward the targets.  If this
      ACK is not received for the DISCONNECT between any two agents
      within the appropriate timeout interval, the request will be
      resent up to NDisconnect times before giving up.

Top       Page 138 
   next protocol identifier
      The next protocol identifier is used by a target ST agent to
      identify to which of several higher layer protocols it should
      pass data packets it receives the network.  Examples of higher
      layer protocols include the Network Voice Protocol and the
      Packet Video Protocol.  These higher layer protocols will
      typically perform further demultiplexing among multiple
      application processes as part of their protocol processing
      activities.

   next-hop
      Synonym for next-hop ST agent.

   next-hop ST agent
      For each origin or intermediate ST agent managing a stream
      there are a set of next-hop ST agents.  The intermediate agent
      forwards each data packet it receives to all the next-hop ST
      agents, which in turn forward the data toward the target host
      agent (if the particular next-hop agent is another intermediate
      agent) or to the next higher protocol layer at the target (if
      the particular next-hop agent is a host agent).

   NextPcol
      NextPcol is a field in each Target of the CONNECT message used
      to convey the next protocol identifier.  See definition of next
      protocol identifier above for more details.

   NHIDAbort
      NHIDAbort is an integer parameter maintained by each ST agent.
      It is the number of unacceptable HID proposals before an ST
      agent aborts the HID negotiation process.

   NHIDAck
      NHIDAck is an integer parameter maintained by each ST agent.
      It is used to control retransmission of HID-CHANGE-REQUEST
      messages.  HID-CHANGE-REQUEST is sent by an ST agent to the
      previous-hop ST agent to request that the HID in use between
      those agents be changed.  The previous-hop acknowledges the
      HID-CHANGE-REQUEST message by sending a HID-CHANGE message.  If
      the HID-CHANGE is not received within the appropriate timeout
      interval, the request will be resent up to NHIDAck times before
      giving up.

   NHIDChange
      NHIDChange is an integer parameter maintained by each ST agent.
      It is used to control retransmission of the HID-CHANGE message.
      A HID-CHANGE message must be acknowledged by the next-hop agent.
      If this ACK is not received within the appropriate timeout
      interval, the request will be resent up to NHIDChange times
      before giving up.

Top       Page 139 
   NRefuse
      NRefuse is an integer parameter maintained by each ST agent.
      It is used to control retransmission of a REFUSE message.  As a
      REFUSE request is relayed by agents back toward the origin, it
      must be acknowledged by each previous-hop agent.  If this ACK is
      not received within the appropriate timeout interval, the
      request will be resent up to NRefuse times before giving up.

   NRetryRoute
      NRetryRoute is an integer parameter maintained by each ST
      agent.  It is used to control route exploration.  When an agent
      receives a REFUSE message whose ReasonCode indicates that the
      originally selected route is not acceptable, the agent should
      attempt to find an alternate route to the target.  If the agent
      has not found a viable route after a maximum of NRetryRoute
      choices, it should give up and notify the previous-hop or
      application that it cannot find an acceptable path to the
      target.

   origin
      The origin of a stream is the host agent where an application
      or higher level protocol originally requested that the stream be
      created.  The origin specifies the data to be sent through the
      stream.

   parameter
      Parameters are additional values that may be included in
      control messages.  Parameters are often optional.  They are
      distinguished from fields, which are always present.

   participants
      Participants are the end-users of a stream.

   PDU
      Abbreviation for Protocol Data Unit, defined below.

   peer
      The term peer is used to refer to entities at the same protocol
      layer.  It is used here to identify instances of an application
      or protocol layer above ST.  For example, data is passed through
      a stream from an originating peer process to its target peers.

   previous-hop
      Synonym for previous-hop ST agent.

   previous-hop ST agent
      The origin or intermediate agent from which an ST agent receives
      its data.

Top       Page 140 
   protocol data unit
      A protocol data unit (PDU) is the unit of data passed to a
      protocol layer by the next higher layer protocol or user.  It
      consists of control information and possibly user data.

   RecoveryTimeout
      RecoveryTimeout is specified in the FlowSpec of each stream.
      The minimum of these values over all streams between a pair of
      adjacent agents determines how often those agents must send
      HELLO messages to each other in order to ensure that failure of
      one of the agents will be detected quickly enough to meet the
      guarantee implied by the FlowSpec.

   Restarted bit
      The Restarted bit is part of the HELLO message.  When set, it
      indicates that the sending agent was restarted recently (within
      the last HelloTimerHoldDown seconds).

   round-trip time
      The round-trip-time is the time it takes a message to be sent,
      delivered, processed, and the acknowledgment received.  It
      includes both network and processing delays.

   RTT
      Abbreviation for round-trip-time.

   RVLId
      Abbreviation for Receiver's Virtual Link Identifier.  It
      uniquely identifies to the receiver the virtual link, and this
      stream, used to send it a message.  See definition for Virtual
      Link Identifier below.

   SAP
      Abbreviation for Service Access Point.

   SCMP
      Abbreviation for ST Control Message Protocol, defined below.

   Service Access Point
      A point where a protocol service provider makes available the
      services it offers to a next higher layer protocol or user.

   setup phase
      Before data can be transmitted through a stream, the ST agents
      must distribute state information about the stream to all agents
      along the path(s) to the target(s).  This is the setup phase.
      The setup phase ends when all the ACCEPT and REFUSE messages
      sent by the targets have been delivered to the origin.  At this
      point, the data transfer phase begins and data can be sent.
      Requests to modify the stream can be issued after the setup
      phase has ended, i.e., during the data transfer phase without
      disrupting the flow of data.

Top       Page 141 
   ST agent
      An ST agent is an entity that implements the ST Protocol.

   ST Control Message Protocol
      The ST Control Message Protocol is the subset of the overall ST
      Protocol responsible for creation, modification, maintenance,
      and tear down of a stream.  It also includes support for event
      notification and status monitoring.

   stream
      A stream is the basic object managed by the ST Protocol for
      transmission of data.  A stream has one origin where data are
      generated and one or more targets where the data are received
      for processing.  A flow specification, provided by the origin
      and negotiated among the origin, intermediate, and target ST
      agents, identifies the requirements of the application and the
      guarantees that can be assured by the ST agents.

   subsets
      Subsets of the ST Protocol are permitted, as defined in various
      sections of this specification.  Subsets are defined to allow
      simplified implementations that can still effectively
      interoperate with more complete implementations without causing
      disruption.

   SVLId
      Abbreviation for Sender's Virtual Link Identifier.  It uniquely
      identifies to the receiver the virtual link identifier that
      should be placed into the RVLId field of all replies sent over
      the virtual link for a given stream.  See definition for Virtual
      Link Identifier below.

   target
      An ST target is the destination where data supplied by the
      origin will be delivered for higher layer protocol or
      application processing.

   tear down
      The tear down phase of a stream begins when the origin indicates
      that it has no further data to send and the ST agents through
      which the stream passes should dismantle the stream and release
      its resources.

   ToAccept
      ToAccept is a timeout in seconds maintained by each ST agent.
      It sets the retransmission interval for ACCEPT messages.

   ToConnect
      ToConnect is a timeout in seconds maintained by each ST agent.
      It sets the retransmission interval a CONNECT messages.

Top       Page 142 
   ToDisconnect
      ToDisconnect is a timeout in seconds maintained by each ST
      agent.  It sets the retransmission interval for DISCONNECT
      messages.

   ToHIDAck
      ToHIDAck is a timeout in seconds maintained by each ST agent.
      It sets the retransmission interval for HID-CHANGE-REQUEST
      messages.

   ToHIDChange
      ToHIDChange is a timeout in seconds maintained by each ST agent.
      It sets the retransmission interval for HID-CHANGE messages.

   ToRefuse
      ToRefuse is a timeout in seconds maintained by each ST agent.
      It sets the retransmission interval for REFUSE messages.

   upstream
      The direction in a stream from a target toward the origin.

   Virtual Link
      A virtual link is one edge of the tree describing the path of
      data flow through a stream.  A separate virtual link is assigned
      to each pair of neighbor ST agents, even when multiple next-hops
      are be reached through a single network level multicast group.
      The virtual link allows efficient demultiplexing of ST Control
      Message PDUs received from a single physical link or network.

   Virtual Link Identifier
      For each ST Control Message sent, the sender provides its own
      virtual link identifier and that of the receiver (if known).
      Either of these identifiers, combined with the address of the
      corresponding host, can be used to identify uniquely the virtual
      control link to the agent.  However, virtual link identifiers
      are chosen by the associated agent so that the agent may
      precisely identify the stream, state machine, and other protocol
      processing data elements managed by that agent, without regard
      to the source of the control message.  Virtual link identifiers
      are not negotiated, and do not change during the lifetime of a
      stream.  They are discarded when the stream is torn down.

Top       Page 143 
7.      References

   [1] Braden, B., Borman, D., and C. Partridge, "Computing the
       Internet Checksum", RFC 1071, USC/Information Sciences
       Institute, Cray Research, BBN Laboratories, September
       1988.


   [2] Braden, R. (ed.), "Requirements for Internet Hosts --
       Communication Layers", RFC 1122, USC/Information Sciences
       Institute, October 1989.


   [3] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
       Specification", RFC 1045, Stanford University, February 1988.


   [4] Cohen, D., "A Network Voice Protocol NVP-II", USC/Information
       Sciences Institute, April 1981.


   [5] Cole, E., "PVP - A Packet Video Protocol", W-Note 28,
       USC/Information Sciences Institute, August 1981.


   [6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
       Stanford University, August 1989.


   [7] Edmond W., Seo K., Leib M., and C. Topolcic, "The DARPA
       Wideband Network Dual Bus Protocol", accepted for presentation
       at ACM SIGCOMM '90, September 24-27, 1990.


   [8] Forgie, J., "ST - A Proposed Internet Stream Protocol",
       IEN 119, M. I. T. Lincoln Laboratory, 7 September 1979.


   [9] Jacobs I., Binder R., and E. Hoversten E., "General Purpose
       Packet Satellite Network", Proc. IEEE, vol 66, pp 1448-1467,
       November 1978.


   [10] Jacobson, V., "Congestion Avoidance and Control", ACM
        SIGCOMM-88, August 1988.


   [11] Karn, P. and C. Partridge, "Round Trip Time Estimation",
        ACM SIGCOMM-87, August 1987.

Top       Page 144 
   [12] Mallory, T., and A. Kullberg, "Incremental Updating of the
        Internet Checksum", RFC 1141, BBN Communications
        Corporation, January 1990.


   [13] Mills, D., "Network Time Protocol (Version 2) Specification
        and Implementation", RFC 1119, University of Delaware,
        September 1989 (Revised February 1990).


   [14] Pope, A., "The SIMNET Network and Protocols", BBN
        Report No. 7102, BBN Systems and Technologies, July 1989.


   [15] Postel, J., ed., "Internet Protocol - DARPA Internet Program
        Protocol Specification", RFC 791, DARPA, September 1981.


   [16] Postel, J., ed., "Transmission Control Protocol - DARPA
        Internet Program Protocol Specification", RFC 793, DARPA,
        September 1981.


   [17] Postel, J., "User Datagram Protocol", RFC 768,
        USC/Information Sciences Institute, August 1980.


   [18] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1060,
        USC/Information Sciences Institute, March 1990.


   [19] SDNS Protocol and Signaling Working Group, SP3 Sub-Group,
        SDNS Secure Data Network System, Security Protocol 3 (SP3),
        SDN.301, Rev. 1.5, 1989-05-15.


   [20] SDNS Protocol and Signaling Working Group, SP3 Sub-Group,
        SDNS Secure Data Network System, Security Protocol 3 (SP3)
        Addendum 1, Cooperating Families, SDN.301.1, Rev. 1.2,
        1988-07-12.

8.      Security Considerations

   See section 3.7.8.

Top       Page 145 
9.      Authors' Addresses

      Stephen Casner
      USC/Information Sciences Institute
      4676 Admiralty Way
      Marina del Rey, CA 90292-6695

      Phone: (213) 822-1511 x153
      EMail: Casner@ISI.Edu


      Charles Lynn, Jr.
      BBN Systems and Technologies,
      a division of Bolt Beranek and Newman Inc.
      10 Moulton Street
      Cambridge, MA  02138

      Phone: (617) 873-3367
      EMail: CLynn@BBN.Com


      Philippe Park
      BBN Systems and Technologies,
      a division of Bolt Beranek and Newman Inc.
      10 Moulton Street
      Cambridge, MA  02138

      Phone: (617) 873-2892
      EMail: ppark@BBN.COM


      Kenneth Schroder
      BBN Systems and Technologies,
      a division of Bolt Beranek and Newman Inc.
      10 Moulton Street
      Cambridge, MA  02138

      Phone: (617) 873-3167
      EMail: Schroder@BBN.Com


      Claudio Topolcic
      BBN Systems and Technologies,
      a division of Bolt Beranek and Newman Inc.
      10 Moulton Street
      Cambridge, MA  02138

      Phone: (617) 873-3874
      EMail: Topolcic@BBN.Com

Top       Page 146 
                   [This page intentionally left blank.]

Top       Page 147 
Appendix 1.      Data Notations

   The convention in the documentation of Internet Protocols is to
   express numbers in decimal and to picture data with the most
   significant octet on the left and the least significant octet on the
   right.

   The order of transmission of the header and data described in this
   document is resolved to the octet level.  Whenever a diagram shows a
   group of octets, the order of transmission of those octets is the
   normal order in which they are read in English.  For example, in the
   following diagram the octets are transmitted in the order they are
   numbered.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |       2       |       3       |       4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       5       |       6       |       7       |       8       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       9       |      10       |      11       |      12       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 56.  Transmission Order of Bytes


   Whenever an octet represents a numeric quantity the left most bit in
   the diagram is the high order or most significant bit.  That is, the
   bit labeled 0 is the most significant bit.  For example, the
   following diagram represents the value 170 (decimal).


                            0 1 2 3 4 5 6 7
                           +-+-+-+-+-+-+-+-+
                           |1 0 1 0 1 0 1 0|
                           +-+-+-+-+-+-+-+-+

                    Figure 57.  Significance of Bits


   Similarly, whenever a multi-octet field represents a numeric quantity
   the left most bit of the whole field is the most significant bit.
   When a multi-octet quantity is transmitted the most significant octet
   is transmitted first.

   Fields whose length is fixed and fully illustrated are shown with a
   vertical bar (|) at the end;  fixed fields whose contents are
   abbreviated are shown with an exclamation point (!);  variable fields
   are shown with colons (:).

Top       Page 148 
   Optional parameters are separated from control messages with a blank
   line.  The order of any optional parameters is not meaningful.