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 4 of 6, p. 75 to 99
Prev RFC Part       Next RFC Part

 


prevText      Top       Page 75 
4.      ST Protocol Data Unit Descriptions

   The ST PDUs sent between ST agents consist of an ST Header
   ncapsulating either a higher layer PDU or an ST Control Message.
   Since ST operates as an extension of IP, the packet arrives at the
   same network service access point that IP uses to receive IP
   datagrams, e.g., ST would use the same ethertype (0x800) as does IP.
   The two types of packets are distinguished by the IP Version Number
   field (the first four bits of the packet);  IP currently uses a value
   of 4, while ST has been assigned the value 5 [18].  There is no
   requirement for compatibility between IP and ST packet headers beyond
   the first four bits.

   The ST Header also includes an ST Version Number, a total length
   field, a header checksum, and a HID, as shown in Figure 21.  See
   Appendix 1 (page 147) for an explanation of the notation.

      ST is the IP Version Number assigned to identify ST packets.  The
      value for ST is 5.

      Ver is the ST Version Number.  This document defines ST Version 2.

      Pri is the priority of the packet.  It is used in data packets to
      indicate those packets to drop if a stream is exceeding its
      allocation.  Zero is the lowest priority and 7 the highest.

      T (bit 11) is used to indicate that a Timestamp is present
      following the ST Header but before any next higher layer protocol
      data.  The Timestamp is not permitted on ST Control Messages
      (which may use the OriginTimestamp option).

      Bits 12 through 15 are spares and should be set to 0.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ST=5 | Ver=2 | Pri |T| Bits  |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              HID              |        HeaderChecksum         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                          Timestamp                          -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 21.  ST Header

Top       Page 76 
      TotalBytes is the length, in bytes, of the entire ST packet, it
      includes the ST Header and optional Timestamp but does not include
      any local network headers or trailers.  In general, all length
      fields in the ST Protocol are in units of bytes.

      HID is the 16-bit hop-by-hop stream identifier.  It is an
      abbreviation for the Name of the stream and is used both to reduce
      the packet header length and, by the receiver of the data packet,
      to make the forwarding function more efficient.  Control Messages
      have a HID value of zero.  HIDs are negotiated by the next-hop and
      previous-hop agents to make the abbreviation unique.  It is used
      here in the ST Header and in various Control Messages.  HID values
      1-3 are reserved for future use.

      HeaderChecksum covers only the ST Header and Timestamp, if
      present.  The ST Protocol uses 16-bit checksums here in the ST
      Header and in each Control Message.  The standard Internet
      checksum algorithm is used:  "The checksum field is the 16-bit
      one's complement of the one's complement sum of all 16-bit words
      in the header.  For purposes of computing the checksum, the value
      of the checksum field is zero."  See [1] [12] [15] for suggestions
      for efficient checksum algorithms.

      Timestamp is an optional timestamp inserted into data packets by
      the origin.  It is only present when the T bit, described above,
      is set (1).  Its use is negotiated at connection setup time;  see
      Sections 4.2.3.5 (page 108) and 4.2.3.1 (page 100).  The Timestamp
      has the NTP format;  see [13].


   4.1.       Data Packets

      ST packets whose HID is not zero to three are user data packets.
      Their interpretation is a matter for the higher layer protocols
      and consequently is not specified here.  The data packets are not
      protected by an ST checksum and will be delivered to the higher
      layer protocol even with errors.

      ST agents will not pass data packets over a new hop whose setup is
      not complete, i.e., a HID must have been negotiated and either an
      ACCEPT or REFUSE has been received for all targets specified in
      the CONNECT.

Top       Page 77 
   4.2.       ST Control Message Protocol Descriptions

      ST Control Messages are between a previous-hop agent and its
      next-hop agent(s) using a HID of zero.  The control protocol
      follows a request-response model with all requests expecting
      responses.  Retransmission after timeout (see Section 3.7.6 (page
      66)) is used to allow for lost or ignored messages.  Control
      messages do not extend across packet boundaries; if a control
      message is too large for the MTU of a hop, its information
      (usually a TargetList) is partitioned and a control message per
      partition is sent.  All control messages have the following
      format:

         OpCode identifies the type of control message.  Each is
         described in detail in following sections.

         Options is used to convey OpCode-specific variations for a
         control message.

         TotalBytes is the length of the control message, in bytes,
         including all OpCode specific fields and optional parameters.
         The value is always divisible by four.

         RVLId is used to convey the Virtual Link Identifier of the
         receiver of the control message, when known, or zero in the
         case of an initial CONNECT or diagnostic message.  The RVLId is
         intended to permit efficient dispatch to the portion of a
         stream's state machine containing information about a specific
         operation in progress over the link.  RVLId values 1-3 are
         reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49).


    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    |    Options    |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-                             -+
   :                      OpCode Specific Data                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 22.  ST Control Message Format

Top       Page 78 
         SVLId is used to convey the Virtual Link Identifier of the
         sender of the control message.  Except for ERROR-IN-REQUEST and
         diagnostic messages, it must never be zero.  SVLId values 1-3
         are reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49).

         Reference is a transaction number.  Each sender of a request
         control message assigns a Reference number to the message that
         is unique with respect to the stream.  The Reference number is
         used by the receiver to detect and discard duplicates.  Each
         acknowledgment carries the Reference number of the request
         being acknowledged.  Reference zero is never used, and
         Reference numbers are assumed to be monotonically increasing
         with wraparound so that the older-than and more-recent-than
         relations are well defined.

         LnkReference contains the Reference field of the request
         control message that caused this request control message to be
         created.  It is used in situations where a single request leads
         to multiple "responses".  Examples are CONNECT and CHANGE
         messages that must be acknowledged hop-by-hop and will also
         lead to an ACCEPT or REFUSE from each target in the TargetList.

         SenderIPAddress is the 32-bit IP address of the network
         interface that the ST agent used to send the control message.
         This value changes each time the packet is forwarded by an ST
         agent (hop-by-hop).

         Checksum is the checksum of the control message.  Because the
         control messages are sent in packets that may be delivered with
         bits in error, each control message must be checked before it
         is acted upon;  see Section 4 (page 76).

         OpCode Specific Data contains any additional information that
         is associated with the control message.  It depends on the
         specific control message and is explained further below.  In
         some response control messages, fields of zero are included to
         allow the format to match that of the corresponding request
         message.  The OpCode Specific Data may also contain any of the
         optional Parameters defined in Section 4.2.2 (page 80).

Top       Page 79 
      4.2.1.        ST Control Messages

         The CONNECT and CHANGE messages are used to establish or modify
         branches in the stream.  They propagate in the direction from
         the origin toward the targets.  They are end-to-end messages
         created by the origin.  They propagate all the way to the
         targets, and require ERROR-IN-REQUEST, ACK, HID-REJECT, HID-
         APPROVE, ACCEPT, or REFUSE messages in response.  The CONNECT
         message is the stream setup message.  The CHANGE message is
         used to change the characteristics of an established stream.
         The CONNECT message is also used to add one or more targets to
         an existing stream and during recovery of a broken stream.
         Both messages have a TargetList parameter and are processed
         similarly.

         The DISCONNECT message is used to tear down streams or parts of
         streams.  It propagates in the direction from the origin toward
         the targets.  It is either used as an end-to-end message
         generated by the origin that is used to completely tear down a
         stream, or is generated by an intermediate ST agent that
         preempts a stream or detects the failure of its previous-hop
         agent or network in the stream.  In the latter case, it is used
         to tear down the part of the stream from the failure to the
         targets, thus the message propagates all the way to the
         targets.

         The REFUSE message is sent by a target to refuse to join or
         remove itself from a stream;  in these cases, it is an end-to-
         end message.  An intermediate ST agent issues a REFUSE if it
         cannot find a route to a target, can only find a route to a
         target through the previous-hop, preempts a stream, or detects
         a failure in a next-hop ST agent or network.  In all cases a
         REFUSE propagates in the direction toward the origin.

         The ACCEPT message is an end-to-end message generated by a
         target and is used to signify the successful completion of the
         setup of a stream or part of a stream, or the change of the
         FlowSpec.  There are no other messages that are similar to it.

         The following sections contain descriptions of common fields
         and parameters, followed by descriptions of the individual
         control messages, both listed in alphabetical order.  A brief
         description of the use of the control message is given.  The
         packet format is shown graphically.

Top       Page 80 
      4.2.2.        Common SCMP Elements

         Several fields and parameters (referred to generically as
         "elements") are common to two or more PDUs.  They are described
         in detail here instead of repeating their description several
         times.  In many cases, the presence of a parameter is optional.
         To permit the parameters to be easily defined and parsed, each
         is identified with a PCode byte that is followed by a PBytes
         byte indicating the length of the parameter in bytes (including
         the PCode, PByte, and any padding bytes).  If the length of the
         information is not a multiple of 4 bytes, the parameter is
         padded with one to three zero (0) bytes.  PBytes is thus always
         a multiple of four.  Parameters can be present in any order.


         4.2.2.1.         DetectorIPAddress

            Several control messages contain the DetectorIPAddress
            field.  It is used to identify the agent that caused the
            first instance of the message to be generated, i.e., before
            it was propagated.  It is copied from the received message
            into the copy of the message that is to be propagated to a
            previous-hop or next-hop.  It use is primarily diagnostic.


         4.2.2.2.         ErroredPDU

            The ErroredPDU parameter (PCode = 1) is used for diagnostic
            purposes to encapsulate a received ST PDU that contained an
            error.  It may be included in the ERROR-IN-REQUEST, ERROR-
            IN-RESPONSE, or REFUSE messages.  It use is primarily
            diagnostic.

               PDUBytes indicates how many bytes of the PDUInError are
               actually present.

               ErrorOffset contains the number of bytes into the errored
               PDU to the field containing the error.  At least as much
               of the PDU in error must be included to


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 1   |     PBytes    |   PDUBytes    |  ErrorOffset  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                          PDUInError           :    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 23.  ErroredPDU

Top       Page 81 
               include the field or parameter identified by ErrorOffset;
               an ErrorOffset of zero would imply a problem with the IP
               Version Number or ST Version Number fields.

               PDUInError is the PDU in error, beginning with the ST
               Header.


         4.2.2.3.         FlowSpec & RFlowSpec

            The FlowSpec is used to convey stream service requirements
            end-to-end.  We expect that other versions of FlowSpec will
            be needed in the future, which may or may not be subsets or
            supersets of the version described here.  PBytes will allow
            new constraints to be added to the end without having to
            simultaneously update all implementations in the field.
            Implementations are expected to be able to process in a
            graceful manner a Version 4 (or higher) structure that has
            more elements than shown here.

            The FlowSpec parameter (PCode = 2) is used in several
            messages to convey the FlowSpec.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     PCode     |     PBytes    |  Version = 3  |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   DutyFactor  |   ErrorRate   |   Precedence  |  Reliability  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tradeoffs           |        RecoveryTimeout        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          LimitOnCost          |         LimitOnDelay          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LimitOnPDUBytes        |        LimitOnPDURate         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MinBytesXRate                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AccdMeanDelay                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       AccdDelayVariance                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          DesPDUBytes          |          DesPDURate           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 24.  FlowSpec & RFlowSpec

Top       Page 82 
            The RFlowSpec parameter (PCode = 12) is used in conjunction
            with the FDx option to convey the FlowSpec that is to be
            used in the reverse direction.

               Version identifies the version of the FlowSpec.  Version
               3 is defined here.

               DutyFactor is the estimated proportion of the time that
               the requested bandwidth will actually be in use.  Zero is
               taken to represent 256 and signify a duty factor of 1.
               Other values are to be divided by 256 to yield the duty
               factor.

               ErrorRate expresses the error rate as the negative
               exponent of 10 in the error rate.  One (1) represents a
               bit error rate of 0.1 and 10 represents 0.0000000001.

               Precedence is the precedence of the connection being
               established.  Zero represents the lowest precedence.
               Note that non-zero values of this parameter should be
               subject to authentication and authorization checks, which
               are not specified here.  In general, the distinction
               between precedence and priority is that precedence
               specifies streams that are permitted to take previously
               committed resources from another stream, while priority
               identifies those PDUs that a stream is most willing to
               have dropped when the stream exceeds its guaranteed
               limits.

               Reliability is modified by each intervening ST agent as a
               measure of the probability that a given offered data
               packet will be forwarded and not dropped.  Zero is taken
               to represent 256 and signify a probability of 1.  Other
               values are to be divided by 256 to yield the probability.

               Tradeoffs is incompletely defined at this time.  Bits
               currently specified are as follows:

                  The most significant bit in the field, bit 0 in the
                  Figure 24, when one (1) means that each ST agent must
                  "implement" all constraints in the FlowSpec even if
                  they are not shown in the figure, e.g., when the
                  FlowSpec has been extended.  When zero (0), unknown
                  constraints may be ignored.

                  The second most significant bit in the field, bit 1,
                  when one (1) means that one or more constraints are
                  unknown and have been ignored.  When zero (0), all
                  constraints are known and have been processed.

Top       Page 83 
                  The third most significant bit in the field, bit 2, is
                  used for RevChrg;  see Section 3.6.5 (page 46).

                  Other bits are currently unspecified, and should be
                  set to zero (0) by the origin ST agent and not changed
                  by other agents unless those agents know their
                  meaning.

               RecoveryTimeout specifies the nominal number of
               milliseconds that the application is willing to wait for
               a failed system component to be detected and any
               corrective action to be taken.

               LimitOnCost specifies the maximum cost that the origin is
               willing to expend.  A value of zero indicates that the
               application is not willing to incur any direct charges
               for the resources used by the stream.  The meaning of
               non-zero values is left for further study.

               LimitOnDelay specifies the maximum end-to-end delay, in
               milliseconds, that can be tolerated by the origin.

               LimitOnPDUBytes is the smallest packet size, in terms of
               ST-user data bytes, that can be tolerated by the origin.

               LimitOnPDURate is the lowest packet rate that can be
               tolerated by the origin, expressed as tenths of a packet
               per second.

               MinBytesXRate is the minimum bandwidth that can be
               tolerated by the origin, expressed as a product of bytes
               and tenths of a packet per second.

               AccdMeanDelay is modified by each intervening ST agent.
               This provides a means of reporting the total expected
               delay, in milliseconds, for a data packet.  Note that it
               is implicitly assumed that the requested mean delay is
               zero and there is no limit on the mean delay, so there
               are no parameters to specify these explicitly.

               AccdDelayVariance is also modified by each intervening ST
               agent as a measure, in milliseconds squared, of the
               packet dispersion.  This quantity can be used by the
               target or origin in determining whether the resulting
               stream has an adequate quality of service to support the
               application.  Note that it is implicitly assumed that the
               requested delay variance is zero and there is no limit on
               the delay variance, so there are no parameters to specify
               these explicitly.

Top       Page 84 
               DesPDUBytes is the desired PDU size in bytes.  This is
               not necessarily the same as the minimum necessary PDU
               size.  This value may be made smaller by intervening ST
               agents so long as it is not made smaller than
               LimitOnPDUBytes.  The *PDUBytes limits measure the size
               of the PDUs of next-higher protocol layer, i.e., the user
               information contained in a data packet.  An ST agent must
               account for both the ST Header (including possible IP
               encapsulation) and any local network headers and trailers
               when comparing a network's MTU with *PDUBytes.  In an
               ACCEPT message, the value of this field will be no larger
               than the MTU of the path to the specified target.

               DesPDURate is the requested PDU rate, expressed as tenths
               of a packet per second.  This value may be made smaller
               by intervening ST agents so long as it is not made
               smaller than LimitOnPDURate.

               It is expected that the next parameter to be added to the
               FlowSpec will be a Burst Descriptor.  This parameter will
               describe the burstiness of the offered traffic.  For
               example, this may include the simple average rate, peak
               rate and variance values, or more complete descriptions
               that characterize the distribution of expected burst
               rates and their expected duration.  The nature of the
               algorithms that deal with the traffic's burstiness and
               the information that needs to be described by this
               parameter will be subjects of further experimentation.
               It is expected that a new FlowSpec with Version = 4 will
               be defined that looks like Version 3 but has a Burst
               Descriptor parameter appended to the end.


         4.2.2.4.         FreeHIDs

            The FreeHIDs parameter (PCode = 3) is used to communicate to
            the previous-hop suggestions for a HID.  It consists of
            BaseHID and FreeHIDBitMask fields.  Experiments will
            determine how long the mask should be for practical use of
            this parameter.  The parameter (if implemented) should be
            included in all HID-REJECTs, and in HID-APPROVEs that are
            linked to a multicast CONNECT, e.g., one containing the
            MulticastAddress parameter.

               BaseHID was the suggested value in a HID-CHANGE or
               CONNECT.  BaseHID is chosen to be the suggested HID value
               to insure that the masks from multiple FreeHIDs
               parameters will overlap.

               FreeHIDBitMask identifies available HID values as
               follows.  Bit 0 in the FreeHIDBitMask corresponds to a

Top       Page 85 
               HID with a value equal to BaseHID with the 5 least
               significant bits set to zero, bit 1 corresponds to that
               value + 1, etc.  This alignment of the mask on a 32-bit
               boundary is used so that masks from several FreeHIDs
               parameters might more easily be combined using a bit-wise
               AND function to find a free HID.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 3   |     4+4*N     |            BaseHID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                        FreeHIDBitMask                         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 25.  FreeHIDs


         4.2.2.5.         Group & RGroup

            The Group parameter (PCode = 4) is an optional argument
            used only for the creation of a stream.  This parameter
            contains a GroupName; the GroupName may be the same as the
            Name of one of the group's streams.  In addition, there
            may be some number of <SubGroupId, Relation> tuples that
            describe the meaning of the grouping and the relation
            between the members of the group.  The forms of grouping
            are for further study.

            The RGroup parameter (PCode = 13) is an optional argument
            used only for the creation of a stream in the reverse
            direction that is a member of a Group;  see the FDx
            option, Section 3.6.3 (page 45).  This parameter has the
            same format as the Group parameter.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     PCode     |    12+4*N     |                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-                             -+
   !                           GroupName                           !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           SubGroupId          |            Relation           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :              ...              :              ...              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           SubGroupId          |            Relation           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 26.  Group & RGroup

Top       Page 86 
            A GroupName has the same format as a Name;  see Figure 29.


         4.2.2.6.         HID & RHID

            The HID parameter (PCode = 5) is used in the NOTIFY message
            when the notification is related to a HID, and possibly in
            the STATUS-RESPONSE message to convey additional HIDs that
            are valid for a stream when there are more than one.  It
            consists of the PCode and PBytes bytes prepended to a HID;
            HIDs were described in Section 4 (page 76).

            The RHID parameter (PCode = 14) is used in conjunction with
            the FDx option to convey the HID that is to be used in the
            reverse direction.  It consists of the PCode and PBytes
            bytes prepended to a HID.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     PCode     |       4       |              HID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 27.  HID & RHID


         4.2.2.7.         MulticastAddress

            The MulticastAddress parameter (PCode = 6) is an optional
            parameter that is used, when setting up a network level
            multicast group, to communicate an IP and/or local network
            multicast address to the next-hop agents that should become
            members of the group.

               LocalNetBytes is the length of the Local Net Multicast
               Address.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 6   |    PBytes     | LocalNetBytes |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IP Multicast Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                  Local Net Multicast Address  :    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 28.  MulticastAddress

Top       Page 87 
               IP Multicast Address is described in [6].  This field is
               zero (0) if no IP multicast address is known or is
               applicable.  The block of addresses 224.1.0.0 -
               224.1.255.255 has been allocated for use by ST.

               Local Net Multicast Address is the multicast address to
               be used on the local network.  It corresponds to the IP
               Multicast Address when the latter is non-zero.


         4.2.2.8.         Name & RName

            Each stream is uniquely (i.e., globally) identified by a
            Name.  A Name is created by the origin host ST agent and is
            composed of 1) a 16-bit number chosen to make the Name
            unique within the agent, 2) the IP address of the origin ST
            agent, and 3) a 32-bit timestamp.  If the origin has
            multiple IP addresses, then any that can be used to reach
            target may be used in the Name.  The intent is that the
            <Unique ID, IP Address> tuple be unique for the lifetime of
            the stream.  It is suggested that to increase robustness a
            Unique ID value not be reused for a period of time on the
            order of 5 minutes.

            The Timestamp is included both to make the Name unique over
            long intervals (e.g., forever) for purposes of network
            management and accounting/billing, and to protect against
            failure of an ST agent that causes knowledge of active
            Unique IDs to be lost.  The assumption is that all ST agents
            have access to some "clock".  If this is not the case, the
            agent should have access to some form of non-volatile memory
            in which it can store some number that at least gets
            incremented per restart.

            The Name parameter (PCode = 7) is used in most control
            messages to identify a stream.

            The RName parameter (PCode = 15) is used in conjunction with
            the FDx option to convey the Name of the reverse stream in
            an ACCEPT message.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     PCode     |       12      |            Unique ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IP Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 29.  Name & RName

Top       Page 88 
         4.2.2.9.         NextHopIPAddress

            The NextHopIPAddress parameter (PCode = 8) is an optional
            parameter of NOTIFY (RouteBack) or REFUSE (RouteInconsist or
            RouteLoop) and contains the IP address of a suggested next-
            hop ST agent.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 8   |       8       |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       next-hop IP address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 30.  NextHopIPAddress


         4.2.2.10.        Origin

            The Origin parameter (PCode = 9) is used to identify the
            origin of the stream, the next higher protocol, and the SAP
            being used in conjunction with that protocol.

               NextPcol is an 8-bit field used in demultiplexing
               operations to identify the protocol to be used above ST.
               The values of NextPcol are in the same number space as
               the IP Header's Protocol field and are consequently
               defined in the Assigned Numbers RFC [18].

               OriginSAPBytes specifies the length of the OriginSAP,
               exclusive of any padding required to maintain 32-bit
               alignment.

               OriginIPAddress is (one of) the IP address of the origin.

               OriginSAP identifies the origin's SAP associated with the
               NextPcol protocol.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 9   |    PBytes     |    NextPcol   |OriginSAPBytes |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         OriginIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                           OriginSAP           :    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 31.  Origin

Top       Page 89 
         4.2.2.11.        OriginTimestamp

            The OriginTimestamp parameter (PCode = 10) is used to
            indicate the time at which the control message was sent.

            The units and format of the timestamp is that defined in the
            NTP protocol specification [13].  Note that discontinuities
            over leap seconds are expected.

            Note that the time synchronization implied by the use of
            such a parameter is the subject of systems management
            functions not described in this memo, e.g., NTP.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 10  |      12       |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                          Timestamp                          -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 32.  OriginTimestamp


         4.2.2.12.        ReasonCode

            Several errors may occur during protocol processing.  All ST
            error codes are taken from a single number space.  The
            currently defined values and their meaning is presented in
            the list below.  Note that new error codes may be defined
            from time to time.  All implementations are expected to
            handle new codes in a graceful manner.  If an unknown
            ReasonCode is encountered, it should be assumed to be fatal.


                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |          ReasonCode           |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 33.  ReasonCode

Top       Page 90 
                  Name       Value                 Meaning
            ---------------- ----- ---------------------------------------

            AcceptTimeout      2   An Accept has not been
                                   acknowledged.

            AccessDenied       3   Access denied.

            AckUnexpected      4   An unexpected ACK was received.

            ApplAbort          5   The application aborted the stream
                                   abnormally.

            ApplDisconnect     6   The application closed the stream
                                   normally.

            AuthentFailed      7   The authentication function
                                   failed.

            CantGetResrc       8   Unable to acquire (additional)
                                   resources.

            CantRelResrc       9   Unable to release excess
                                   resources.

            CksumBadCtl       10   A received control PDU has a bad
                                   message checksum.

            CksumBadST        11   A received PDU has a bad ST Header
                                   checksum.

            DropExcdDly       12   A received PDU was dropped because
                                   it could not be processed within
                                   the delay specification.

            DropExcdMTU       13   A received PDU was dropped because
                                   its size exceeds the MTU.

            DropFailAgt       14   A received PDU was dropped because
                                   of a failed ST agent.

            DropFailHst       15   A received PDU was dropped because
                                   of a host failure.

            DropFailIfc       16   A received PDU was dropped because
                                   of a broken interface.

            DropFailNet       17   A received PDU was dropped because
                                   of a network failure.

Top       Page 91 
                  Name       Value                 Meaning
            ---------------- ----- ---------------------------------------

            DropLimits        18   A received PDU was dropped because
                                   it exceeds the resource limits for
                                   its stream.

            DropNoResrc       19   A received PDU was dropped due to
                                   no available resources (including
                                   precedence).

            DropNoRoute       20   A received PDU was dropped because
                                   of no available route.

            DropPriLow        21   A received PDU was dropped because
                                   it has a priority too low to be
                                   processed.

            DuplicateIgn      22   A received control PDU is a
                                   duplicate and is being
                                   acknowledged.

            DuplicateTarget   23   A received control PDU contains a
                                   duplicate target, or an attempt to
                                   add an existing target.

            ErrorUnknown       1   An error not contained in this
                                   list has been detected.

            failure          N/A   An abbreviation used in the text
                                   for any of the more specific
                                   errors:  DropFailAgt, DropFailHst,
                                   DropFailIfc, DropFailNet,
                                   IntfcFailure, NetworkFailure,
                                   STAgentFailure, FailureRecovery.

            FailureRecovery   24   A notification that recovery is
                                   being attempted.

            FlowVerBad        25   A received control PDU has a
                                   FlowSpec Version Number that is
                                   not supported.

            GroupUnknown      26   A received control PDU contains an
                                   unknown Group Name.

            HIDNegFails       28   HID negotiation failed.

            HIDUnknown        29   A received control PDU contains an
                                   unknown HID.

Top       Page 92 
                  Name       Value                 Meaning
            ---------------- ----- ---------------------------------------

            InconsistHID      30   An inconsistency has been detected
                                   with a stream Name and
                                   corresponding HID.

            InconsistGroup    31   An inconsistency has been detected
                                   with the streams forming a group.

            IntfcFailure      32   A network interface failure has
                                   been detected.

            InvalidHID        33   A received ST PDU contains an
                                   invalid HID.

            InvalidSender     34   A received control PDU has an
                                   invalid SenderIPAddress field.

            InvalidTotByt     35   A received control PDU has an
                                   invalid TotalBytes field.

            LnkRefUnknown     36   A received control PDU contains an
                                   unknown LnkReference.

            NameUnknown       37   A received control PDU contains an
                                   unknown stream Name.

            NetworkFailure    38   A network failure has been
                                   detected.

            NoError            0   No error has occurred.

            NoRouteToAgent    39   Cannot find a route to an ST
                                   agent.

            NoRouteToDest     40   Cannot find a route to the
                                   destination.

            NoRouteToHost     41   Cannot find a route to a host.

            NoRouteToNet      42   Cannot find a route to a network.

            OpCodeUnknown     43   A received control PDU has an
                                   invalid OpCode field.

            PCodeUnknown      44   A received control PDU has a
                                   parameter with an invalid PCode.

            ParmValueBad      45   A received control PDU contains an
                                   invalid parameter value.

Top       Page 93 
                  Name       Value                 Meaning
            ---------------- ----- ---------------------------------------

            PcolIdUnknown     46   A received control PDU contains an
                                   unknown next-higher layer protocol
                                   identifier.

            ProtocolError     47   A protocol error was detected.

            PTPError          48   Multiple targets were specified
                                   for a stream created with the PTP
                                   option.

            RefUnknown        49   A received control PDU contains an
                                   unknown Reference.

            RestartLocal      50   The local ST agent has recently
                                   restarted.

            RemoteRestart     51   The remote ST agent has recently
                                   restarted.

            RetransTimeout    52   An acknowledgment to a control
                                   message has not been received
                                   after several retransmissions.

            RouteBack         53   The routing function indicates
                                   that the route to the next-hop is
                                   through the same interface as the
                                   previous-hop and is not the
                                   previous-hop.

            RouteInconsist    54   A routing inconsistency has been
                                   detected, e.g., a route loop.

            RouteLoop         55   A CONNECT was received that
                                   specified an existing target.

            SAPUnknown        56   A received control PDU contains an
                                   unknown next-higher layer SAP
                                   (port).

            STAgentFailure    57   An ST agent failure has been
                                   detected.

            StreamExists      58   A stream with the given Name or
                                   HID already exists.

            StreamPreempted   59   The stream has been preempted by
                                   one with a higher precedence.

Top       Page 94 
                  Name       Value                 Meaning
            ---------------- ----- ---------------------------------------

            STVerBad          60   A received PDU is not ST Version
                                   2.

            TooManyHIDs       61   Attempt to add more HIDs to a
                                   stream than the implementation
                                   supports.

            TruncatedCtl      62   A received control PDU is shorter
                                   than expected.

            TruncatedPDU      63   A received ST PDU is shorter than
                                   the ST Header indicates.

            UserDataSize      64   The UserData parameter is too
                                   large to permit a control message
                                   to fit into a network's MTU.


         4.2.2.13.        RecordRoute

            The RecordRoute parameter (PCode = 11) may be used to
            request that the route between the origin and a target be
            recorded and returned to the agent specified in the
            DetectorIPAddress field.

            FreeOffset is the offset to the position where the next
            next-hop IP address should be inserted.  It is initialized
            to four (4) and incremented by four each time an agent
            inserts its IP address.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 11  |     PBytes    |       0       |  FreeOffset   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       next-hop IP address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       next-hop IP address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 34.  RecordRoute

Top       Page 95 
         4.2.2.14.        SrcRoute

            The SrcRoute parameter is used, in the Target structure
            shown in Figure 36, to specify the IP addresses of the ST
            agents through which the stream to the target should pass.
            There are two forms of the option, distinguished by the
            PCode.

            With loose source route (PCode = 18) each ST agent first
            examines the first next-hop IP address in the option.  If
            the address is (one of) the address of the current ST agent,
            that entry is removed, and the PBytes field reduced by four
            (4).  If the resulting PBytes field contains 4 (i.e., there
            are no more next-hop IP addresses) the parameter is removed
            from the Target.  In either case, the Target's TargetBytes
            field and the TargetList's PBytes field must be reduced
            accordingly.  The ST agent then routes toward the first
            next-hop IP address in the option, if one exists, or toward
            the target otherwise.  Note that the target's IP address is
            not included as the last entry in the list.

            With a strict source route (PCode = 19) each ST agent first
            examines the first next-hop IP address in the option.  If
            the address is not (one of) the address of the current ST
            agent, a routing error has occurred and should be reported
            with the appropriate reason code.  Otherwise that entry is
            removed, and the PBytes field reduced by four (4).  If the
            resulting PBytes field contains 4 (i.e., there are no more
            next-hop IP addresses) the parameter is removed from the
            Target.  In either case, the Target's TargetBytes field and
            the TargetList's PBytes field must be reduced accordingly.
            The ST agent then routes toward the first next-hop IP
            address in the option, if one exists, or toward the target
            otherwise.  Note that the target's IP address is not
            included as the last entry in the list.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      PCode    |     4+4*N     |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      next-hop IP address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      next-hop IP address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 35.  SrcRoute

Top       Page 96 
            Since it is possible that a single hop between ST agents is
            actually composed of multiple IP hops using IP
            encapsulation, it might be necessary to also specify an IP
            source routing option.  Two additional PCodes are used in
            this case.  See [15] for a description of IP routing
            options.

            An IP Loose Source Route (PCode = 16) indicates that PDUs
            for the next-hop ST agent should be encapsulated in IP and
            that the IP datagram should contain an IP Loose Source Route
            constructed from the list of IP router addresses contained
            in this option.

            An IP Strict Source Route (PCode = 17) is similarly used
            when the corresponding IP Strict Source Route option should
            be constructed.

            Consequently, the "routing parameter" may consist of a
            sequence of one or more separate parameters with PCodes 16,
            17, 18, or 19.


         4.2.2.15.        Target and TargetList

            Several control messages use a parameter called TargetList
            (PCode = 20), which contains information about the targets
            to which the message pertains.  For each Target in the
            TargetList, the information includes the IP addresses of the
            target, the SAP applicable to the next higher layer
            protocol, the length of the SAP (SAPBytes), and zero or more
            optional SrcRoute parameters;  see Section 4.2.2.14 (page
            95).  Consequently, a Target structure can be of variable
            length.  Each entry has the format shown in Figure 36.

            The optional SrcRoute parameter is only meaningful in a
            CONNECT messages;  if present in other messages, they are
            ignored.  Note that the presence of SrcRoute parameter(s)
            reduces the number of Targets that can be contained in a
            TargetList since the maximum size of a TargetList is 256
            bytes.  Consequently an implementation should be prepared to
            accept multiple TargetLists in a single message.

               TargetIPAddress is the IP Address of the Target.

               TargetBytes is the length of the Target structure,
               beginning with the TargetIPAddress and including any
               SrcRoute Parameter(s).

               SAPBytes is the length of the SAP, excluding any padding
               required to maintain 32-bit alignment.  I.e.,

Top       Page 97 
               there would be no padding required for SAPs with lengths
               of 2, 6, etc., bytes.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        TargetIPAddress                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TargetBytes  |   SAPBytes    |                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             -+-+-+-+-+-+-+-+-+
   :                              SAP              :    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     SrcRoute Parameter(s)                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 36.  Target


            We assume that the ST agents must know the maximum packet
            size of the networks to which they are connected (the MTU),
            and those maximum sizes will restrict the number of targets
            that can be specified in control messages.  We feel that
            this is not a serious drawback.  High bandwidth networks
            such as the Ethernet or the Terrestrial Wideband network
            support packet sizes large enough to allow well over one
            hundred targets to be specified, and we feel that
            conferences with a larger number of participants will not
            occur for quite some time.  Furthermore, we expect that
            future higher bandwidth networks will allow even larger
            packet sizes.  It may be desirable to send ST voice data
            packets in individual B-ISDN ATM cells, which are small, but
            network services on ATM will provide "adaptation layers" to
            implement network-level fragmentation that may be used to
            carry larger ST control messages.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 20  |    PBytes     |        TargetCount = N        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                            Target 1                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                            Target N                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 37.  TargetList

Top       Page 98 
            If a message must pass across a network whose maximum packet
            size is too small, the message must be broken up into
            multiple messages, each of which carries part of the
            TargetList.  The function of the message can still be
            performed even if the message is so partitioned.  The effect
            in this partitioning is to compromise the performance, but
            still allows proper operation.  For example, if a CONNECT
            message were partitioned, the first CONNECT would establish
            the stream, and the rest of the CONNECTs would be processed
            as additions to the first.  The routing decisions might
            suffer, however, since they would be made on partial
            information.  Nevertheless, the stream would be created.


         4.2.2.16.        UserData

            The UserData parameter (PCode = 21) is an optional parameter
            that may be used by the next higher protocol or an
            application to convey arbitrary information to its peers.
            Note that since the size of control messages is limited by
            the smallest MTU in the path to the target(s), the maximum
            size of this parameter cannot be specified a priori.  If the
            parameter is too large for some network's MTU, a
            UserDataSize error will occur.  The parameter must be padded
            to a multiple of 32 bits.

               UserBytes specifies the number of valid UserInformation
               bytes.

               UserInformation is arbitrary data meaningful to the next
               higher protocol layer or application.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PCode = 21  |    PBytes     |           UserBytes           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                        UserInformation        :    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 38.  UserData

Top       Page 99 
4.2.3.        ST Control Message PDUs

         Each control message is described in a following section.  See
         Appendix 1 (page 147) for an explanation of the notation.


Next RFC Part