5.3.  Object Processing

   This section presents processing rules for individual QoS NSLP
   objects.

5.3.1.  Reservation Sequence Number (RSN)

   A QNE's own RSN is a sequence number which applies to a particular
   signaling session (i.e., with a particular SESSION-ID).  It MUST be
   incremented for each new RESERVE message where the reservation for
   the session changes.  The RSN is manipulated using the serial number
   arithmetic rules from [RFC1982], which also defines wrapping rules
   and the meaning of 'equals', 'less than', and 'greater than' for
   comparing sequence numbers in a circular sequence space.

   The RSN starts at zero.  It is stored as part of the per-session
   state, and it carries on incrementing (i.e., it is not reset to zero)
   when a downstream peer change occurs.  (Note that Section 5.2.5.2
   provides some particular rules for use when a downstream peer
   changes.)

   The RSN object also contains an Epoch Identifier, which provides a
   method for determining when a peer has restarted (e.g., due to node
   reboot or software restart).  The exact method for providing this
   value is implementation defined.  Options include storing a serial
   number that is incremented on each restart, picking a random value on
   each restart, or using the restart time.

   On receiving a RESERVE message a QNE examines the Epoch Identifier to
   determine if the peer sending the message has restarted.  If the
   Epoch Identifier is different to that stored for the reservation then
   the RESERVE message MUST be treated as an updated reservation (even
   if the RSN is less than the current stored value), and the stored RSN
   and Epoch Identifier MUST be updated to the new values.

   When receiving a RESERVE message, a QNE uses the RSN given in the
   message to determine whether the state being requested is different
   to that already stored.  If the RSN is equal to that stored for the
   current reservation, the current state MUST be refreshed.  If the RSN
   is greater than the current stored value, the current reservation
   MUST be modified appropriately as specified in the QSPEC (provided
   that admission control and policy control succeed), and the stored
   RSN value updated to that for the new reservation.  If the RSN is
   greater than the current stored value and the RESERVE was a reduced
   refresh, the QNE SHOULD send upstream a transient error message "Full
   QSPEC required".  If the RSN is less than the current value, then it
   indicates an out-of-order message, and the RESERVE message MUST be
   discarded.

   If the QNE does not store per-session state (and so does not keep any
   previous RSN values), then it MAY ignore the value of the RSN.  It
   MUST also copy the same RSN into the RESERVE message (if any) that it
   sends as a consequence of receiving this one.

5.3.2.  Request Identification Information (RII)

   A QNE sending QUERY or RESERVE messages may require a response to be
   sent.  It does so by including a Request Identification Information
   (RII) object.  When creating an RII object, the QNE MUST select the
   value for the RII such that it is probabilistically unique within the
   given session.  A RII object is typically set by the QNI.

   A number of choices are available when implementing this.
   Possibilities might include using a random value, or a node
   identifier together with a counter.  If the value collides with one
   selected by another QNE for a different QUERY, then RESPONSE messages
   may be incorrectly terminated, and may not be passed back to the node
   that requested them.

   The node that created the RII object MUST remember the value used in
   the RII in order to match back any RESPONSE it will receive.  The
   node SHOULD use a timer to identify situations where it has taken too
   long to receive the expected RESPONSE.  If the timer expires without
   receiving a RESPONSE, the node MAY perform a retransmission as
   discussed in Section 5.2.4.  In this case, the QNE MUST NOT generate
   any RESPONSE or NOTIFY message to notify this error.

   If an intermediate QNE wants to receive a response for an outgoing
   message, but the message already included an RII when it arrived, the
   QNE MUST NOT add a new RII object nor replace the old RII object, but
   MUST simply remember this RII in order to match a later RESPONSE
   message.  When it receives the RESPONSE, it forwards the RESPONSE
   upstream towards the RII originating node.  Note that only the node

   that originally created the RII can set up a retransmission timer.
   Thus, if an intermediate QNE decides to use the RII already contained
   in the message, it MUST NOT set up a retransmission timer, but rely
   on the retransmission timer set up by the QNE that inserted the RII.

   When receiving a message containing an RII object the node MUST send
   a RESPONSE if

      o The SCOPING flag is set ('next hop' scope),

      o The PROXY scope flag is set and the QNE is the P-QNE, or

      o This QNE is the last one on the path for the given session.

   and the QNE keeps per-session state for the given session.

   In the rare event that the QNE wants to request a response for a
   message that already included an RII, and this RII value conflicts
   with an existing RII value on the QNE, the node should interrupt the
   processing the message, send an error message upstream to indicate an
   RII collision, and request a retry with a new RII value.

5.3.3.  BOUND-SESSION-ID

   As shown in the examples in Section 4, the QoS NSLP can relate
   multiple sessions together.  It does this by including the SESSION-ID
   from one session in a BOUND-SESSION-ID object in messages in another
   session.

   When receiving a message with a BOUND-SESSION-ID object, a QNE MUST
   copy the BOUND-SESSION-ID object into all messages it sends for the
   same session.  A QNE that stores per-session state MUST store the
   value of the BOUND-SESSION-ID.

   The BOUND-SESSION-ID is only indicative in nature.  However, a QNE
   implementation may use BOUND-SESSION-ID information to optimize
   resource allocation, e.g., for bidirectional reservations.  When
   receiving a teardown message (e.g., a RESERVE message with teardown
   semantics) for an aggregate reservation, the QNE may use this
   information to initiate a teardown for end-to-end sessions bound to
   the aggregate.  A QoS NSLP implementation MUST be ready to process
   more than one BOUND-SESSION-ID object within a single message.

5.3.4.  REFRESH-PERIOD

   Refresh timer management values are carried by the REFRESH-PERIOD
   object, which has local significance only.  At the expiration of a
   "refresh timeout" period, each QNE independently examines its state

   and sends a refreshing RESERVE message to the next QNE peer where it
   is absorbed.  This peer-to-peer refreshing (as opposed to the QNI
   initiating a refresh that travels all the way to the QNR) allows QNEs
   to choose refresh intervals as appropriate for their environment.
   For example, it is conceivable that refreshing intervals in the
   backbone, where reservations are relatively stable, are much larger
   than in an access network.  The "refresh timeout" is calculated
   within the QNE and is not part of the protocol; however, it must be
   chosen to be compatible with the reservation lifetime as expressed by
   the REFRESH-PERIOD and with an assessment of the reliability of
   message delivery.

   The details of timer management and timer changes (slew handling and
   so on) are identical to the ones specified in Section 3.7 of RFC 2205
   [RFC2205].

   There are two time parameters relevant to each QoS NSLP state in a
   node: the refresh period R between generation of successive refreshes
   for the state by the neighbor node, and the local state's lifetime L.
   Each RESERVE message may contain a REFRESH-PERIOD object specifying
   the R value that was used to generate this (refresh) message.  This R
   value is then used to determine the value for L when the state is
   received and stored.  The values for R and L may vary from peer to
   peer.

5.3.5.  INFO-SPEC

   The INFO-SPEC object is carried by the RESPONSE and NOTIFY messages,
   and it is used to report a successful, an unsuccessful, or an error
   situation.  In case of an error situation, the error messages SHOULD
   be generated even if no RII object is included in the RESERVE or in
   the QUERY messages.  Note that when the TEAR flag is set in the
   RESERVE message an error situation SHOULD NOT trigger the generation
   of a RESPONSE message.

   Six classes of INFO-SPEC objects are identified and specified in
   Section 5.1.3.6.  The message processing rules for each class are
   defined below.

   A RESPONSE message MUST carry INFO-SPEC objects towards the QNI.  The
   RESPONSE message MUST be forwarded unconditionally up to the QNI.
   The actions that SHOULD be undertaken by the QNI that receives the
   INFO-SPEC object are specified by the local policy of the QoS model
   supported by this QNE.  The default action is that the QNI that
   receives the INFO-SPEC object SHOULD NOT trigger any other QoS NSLP
   procedure.

   The Informational INFO-SPEC class MUST be generated by a stateful QoS
   NSLP QNE when an Informational error class is caught.  The
   Informational INFO-SPEC object MUST be carried by a RESPONSE or a
   NOTIFY message.

   In case of a unidirectional reservation, the Success INFO-SPEC class
   MUST be generated by a stateful QoS NSLP QNR when a RESERVE message
   is received and the reservation state installation or refresh
   succeeded.  In case of a bidirectional reservation, the INFO-SPEC
   object SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE
   message is received and the reservation state installation or refresh
   succeeded.  The Success INFO-SPEC object MUST be carried by a
   RESPONSE or a NOTIFY message.

   In case of a unidirectional reservation, the Protocol Error INFO-SPEC
   class MUST be generated by a stateful QoS NSLP QNE when a RESERVE or
   QUERY message is received by the QNE and a protocol error is caught.
   In case of a bidirectional reservation, the Protocol Error INFO-SPEC
   class SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE
   or QUERY message is received by the QNE and a protocol error is
   caught.  A RESPONSE message MUST carry this object, which MUST be
   forwarded unconditionally towards the upstream QNE that generated the
   RESERVE or QUERY message that triggered the generation of this INFO-
   SPEC object.  The default action for a stateless QoS NSLP QNE that
   detects such an error is that none of the QoS NSLP objects SHOULD be
   processed, and the RESERVE or QUERY message SHOULD be forwarded
   downstream.

   In case of a unidirectional reservation, the Transient Failure INFO-
   SPEC class MUST be generated by a stateful QoS NSLP QNE when a
   RESERVE or QUERY message is received by the QNE and one Transient
   failure error code is caught, or when an event happens that causes a
   transient error.  In case of a bidirectional reservation, the
   Transient Failure INFO-SPEC class SHOULD be generated by a stateful
   QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE
   and one Transient failure error code is caught.

   A RESPONSE message MUST carry this object, which MUST be forwarded
   unconditionally towards the upstream QNE that generated the RESERVE
   or QUERY message that triggered the generation of this INFO-SPEC
   object.  The transient RMF-related error MAY also be carried by a
   NOTIFY message.  The default action is that the QNE that receives
   this INFO-SPEC object SHOULD re-trigger the retransmission of the
   RESERVE or QUERY message that triggered the generation of the INFO-
   SPEC object.  The default action for a stateless QoS NSLP QNE that
   detects such an error is that none of the QoS NSLP objects SHOULD be
   processed and the RESERVE or QUERY message SHOULD be forwarded
   downstream.

   In case of a unidirectional reservation, the Permanent Failure INFO-
   SPEC class MUST be generated by a stateful QoS NSLP QNE when a
   RESERVE or QUERY message is received by a QNE and an internal or
   system error occurred, or authorization failed.  In case of a
   bidirectional reservation, the Permanent Failure INFO-SPEC class
   SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE or
   QUERY message is received by a QNE and an internal or system error
   occurred, or authorization failed.  A RESPONSE message MUST carry
   this object, which MUST be forwarded unconditionally towards the
   upstream QNE that generated the RESERVE or QUERY message that
   triggered this protocol error.  The internal, system, or permanent
   RMF-related errors MAY also be carried by a NOTIFY message.  The
   default action for a stateless QoS NSLP QNE that detects such an
   error is that none of the QoS NSLP objects SHOULD be processed and
   the RESERVE or QUERY message SHOULD be forwarded downstream.

   The QoS-specific error class may be used when errors outside the QoS
   NSLP itself occur that are related to the particular QoS model being
   used.  The processing rules of these errors are not specified in this
   document.

5.3.6.  SESSION-ID-LIST

   A SESSION-ID-LIST is carried in RESERVE messages.  It is used in two
   cases, to refresh or to tear down the indicated sessions.  A SESSION-
   ID-LIST carries information about sessions that should be refreshed
   or torn down, in addition to the main (primary) session indicated in
   the RESERVE.

   If the primary SESSION-ID is not understood, the SESSION-ID-LIST
   object MUST NOT be processed.

   When a stateful QNE goes through the SESSION-ID-LIST, if it finds one
   or more unknown SESSION-ID values, it SHOULD construct an
   informational RESPONSE message back to the upstream stateful QNE with
   the error code for unknown SESSION-ID in SESSION-ID-LIST, and include
   all unknown SESSION-IDs in a SESSION-ID-LIST.

   If the RESERVE is a tear, for each session in the SESSION-ID-LIST,
   the stateful QNE MUST inform the RMF that the reservation is no
   longer required.  RSN values MUST also be interpreted in order to
   distinguish whether the tear down is valid, or whether it is
   referring to an old state, and, thus, should be silently discarded.

   If the RESERVE is a refresh, the stateful QNE MUST also process the
   RSN-LIST object as detailed in the next section.

   If the RESERVE is a tear, for each session in the SESSION-ID-LIST,
   the QNE MUST inform the RMF that the reservation is no longer
   required.  RSN values MUST be interpreted.

   Note that a stateless QNE cannot support summary or single reduced
   refreshes, and always needs full single refreshes.

5.3.7.  RSN-LIST

   An RSN-LIST MUST be carried in RESERVE messages when a QNE wants to
   perform a refresh or teardown of several sessions with a single NSLP
   message.  The RSN-LIST object MUST be populated with RSN values of
   the same sessions and in the same order as indicated in the SESSION-
   ID-LIST.  Thus, entries in both objects at position X refer to the
   same session.

   If the primary session and RSN reference in the RESERVE were not
   understood, the stateful QNE MUST NOT process the RSN-LIST.  Instead,
   an error RESPONSE SHOULD be sent back to the upstream stateful QNE.

   On receiving an RSN-LIST object, the stateful QNE should check
   whether the number of items in the SESSION-ID-LIST and RSN-LIST
   objects match.  If there is a mismatch, the stateful QNE SHOULD send
   back a protocol error indicating a bad value in the object.

   While matching the RSN-LIST values to the SESSION-ID-LIST values, if
   one or more RSN values in the RSN-LIST are not in synch with the
   local values, the stateful QNE SHOULD construct an informational
   RESPONSE message with an error code for RSN mismatch in the RSN-LIST.
   The stateful QNE MUST include the erroneous SESSION-ID and RSN values
   in SESSION-ID-LIST and RSN-LIST objects in the RESPONSE.

   If no errors were found in processing the RSN-LIST, the stateful QNE
   refreshes the reservation states of all sessions -- the primary
   single session indicated in the refresh, and all sessions in the
   SESSION-ID-LIST.

   For each successfully processed session in the RESERVE, the stateful
   QNE performs a refresh of the reservation state.  Thus, even if some
   sessions were not in synch, the remaining sessions in the SESSION-ID-
   LIST and RSN-LIST are refreshed.

5.3.8.  QSPEC

   The contents of the QSPEC depend on the QoS model being used.  A
   template for QSPEC objects can be found in [RFC5975].

   Upon reception, the complete QSPEC is passed to the Resource
   Management Function (RMF), along with other information from the
   message necessary for the RMF processing.  A QNE may also receive an
   INFO-SPEC that includes a partial or full QSPEC.  This will also be
   passed to the RMF.

5.4.  Message Processing Rules

   This section provides rules for message processing.  Not all possible
   error situations are considered.  A general rule for dealing with
   erroneous messages is that a node should evaluate the situation
   before deciding how to react.  There are two ways to react to
   erroneous messages:

   a) Silently drop the message, or

   b) Drop the message, and reply with an error code to the sender.

   The default behavior, in order to protect the QNE from a possible
   denial-of-service attack, is to silently drop the message.  However,
   if the QNE is able to authenticate the sender, e.g., through GIST,
   the QNE may send a proper error message back to the neighbor QNE in
   order to let it know that there is an inconsistency in the states of
   adjacent QNEs.

5.4.1.  RESERVE Messages

   The RESERVE message is used to manipulate QoS reservation state in
   QNEs.  A RESERVE message may create, refresh, modify, or remove such
   state.  A QNE sending a RESERVE MAY require a response to be sent by
   including a Request Identification Information (RII) object; see
   Section 5.3.2.

   RESERVE messages MUST only be sent towards the QNR.  A QNE that
   receives a RESERVE message checks the message format.  In case of
   malformed messages, the QNE MAY send a RESPONSE message with the
   appropriate INFO-SPEC.

   Before performing any state-changing actions, a QNE MUST determine
   whether the request is authorized.  The way to do this check depends
   on the authorization model being used.

   When the RESERVE is authorized, a QNE checks the COMMON-HEADER flags.
   If the TEAR flag is set, the message is a tearing RESERVE that
   indicates complete QoS NSLP state removal (as opposed to a
   reservation of zero resources).  On receiving such a RESERVE message,

   the QNE MUST inform the RMF that the reservation is no longer
   required.  The RSN value MUST be processed.  After this, there are
   two modes of operation:

   1.  If the tearing RESERVE did not include an RII, i.e., the QNI did
       not want a confirmation, the QNE SHOULD remove the QoS NSLP
       state.  It MAY signal to GIST (over the API) that reverse-path
       state for this reservation is no longer required.  Any errors in
       processing the tearing RESERVE SHOULD NOT be sent back towards
       the QNI since the upstream QNEs will already have removed their
       session states; thus, they are unable to do anything to the
       error.

   2.  If an RII was included, the stateful QNE SHOULD still keep the
       NSLP operational state until a RESPONSE for the tear going
       towards the QNI is received.  This operational state SHOULD be
       kept for one refresh interval, after which the NSLP operational
       state for the session is removed.  Depending on the QoS model,
       the tear message MAY include a QSPEC to further specify state
       removal.  If the QoS model requires a QSPEC, and none is
       provided, the QNE SHOULD reply with an error message and SHOULD
       NOT remove the reservation.

   If the tearing RESERVE includes a QSPEC, but none is required by the
   QoS model, the QNE MAY silently discard the QSPEC and proceed as if
   it did not exist in the message.  In general, a QoS NSLP
   implementation should carefully consider when an error message should
   be sent, and when not.  If the tearing RESERVE did not include an
   RII, then the upstream QNE has removed the RMF and NSLP states, and
   it will not be able to do anything to the error.  If an RII was
   included, the upstream QNE may still have the NSLP operational state,
   but no RMF state.

   If a QNE receives a tearing RESERVE for a session for which it still
   has the operational state, but the RMF state was removed, the QNE
   SHOULD accept the message and forward it downstream as if all is
   well.

   If the tearing RESERVE includes a SESSION-ID-LIST, the stateful QNE
   MUST process the object as described earlier in this document, and
   for each identified session, indicate to the RMF that the reservation
   is no longer required.

   If a QNE receives a refreshing RESERVE for a session for which it
   still has the operational state, but the RMF state was removed, the
   QNE MUST silently drop the message and not forward it downstream.

   As discussed in Section 5.2.5.2, to avoid incorrect removal of state
   after a rerouting event, a node receiving a RESERVE message that has
   the TEAR flag set and that does not come from the current peer QNE
   (identified by its SII) MUST be ignored and MUST NOT be forwarded.

   If the QNE has reservations that are bound and dependent to this
   session (they contain the SESSION-ID of this session in their BOUND-
   SESSION-ID object and use Binding Code 0x04), it MUST send a NOTIFY
   message for each of the reservations with an appropriate INFO-SPEC.
   If the QNE has reservations that are bound, but that they are not
   dependent to this session (the Binding Code in the BOUND-SESSION-ID
   object has one of the values: 0x01, 0x02, or 0x03), it MAY send a
   NOTIFY message for each of the reservations with an appropriate INFO-
   SPEC.  The QNE MAY elect to send RESERVE messages with the TEAR flag
   set for these reservations.

   The default behavior of a QNE that receives a RESERVE with a
   SESSION-ID for which it already has state installed but with a
   different flow ID is to replace the existing reservation (and to tear
   down the reservation on the old branch if the RESERVE is received
   with a different SII).

   In some cases, this may not be the desired behavior, so the QNI or a
   QNE MAY set the REPLACE flag in the common header to zero to indicate
   that the new session does not replace the existing one.

   A QNE that receives a RESERVE with the REPLACE flag set to zero but
   with the same SII will indicate REPLACE=0 to the RMF (where it will
   be used for the resource handling).  Furthermore, if the QNE
   maintains a QoS NSLP state, then it will also add the new flow ID in
   the QoS NSLP state.  If the SII is different, this means that the QNE
   is a merge point.  In that case, in addition to the operations
   specified above, the value REPLACE=0 is also indicating that a
   tearing RESERVE SHOULD NOT be sent on the old branch.

   When a QNE receives a RESERVE message with an unknown SESSION-ID and
   this message contains no QSPEC because it was meant as a refresh,
   then the node MUST send a RESPONSE message with an INFO-SPEC that
   indicates a missing QSPEC to the upstream peer ("Full QSPEC
   required").  The upstream peer SHOULD send a complete RESERVE (i.e.,
   one containing a QSPEC) on the new path (new SII).

   At a QNE, resource handling is performed by the RMF.  For sessions
   with the REPLACE flag set to zero, we assume that the QoS model
   includes directions to deal with resource sharing.  This may include
   adding the reservations or taking the maximum of the two or more
   complex mathematical operations.

   This resource-handling mechanism in the QoS model is also applicable
   to sessions that have different SESSION-IDs but that are related
   through the BOUND-SESSION-ID object.  Session replacement is not an
   issue here, but the QoS model may specify whether or not to let the
   sessions that are bound together share resources on common links.

   Finally, it is possible that a RESERVE is received with no QSPEC at
   all.  This is the case of a reduced refresh.  In this case, rather
   than sending a refreshing RESERVE with the full QSPEC, only the
   SESSION-ID and the RSN are sent to refresh the reservation.  Note
   that this mechanism just reduces the message size (and probably eases
   processing).  One RESERVE per session is still needed.  Such a
   reduced refresh may further include a SESSION-ID-LIST and RSN-LIST,
   which indicate further sessions to be refreshed along the primary
   session.  The processing of these objects was described earlier in
   this document.

   If the REPLACE flag is set, the QNE SHOULD update the reservation
   state according to the QSPEC contained in the message (if the QSPEC
   is missing, the QNE SHOULD indicate this error by replying with a
   RESPONSE containing the corresponding INFO-SPEC "Full QSPEC
   required").  It MUST update the lifetime of the reservation.  If the
   REPLACE flag is not set, a QNE SHOULD NOT remove the old reservation
   state if the SII that is passed by GIST over the API is different
   than the SII that was stored for this reservation.  The QNE MAY elect
   to keep sending refreshing RESERVE messages.

   If a stateful QoS NSLP QNE receives a RESERVE message with the BREAK
   flag set, then the BREAK flag of newly generated messages (e.g.,
   RESERVE or RESPONSE) MUST be set.  When a stateful QoS NSLP QNE
   receives a RESERVE message with the BREAK flag not set, then the IP-
   TTL and Original-TTL values in the GIST RecvMessage primitive MUST be
   monitored.  If they differ, it is RECOMMENDED to set the BREAK flag
   in newly generated messages (e.g., RESERVE or RESPONSE).  In
   situations where a QNE or a domain is able to provide QoS using other
   means (see Section 3.3.5), the BREAK flag SHOULD NOT be set.

   If the RESERVE message included an RII, and any of the following are
   true, the QNE MUST send a RESPONSE message:

   o  If the QNE is configured, for a particular session, to be a QNR,

   o  the SCOPING flag is set,

   o  the Proxy scope flag is set and the QNE is a P-QNE, or

   o  the QNE is the last QNE on the path to the destination.

   When a QNE receives a RESERVE message, its processing may involve
   sending out another RESERVE message.

   If a QNE has received a RESPONSE mandating the use of full refreshes
   from its downstream peer for a session, the QNE MUST continue to use
   full refresh messages.

   If the session of this message is bound to another session, then the
   RESERVE message MUST include the SESSION-ID of that other session in
   a BOUND-SESSION-ID object.  In the situation of aggregated tunnels,
   the aggregated session MAY not include the SESSION-ID of its bound
   sessions in BOUND-SESSION-ID(s).

   In case of receiver-initiated reservations, the RESERVE message must
   follow the same path that has been followed by the QUERY message.
   Therefore, GIST is informed, over the QoS NSLP/GIST API, to pass the
   message upstream, i.e., by setting GIST "D" flag; see GIST [RFC5971].

   The QNE MUST create a new RESERVE and send it to its next peer, when:

   -  A new resource setup was done,

   -  A new resource setup was not done, but the QOSM still defines that
      a RESERVE must be propagated,

   -  The RESERVE is a refresh and includes a new MRI, or

   -  If the RESERVE-INIT flag is included in an arrived QUERY.

   If the QNE sent out a refresh RESERVE with the ACK-REQ flag set, and
   did not receive a RESPONSE from its immediate stateful peer within
   the retransmission period of QOSNSLP_RETRY_MAX, the QNE SHOULD send a
   NOTIFY to its immediate upstream stateful peer and indicate "Path
   truncated - Next peer dead" in the INFO-SPEC.  The ACK-REQ flag
   SHOULD NOT be added to a RESERVE that already include an RII object,
   since a confirmation from the QNR has already been requested.

   Finally, if a received RESERVE requested acknowledgement through the
   ACK-REQ flag in the COMMON HEADER flags and the processing of the
   message was successful, the stateful QNE SHOULD send back a RESPONSE
   with an INFO-SPEC carrying the acknowledgement success code.  The QNE
   MAY include the ACK-REQ flag in the next refresh message it will send
   for the session.  The use of the ACK-REQ-flag for diagnostic purposes
   is a policy issue.  An acknowledged refresh message can be used to
   probe the end-to-end path in order to check that it is still intact.

5.4.2.  QUERY Messages

   A QUERY message is used to request information about the data path
   without making a reservation.  This functionality can be used to
   'probe' the network for path characteristics or for support of
   certain QoS models, or to initiate a receiver-initiated reservation.

   A QNE sending a QUERY indicates a request for a response by including
   a Request Identification Information (RII) object; see Section 5.3.2.
   A request to initiate a receiver-initiated reservation is done
   through the RESERVE-INIT flag; see Section 5.1.2.2.

   When a QNE receives a QUERY message the QSPEC is passed to the RMF
   for processing.  The RMF may return a modified QSPEC that is used in
   any QUERY or RESPONSE message sent out as a result of the QUERY
   processing.

   When processing a QUERY message, a QNE checks whether the RESERVE-
   INIT flag is set.  If the flag is set, the QUERY is used to install
   reverse-path state.  In this case, if the QNE is not the QNI, it
   creates a new QUERY message to send downstream.  The QSPEC MUST be
   passed to the RMF where it may be modified by the QoS-model-specific
   QUERY processing.  If the QNE is the QNI, the QNE creates a RESERVE
   message, which contains a QSPEC received from the RMF and which may
   be based on the received QSPEC.  If this node was not expecting to
   perform a receiver-initiated reservation, then an error MUST be sent
   back along the path.

   The QNE MUST generate a RESPONSE message and pass it back along the
   reverse of the path used by the QUERY if:

   o  an RII object is present,

   o  the QNE is the QNR,

   o  the SCOPING flag is set, or

   o  the PROXY scope flag is set, and the QNE is a P-QNE.

   If an RII object is present, and if the QNE is the QNR, the SCOPING
   flag is set or the PROXY scope flag is set and the QNE is a P-QNE,
   the QNE MUST generate a RESPONSE message and pass it back along the
   reverse of the path used by the QUERY.

   In other cases, the QNE MUST generate a QUERY message that is then
   forwarded further along the path using the same MRI, Session ID, and
   Direction as provided when the QUERY was received over the GIST API.

   The QSPEC to be used is that provided by the RMF as described
   previously.  When generating a QUERY to send out to pass the query
   further along the path, the QNE MUST copy the RII object (if present)
   unchanged into the new QUERY message.  A QNE that is also interested
   in the response to the query keeps track of the RII to identify the
   RESPONSE when it passes through it.

   Note that QUERY messages with the RESERVE-INIT flag set MUST be
   answered by the QNR.  This feature may be used, e.g., following
   handovers, to set up new path state in GIST and to request that the
   other party to send a RESERVE back on this new GIST path.

   If a stateful QoS NSLP QNE receives a QUERY message with the RESERVE-
   INIT flag and BREAK flag set, then the BREAK flag of newly generated
   messages (e.g., QUERY, RESERVE, or RESPONSE) MUST be set.  When a
   stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT
   flag set and BREAK flag not set, then the IP-TTL and Original-TTL
   values in GIST RecvMessage primitive MUST be monitored.  If they
   differ, it is RECOMMENDED to set the BREAK flag in newly generated
   messages (e.g., QUERY, RESERVE, or RESPONSE).  In situations where a
   QNE or a domain is able to provide QoS using other means (see
   Section 3.3.5), the BREAK flag SHOULD NOT be set.

   Finally, if a received QUERY requested acknowledgement through the
   ACK-REQ flag in the COMMON HEADER flags and the processing of the
   message was successful, the stateful QNE SHOULD send back a RESPONSE
   with an INFO-SPEC carrying the acknowledgement success code.

5.4.3.  RESPONSE Messages

   The RESPONSE message is used to provide information about the result
   of a previous QoS NSLP message, e.g., confirmation of a reservation
   or information resulting from a QUERY.  The RESPONSE message does not
   cause any state to be installed, but may cause state(s) to be
   modified, e.g., if the RESPONSE contains information about an error.

   A RESPONSE message MUST be sent when the QNR processes a RESERVE or
   QUERY message containing an RII object or if the QNE receives a
   scoped RESERVE or a scoped QUERY.  In this case, the RESPONSE message
   MUST contain the RII object copied from the RESERVE or the QUERY.
   Also, if there is an error in processing a received RESERVE, a
   RESPONSE is sent indicating the nature of the error.  In this case,
   the RII and RSN, if available, MUST be included in the RESPONSE.

   On receipt of a RESPONSE message containing an RII object, the
   stateful QoS NSLP QNE MUST attempt to match it to the outstanding
   response requests for that signaling session.  If the match succeeds,
   then the RESPONSE MUST NOT be forwarded further along the path if it

   contains an Informational or Success INFO-SPEC class.  If the QNE did
   not insert this RII itself, it must forward the RESPONSE to the next
   peer.  Thus, for RESPONSEs indicating success, forwarding should only
   stop if the QNE inserted the RII by itself.  If the RESPONSE carries
   an INFO-SPEC indicating an error, forwarding SHOULD continue upstream
   towards the QNI by using RSNs as described in the next paragraph.

   On receipt of a RESPONSE message containing an RSN object, a stateful
   QoS NSLP QNE MUST compare the RSN to that of the appropriate
   signaling session.  If the match succeeds, then the INFO-SPEC MUST be
   processed.  If the INFO-SPEC object is used to send error
   notifications then the node MUST use the stored upstream peer RSN
   value, associated with the same session, and forward the RESPONSE
   message further along the path towards the QNI.

   If the INFO-SPEC is not used to notify error situations (see above),
   then if the RESPONSE message carries an RSN, the message MUST NOT be
   forwarded further along the path.

   If there is no match for RSN, the message SHOULD be silently dropped.

   On receipt of a RESPONSE message containing neither an RII nor an RSN
   object, the RESPONSE MUST NOT be forwarded further along the path.

   In the typical case, RESPONSE messages do not change the states
   installed in intermediate QNEs.  However, depending on the QoS model,
   there may be situations where states are affected, e.g.,

   -  if the RESPONSE includes an INFO-SPEC describing an error
      situation resulting in reservations to be removed, or

   -  the QoS model allows a QSPEC to define [min,max] limits on the
      resources requested, and downstream QNEs gave less resources than
      their upstream nodes, which means that the upstream nodes may
      release a part of the resource reservation.

   If a stateful QoS NSLP QNE receives a RESPONSE message with the BREAK
   flag set, then the BREAK flag of newly generated message (e.g.,
   RESPONSE) MUST be set.

5.4.4.  NOTIFY Messages

   NOTIFY messages are used to convey information to a QNE
   asynchronously.  NOTIFY messages do not cause any state to be
   installed.  The decision to remove state depends on the QoS model.
   The exact operation depends on the QoS model.  A NOTIFY message does

   not directly cause other messages to be sent.  NOTIFY messages are
   sent asynchronously, rather than in response to other messages.  They
   may be sent in either direction (upstream or downstream).

   A special case of synchronous NOTIFY is when the upstream QNE is
   asked to use reduced refresh by setting the appropriate flag in the
   RESERVE.  The QNE receiving such a RESERVE MUST reply with a NOTIFY
   and a proper INFO-SPEC code indicating whether the QNE agrees to use
   reduced refresh between the upstream QNE.

   The Transient error code 0x07 "Reservation preempted" is sent to the
   QNI whose resources were preempted.  The NOTIFY message carries
   information to the QNI that one QNE no longer has a reservation for
   the session.  It is up to the QNI to decide what to do based on the
   QoS model being used.  The QNI would normally tear down the preempted
   reservation by sending a RESERVE with the TEAR flag set using the SII
   of the preempted reservation.  However, the QNI can follow other
   procedures as specified in its QoS Model.  More discussion on
   preemption can be found in the QSPEC Template [RFC5975] and the
   individual QoS Model specifications.

6.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the QoS
   NSLP, in accordance with BCP 26, RFC 5226 [RFC5226].

   Per QoS NSLP, IANA has created a number of new registries:

      - QoS NSLP Message Types
      - QoS NSLP Binding Codes
      - QoS NSLP Error Classes
        - Informational Error Codes
        - Success Error Codes
        - Protocol Error Codes
        - Transient Failure Codes
        - Permanent Failure Codes
      - QoS NSLP Error Source Identifiers

   IANA has also registered new values in a number of registries:

      - NSLP Object Types
      - NSLP Identifiers (under GIST Parameters)
      - Router Alert Option Values (IPv4 and IPv6)

6.1.  QoS NSLP Message Type

   The QoS NSLP Message Type is an 8-bit value.  This specification
   defines four QoS NSLP message types, which form the initial contents
   of this registry: RESERVE (0x01), QUERY (0x02), RESPONSE (0x03), and
   NOTIFY (0x04).

   The value 0 is reserved.  Values 240 to 255 are for Experimental/
   Private Use.  The registration procedure is IETF Review.

   When a new message type is defined, any message flags used with it
   must also be defined.

6.2.  NSLP Message Objects

   A new registry has been created for NSLP Message Objects.  This is a
   12-bit field (giving values from 0 to 4095).  This registry is shared
   between a number of NSLPs.

   Registration procedures are as follows:

      0: Reserved

      1-1023: IETF Review

      1024-1999: Specification Required

   Allocation policies are as follows:

      2000-2047: Private/Experimental Use

      2048-4095: Reserved

   When a new object is defined, the extensibility bits (A/B) must also
   be defined.

   This document defines eleven new NSLP message objects.  These are
   described in Section 5.1.3: RII (0x001), RSN (0x002), REFRESH-PERIOD
   (0x003), BOUND-SESSION-ID (0x004), PACKET-CLASSIFIER (0x005), INFO-
   SPEC (0x006), SESSION-ID-LIST (0x007), RSN-LIST (0x008), MSG-ID
   (0x009), BOUND-MSG-ID (0x00A), and QSPEC (0x00B).

   Additional values are to be assigned from the IETF Review section of
   the NSLP Message Objects registry.

6.3.  QoS NSLP Binding Codes

   A new registry has been created for the 8-bit Binding Codes used in
   the BOUND-SESSION-ID object.  The initial values for this registry
   are listed in Section 5.1.3.4.

   The registration procedure is IETF Review.  Value 0 is reserved.
   Values 128 to 159 are for Experimental/Private Use.  Other values are
   Reserved.

6.4.  QoS NSLP Error Classes and Error Codes

   In addition, Error Classes and Error Codes for the INFO-SPEC object
   are defined.  These are described in Section 5.1.3.6.

   The Error Class is 4 bits in length.  The initial values are:

      0: Reserved

      1: Informational

      2: Success

      3: Protocol Error

      4: Transient Failure

      5: Permanent Failure

      6: QoS Model Error

      7: Signaling session failure (described in [RFC5973])

      8-15: Reserved

   Additional values are to be assigned based on IETF Review.

   The Error Code is 8 bits in length.  Each Error Code is assigned
   within a particular Error Class.  This requires the creation of a
   registry for Error Codes in each Error Class.  The Error Code 0 in
   each class is Reserved.

   Policies for the error code registries are as follows:

      0-63: IETF Review

      64-127: Specification Required

      128-191: Experimental/Private Use

      192-255: Reserved

   The initial assignments for the Error Code registries are given in
   Section 5.1.3.6.  Experimental and Reserved values are relevant to
   all Error classes.

6.5.  QoS NSLP Error Source Identifiers

   Section 5.1.3.6 defines Error Source Identifiers, the type of which
   is identified by a 4-bit value.

   The value 0 is reserved.

   Values 1-3 are given in Section 5.1.3.6.

   Values 14 and 15 are for Experimental/Private Use.

   The registration procedure is Specification Required.

6.6.  NSLP IDs and Router Alert Option Values

   This specification defines an NSLP for use with GIST.  Furthermore,
   it specifies that a number of NSLPID values are used for the support
   of bypassing intermediary nodes.  Consequently, new identifiers must
   be assigned for them from the GIST NSLP identifier registry.  As
   required by the QoS NSLP, 32 NSLPID values have been assigned,
   corresponding to QoS NSLP Aggregation Levels 0 to 31.

   The GIST specification also requires that NSLPIDs be associated with
   specific Router Alert Option (RAO) values (although multiple NSLPIDs
   may be associated with the same value).  For the purposes of the QoS
   NSLP, each of its NSLPID values should be associated with a different
   RAO value.  A block of 32 new IPv4 RAO values and a block of 32 new
   IPv6 RAO values have been assigned, corresponding to QoS NSLP
   Aggregation Levels 0 to 31.