Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5974

NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling

Pages: 102
Part 4 of 6 – Pages 42 to 65
First   Prev   Next

Top   ToC   RFC5974 - Page 42   prevText

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.
Top   ToC   RFC5974 - Page 43
   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.
Top   ToC   RFC5974 - Page 44

5.1.2. Message Formats 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.
Top   ToC   RFC5974 - Page 45
   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.
Top   ToC   RFC5974 - Page 46
   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. 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).
Top   ToC   RFC5974 - Page 47 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC5974 - Page 48
   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

      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,

   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.
Top   ToC   RFC5974 - Page 49 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.
Top   ToC   RFC5974 - Page 50
    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)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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
Top   ToC   RFC5974 - Page 51
   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. 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
Top   ToC   RFC5974 - Page 52
   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. 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:
Top   ToC   RFC5974 - Page 53
   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

   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
Top   ToC   RFC5974 - Page 54
   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
Top   ToC   RFC5974 - Page 55
      *  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
Top   ToC   RFC5974 - Page 56
    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.
Top   ToC   RFC5974 - Page 57
   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

   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. SESSION-ID List (SESSION-ID-LIST)
Type: 0x007 Length: Variable
Top   ToC   RFC5974 - Page 58
   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                         +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC5974 - Page 59 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 dependency 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.
Top   ToC   RFC5974 - Page 60
       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 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.
Top   ToC   RFC5974 - Page 61

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.
Top   ToC   RFC5974 - Page 62
   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
Top   ToC   RFC5974 - Page 63
   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 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 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 Avoiding Mistaken Teardown
In order to handle the spurious route change problem described in Section, 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.
Top   ToC   RFC5974 - Page 64
   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. 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. 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:
Top   ToC   RFC5974 - Page 65
   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)

Next Section