tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 1819

 
 
 

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

Part 4 of 4, p. 77 to 109
Prev RFC Part

 


prevText      Top      Up      ToC       Page 77 
10.  ST2 Protocol Data Units Specification

10.1  Data PDU

   IP and ST packets can be distinguished by the IP Version Number
   field, i.e., the first four (4) bits of the packet; ST has been
   assigned the value 5 (see [RFC1700]). There is no requirement for
   compatibility between IP and ST packet headers beyond the first four
   bits. (IP uses value 4.)

   The ST PDUs sent between ST agents consist of an ST Header
   encapsulating either a higher layer PDU or an ST Control Message.
   Data packets are distinguished from control messages via the D-bit
   (bit 8) in the ST header.

   The ST Header also includes an ST Version Number, a total length
   field, a header checksum, a unique id, and the stream origin 32-bit
   IP address. The unique id and the stream origin 32-bit IP address
   form the stream id (SID). This is shown in Figure 10. Please refer to
   Section 10.6 for an explanation of the notation.

        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=3 |D| Pri |   0   |            TotalBytes         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          HeaderChecksum       |            UniqueID           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         OriginIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 10: ST Header

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

o   Ver is the ST Version Number. The value for the current ST2+ version
    is 3.

o   D (bit 8) is set to 1 in all ST data packets and to 0 in all SCMP
    control messages.

o   Pri (bits 9-11) is the packet-drop priority field with zero (0)
    being lowest priority and seven the highest. The field is to be used
    as described in Section 3.2.2.

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

o   HeaderChecksum covers only the ST Header (12 bytes). The ST Protocol
    uses 16-bit checksums here in the ST Header and in each Control
    Message. For checksum computation, see Section 8.3.

o   UniqueID is the first element of the stream ID (SID). It is locally
    unique at the stream origin, see Section 8.1.

o   OriginIPAddress is the second element of the SID. It is the 32-bit
    IP address of the stream origin, see Section 8.1.

   Bits 12-15 must be set to zero (0) when using the flow specifications
   defined in this document, see Section 9. They may be set accordingly
   when other flow specifications are used, e.g., as described in
   [WoHD95].

10.1.1  ST Data Packets

   ST packets whose D-bit is non-zero are 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.

10.2  Control PDUs

   SCMP control messages are exchanged between neighbor ST agents using
   a D-bit of zero (0). The control protocol follows a request-response
   model with all requests expecting responses. Retransmission after
   timeout (see Section 4.3) 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
   is partitioned and a control message per partition is sent (see
   Section 5.1.2). All control messages have the following format

Top      Up      ToC       Page 79 
        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          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Reference            |          LnkReference         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |            ReasonCode         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                      OpCodeSpecificData                       :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 11: ST Control Message Format

o   OpCode identifies the type of control message.

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

o   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 (4).

o   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 (0) 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.

o   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 from the same ST agent. Examples are CONNECT and CHANGE
    messages that are first acknowledged hop-by-hop and then lead to an
    ACCEPT or REFUSE response from each target.

o   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).

Top      Up      ToC       Page 80 
o   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 to be error free before
    it is acted upon.

o   ReasonCode is set to zero (0 = NoError) in most SCMP messages.
    Otherwise, it can be set to an appropriate value to indicate an
    error situation as defined in Section 10.5.3.

o   OpCodeSpecificData 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 (0) are included to allow the
    format to match that of the corresponding request message. The
    OpCodeSpecificData may also contain optional parameters. The
    specifics of OpCodeSpecificData are defined in Section 10.3.

10.3  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 four
   (4) bytes, the parameter is padded with one to three zero (0) bytes.
   PBytes is thus always a multiple of four (4). Parameters can be
   present in any order.

10.3.1  FlowSpec

   The FlowSpec parameter (PCode = 1) is used in several SCMP messages
   to convey the ST2 flow specification. The FlowSpec parameter has the
   following format:

        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     |   Version     |       0       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                        FlowSpec detail                        :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 12: FlowSpec Parameter

Top      Up      ToC       Page 81 
o   the Version field contains the FlowSpec version.

o   the FlowSpec detail field contains the flow specification and is
    transparent to the ST agent. It is the data structure to be passed
    to the LRM. It must be 4-byte aligned.

   The Null FlowSpec, see Section 9.1, has no FlowSpec detail field.
   PBytes is set to four (4), and Version is set to zero (0). The ST2+
   FlowSpec, see Section 9.2, is a 32-byte data structure. PBytes is set
   to 36, and Version is set to seven (7).

10.3.2  Group

   The Group parameter (PCode = 2) is an optional argument used to
   indicate that the stream is a member in the specified group.

        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 = 2    |   PBytes = 16 |           GroupUniqueID       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        GroupCreationTime                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     GroupInitiatorIPAddress                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Relationship       |                 N             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 13: Group Parameter

o   GroupUniqueID, GroupInitiatorIPAddress, and GroupCreationTime
    together form the GroupName field. They are allocated by the group
    name generator function, see Section 8.2. GroupUniqueID and
    GroupCreationTime are implementation specific and have only local
    definitions.

o   Relationship has the following format:

                                            0
                        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |    0 (unused)         |S|P|F|B|
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 14: Relationship Field

Top      Up      ToC       Page 82 
   The B, F, P, S bits correspond to Bandwidth, Fate, Path, and Subnet
   resources sharing, see Section 7. A value of 1 indicates that the
   relationship exists for this group. All combinations of the four bits
   are allowed. Bits 0-11 of the Relationship field are reserved for
   future use and must be set to 0.

o   N contains a legal value only if the B-bit is set. It is the value
    of the N parameter to be used as explained in Section 7.1.1.

10.3.3  MulticastAddress

   The MulticastAddress parameter (PCode = 3) is an optional parameter
   that is used when using IP encapsulation and setting up an IP
   multicast group. This parameter is used to communicate the desired IP
   multicast address to next-hop ST agents that should become members of
   the group, see Section 8.8.

        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    |   PBytes = 8  |                0              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        IPMulticastAddress                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 15:  MulticastAddress

o   IPMulticastAddress is the 32-bit IP multicast address to be used to
    receive data packets for the stream.

10.3.4  Origin

   The Origin parameter (PCode = 4) is used to identify the next higher
   protocol, and the SAP being used in conjunction with that 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 = 5    |   PBytes      | NextPcol      |OriginSAPBytes |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                OriginSAP                      :     Padding   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 16: Origin

Top      Up      ToC       Page 83 
o   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 [RFC1700].

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

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

   Note that the 32-bit IP address of the stream origin is not included
   in this parameter because it is always available as part of the ST
   header.

10.3.5  RecordRoute

   The RecordRoute parameter (PCode = 5) is used to request that the
   route between the origin and a target be recorded and delivered to
   the user application. The ST agent at the origin (or target)
   including this parameter, has to determine the parameter's length,
   indicated by the PBytes field. ST agents processing messages
   containing this parameter add their receiving IP address in the
   position indicated by the FreeOffset field, space permitting. If no
   space is available, the parameter is passed unchanged. When included
   by the origin, all agents between the origin and the target add their
   IP addresses and this information is made available to the
   application at the target. When included by the target, all agents
   between the target and the origin, inclusive, add their IP addresses
   and this information is made available to the application at the
   origin.

        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 = 5   |     PBytes    |       0       |  FreeOffset   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          IP Address 1                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          IP Address N                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 17: RecordRoute

o   PBytes is the length of the parameter in bytes. Length is determined
    by the agent (target or origin) that first introduces the parameter.

Top      Up      ToC       Page 84 
    Once set, the length of the parameter remains unchanged.

o   FreeOffset indicates the offset, relative to the start of the
    parameter, for the next IP address to be recorded. When the
    FreeOffset is greater than, or equal to, PBytes the RecordRoute
    parameter is full.

o   IP Address is filled in, space permitting, by each ST agent
    processing this parameter.

10.3.6  Target and TargetList

   Several control messages use a parameter called TargetList (PCode =
   6), which contains information about the targets to which the message
   pertains. For each Target in the TargetList, the information includes
   the 32-bit IP address of the target, the SAP applicable to the next
   higher layer protocol, and the length of the SAP (SAPBytes).
   Consequently, a Target structure can be of variable length. Each
   entry has the format shown in Figure 18.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Target IP Address                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  TargetBytes  |  SAPBytes     |     SAP       :    Padding    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 18: Target

o   TargetIPAddress is the 32-bit IP Address of the Target.

o   TargetBytes is the length of the Target structure, beginning with
    the TargetIPAddress.

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

o   SAP may be longer than 2 bytes and it includes a padding when
    required. There would be no padding required for SAPs with lengths
    of 2, 6, 10, etc., bytes.

Top      Up      ToC       Page 85 
        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      |           TargetCount = N     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Target 1                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                               :                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Target N                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 19: TargetList
10.3.7  UserData

   The UserData parameter (PCode = 7) is an optional parameter that may
   be used by the next higher protocol or an application to convey
   arbitrary information to its peers. This parameter is propagated in
   some control messages and its contents have no significance to ST
   agents. Note that since the size of control messages is limited by
   the smallest MTU in the path to the targets, the maximum size of this
   parameter cannot be specified a priori. If the size of this parameter
   causes a message to exceed the network MTU, an ST agent behaves as
   described in Section 5.1.2. The parameter must be padded to a
   multiple of 32 bits.

        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 = 7    |   PBytes      |           UserBytes           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                      UserInfo                 :   Padding     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 20:  UserData

o   UserBytes specifies the number of valid UserInfo bytes.

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

Top      Up      ToC       Page 86 
10.3.8  Handling of Undefined Parameters

   An ST agent must be able to handle all parameters listed above. To
   support possible future uses, parameters with unknown PCodes must
   also be supported. If an agent receives a message containing a
   parameter with an unknown Pcode value, the agent should handle the
   parameter as if it was a UserData parameter. That is, the contents of
   the parameter should be ignored, and the message should be
   propagated, as appropriate, along with the related control message.

10.4  ST Control Message PDUs

   ST Control messages are described in the following section. Please
   refer to Section 10.6 for an explanation of the notation.

10.4.1  ACCEPT

   ACCEPT (OpCode = 1) is issued by a target as a positive response to a
   CONNECT message. It implies that the target is prepared to accept
   data from the origin along the stream that was established by the
   CONNECT.  ACCEPT is also issued as a positive response to a CHANGE
   message. It implies that the target accepts the proposed stream
   modification.

   ACCEPT is relayed by the ST agents from the target to the origin
   along the path established by CONNECT (or CHANGE) but in the reverse
   direction. ACCEPT must be acknowledged with ACK at each hop.

Top      Up      ToC       Page 87 
        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 = 1   |      0        |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Reference                |         LnkReference          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |          ReasonCode = 0       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          MaxMsgSize           |          RecoveryTimeout      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      StreamCreationTime                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   IPHops      |                        0                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           FlowSpec                            :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           TargetList                          :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           RecordRoute                         :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           UserData                            :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 21: ACCEPT Control Message

o   Reference contains a number assigned by the ST agent sending ACCEPT
    for use in the acknowledging ACK.

o   LnkReference is the Reference number from the corresponding CONNECT
    (or CHANGE)

o   MaxMsgSize indicates the smallest MTU along the path traversed by
    the stream. This field is only set when responding to a CONNECT
    request.

o   RecoveryTimeout reflects 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. This field
    represents what can actually be supported by each participating
    agent, and is only set when responding to a CONNECT request.

o   StreamCreationTime is the 32- bits system dependent timestamp copied
    from the corresponding CONNECT request.

Top      Up      ToC       Page 88 
o   IPHops is the number of IP encapsulated hops traversed by the
    stream. This field is set to zero by the origin, and is incremented
    at each IP encapsulating agent.

10.4.2  ACK

   ACK (OpCode = 2) is used to acknowledge a request. The ACK message is
   not propagated beyond the previous-hop or 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  OpCode = 2   |     0         |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Reference               |           LnkReference = 0    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Checksum                |           ReasonCode          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 22: ACK Control Message

o   Reference is the Reference number of the control message being
    acknowledged.

o   ReasonCode is usually NoError, but other possibilities exist, e.g.,
    DuplicateIgn.

Top      Up      ToC       Page 89 
10.4.3  CHANGE

   CHANGE (OpCode = 3) is used to change the FlowSpec of an established
   stream. The CHANGE message is processed similarly to CONNECT, except
   that it travels along the path of an established stream. CHANGE must
   be propagated until it reaches the related stream's targets. CHANGE
   must be acknowledged with ACK at each hop.

        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 = 3   |G|I|     0     |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Reference           |          LnkReference = 0     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SenderIPAddress                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |          ReasonCode = 0       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                            FlowSpec                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           TargetList                          :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           RecordRoute                         :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                            UserData                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 23: CHANGE Control Message

o   G (bit 8) is used to request a global, stream-wide change; the
    TargetList parameter should be omitted when the G bit is specified.

o   I (bit 7) is used to indicate that the LRM is permitted to interrupt
    and, if needed, break the stream in the process of trying to satisfy
    the requested change.

o   Reference contains a number assigned by the ST agent sending CHANGE
    for use in the acknowledging ACK.

10.4.4  CONNECT

   CONNECT (OpCode = 4) requests the setup of a new stream or an
   addition to or recovery of an existing stream. Only the origin can
   issue the initial set of CONNECTs to setup a stream, and the first

Top      Up      ToC       Page 90 
   CONNECT to each next-hop is used to convey the SID.

   The next-hop initially responds with an ACK, which implies that the
   CONNECT was valid and is being processed. The next-hop will later
   relay back either an ACCEPT or REFUSE from each target. An
   intermediate ST agent that receives a CONNECT behaves as explained in
   Section 4.5.

        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 = 4   |J N|S|    0    |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Reference           |          LnkReference = 0     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |          ReasonCode = 0       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           MaxMsgSize          |          RecoveryTimeout      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        StreamCreationTime                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   IPHops      |                        0                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                             Origin                            :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           FlowSpec                            :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                          TargetList                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                          RecordRoute                          :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                             Group                             :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                        MulticastAddress                       :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                            UserData                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 24: CONNECT Control Message

Top      Up      ToC       Page 91 
o   JN (bits 8 and 9) indicate the join authorization level for the
    stream, see Section 4.4.2.

o   S (bit 10) indicates the NoRecovery option (Section 4.4.1). When the
    S-bit is set (1), the NoRecovery option is specified for the stream.

o   Reference contains a number assigned by the ST agent sending CONNECT
    for use in the acknowledging ACK.

o   MaxMsgSize indicates the smallest MTU along the path traversed by
    the stream. This field is initially set to the network MTU of the
    agent issues the CONNECT.

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

o   StreamCreationTime is the 32- bits system dependent timestamp
    generated by the ST agent issuing the CONNECT.

o   IPHops is the number of IP encapsulated hops traversed by the
    stream. This field is set to zero by the origin, and is incremented
    at each IP encapsulating agent.

Top      Up      ToC       Page 92 
10.4.5  DISCONNECT

   DISCONNECT (OpCode = 5) is used by an origin to tear down an
   established stream or part of a stream, or by an intermediate ST
   agent that detects a failure between itself and its previous-hop, as
   distinguished by the ReasonCode. The DISCONNECT message specifies the
   list of targets that are to be disconnected. An ACK is required in
   response to a DISCONNECT message. The DISCONNECT message is
   propagated all the way to the specified targets. The targets are
   expected to terminate their participation in the stream.

        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 = 5   |G|    0        |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Reference                |     LnkReference = 0          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |          ReasonCode           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      GeneratorIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           TargetList                          :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                            UserData                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 25: DISCONNECT Control Message

o   G (bit 8) is used to request a DISCONNECT of all the stream's
    targets. TargetList should be omitted when the G-bit is set (1). If
    TargetList is present, it is ignored.

o   Reference contains a number assigned by the ST agent sending
    DISCONNECT for use in the acknowledging ACK.

o   ReasonCode reflects the event that initiated the message.

o   GeneratorIPAddress is the 32-bit IP address of the host that first
    generated the DISCONNECT message.

Top      Up      ToC       Page 93 
10.4.6  ERROR

   ERROR (OpCode = 6) is sent in acknowledgment to a request in which an
   error is detected. No action is taken on the erroneous request. No
   ACK is expected. The ERROR message is not propagated beyond the
   previous-hop or next-hop ST agent. An ERROR is never sent in response
   to another ERROR. The receiver of an ERROR is encouraged to try again
   without waiting for a retransmission timeout.

        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 = 6   |       0       |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Reference                |     LnkReference = 0          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |        ReasonCode             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           PDUInError                          :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 26: ERROR Control Message

o   Reference is the Reference number of the erroneous request.

o   ReasonCode indicates the error that triggered the message.

o   PDUInError is the PDU in error, beginning with the ST Header. This
    parameter is optional. Its length is limited by network MTU, and may
    be truncated when too long.

Top      Up      ToC       Page 94 
10.4.7  HELLO

   HELLO (OpCode = 7) is used as part of the ST failure detection
   mechanism, see Section 6.1.

        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 = 7   |R|    0        |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Reference = 0           |        LnkReference = 0       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Checksum              |          ReasonCode = 0       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          HelloTimer                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 27: HELLO Control Message

o   R (bit 8) is used for the Restarted-bit.

o   HelloTimer represents the time in millisecond since the agent was
    restarted, modulo the precision of the field. It is used to detect
    duplicate or delayed HELLO messages.

Top      Up      ToC       Page 95 
10.4.8  JOIN

   JOIN (OpCode = 8) is used as part of the ST steam joining mechanism,
   see Section 4.6.3.

        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 = 8   |      0        |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Reference                |         LnkReference = 0      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |          ReasonCode = 0       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      GeneratorIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                          TargetList                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 28: JOIN Control Message

o   Reference contains a number assigned by the ST agent sending JOIN
    for use in the acknowledging ACK.

o   GeneratorIPAddress is the 32-bit IP address of the host that
    generated the JOIN message.

o   TargetList is the information associated with the target to be added
    to the stream.

Top      Up      ToC       Page 96 
10.4.9  JOIN-REJECT

   JOIN-REJECT (OpCode = 9) is used as part of the ST steam joining
   mechanism, see Section 4.6.3.

        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 = 9   |      0        |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Reference                |          LnkReference         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |          ReasonCode           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      GeneratorIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 29: JOIN-REJECT Control Message

o   Reference contains a number assigned by the ST agent sending the
    REFUSE for use in the acknowledging ACK.

o   LnkReference is the Reference number from the corresponding JOIN
    message.

o   ReasonCode reflects the reason why the JOIN request was rejected.

o   GeneratorIPAddress is the 32-bit IP address of the host that first
    generated the JOIN-REJECT message.

Top      Up      ToC       Page 97 
10.4.10  NOTIFY

   NOTIFY (OpCode = 10) is issued by an ST agent to inform other ST
   agents of events that may be significant. NOTIFY may be propagated
   beyond the previous-hop or next-hop ST agent depending on the
   ReasonCode, see Section 10.5.3; NOTIFY must be acknowledged with an
   ACK.

        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 = 10  |      0        |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Reference                |         LnkReference = 0      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |          ReasonCode           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      DetectorIPAddress                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          MaxMsgSize           |          RecoveryTimeout      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           FlowSpec                            :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           TargetList                          :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           UserData                            :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 30: NOTIFY Control Message

o   Reference contains a number assigned by the ST agent sending the
    NOTIFY for use in the acknowledging ACK.

o   ReasonCode identifies the reason for the notification.

o   DetectorIPAddress is the 32-bit IP address of the ST agent that
    detects the event.

o   MaxMsgSize is set when the MTU of the listed targets has changed
    (e.g., due to recovery), or when the notification is generated after
    a successful JOIN. Otherwise it is set to zero (0).

Top      Up      ToC       Page 98 
o   RecoveryTimeout is set when the notification is generated after a
    successful JOIN. Otherwise it is set to zero (0).

o   FlowSpec is present when the notification is generated after a
    successful JOIN.

o   TargetList is present when the notification is related to one or
    more targets, or when MaxMsgSize is set

o   UserData is present if the notification is generated after a
    successful JOIN and the UserData parameter was set in the ACCEPT
    message.

10.4.11  REFUSE

   REFUSE (OpCode = 11) is issued by a target that either does not wish
   to accept a CONNECT message or wishes to remove itself from an
   established stream. It might also be issued by an intermediate ST
   agent in response to a CONNECT or CHANGE either to terminate a
   routing loop, or when a satisfactory next-hop to a target cannot be
   found. It may also be a separate command when an existing stream has
   been preempted by a higher precedence stream or an ST agent detects
   the failure of a previous-hop, next-hop, or the network between them.
   In all cases, the TargetList specifies the targets that are affected
   by the condition. Each REFUSE must be acknowledged by an ACK.

   The REFUSE is relayed back by the ST agents to the origin (or
   intermediate ST agent that created the CONNECT or CHANGE) along the
   path traced by the CONNECT. The ST agent receiving the REFUSE will
   process it differently depending on the condition that caused it, as
   specified in the ReasonCode field. No special effort is made to
   combine multiple REFUSE messages since it is considered most unlikely
   that separate REFUSEs will happen to both pass through an ST agent at
   the same time and be easily combined, e.g., have identical
   ReasonCodes and parameters.

Top      Up      ToC       Page 99 
        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 = 11  |G|E|N|    0    |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Reference                |         LnkReference          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |          ReasonCode           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       DetectorIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       ValidTargetIPAddress                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                          TargetList                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                         RecordRoute                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                            UserData                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 31: REFUSE Control Message

o   G (bit 8) is used to indicate that all targets down stream from the
    sender are refusing. It is expected that this will be set most
    commonly due to network failures. The TargetList parameter is
    ignored or not present when this bit is set, and must be included
    when not set.

o   E (bit 9) is set by an ST agent to indicate that the request failed
    and that the pre-change stream attributes, including resources, and
    the stream itself still exist.

o   N (bit 10) is used to indicate that no further attempts to recover
    the stream should be made. This bit must be set when stream recovery
    should not be attempted, even in the case where the target
    application has shut down normally (ApplDisconnect).

o   Reference contains a number assigned by the ST agent sending the
    REFUSE for use in the acknowledging ACK.

o   LnkReference is either the Reference number from the corresponding
    CONNECT or CHANGE, if it is the result of such a message, or zero
    when the REFUSE was originated as a separate command.

Top      Up      ToC       Page 100 
o   DetectorIPAddress is the 32-bit IP address of the host that first
    generated the REFUSE message.

o   ValidTargetIPAddress is the 32-bit IP address of a host that is
    properly connected as part of the stream. This parameter is only
    used when recovering from stream convergence, otherwise it is set to
    zero (0).

10.4.12  STATUS

   STATUS (OpCode = 12) is used to inquire about the existence of a
   particular stream identified by the SID. Use of STATUS is intended
   for collecting information from an neighbor ST agent, including
   general and specific stream information, and round trip time
   estimation. The use of this message type is described in Section 8.4.

        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 = 12   |       0       |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Reference                |       LnkReference = 0        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |          ReasonCode = 0       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                          TargetList                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 32: STATUS Control Message

o   Reference contains a number assigned by the ST agent sending STATUS
    for use in the replying STATUS-RESPONSE.

o   TargetList is an optional parameter that when present indicates that
    only information related to the specific targets should be relayed
    in the STATUS-RESPONSE.

10.4.13  STATUS-RESPONSE

   STATUS-RESPONSE (OpCode = 13) 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 SID but no other parameters. It
   will otherwise contain the current SID, FlowSpec, TargetList, and
   possibly Groups of the stream. It the full target list can not fit in
   a single message, only those targets that can be included in one

Top      Up      ToC       Page 101 
   message will be included. As mentioned in Section 10.4.12, it is
   possible to request information on a specific target.

        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 = 13  |    0          |           TotalBytes          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Reference                |       LnkReference = 0        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SenderIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Checksum           |       ReasonCode = 0          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           FlowSpec                            :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           Groups                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                          TargetList                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 33: STATUS-RESPONSE Control Message

o   Reference contains a number assigned by the ST agent sending the
    STATUS.

10.5  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.

Top      Up      ToC       Page 102 
10.5.1  SCMP Messages

   1)      ACCEPT
   2)      ACK
   3)      CHANGE
   4)      CONNECT
   5)      DISCONNECT
   6)      ERROR
   7)      HELLO
   8)      JOIN
   9)      JOIN-REJECT
   10)     NOTIFY
   11)     REFUSE
   12)     STATUS
   13)     STATUS-RESPONSE

10.5.2  SCMP Parameters

   1)      FlowSpec
   2)      Group
   3)      MulticastAddress
   4)      Origin
   5)      RecordRoute
   6)      TargetList
   7)      UserData

10.5.3  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. The
   ReasonCode is an 8-bit field. Following values are defined:

1       NoError         No error has occurred.
2       ErrorUnknown    An error not contained in this list has been
                        detected.
3       AccessDenied    Access denied.
4       AckUnexpected   An unexpected ACK was received.
5       ApplAbort       The application aborted the stream abnormally.
6       ApplDisconnect  The application closed the stream normally.
7       ApplRefused     Applications refused requested connection or
                        change.
8       AuthentFailed   The authentication function failed.
9       BadMcastAddress IP Multicast address is unacceptable in CONNECT
10      CantGetResrc    Unable to acquire (additional) resources.

Top      Up      ToC       Page 103 
11      CantRelResrc    Unable to release excess resources.
12      CantRecover     Unable to recover failed stream.
13      CksumBadCtl     Control PDU has a bad message checksum.
14      CksumBadST      PDU has a bad ST Header checksum.
15      DuplicateIgn    Control PDU is a duplicate and is being
                        acknowledged.
16      DuplicateTarget Control PDU contains a duplicate target, or an
                        attempt to add an existing target.
17      FlowSpecMismatch        FlowSpec in request does not match
                                existing FlowSpec.
18      FlowSpecError   An error occurred while processing the FlowSpec
19      FlowVerUnknown  Control PDU has a FlowSpec Version Number that
                        is not supported.
20      GroupUnknown    Control PDU contains an unknown Group Name.
21      InconsistGroup  An inconsistency has been detected with the
                        streams forming a group.
22      IntfcFailure    A network interface failure has been detected.
23      InvalidSender   Control PDU has an invalid SenderIPAddress
                        field.
24      InvalidTotByt   Control PDU has an invalid TotalBytes field.
25      JoinAuthFailure Join failed due to stream authorization level.
26      LnkRefUnknown   Control PDU contains an unknown LnkReference.
27      NetworkFailure  A network failure has been detected.
28      NoRouteToAgent  Cannot find a route to an ST agent.
29      NoRouteToHost   Cannot find a route to a host.
30      NoRouteToNet    Cannot find a route to a network.
31      OpCodeUnknown   Control PDU has an invalid OpCode field.
32      PCodeUnknown    Control PDU has a parameter with an invalid
                        PCode.
33      ParmValueBad    Control PDU contains an invalid parameter value.
34      PathConvergence Two branches of the stream join during the
                        CONNECT setup.
35      ProtocolUnknown Control PDU contains an unknown next-higher
                        layer protocol identifier.
36      RecordRouteSize RecordRoute parameter is too long to permit
                        message to fit a network's MTU.
37      RefUnknown      Control PDU contains an unknown Reference.
38      ResponseTimeout Control message has been acknowledged but not
                        answered by an appropriate control message.
39      RestartLocal    The local ST agent has recently restarted.
40      RestartRemote   The remote ST agent has recently restarted.
41      RetransTimeout  An acknowledgment has not been received after
                        several retransmissions.
42      RouteBack       Route to next-hop through same interface as
                        previous-hop and is not previous-hop.
43      RouteInconsist  A routing inconsistency has been detected.
44      RouteLoop       A routing loop has been detected.

Top      Up      ToC       Page 104 
45      SAPUnknown      Control PDU contains an unknown next-higher
                        layer SAP (port).
46      SIDUnknown      Control PDU contains an unknown SID.
47      STAgentFailure  An ST agent failure has been detected.
48      STVer3Bad       A received PDU is not ST Version 3.
49      StreamExists    A stream with the given SID already exists.
50      StreamPreempted The stream has been preempted by one with a
                        higher precedence.
51      TargetExists    A CONNECT was received that specified an
                        existing target.
52      TargetUnknown   A target is not a member of the specified
                        stream.
53      TargetMissing   A target parameter was expected and is not
                        included, or is empty.
54      TruncatedCtl    Control PDU is shorter than expected.
55      TruncatedPDU    A received ST PDU is shorter than the ST Header
                        indicates.
56      UserDataSize    UserData parameter too large to permit a
                        message to fit into a network's MTU.

10.5.4  Timeouts and Other Constants

   SCMP uses retransmission to effect reliability and thus has several
   "retransmission timers". Each "timer" is modeled by an initial time
   interval (ToXxx), which may get 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. Note that the variables are described
   for reference purposes only, different implementations may not
   include the identical variables.

Value   Timeout Name    Meaning
------------------------------------------------------------------------
  500   ToAccept        Initial hop-by-hop timeout for acknowledgment of
                        ACCEPT
    3   NAccept         ACCEPT retries before failure
  500   ToChange        Initial hop-by-hop timeout for acknowledgment of
                        CHANGE
    3   NChange         CHANGE retries before failure
 5000   ToChangeResp    End-to-End CHANGE timeout for receipt of ACCEPT
                        or REFUSE
  500   ToConnect       Initial hop-by-hop timeout for acknowledgment of
                        CONNECT
    5   NConnect        CONNECT retries before failure
 5000   ToConnectResp   End-to-End CONNECT timeout for receipt of ACCEPT
                        or REFUSE from targets by origin
  500   ToDisconnect    Initial hop-by-hop timeout for acknowledgment of
                        DISCONNECT

Top      Up      ToC       Page 105 
    3   NDisconnect     DISCONNECT retries before failure
  500   ToJoin          Initial hop-by-hop timeout for acknowledgment of
                        JOIN
    3   NJoin           JOIN retries before failure
  500   ToJoinReject    Initial hop-by-hop timeout for acknowledgment of
                        JOIN-REJECT
    3   NJoinReject     JOIN-REJECT retries before failure
 5000   ToJoinResp      Timeout for receipt of CONNECT or JOIN-REJECT
                        from origin or intermediate hop
  500   ToNotify        Initial hop-by-hop timeout for acknowledgment of
                        NOTIFY
    3   NNotify         NOTIFY retries before failure
  500   ToRefuse        Initial hop-by-hop timeout for acknowledgment of
                        REFUSE
    3   NRefuse         REFUSE retries before failure
  500   ToRetryRoute    Timeout for receipt of ACCEPT or REFUSE from
                        targets during failure recovery
    5   NRetryRoute     CONNECT retries before failure
 1000   ToStatusResp    Timeout for receipt of STATUS-RESPONSE
    3   NStatus         STATUS retries before failure
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

10.6  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.

Top      Up      ToC       Page 106 
        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 34:  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 35: 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 (:). Optional parameters are separated from
   control messages with a blank line. The order of parameters is not
   meaningful.

11.  References

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

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

Top      Up      ToC       Page 107 
[WoHD95]        L. Wolf, R. G. Herrtwich, L. Delgrossi: Filtering
                Multimedia Data in Reservation-based Networks,
                Kommunikation in Verteilten Systemen 1995 (KiVS),
                Chemnitz-Zwickau, Germany, February 1995.

[RFC1122]       Braden, R., "Requirements for Internet Hosts --
                Communication Layers", STD 3, RFC 1122,
                USC/Information Sciences Institute, October 1989.

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

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

[RFC1141]       Mallory, T., and A. Kullberg, "Incremental Updating
                of the Internet Checksum", RFC 1141, BBN, January 1990.

[RFC1363]       Partridge, C., "A Proposal Flow Specification",
                RFC 1363, BBN, September 1992.

[RFC791]        Postel, J., "Internet Protocol", STD 5, RFC 791,
                DARPA, September 1981.

[RFC1700]       Reynolds, J., and J. Postel, "Assigned Numbers",
                STD 2, RFC 1700, USC/Information Sciences Institute,
                October 1994.

[RFC1190]       Topolcic C., "Internet Stream Protocol Version 2
                (ST-II)", RFC 1190, CIP Working Group, October 1990.

[RFC1633]       Braden, R., Clark, D., and S. Shenker, "Integrated
                Services in the Internet Architecture: an Overview",
                RFC 1633, USC/Information Sciences Institute,
                MIT, Xerox PARC, June 1994.

[VoHN93]        C. Vogt, R. G. Herrtwich, R. Nagarajan: HeiRAT: the
                Heidelberg Resource Administration Technique - Design
                Philosophy and Goals, Kommunikation In Verteilten
                Systemen, Munich, Informatik Aktuell, Springer-Verlag,
                Heidelberg, 1993.

[Cohe81]        D. Cohen: A Network Voice Protocol NVP-II, University of
                Southern California, Los Angeles, 1981.

[Cole81]        R. Cole: PVP - A Packet Video Protocol, University of
                Southern California, Los Angeles, 1981.

Top      Up      ToC       Page 108 
[DeAl92]        L. Delgrossi (Ed.) The BERKOM-II Multimedia Transport
                System, Version 1, BERKOM Working Document, October,
                1992.

[DHHS92]        L. Delgrossi, C. Halstrick, R. G. Herrtwich, H.
                Stuettgen: HeiTP: a Transport Protocol for ST-II,
                GLOBECOM'92, Orlando (Florida), December 1992.

[Schu94]        H. Schulzrinne: RTP: A Transport Protocol for Real-Time
                Applications. Work in Progress, 1994.


12.  Security Considerations

   Security issues are not discussed in this memo.

13.  Acknowledgments and Authors' Addresses

   Many individuals have contributed to the work described in this memo.
   We thank the participants in the ST Working Group for their input,
   review, and constructive comments. George Mason University C3I Center
   for hosting an interim meeting. Murali Rajagopal for his efforts on
   ST2+ state machines. Special thanks are due to Steve DeJarnett, who
   served as working group co-chair until summer 1993.

   We would also like to acknowledge the authors of [RFC1190]. All
   authors of [RFC1190] should be considered authors of this document
   since this document contains much of their text and ideas.

Top      Up      ToC       Page 109 
   Louis Berger
   BBN Systems and Technologies
   1300 North 17th Street, Suite 1200
   Arlington, VA 22209

   Phone: 703-284-4651
   EMail: lberger@bbn.com


   Luca Delgrossi
   Andersen Consulting Technology Park
   449, Route des Cretes
   06902 Sophia Antipolis, France

   Phone: +33.92.94.80.92
   EMail: luca@andersen.fr


   Dat Duong
   BBN Systems and Technologies
   1300 North 17th Street, Suite 1200
   Arlington, VA 22209

   Phone: 703-284-4760
   EMail: dat@bbn.com


   Steve Jackowski
   Syzygy Communications Incorporated
   269 Mt. Hermon Road
   Scotts Valley, CA 95066

   Phone: 408-439-6834
   EMail: stevej@syzygycomm.com


   Sibylle Schaller
   IBM ENC
   Broadband Multimedia Communications
   Vangerowstr. 18
   D69020 Heidelberg, Germany

   Phone: +49-6221-5944553
   EMail: schaller@heidelbg.ibm.com