tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5974

 
 
 

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

Part 4 of 6, p. 42 to 65
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 42 
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      Up      ToC       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      Up      ToC       Page 44 
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.

Top      Up      ToC       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      Up      ToC       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.

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).

Top      Up      ToC       Page 47 
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         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       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
      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.

Top      Up      ToC       Page 49 
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.

Top      Up      ToC       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)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Top      Up      ToC       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.

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

Top      Up      ToC       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.

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:

Top      Up      ToC       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
   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

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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
   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

Top      Up      ToC       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                         +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 59 
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 dependency

5.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.

Top      Up      ToC       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

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.

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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

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.

Top      Up      ToC       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.

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:

Top      Up      ToC       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 RFC Part