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 22.214.171.124 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 126.96.36.199. 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 188.8.131.52, 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 184.108.40.206. 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 220.127.116.11. 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 18.104.22.168. 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 22.214.171.124. Experimental and Reserved values are relevant to all Error classes. 6.5. QoS NSLP Error Source Identifiers Section 126.96.36.199 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 188.8.131.52. 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.