RFC 5974
NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling
Pages: 102
Experimental
Experimental
Part 4 of 6 – Pages 42 to 65
5. QoS NSLP Functional Specification
5.1. QoS NSLP Message and Object Formats
A QoS NSLP message consists of a common header, followed by a body consisting of a variable number of variable-length, typed "objects". The common header and other objects are encapsulated together in a GIST NSLP-Data object. The following subsections define the formats of the common header and each of the QoS NSLP message types. In the message formats, the common header is denoted as COMMON-HEADER. For each QoS NSLP message type, there is a set of rules for the permissible choice of object types. These rules are specified using the Augmented Backus-Naur Form (ABNF) specified in RFC 5234 [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.5.1.1. Common Header
All GIST NSLP-Data objects for the QoS NSLP MUST contain this common header as the first 32 bits of the object (this is not the same as the GIST Common Header). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Message Flags | Generic Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the common header are as follows: Msg Type: 8 bits 1 = RESERVE 2 = QUERY 3 = RESPONSE 4 = NOTIFY Message-specific flags: 8 bits These flags are defined as part of the specification of individual messages, and, thus, are different with each message type.
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.
5.1.2. Message Formats
5.1.2.1. RESERVE
The format of a RESERVE message is as follows: RESERVE = COMMON-HEADER RSN [ RII ] [ REFRESH-PERIOD ] [ *BOUND-SESSION-ID ] [ SESSION-ID-LIST [ RSN-LIST ] ] [ MSG-ID / BOUND-MSG-ID ] [ INFO-SPEC ] [ [ PACKET-CLASSIFIER ] QSPEC ] The RSN is the only mandatory object and MUST always be present in all cases. A QSPEC MUST be included in the initial RESERVE sent towards the QNR. A PACKET-CLASSIFIER MAY be provided. If the PACKET-CLASSIFIER is not provided, then the full set of information provided in the GIST MRI for the session should be used for packet classification purposes. Subsequent RESERVE messages meant as reduced refreshes, where no QSPEC is provided, MUST NOT include a PACKET-CLASSIFIER either. There are no requirements on transmission order, although the above order is recommended. Two message-specific flags are defined for use in the common header with the RESERVE message. These are: +-+-+-+-+-+-+-+-+ |Reserved |T|R| +-+-+-+-+-+-+-+-+ TEAR (T) - when set, indicates that reservation state and QoS NSLP operation state should be torn down. The former is indicated to the RMF. Depending on the QoS model, the tear message may include a QSPEC to further specify state removal, e.g., for an aggregation, the QSPEC may specify the amount of resources to be removed from the aggregate. REPLACE (R) - when set, the flag has two uses. First, it indicates that a RESERVE with different MRI (but same SID) replaces an existing one, so the old one MAY be torn down immediately. This is the default situation. This flag may be unset to indicate a desire from an upstream node to keep an existing reservation on an old branch in place. Second, this flag is also used to indicate whether the reserved resources on the old branch should be torn down or not when a data path change happens. In this case, the MRI is the same and only the route path changes.
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.5.1.2.2. QUERY
The format of a QUERY message is as follows: QUERY = COMMON-HEADER [ RII ] [ *BOUND-SESSION-ID ] [ PACKET-CLASSIFIER ] [ INFO-SPEC ] QSPEC [ QSPEC ] QUERY messages MUST always include a QSPEC. QUERY messages MAY include a PACKET-CLASSIFIER when the message is used to trigger a receiver-initiated reservation. If a PACKET-CLASSIFIER is not included then the full GIST MRI should be used for packet classification purposes in the subsequent RESERVE. A QUERY message MAY contain a second QSPEC object. A QUERY message for requesting information about network resources MUST contain an RII object to match an incoming RESPONSE to the QUERY. The QSPEC object describes what is being queried for and may contain objects that gather information along the data path. There are no requirements on transmission order, although the above order is recommended. One message-specific flag is defined for use in the common header with the QUERY message. It is: +-+-+-+-+-+-+-+-+ |Reserved |R| +-+-+-+-+-+-+-+-+ RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger for the recipient to make a resource reservation by sending a RESERVE. 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).
5.1.2.3. RESPONSE
The format of a RESPONSE message is as follows: RESPONSE = COMMON-HEADER [ RII / RSN ] INFO-SPEC [SESSION-ID-LIST [ RSN-LIST ] ] [ QSPEC ] A RESPONSE message MUST contain an INFO-SPEC object that indicates the success of a reservation installation or an error condition. Depending on the value of the INFO-SPEC, the RESPONSE MAY also contain a QSPEC object. The value of an RII or an RSN object was provided by some previous QNE. There are no requirements on transmission order, although the above order is recommended. No message-specific flags are defined for use in the common header with the RESPONSE message.5.1.2.4. NOTIFY
The format of a NOTIFY message is as follows: NOTIFY = COMMON-HEADER INFO-SPEC [ QSPEC ] A NOTIFY message MUST contain an INFO-SPEC object indicating the reason for the notification. Depending on the INFO-SPEC value, it MAY contain a QSPEC object providing additional information. No message-specific flags are defined for use with the NOTIFY message.5.1.3. Object Formats
The QoS NSLP uses a Type-Length-Value (TLV) object format similar to that used by GIST. Every object consists of one or more 32-bit words with a one-word header. For convenience, the standard object header is shown here: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B|r|r| Type |r|r|r|r| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
5.1.3.1. Request Identification Information (RII)
Type: 0x001 Length: Fixed - 1 32-bit word Value: An identifier that MUST be (probabilistically) unique within the context of a SESSION-ID and SHOULD be different every time a RESPONSE is desired. Used by a QNE to match back a RESPONSE to a request in a RESERVE or QUERY message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identification Information (RII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.3.2. Reservation Sequence Number (RSN)
Type: 0x002 Length: Fixed - 2 32-bit words Value: An incrementing sequence number that indicates the order in which state-modifying actions are performed by a QNE, and an epoch identifier to allow the identification of peer restarts. The RSN has local significance only, i.e., between a QNE and its downstream stateful peers. The RSN is not reset when the downstream peer changes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reservation Sequence Number (RSN) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Epoch Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.3.3. Refresh Period (REFRESH-PERIOD)
Type: 0x003 Length: Fixed - 1 32-bit word Value: The refresh timeout period R used to generate this message; in milliseconds.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.3.4. Bound Session ID (BOUND-SESSION-ID)
Type: 0x004
Length: Fixed - 5 32-bit words
Value: contains an 8-bit Binding_Code that indicates the nature of
the binding. The rest specifies the SESSION-ID (as specified in GIST
[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.5.1.3.5. Packet Classifier (PACKET-CLASSIFIER)
Type: 0x005 Length: Variable Value: Contains variable-length MRM-specific data 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Method-specific classifier data (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ At this stage, the QoS NSLP only uses the path-coupled routing MRM. The method-specific classifier data is four bytes long and consists of a set of flags: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|Y|P|T|F|S|A|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The flags are: X - Source Address and Prefix Y - Destination Address and Prefix P - Protocol T - Diffserv Code Point F - Flow Label S - SPI A - Source Port B - Destination Port
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.5.1.3.6. Information Object (INFO-SPEC) and Error Codes
Type: 0x006 Length: Variable Value: Contains 8 reserved bits, an 8-bit error code, a 4-bit error class, a 4-bit error source identifier type, and an 8-bit error source identifier length (in 32-bit words), an error source identifier, and optionally variable-length error-specific information. 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 | Error Code |E-Class|ESI Typ| ESI-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Error Source Identifier // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional error-specific information // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class Field: The four E-Class bits of the object indicate the error severity class. The currently defined error classes are:
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.
5.1.3.7. SESSION-ID List (SESSION-ID-LIST)
Type: 0x007
Length: Variable
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.3.8. Reservation Sequence Number (RSN) List (RSN-LIST)
Type: 0x008
Length: Variable
Value: A list of 32-bit Reservation Sequence Number (RSN) values.
All RSN 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number 1 (RSN1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number n (RSNn) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.3.9. Message ID (MSG-ID)
Type: 0x009 Length: Fixed - 5 32-bit words Value: contains a 1-bit Message_Binding_Type (D) that indicates the dependency relation of a message binding. The rest specifies a 128-bit randomly generated value that "uniquely" identifies this particular message. 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Message ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Binding Codes are: * 0 - Unidirectional binding dependency * 1 - Bidirectional binding dependency5.1.3.10. Bound Message ID (BOUND-MSG-ID)
Type: 0x00A Length: Fixed - 5 32-bit words Value: contains a 1-bit Message_Binding_Type (D) that indicates the dependency relation of a message binding. The rest specifies a 128-bit randomly generated value that refers to a Message ID in another message.
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
5.1.3.11. QoS Specification (QSPEC)
Type: 0x00B
Length: Variable
Value: Variable-length QSPEC (QoS specification) information, which
is dependent on the QoS model.
The contents and encoding rules for this object are specified in
other documents. See [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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. General Processing Rules
This section provides the general processing rules used by QoS-NSLP.
The triggers communicated between RM/QOSM and QoS-NSLP
functionalities are given in Appendices Appendix A.1, Appendix A.2,
and Appendix A.3.
5.2.1. State Manipulation
The processing of a message and its component objects involves manipulating the QoS NSLP and reservation state of a QNE. For each flow, a QNE stores (RMF-related) reservation state that depends on: o the QoS model / QSPEC used, o the QoS NSLP operation state, which includes non-persistent state (e.g., the API parameters while a QNE is processing a message), and o the persistent state, which is kept as long as the session is active. The persistent QoS NSLP state is conceptually organized in a table with the following structure. The primary key (index) for the table is the SESSION-ID: SESSION-ID A 128-bit identifier. The state information for a given key includes: Flow ID Based on GIST MRI. Several entries are possible in case of mobility events. SII-Handle for each upstream and downstream peer The SII-Handle is a local identifier generated by GIST and passed over the API. It is a handle that allows to refer to a particular GIST next hop. See SII-Handle in [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.
5.2.2. Message Forwarding
QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP
does not have the concept of a message being sent directly to the end
of the path. Instead, messages are received by a QNE, which may then
send another message (which may be identical to the received message
or contain some subset of objects from it) to continue in the same
direction (i.e., towards the QNI or QNR) as the message received.
The decision on whether to generate a message to forward may be
affected by the value of the SCOPING or PROXY flags, or by the
presence of an RII object.
5.2.3. Standard Message Processing Rules
If a mandatory object is missing from a message then the receiving
QNE MUST NOT propagate the message any further. It MUST construct a
RESPONSE message indicating the error condition and send it back to
the peer QNE that sent the message.
If a message contains an object of an unrecognised type, then the
behavior depends on the AB extensibility flags.
If the Proxy scope flag was set in an incoming QoS NSLP message, the
QNE must set the same flag in all QoS NSLP messages it sends that are
related to this session.
5.2.4. Retransmissions
Retransmissions may happen end-to-end (e.g., between QNI and QNR
using an RII object) or peer-to-peer (between two adjacent QNEs).
When a QNE transmits a RESERVE with an RII object set, it waits for a
RESPONSE from the responding QNE. QoS NSLP messages for which a
response is requested by including an RII object, but that fail to
elicit a response are retransmitted. Similarly, a QNE may include
the ACK-REQ flag to request confirmation of a refresh message
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.
5.2.5. Rerouting
5.2.5.1. Last Node Behavior
As discussed in 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 5.2.5.1.
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 5.2.5.1.
5.2.5.2. Avoiding Mistaken Teardown
In order to handle the spurious route change problem described in
Section 3.2.12.2, 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.5.2.5.3. Upstream Route Change Notification
GIST may notify the QoS NSLP that a possible upstream route change has occurred over the GIST API. On receiving such a notification, the QoS NSLP SHOULD send a NOTIFY message with Informational code 0x02 for signaling sessions associated with the identified MRI. If this is sent, it MUST be sent to the old peer using the GIST explicit routing mechanism through the use of the SII-Handle. On receiving such a NOTIFY message, the QoS NSLP SHOULD use the InvalidateRoutingState API call to inform GIST that routing state may be out of date. The QoS NSLP SHOULD send a NOTIFY message upstream. The NOTIFY message should be propagated back to the QNI or QNR.5.2.5.4. Route Change Oscillation
In some circumstances, a route change may occur, but the path then falls back to the original route. After a route change the routers on the old path will continue to refresh the reservation until soft state times out or an explicit TEAR is received. After detecting an upstream route change, a QNE SHOULD consider the new upstream peer as current and not fall back to the old upstream peer unless:
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.
(page 65 continued on part 5)