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 188.8.131.52 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. 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. 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.
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. Section 184.108.40.206. 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.
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. 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. 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 220.127.116.11, 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.
Section 5.3.2. A request to initiate a receiver-initiated reservation is done through the RESERVE-INIT flag; see Section 18.104.22.168. 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.
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.
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. 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)
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.
Section 22.214.171.124. The registration procedure is IETF Review. Value 0 is reserved. Values 128 to 159 are for Experimental/Private Use. Other values are Reserved. Section 126.96.36.199. 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 188.8.131.52. Experimental and Reserved values are relevant to all Error classes. Section 184.108.40.206 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 220.127.116.11. Values 14 and 15 are for Experimental/Private Use. The registration procedure is Specification Required.