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 5 of 6, p. 100 to 124
Prev RFC Part       Next RFC Part

 


prevText      Top       Page 100 
         4.2.3.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.  The ACCEPT includes
            the FlowSpec that contains the cumulative information that
            was calculated by the intervening ST agents as the CONNECT
            made its way from the origin to the target, as well as any
            modifications made by the application at the target.  The
            ACCEPT is relayed by the ST agents from the target to the
            origin along the path established by the CONNECT but in the
            reverse direction.  The ACCEPT must be acknowledged with an
            ACK at each hop.

            The FlowSpec is not modified on this trip from the target
            back to the origin.  Since the cumulative FlowSpec
            information can be different for different targets, no
            attempt is made to combine the ACCEPTs from the various
            targets.  The TargetList included in each ACCEPT contains
            the IP address of only the target that issued the ACCEPT.

            Any SrcRoute parameters in the TargetList are ignored.

            Since an ACCEPT might be the first response from a next-hop
            on a control link (due to network reordering), the SVLId
            field may be the first source of the Virtual Link Identifier
            to be used in the RVLId field of subsequent control messages
            sent to that next-hop.

            When the FDx option has been selected to setup a second
            stream in the reverse direction, the ACCEPT will contain
            both RFlowSpec and RName parameters.  Each agent should
            update the state tables for the reverse stream with this
            information.

               TSR (bits 14 and 15) specifies the target's response for
               the use of data packet timestamps; see Section 4 (page
               76).  Its values and semantics are:

                  00  Not implemented.
                  01  No timestamps are permitted.
                  10  Timestamps must always be present.
                  11  Timestamps may optionally be present.

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

               LnkReference is the Reference number from the
               corresponding CONNECT or CHANGE.

Top       Page 101 
    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     |TSR|           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DetectorIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      FlowSpec Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     TargetList Parameter                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     RecordRoute Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      RFlowSpec Parameter                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         RName Parameter                       !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      UserData Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 39.  ACCEPT Control Message

Top       Page 102 
         4.2.3.2.         ACK

            ACK (OpCode = 2) is used to acknowledge a request.  The
            Reference in the header is the Reference number of the
            control message being acknowledged.

            Since a ACK might be the first response from a next-hop on a
            control link, the SVLId field may be the first source of the
            Virtual Link Identifier to be used in the RVLId field of
            subsequent control messages sent to that next-hop.

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


    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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |          ReasonCode           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 40.  ACK Control Message

Top       Page 103 
         4.2.3.3.         CHANGE-REQUEST

            CHANGE-REQUEST (OpCode = 4) is used by an intermediate or
            target agent to request that the origin change the FlowSpec
            of an established stream.  The CHANGE-REQUEST message is
            propagated hop-by-hop to the origin, with an ACK at each
            hop.

            Any SrcRoute parameters in the targets of the TargetList are
            ignored.

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


    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   |G|      0      |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DetectorIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                       FlowSpec Parameter                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      UserData Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 41.  CHANGE-REQUEST Control Message

Top       Page 104 
         4.2.3.4.         CHANGE

            CHANGE (OpCode = 3) is used to change the FlowSpec of an
            established stream.  Parameters are the same as for CONNECT
            but the TargetList is not required.  The CHANGE message is
            processed similarly to the CONNECT message, except that it
            travels along the path of an established stream.

            If the change to the FlowSpec is in a direction that makes
            fewer demands of the involved networks, then the change has
            a high probability of success along the path of the
            established stream.  Each ST agent receiving the CHANGE
            message makes the necessary requested changes to the network
            resource allocations, and if successful, propagates the
            CHANGE message along the established paths.  If the change
            cannot be made then the ST agent must recover using
            DISCONNECT and REFUSE messages as in the case of a network
            failure.  Note that a failure to change the resources
            requested for a specific target(s) should not cause other
            targets in the stream to be deleted.  The CHANGE must be
            ACKed.

            If the CHANGE is a result of a CHANGE-REQUEST the
            LnkReference field of the CHANGE will contain the value from
            the Reference field of the CHANGE-REQUEST.

            It is recommended that the origin only have one outstanding
            CHANGE per target;  if the application requests more that
            one to be outstanding at a time, it is the application's
            responsibility to deal with any sequencing problems that may
            arise.

            Any SrcRoute parameters in the targets of the
            TargetListParameter are ignored.

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

Top       Page 105 
    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|      0      |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DetectorIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                       FlowSpec Parameter                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      UserData Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 42.  CHANGE Control Message




         4.2.3.5.         CONNECT

            CONNECT (OpCode = 5) 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 CONNECT to each next-hop is used to
            convey the initial suggestion for a HID.  If the stream's
            data packets will be sent to some set of next-hop ST agents
            by multicast then the CONNECTs to that set must suggest the
            same HID.  Otherwise, the HIDs in the various CONNECTs can
            be different.

            The CONNECT message must fit within the maximum allowable
            packet size (MTU) for the intervening network.  If a CONNECT
            message is too large, it must be fragmented into multiple
            CONNECT messages by partitioning the TargetList; see Section
            4.2 (page 77).  Any UserData parameter will be replicated in
            each fragment for delivery to all targets.

Top       Page 106 
            The next-hop can initially respond with any of the following
            five responses:

             1  ERROR-IN-REQUEST, which implies that the CONNECT was
                not valid and has been ignored,

             2  ACK, which implies that the CONNECT with the H bit not
                set was valid and is being processed,

             3  HID-APPROVE, which implies that the CONNECT with the
                H bit set was valid, and the suggested HID can be
                used or was deferred,

             4  HID-REJECT, which implies that the CONNECT with the H
                bit set was valid but the suggested HID cannot be
                used and another must be suggested in a subsequent
                HID-CHANGE message, or

             5  REFUSE, which implies that the CONNECT was valid but
                the included list of targets in the REFUSE cannot be
                processed for the stated reason.

            The next-hop will later relay back either an ACCEPT or
            REFUSE from each target not already specified in the REFUSE
            of case 5 above (note multiple targets may be included in a
            single REFUSE message).

            An intermediate ST agent that receives a CONNECT selects the
            next-hop ST agents, partitions the TargetList accordingly,
            reserves network resources in the direction toward the
            next-hop, updating the FlowSpec accordingly (see Section
            4.2.2.3 (page 81)), selects a proposed HID for each next-
            hop, and sends the resulting CONNECTs.

            If the intermediate ST agent that is processing a CONNECT
            fails to find a route to a target, then it responds with a
            REFUSE with the appropriate reason code.  If the next-hop to
            a target is by way of the network from which it received the
            CONNECT, then it sends a NOTIFY with the appropriate reason
            code (RouteBack).  In either case, the TargetList specifies
            the affected targets.  The intermediate ST agent will only
            route to and propagate a CONNECT to the targets for which it
            does not issue either an ERROR-IN-REQUEST or a REFUSE.

Top       Page 107 
            The processing of a received CONNECT message requires care
            to avoid routing loops that could result from delays in
            propagating routing information among ST agents.  If a
            received CONNECT contains a new Name, a new stream should be
            created (unless the Virtual Link Identifier matches a known
            link in which case an ERROR-IN-REQUEST should be sent).  If
            the Name is known, there are four cases:

             1  the Virtual Link Identifier matches and the Target
                matches a current Target -- the duplicate target
                should be ignored.

             2  the Virtual Link Identifier matches but the Target is
                new -- the stream should be expanded to include the
                new target.

             3  the Virtual Link Identifier differs and the Target
                matches a current Target -- an ERROR-IN-REQUEST
                message should be sent specifying that the target is
                involved in a routing loop.  If a reroute, the old
                path will eventually timeout and send a DISCONNECT;
                a subsequent retransmission of the rerouted CONNECT
                will then be processed under case 2 above.

             4  the Virtual Link Identifier differs but the Target is
                new -- a new (instance of the) stream should be
                created for the target that is deliberately part of
                a loop using a SrcRoute parameter.


            Note that the test for a known or matching Target includes
            comparing any SrcRoute parameter that might be present.

            Option bits are specified by either the origin's service
            user or by an intermediate agent, depending on the specific
            option.  Bits not specified below are currently unspecified,
            and should be set to zero (0) by the origin agent and not
            changed by other agents unless those agents know their
            meaning.

               H (bit 8) is used for the HID Field option; see Section
               3.6.1 (page 44).  It is set to one (1) only if the HID
               field contains either zero (when the HID selection is
               being deferred), or the proposed HID.  This bit is zero
               (0) if the HID field does not contain valid data and
               should be ignored.

               P (bit 9) is used for the PTP option; see Section 3.6.2
               (page 44).

               S (bit 10) is used for the NoRecovery option; see Section
               3.6.4 (page 46).

Top       Page 108 
               TSP (bits 14 and 15) specifies the origin's proposal for
               the use of data packet timestamps; see Section 4 (page
               76).  Its values and semantics are:

                  00  No proposal.
                  01  Cannot insert timestamps.
                  10  Must always insert timestamps.
                  11  Can insert timestamps if requested.

               RVLId, the receiver's Virtual Link Identifier, is set to
               zero in all CONNECT messages until its value arrives in
               the SVLId field of an acknowledgment to the CONNECT.

               SVLId, the sender's Virtual Link Identifier, is set to a
               value chosen by each hop to facilitate efficient
               dispatching of subsequent control messages.

               HID is the identifier that will be used with data packets
               moving through the stream in the direction from the
               origin to the targets.  It is a hop-by-hop shorthand
               identifier for the stream's Name, and is chosen by each
               agent for the branch to the next-hop agents.  The
               contents of the HID field are only valid, and a HID-
               REJECT or HID-APPROVE reply may only be sent, when the
               HID Field option (H bit) is set (1).  If the HID Field
               option is specified and the proposed HID is zero, the
               selection of the HID is deferred to the receiving next-
               hop agent.  If the HID Field option is not set (H bit is
               0), then the HID field does not contain valid data and
               should be ignored;  see Section 3.6.1 (page 44).

               TargetList is the list of IP addresses of the target
               processes.  It is of arbitrary size up to the maximum
               allowed for packets traveling across the specific
               network.

Top       Page 109 
    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   |H|P|S|  0  |TSP|           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            RVLId/0            |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |             HID/0             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DetectorIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                       Origin Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      FlowSpec Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      TargetList Parameter(s)                  :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   MulticastAddress Parameter                  :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     RecordRoute Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      RFlowSpec Parameter                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                        RGroup Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                        RHID Parameter                         !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      UserData Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 43.  CONNECT Control Message

Top       Page 110 
         4.2.3.6.         DISCONNECT

            DISCONNECT (OpCode = 6) is used by an origin to tear down an
            established stream or part of a stream, or by an
            intermediate 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.

            Note that in the case of a failure it may be advantageous to
            retain state information as the stream should be repaired
            shortly;  see Section 3.7.2 (page 52).

               G (bit 8) is used to request a DISCONNECT of all the
               stream's targets; the TargetList parameter may be omitted
               when the G bit is set (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 = 6   |G|      0      |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |          ReasonCode           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DetectorIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      UserData Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 44.  DISCONNECT Control Message

Top       Page 111 
         4.2.3.7.         ERROR-IN-REQUEST

            ERROR-IN-REQUEST (OpCode = 7) is sent in acknowledgment to a
            request in which an error is detected.  No action is taken
            on the erroneous request and no state information for the
            stream is retained.  Consequently it is appropriate for the
            SVLId to be zero (0).  No ACK is expected.

            An ERROR-IN-REQUEST is never sent in response to either an
            ERROR-IN-REQUEST or an ERROR-IN-RESPONSE;  however, the
            event should be logged for diagnostic purposes.  The
            receiver of an ERROR-IN-REQUEST is encouraged to try again
            without waiting for a retransmission timeout.

               Reference is the Reference number of the erroneous
               request.


    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   |       0       |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |            SVLId/0            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |          ReasonCode           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DetectorIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                          ErroredPDU                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

              Figure 45.  ERROR-IN-REQUEST Control Message

Top       Page 112 
         4.2.3.8.         ERROR-IN-RESPONSE

            ERROR-IN-RESPONSE (OpCode = 8) is sent in acknowledgment to
            a response in which an error is detected.  No ACK is
            expected.  Action taken by the requester and responder will
            vary with the nature of the request.

            An ERROR-IN-REQUEST is never sent in response to either an
            ERROR-IN-REQUEST or an ERROR-IN-RESPONSE;  however, the
            event should be logged for diagnostic purposes.  The
            receiver of an ERROR-IN-RESPONSE is encouraged to try again
            without waiting for a retransmission timeout.

            Reference identifies the erroneous response.


    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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |          ReasonCode           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DetectorIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                          ErroredPDU                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

             Figure 46.  ERROR-IN-RESPONSE Control Message

Top       Page 113 
         4.2.3.9.         HELLO

            HELLO (OpCode = 9) is used as part of the ST failure
            detection mechanism; see Section 3.7.1.2 (page 49).

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

               Reference is non-zero to inform the receiver that an ACK
               should be promptly sent so that the sender can update its
               round-trip time estimates.  If the Reference is zero, no
               ACK should be sent.


    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   |R|      0      |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            RVLId/0            |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reference/0          |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          HelloTimer                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                        OriginTimestamp                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 47.  HELLO Control Message

Top       Page 114 
         4.2.3.10.        HID-APPROVE

            HID-APPROVE (OpCode = 10) is used by the agent that is
            responding to either a CONNECT or HID-CHANGE to agree to
            either use the proposed HID or to the addition or deletion
            of the specified HID.  In all cases but deletion, the newly
            approved HID is returned in the HID field;  for deletion,
            the HID field must be set to zero.  The HID-APPROVE is the
            acknowledgment of a CONNECT or HID-CHANGE.

            The optional FreeHIDs parameter provides the previous-hop
            agent with hints about what other HIDs are acceptable in
            case a multicast HID is being negotiated;  see Section
            4.2.2.4 (page 84).

            Since a HID-APPROVE might be the first response from a
            next-hop on a control link, the SVLId field may be the first
            source of the Virtual Link Identifier to be used in the
            RVLId field of subsequent control messages sent to that
            next-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 = 10  |       0       |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |              HID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      FreeHIDs Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 48.  HID-APPROVE Control Message

Top       Page 115 
         4.2.3.11.        HID-CHANGE-REQUEST

            HID-CHANGE-REQUEST (OpCode = 12) is used by a next-hop agent
            that would like, for administrative reasons, to change the
            HID that is in use.  The receiving previous-hop agent
            acknowledges the request by either an ERROR-IN-REQUEST if it
            is unwilling to make the requested change, or with a HID-
            CHANGE if it can accommodate the request.

               A (bit 8) is used to indicate that the specified HID
               should be included in the set of HIDs for the specified
               Name.  When a HID is added, the acknowledging HID-APPROVE
               should contain a HID field whose contents is the HID just
               added.

               D (bit 9) is used to indicate that the specified HID
               should be removed in the set of HIDs for the specified
               Name.  When a HID is deleted, the acknowledging HID-
               APPROVE should contain a HID field whose contents is
               zero.  Note that the Reference field may be used to
               determine the HID that has been deleted.

               If neither bit is set, the specified HID should replace
               that currently in use with the specified Name.


    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  |A|D|     0     |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |              HID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 49.  HID-CHANGE-REQUEST Control Message

Top       Page 116 
         4.2.3.12.        HID-CHANGE

            HID-CHANGE (OpCode = 11) is used by the agent that issued a
            CONNECT and received a HID-REJECT to attempt to negotiate a
            suitable HID.  The HID in the HID-CHANGE message must be
            different from that in the CONNECT, or any previous HID-
            CHANGE messages for the given Name.  The agent receiving the
            HID-CHANGE must respond with a HID-APPROVE if the new HID is
            suitable, or a HID-REJECT if it is not.  In case of an
            error, either an ERROR-IN-REQUEST or a REFUSE may be
            returned as an acknowledgment.

            Since an agent may send CONNECT messages with the same HID
            to several next-hops in order to use multicast data
            transfer, any HID-CHANGE must also be sent to the same set
            of next-hops.  Therefore, a next-hop agent must be prepared
            to receive a HID-CHANGE before or after it has sent a HID-
            APPROVE response to the CONNECT or a previous HID-CHANGE.
            Only the last HID-CHANGE is relevant.  The previous-hop
            agent will ignore HID-APPROVE or HID-REJECT messages to
            previous CONNECT or HID-CHANGE messages.

            A DISCONNECT can be sent instead of a HID-CHANGE, or a
            REFUSE can be sent instead of a HID-APPROVE or HID-REJECT,
            to terminate fatally the HID negotiation and the agent's
            knowledge of the stream.

            The A and D bits are used to change a HID, e.g., when adding
            a new next-hop to a multicast group, in such a way that data
            packets that are flowing through the network will not be
            mishandled due to a race condition in processing the HID-
            CHANGE messages between the previous-hop and its next-hops.
            An implementation may choose to limit the number of
            simultaneous HIDs associated with a stream, but must allow
            at least two.

               A (bit 8) is used to indicate that the specified HID
               should be included in the set of HIDs for the specified
               Name.  When a HID is added, the acknowledging HID-APPROVE
               should contain a HID field whose contents is the HID just
               added.

               D (bit 9) is used to indicate that the specified HID
               should be removed from the set of HIDs for the specified
               Name.  When a HID is deleted, the acknowledging HID-
               APPROVE should contain a HID field whose contents is
               zero.  Note that the Reference field may be used to
               determine the HID that has been deleted.

               If neither bit is set, the specified HID should replace
               that currently in use for the specified Name.

Top       Page 117 
    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  |A|D|     0     |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |              HID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 50.  HID-CHANGE Control Message

Top       Page 118 
         4.2.3.13.        HID-REJECT

            HID-REJECT (OpCode = 13) is used as an acknowledgment that a
            CONNECT or HID-CHANGE was received and is being processed,
            but means that the HID contained in the CONNECT or HID-
            CHANGE is not acceptable.  Upon receipt of this message the
            agent that issued the CONNECT or HID-CHANGE must now issue a
            HID-CHANGE to attempt to find a suitable HID.  The HID-
            CHANGE can cause another HID-REJECT but eventually the HID-
            CHANGE must be acknowledged with a HID-APPROVE to end
            successfully the HID negotiation.  The agent that issued the
            HID-REJECT may not issue an ACCEPT before it has found an
            acceptable HID.

            Since a HID-REJECT might be the first response from a next-
            hop on a control link, the SVLId field may be the first
            source of the Virtual Link Identifier to be used in the
            RVLId field of subsequent control messages sent to that
            next-hop.

            Either agent may terminate the negotiation by issuing either
            a DISCONNECT or a REROUTE.  The agent that issued the HID-
            REJECT may issue a REFUSE, or REROUTE at any time after the
            HID-REJECT.  In this case, the stream cannot be created, the
            HID negotiation need not proceed, and the previous-hop need
            not transmit any further messages;  any further messages
            that are received should be ignored.

            The optional FreeHIDs parameter provides the previous-hop
            agent with hints about what HIDs would have been acceptable;
            see Section 4.2.2.4 (page 84).

Top       Page 119 
    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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |          RejectedHID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Name Parameter                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      FreeHIDs Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 51.  HID-REJECT Control Message

Top       Page 120 
         4.2.3.14.        NOTIFY

            NOTIFY (OpCode = 14) is issued by a an agent to inform other
            agents, the origin, or target(s) of events that may be
            significant.  The action taken by the receiver of a NOTIFY
            depends on the ReasonCode.  Possible events are suspected
            routing problems or resource allocation changes that occur
            after a stream has been established.  These changes occur
            when network components fail and when competing streams
            preempt resources previously reserved by a lower precedence
            stream.  We also anticipate that NOTIFY can be used in the
            future when additional resources become available, as is the
            case when network components recover or when higher
            precedence streams are deleted.

            NOTIFY may contain a FlowSpec that reflects that revised
            guarantee that can be promised to the stream.  NOTIFY may
            also identify those targets that are affected by the change.
            In this way, NOTIFY is similar to ACCEPT.

            NOTIFY may be relayed by the ST agents back to the origin,
            along the path established by the CONNECT but in the reverse
            direction.  It is up to the origin to decide whether a
            CHANGE should be submitted.

            When NOTIFY is received at the origin, the application
            should be notified of the target and the change in resources
            allocated along the path to it, as specified in the FlowSpec
            contained in the NOTIFY message.  The application may then
            use the information to either adjust or terminate the
            portion of the stream to each affected target.

            The NOTIFY may be propagated beyond the previous-hop or
            next-hop agent; it must be acknowledged with an ACK.

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

               ReasonCode identifies the reason for the notification.

               LnkReference, when non-zero, is the Reference number from
               a command that is the subject of the notification.

               HID is present when the notification is related to a HID.

               Name is present when the notification is related to a
               stream.

Top       Page 121 
               NextHopIPAddress is an optional parameter and contains
               the IP address of a suggested next-hop ST agent.

               TargetList is present when the notification is related to
               one or more targets.


    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 = 14  |       0       |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |          ReasonCode           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DetectorIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                          ErroredPDU                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                  NextHopIPAddress Parameter                   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     RecordRoute Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

                Figure 52.  NOTIFY Control Message

Top       Page 122 
         4.2.3.15.        REFUSE

            REFUSE (OpCode = 15) 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 agent in response to a CONNECT or CHANGE
            either to terminate fatally a failing HID negotiation, 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 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 by the agents from the originating
            agent to the origin (or intermediate agent that created the
            CONNECT or CHANGE) along the path traced by the CONNECT.
            The agent receiving the REFUSE will process it differently
            depending on the condition that caused it, as specified in
            the ReasonCode field.  In some cases, such as if a next-hop
            cannot obtain resources, the agent can release any resources
            reserved exclusively for transmissions in the stream in
            question to the target specified in the TargetList, and the
            previous-hop can attempt to find an alternate route.  In
            some cases, such as a routing failure, the previous-hop
            cannot determine where the failure occurred, and must
            propagate the REFUSE back to the origin, which can attempt
            recovery of the stream by issuing a new CONNECT.

            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 agent at the
            same time and be easily combined, e.g., have identical
            ReasonCodes and parameters.

            Since a REFUSE might be the first response from a next-hop
            on a control link, the SVLId field may be the first source
            of the Virtual Link Identifier to be used in the RVLId field
            of subsequent control messages sent to that next-hop.

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

               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       Page 123 
    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 = 15  |       0       |           TotalBytes          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RVLId             |             SVLId             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reference           |         LnkReference          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SenderIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |          ReasonCode           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DetectorIPAddress                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                        Name Parameter                         !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     TargetList Parameter                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                          ErroredPDU                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     RecordRoute Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      UserData Parameter                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 53.  REFUSE Control Message

Top       Page 124 
         4.2.3.16.        STATUS

            STATUS (OpCode = 16) is used to inquire about the existence
            of a particular stream identified by either a HID (H bit
            set) or Name (Name Parameter present).

            When a stream has been identified, a STATUS-RESPONSE is
            returned that will contain the specified HID and/or Name but
            no other parameters if the specified stream is unknown, or
            will otherwise contain the current HID(s), Name, FlowSpec,
            TargetList, and possibly Group(s) of the stream.  Note that
            if a stream has no current HID, the HID field in the
            STATUS-RESPONSE will contain zero;  it will contain the
            first, or only, HID if a valid HID exists; additional valid
            HIDs will be returned in HID parameters.

            Use of STATUS is intended for diagnostic purposes and to
            assist in stream cleanup operations.  Note that if both a
            HID and Name are specified, but they do not correspond to
            the same stream, an ERROR-IN-REQUEST with the appropriate
            reason code (InconsistHID) would be returned.

            It is possible in cases of multiple failures or network
            partitioning for an ST agent to have information about a
            stream after the stream has either ceased to exist or has
            been rerouted around the agent.  When an agent concludes
            that a stream has not been used for a period of time and
            might no longer be valid, it can probe the stream's
            previous-hop or next-hop(s) to see if they believe that the
            stream still exists through the interrogating agent.  If
            not, those hops would reply with a STATUS-RESPONSE that
            contains the HID and/or Name but no other parameters;
            otherwise, if the stream is still valid, the hops would
            reply with the parameters of the stream.

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

               Q (bit 9) is set to one (1) for remote diagnostic
               purposes when the receiving agent should return a
               stream's parameters, whether or not the source of the
               message is believed to be a previous-hop or next-hop in
               the specified stream.  Note that this use has potential
               for disclosure of sensitive information.

               RVLId and SVLId may either or both be zero when STATUS is
               used for diagnostic purposes.


Next RFC Part