RFC5234]. The ABNF implies an order for the objects in a message. However, in many (but not all) cases, object order makes no logical difference. An implementation SHOULD create messages with the objects in the order shown here, but MUST accept the objects in any order.
Generic flags: 16 bits Generic flags have the same meaning for all message types. There exist currently four generic flags: the (next hop) Scoping flag (S), the Proxy scope flag (P), the Acknowledgement Requested flag (A), and the Break flag (B). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |B|A|P|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SCOPING (S) - when set, indicates that the message is scoped and should not travel down the entire path but only as far as the next QNE (scope="next hop"). By default, this flag is not set (default scope="whole path"). PROXY (P) - when set, indicates that the message is scoped, and should not travel down the entire path but only as far as the P-QNE. By default, this flag is not set. ACK-REQ (A) - when set, indicates that the message should be acknowledged by the receiving peer. The flag is only used between stateful peers, and only used with RESERVE and QUERY messages. Currently, the flag is only used with refresh messages. By default, the flag is not set. BREAK (B) - when set, indicates that there are routers along the path where QoS cannot be provided. The set of appropriate flags depends on the particular message being processed. Any bit not defined as a flag for a particular message MUST be set to zero on sending and MUST be ignored on receiving. The ACK-REQ flag is useful when a QNE wants to make sure the messages received by the downstream QNE are truly processed by the QoS NSLP, not just delivered by GIST. This is useful for faster dead peer detection on the NSLP layer. This liveliness test can only be used with refresh RESERVE messages. The ACK-REQ flag must not be set for RESERVE messages that already include an RII object, since a confirmation has already been requested from the QNR. Reliable transmission of messages between two QoS NSLP peers should be handled by GIST, not the NSLP by itself.
If the REFRESH-PERIOD is not present, a default value of 30 seconds is assumed. 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). The negotiation of whether to perform sender- or receiver-initiated signaling is done outside the QoS NSLP. Yet, in theory, it is possible that a "reservation collision" may occur if the sender believes that a sender-initiated reservation should be performed for a flow, whilst the other end believes that it should be starting a receiver-initiated reservation. If different session identifiers are used, then this error condition is transparent to the QoS NSLP, though it may result in an error from the RMF. Otherwise, the removal of the duplicate reservation is left to the QNIs/QNRs for the two sessions. If a reservation is already installed and a RESERVE message is received with the same session identifier from the other direction (i.e., going upstream where the reservation was installed by a downstream RESERVE message, or vice versa), then an error indicating "RESERVE received from wrong direction" MUST be sent in a RESPONSE message to the signaling message source for this second RESERVE. A refresh right along the path can be forced by requesting a RESPONSE from the far end (i.e., by including an RII object in the RESERVE message). Without this, a refresh RESERVE would not trigger RESERVE messages to be sent further along the path, as each hop has its own refresh timer. A QNE may ask for confirmation of a tear operation by including an RII object. QoS NSLP retransmissions SHOULD be disabled. A QNE sending a tearing RESERVE with an RII included MAY ask GIST to use reliable transport. When the QNE sends out a tearing RESERVE, it MUST NOT send refresh messages anymore. If the routing path changed due to mobility and the mobile node's IP address changed, and it sent a Mobile IP binding update, the resulting refresh is a new RESERVE. This RESERVE includes a new MRI and will be propagated end-to-end; there is no need to force end-to- end forwarding by including an RII.
Note: It is possible for a host to use this mechanism to constantly force the QNEs on the path to send refreshing RESERVE messages. It may, therefore, be appropriate for QNEs to perform rate-limiting on the refresh messages that they send.
The value for the Type field comes from the shared NSLP object type space; the various objects are presented in subsequent sections. The Length field is given in units of 32-bit words and measures the length of the Value component of the TLV object (i.e., it does not include the standard header). The bits marked 'A' and 'B' are flags used to signal the desired treatment for objects whose treatment has not been defined in the protocol specification (i.e., whose Type field is unknown at the receiver). The following four categories of object have been identified, and are described here. AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected, and an error message sent back. AB=01 ("Ignore"): If the object is not understood, it MUST be deleted and the rest of the message processed as usual. AB=10 ("Forward"): If the object is not understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but not stored locally. AB=11 ("Refresh"): If the object is not understood, it should be incorporated into the locally stored QoS NSLP signaling application operational state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message that is generated locally. The contents of this object does not need to be interpreted, and should only be stored as bytes on the QNE. The remaining bits marked 'r' are reserved. These SHALL be set to 0 and SHALL be ignored on reception. The extensibility flags AB are similar to those used in the GIST specification. All objects defined in this specification MUST be understood by all QNEs; thus, they MUST have the AB-bits set to "00". A QoS NSLP implementation must recognize objects of the following types: RII, RSN, REFRESH-PERIOD, BOUND-SESSION-ID, INFO-SPEC, and QSPEC. The object header is followed by the Value field, which varies for different objects. The format of the Value field for currently defined objects is specified below. The object diagrams here use '//' to indicate a variable-sized field.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Period (R) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC5971]) of the session that MUST be bound to the session associated with the message carrying this object. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Binding Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Session ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Currently defined Binding Codes are: o 0x01 - Tunnel and end-to-end sessions o 0x02 - Bidirectional sessions o 0x03 - Aggregate sessions o 0x04 - Dependent sessions (binding session is alive only if the other session is also alive) o 0x05 - Indicated session caused preemption More binding codes may be defined based on the above five atomic binding actions. Note a message may include more than one BOUND- SESSION-ID object. This may be needed in case one needs to define more specifically the reason for binding, or if the session depends
on more than one other session (with possibly different reasons). Note that a session with, e.g., SID_A (the binding session), can express its unidirectional dependency relation to another session with, e.g., SID_B (the bound session), by including a BOUND-SESSION-ID object containing SID_B in its messages.
The flags indicate which fields from the MRI MUST be used by the packet classifier. This allows a subset of the information in the MRI to be used for identifying the set of packets that are part of the reservation. Flags MUST only be set if the data is present in the MRI (i.e., where there is a corresponding flag in the GIST MRI, the flag can only be set if the corresponding GIST MRI flag is set). It should be noted that some flags in the PACKET-CLASSIFIER (X and Y) relate to data that is always present in the MRI, but are optional to use for QoS NSLP packet classification. The appropriate set of flags set may depend, to some extent, on the QoS model being used. As mentioned earlier in this section, the QoS NSLP is currently only defined for use with the Path-Coupled Message Routing Method (MRM) in GIST. Future work may extend the QoS NSLP to additional routing mechanisms. Such MRMs must include sufficient information in the MRI to allow the subset of packets for which QoS is to be provided to be identified. When QoS NSLP is extended to support a new MRM, appropriate method-specific classifier data for the PACKET-CLASSIFIER object MUST be defined.
o 1 - Informational o 2 - Success o 3 - Protocol Error o 4 - Transient Failure o 5 - Permanent Failure o 6 - QoS Model Error Error field: Within each error severity class, a number of Error Code values are defined. o Informational: * 0x01 - Unknown BOUND-SESSION-ID: the message refers to an unknown SESSION-ID in its BOUND-SESSION-ID object. * 0x02 - Route Change: possible route change occurred on downstream path. * 0x03 - Reduced refreshes not supported; full QSPEC required. * 0x04 - Congestion situation: Possible congestion situation occurred on downstream path. * 0x05 - Unknown SESSION-ID in SESSION-ID-LIST. * 0x06 - Mismatching RSN in RSN-LIST. o Success: * 0x01 - Reservation successful * 0x02 - Teardown successful * 0x03 - Acknowledgement * 0x04 - Refresh successful
o Protocol Error: * 0x01 - Illegal message type: the type given in the Message Type field of the common header is unknown. * 0x02 - Wrong message length: the length given for the message does not match the length of the message data. * 0x03 - Bad flags value: an undefined flag or combination of flags was set in the generic flags. * 0x04 - Bad flags value: an undefined flag or combination of flags was set in the message-specific flags. * 0x05 - Mandatory object missing: an object required in a message of this type was missing. * 0x06 - Illegal object present: an object was present that must not be used in a message of this type. * 0x07 - Unknown object present: an object of an unknown type was present in the message. * 0x08 - Wrong object length: the length given for the object did not match the length of the object data present. * 0x09 - RESERVE received from wrong direction. * 0x0a - Unknown object field value: a field in an object had an unknown value. * 0x0b - Duplicate object present. * 0x0c - Malformed QSPEC. * 0x0d - Unknown MRI. * 0x0e - Erroneous value in the TLV object's value field. * 0x0f - Incompatible QSPEC. o Transient Failure: * 0x01 - No GIST reverse-path forwarding state * 0x02 - No path state for RESERVE, when doing a receiver- oriented reservation
* 0x03 - RII conflict * 0x04 - Full QSPEC required * 0x05 - Mismatch synchronization between end-to-end RESERVE and intra-domain RESERVE * 0x06 - Reservation preempted * 0x07 - Reservation failure * 0x08 - Path truncated - Next peer dead o Permanent Failure: * 0x01 - Internal or system error * 0x02 - Authorization failure o QoS Model Error: This error class can be used by QoS models to add error codes specific to the QoS model being used. All these errors and events are created outside the QoS NSLP itself. The error codes in this class are defined in QoS model specifications. Note that this error class may also include codes that are not purely errors, but rather some non-fatal information. Error Source Identifier (ESI) The Error Source Identifier is for diagnostic purposes and its inclusion is OPTIONAL. It is suggested that implementations use this for the IP address, host name, or other identifier of the QNE generating the INFO-SPEC to aid diagnostic activities. A QNE SHOULD NOT be used in any purpose other than error logging or being presented to the user as part of any diagnostic information. A QNE SHOULD NOT attempt to send a message to that address. If no Error Source Identifier is included, the Error Source Identifier Type field must be zero. Currently three Error Source Identifiers have been defined: IPv4, IPv6, and FQDN. Error Source Identifier: IPv4 Error Source Identifier Type: 0x1
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Source Identifier: IPv6 Error Source Identifier Type: 0x2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 128-bit IPv6 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Source Identifier: FQDN in UTF-8 Error Source Identifier Type: 0x3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // FQDN // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the length of the FQDN is not a multiple of 32-bits, the field is padded with zero octets to the next 32-bit boundary. If a QNE encounters protocol errors, it MAY include additional information, mainly for diagnostic purposes. Additional information MAY be included if the type of an object is erroneous, or a field has an erroneous value. If the type of an object is erroneous, the following optional error- specific information may be included at the end of the INFO-SPEC.
Object Type Info: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object provides information about the type of object that caused the error. If a field in an object had an incorrect value, the following Optional error-specific information may be added at the end of the INFO-SPEC. Object Value Info: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | Real Object Length | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Object // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Real Object Length: Since the length in the original TLV header may be inaccurate, this field provides the actual length of the object (including the TLV Header) included in the error message. Offset: Indicates which part of the erroneous object is included. When this field is set to "0", the complete object is included. If Offset is bigger than "0", the erroneous object from offset (calculated from the beginning of the object) to the end of the object is included. Object: The invalid TLV object (including the TLV Header). This object carries information about a TLV object that was found to be invalid in the original message. An error message may contain more than one Object Value Info object.
Value: A list of 128-bit SESSION-IDs used in summary refresh and summary tear messages. All SESSION-IDs are concatenated together. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Session ID 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Session ID n + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED |D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Bound Message ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Binding Codes are: * 0 - Unidirectional binding dependency * 1 - Bidirectional binding dependency RFC5975]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // QSPEC Data // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Appendix A.1, Appendix A.2, and Appendix A.3.
RFC5971] for more information. RSN from the upstream peer The RSN is a 32-bit counter. The latest local RSN A 32-bit counter. List of RII for outstanding responses with processing information. The RII is a 32-bit number. State lifetime The state lifetime indicates how long the state that is being signaled for remains valid.
List of bound sessions A list of BOUND-SESSION-ID 128-bit identifiers for each session bound to this state. Scope of the signaling If the Proxy scope is used, a flag is needed to identify all signaling of this session as being scoped. Adding the state requirements of all these items gives an upper bound on the state to be kept by a QNE. The need to keep state depends on the desired functionality at the NSLP layer.
reception from its immediate peer. The retransmitted message should be exactly the same as the original message, e.g., the RSN is not modified with each retransmission. The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). QoS NSLP messages SHOULD be retransmitted until either a RESPONSE (which might be an error) has been obtained, or until QOSNSLP_RETRY_MAX seconds after the initial transmission. In the latter case, a failure SHOULD be indicated to the signaling application. The default values for the above-mentioned timers are: QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial retransmit of the message QOSNSLP_RETRY_MAX: 30 seconds Period to retry sending the message before giving up Retransmissions SHOULD be disabled for tear messages. Section 3.2.12, some care needs to be taken to handle cases where the last node on the path may change. A node that is the last node on the path, but not the data receiver (or an explicitly configured proxy for it), MUST continue to attempt to send messages downstream to probe for path changes. This must be done in order to handle the "Path Extension" case described in Section 188.8.131.52. A node on the path, that was not previously the last node, MUST take over as the last node on the signaling path if GIST path change detection identifies that there are no further downstream nodes on the path. This must be done in order to handle the "Path Truncation" case described in Section 184.108.40.206. Section 220.127.116.11, the RSN must be used in a particular way when maintaining the reservation after a route change is believed to have occurred. We assume that the current RSN (RSN[current]) is initially RSN0.
When a route change is believed to have occurred, the QNE SHOULD send a RESERVE message, including the full QSPEC. This must contain an RSN which is RSN[current] = RSN0 + 2. It SHOULD include an RII to request a response from the QNR. An SII-Handle MUST NOT be specified when passing this message over the API to GIST, so that the message is correctly routed to the new peer QNE. When the QNE receives the RESPONSE message that relates to the RESERVE message sent down the new path, it SHOULD send a RESERVE message with the TEAR flag sent down the old path. To do so, it MUST request GIST to use its explicit routing mechanism, and the QoS NSLP MUST supply an SII-Handle relating to the old peer QNE. When sending this RESERVE message, it MUST contain an RSN that is RSN[current] - 1. (RSN[current] remains unchanged.) If the RESPONSE received after sending the RESERVE down the new path contains the code "Refresh successful" in the INFO-SPEC, then the QNE MAY elect not to send the tearing RESERVE, since this indicates that the path is unchanged.
o it stops receiving refreshes from the old upstream peer for at least the soft-state timeout period and then starts receiving messages from the old upstream peer again, or o it stops receiving refreshes from the new upstream peer for at least the soft-state timeout period. GIST routing state keeps track of the latest upstream peer it has seen, and so may spuriously indicate route changes occur when the old upstream peer refreshes its routing state until the state at that node is explicitly torn down or times out.