GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5974

Internet Engineering Task Force (IETF) J. Manner Request for Comments: 5974 Aalto University Category: Experimental G. Karagiannis ISSN: 2070-1721 University of Twente/Ericsson

                                                           A. McDonald
                                                                  Roke
                                                          October 2010

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

Abstract

 This specification describes the NSIS Signaling Layer Protocol (NSLP)
 for signaling Quality of Service (QoS) reservations in the Internet.
 It is in accordance with the framework and requirements developed in
 NSIS.  Together with General Internet Signaling Transport (GIST), it
 provides functionality similar to RSVP and extends it.  The QoS NSLP
 is independent of the underlying QoS specification or architecture
 and provides support for different reservation models.  It is
 simplified by the elimination of support for multicast flows.  This
 specification explains the overall protocol approach, describes the
 design decisions made, and provides examples.  It specifies object,
 message formats, and processing rules.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This document is a product of the Internet Engineering
 Task Force (IETF).  It represents the consensus of the IETF
 community.  It has received public review and has been approved for
 publication by the Internet Engineering Steering Group (IESG).  Not
 all documents approved by the IESG are a candidate for any level of
 Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5974.

Manner, et al. Experimental [Page 1] RFC 5974 QoS NSLP October 2010

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
 3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.  Overall Approach . . . . . . . . . . . . . . . . . . . . .  6
     3.1.1.  Protocol Messages  . . . . . . . . . . . . . . . . . .  9
     3.1.2.  QoS Models and QoS Specifications  . . . . . . . . . . 10
     3.1.3.  Policy Control . . . . . . . . . . . . . . . . . . . . 12
   3.2.  Design Background  . . . . . . . . . . . . . . . . . . . . 13
     3.2.1.  Soft States  . . . . . . . . . . . . . . . . . . . . . 13
     3.2.2.  Sender and Receiver Initiation . . . . . . . . . . . . 13
     3.2.3.  Protection against Message Re-ordering and
             Duplication  . . . . . . . . . . . . . . . . . . . . . 14
     3.2.4.  Explicit Confirmations . . . . . . . . . . . . . . . . 14
     3.2.5.  Reduced Refreshes  . . . . . . . . . . . . . . . . . . 14
     3.2.6.  Summary Refreshes and Summary Tear . . . . . . . . . . 15
     3.2.7.  Message Scoping  . . . . . . . . . . . . . . . . . . . 15
     3.2.8.  Session Binding  . . . . . . . . . . . . . . . . . . . 16
     3.2.9.  Message Binding  . . . . . . . . . . . . . . . . . . . 16
     3.2.10. Layering . . . . . . . . . . . . . . . . . . . . . . . 17
     3.2.11. Support for Request Priorities . . . . . . . . . . . . 18
     3.2.12. Rerouting  . . . . . . . . . . . . . . . . . . . . . . 19
     3.2.13. Preemption . . . . . . . . . . . . . . . . . . . . . . 24
   3.3.  GIST Interactions  . . . . . . . . . . . . . . . . . . . . 24
     3.3.1.  Support for Bypassing Intermediate Nodes . . . . . . . 25
     3.3.2.  Support for Peer Change Identification . . . . . . . . 25
     3.3.3.  Support for Stateless Operation  . . . . . . . . . . . 26
     3.3.4.  Priority of Signaling Messages . . . . . . . . . . . . 26
     3.3.5.  Knowledge of Intermediate QoS-NSLP-Unaware Nodes . . . 26
 4.  Examples of QoS NSLP Operation . . . . . . . . . . . . . . . . 26
   4.1.  Sender-Initiated Reservation . . . . . . . . . . . . . . . 27
   4.2.  Sending a Query  . . . . . . . . . . . . . . . . . . . . . 28

Manner, et al. Experimental [Page 2] RFC 5974 QoS NSLP October 2010

   4.3.  Basic Receiver-Initiated Reservation . . . . . . . . . . . 29
   4.4.  Bidirectional Reservations . . . . . . . . . . . . . . . . 31
   4.5.  Aggregate Reservations . . . . . . . . . . . . . . . . . . 33
   4.6.  Message Binding  . . . . . . . . . . . . . . . . . . . . . 34
   4.7.  Reduced-State or Stateless Interior Nodes  . . . . . . . . 38
     4.7.1.  Sender-Initiated Reservation . . . . . . . . . . . . . 38
     4.7.2.  Receiver-Initiated Reservation . . . . . . . . . . . . 40
   4.8.  Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . 41
 5.  QoS NSLP Functional Specification  . . . . . . . . . . . . . . 42
   5.1.  QoS NSLP Message and Object Formats  . . . . . . . . . . . 42
     5.1.1.  Common Header  . . . . . . . . . . . . . . . . . . . . 42
     5.1.2.  Message Formats  . . . . . . . . . . . . . . . . . . . 44
     5.1.3.  Object Formats . . . . . . . . . . . . . . . . . . . . 47
   5.2.  General Processing Rules . . . . . . . . . . . . . . . . . 60
     5.2.1.  State Manipulation . . . . . . . . . . . . . . . . . . 61
     5.2.2.  Message Forwarding . . . . . . . . . . . . . . . . . . 62
     5.2.3.  Standard Message Processing Rules  . . . . . . . . . . 62
     5.2.4.  Retransmissions  . . . . . . . . . . . . . . . . . . . 62
     5.2.5.  Rerouting  . . . . . . . . . . . . . . . . . . . . . . 63
   5.3.  Object Processing  . . . . . . . . . . . . . . . . . . . . 65
     5.3.1.  Reservation Sequence Number (RSN)  . . . . . . . . . . 65
     5.3.2.  Request Identification Information (RII) . . . . . . . 66
     5.3.3.  BOUND-SESSION-ID . . . . . . . . . . . . . . . . . . . 67
     5.3.4.  REFRESH-PERIOD . . . . . . . . . . . . . . . . . . . . 67
     5.3.5.  INFO-SPEC  . . . . . . . . . . . . . . . . . . . . . . 68
     5.3.6.  SESSION-ID-LIST  . . . . . . . . . . . . . . . . . . . 70
     5.3.7.  RSN-LIST . . . . . . . . . . . . . . . . . . . . . . . 71
     5.3.8.  QSPEC  . . . . . . . . . . . . . . . . . . . . . . . . 71
   5.4.  Message Processing Rules . . . . . . . . . . . . . . . . . 72
     5.4.1.  RESERVE Messages . . . . . . . . . . . . . . . . . . . 72
     5.4.2.  QUERY Messages . . . . . . . . . . . . . . . . . . . . 77
     5.4.3.  RESPONSE Messages  . . . . . . . . . . . . . . . . . . 78
     5.4.4.  NOTIFY Messages  . . . . . . . . . . . . . . . . . . . 79
 6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 80
   6.1.  QoS NSLP Message Type  . . . . . . . . . . . . . . . . . . 81
   6.2.  NSLP Message Objects . . . . . . . . . . . . . . . . . . . 81
   6.3.  QoS NSLP Binding Codes . . . . . . . . . . . . . . . . . . 82
   6.4.  QoS NSLP Error Classes and Error Codes . . . . . . . . . . 82
   6.5.  QoS NSLP Error Source Identifiers  . . . . . . . . . . . . 83
   6.6.  NSLP IDs and Router Alert Option Values  . . . . . . . . . 83
 7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 83
   7.1.  Trust Relationship Model . . . . . . . . . . . . . . . . . 85
   7.2.  Authorization Model Examples . . . . . . . . . . . . . . . 87
     7.2.1.  Authorization for the Two-Party Approach . . . . . . . 87
     7.2.2.  Token-Based Three-Party Approach . . . . . . . . . . . 88
     7.2.3.  Generic Three-Party Approach . . . . . . . . . . . . . 90
   7.3.  Computing the Authorization Decision . . . . . . . . . . . 90
 8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 91

Manner, et al. Experimental [Page 3] RFC 5974 QoS NSLP October 2010

 9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 91
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
   10.1. Normative References . . . . . . . . . . . . . . . . . . . 91
   10.2. Informative References . . . . . . . . . . . . . . . . . . 91
 Appendix A.  Abstract NSLP-RMF API . . . . . . . . . . . . . . . . 94
   A.1.  Triggers from QOS-NSLP towards RMF . . . . . . . . . . . . 94
   A.2.  Triggers from RMF/QOSM towards QOS-NSLP  . . . . . . . . . 96
   A.3.  Configuration Interface  . . . . . . . . . . . . . . . . . 99
 Appendix B.  Glossary  . . . . . . . . . . . . . . . . . . . . .  100

1. Introduction

 This document defines a Quality of Service (QoS) NSIS Signaling Layer
 Protocol (NSLP), henceforth referred to as the "QoS NSLP".  This
 protocol establishes and maintains state at nodes along the path of a
 data flow for the purpose of providing some forwarding resources for
 that flow.  It is intended to satisfy the QoS-related requirements of
 RFC 3726 [RFC3726].  This QoS NSLP is part of a larger suite of
 signaling protocols, whose structure is outlined in the NSIS
 framework [RFC4080].  The abstract NTLP has been developed into a
 concrete protocol, GIST (General Internet Signaling Transport)
 [RFC5971].  The QoS NSLP relies on GIST to carry out many aspects of
 signaling message delivery.
 The design of the QoS NSLP is conceptually similar to RSVP [RFC2205]
 and uses soft-state peer-to-peer refresh messages as the primary
 state management mechanism (i.e., state installation/refresh is
 performed between pairs of adjacent NSLP nodes, rather than in an
 end-to-end fashion along the complete signaling path).  The QoS NSLP
 extends the set of reservation mechanisms to meet the requirements of
 RFC 3726 [RFC3726], in particular, support of sender- or receiver-
 initiated reservations, as well as a type of bidirectional
 reservation and support of reservations between arbitrary nodes,
 e.g., edge-to-edge, end-to-access, etc.  On the other hand, there is
 currently no support for IP multicast.
 A distinction is made between the operation of the signaling protocol
 and the information required for the operation of the Resource
 Management Function (RMF).  This document describes the signaling
 protocol, whilst [RFC5975] describes the RMF-related information
 carried in the QSPEC (QoS Specification) object in QoS NSLP messages.
 This is similar to the decoupling between RSVP and the IntServ
 architecture [RFC1633].  The QSPEC carries information on resources
 available, resources required, traffic descriptions, and other
 information required by the RMF.

Manner, et al. Experimental [Page 4] RFC 5974 QoS NSLP October 2010

 This document is structured as follows.  The overall protocol design
 is outlined in Section 3.1.  The operation and use of the QoS NSLP is
 described in more detail in the rest of Section 3.  Section 4 then
 clarifies the protocol by means of a number of examples.  These
 sections should be read by people interested in the overall protocol
 capabilities.  The functional specification in Section 5 contains
 more detailed object and message formats and processing rules and
 should be the basis for implementers.  The subsequent sections
 describe IANA allocation issues and security considerations.

2. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].
 The terminology defined by GIST [RFC5971] applies to this document.
 In addition, the following terms are used:
 QNE: an NSIS Entity (NE), which supports the QoS NSLP.
 QNI: the first node in the sequence of QNEs that issues a reservation
 request for a session.
 QNR: the last node in the sequence of QNEs that receives a
 reservation request for a session.
 P-QNE: Proxy-QNE, a node set to reply to messages with the PROXY
 scope flag set.
 Session: A session defines an association between a QNI and QNR
 related to a data flow.  Intermediate QNEs on the path, the QNI, and
 the QNR use the same identifier to refer to the state stored for the
 association.  The same QNI and QNR may have more than one session
 active at any one time.
 Session Identification (SESSION-ID, SID): This is a cryptographically
 random and (probabilistically) globally unique identifier of the
 application-layer session that is associated with a certain flow.
 Often, there will only be one data flow for a given session, but in
 mobility/multihoming scenarios, there may be more than one, and they
 may be differently routed [RFC4080].
 Source or message source: The one of two adjacent NSLP peers that is
 sending a signaling message (maybe the upstream or the downstream
 peer).  Note that this is not necessarily the QNI.

Manner, et al. Experimental [Page 5] RFC 5974 QoS NSLP October 2010

 QoS NSLP operation state: State used/kept by the QoS NSLP processing
 to handle messaging aspects.
 QoS reservation state: State used/kept by the Resource Management
 Function to describe reserved resources for a session.
 Flow ID: This is essentially the Message Routing Information (MRI) in
 GIST for path-coupled signaling.
 Figure 1 shows the components that have a role in a QoS NSLP
 signaling session.  The flow sender and receiver would in most cases
 be part of the QNI and QNR nodes.  Yet, these may be separate nodes,
 too.
                      QoS NSLP nodes
IP address            (QoS-unaware NSIS nodes are          IP address
= Flow                 not shown)                          = Flow
Source                 |          |            |           Destination
Address                |          |            |           Address
                       V          V            V
+--------+  Data +------+      +------+       +------+     +--------+
|  Flow  |-------|------|------|------|-------|------|---->|  Flow  |
| Sender |  Flow |      |      |      |       |      |     |Receiver|
+--------+       | QNI  |      | QNE  |       | QNR  |     +--------+
                 |      |      |      |       |      |
                 +------+      +------+       +------+
                         =====================>
                         <=====================
                               Signaling
                                 Flow
           Figure 1: Components of the QoS NSLP Architecture
 A glossary of terms and abbreviations used in this document can be
 found in Appendix B.

3. Protocol Overview

3.1. Overall Approach

 This section presents a logical model for the operation of the QoS
 NSLP and associated provisioning mechanisms within a single node.
 The model is shown in Figure 2.

Manner, et al. Experimental [Page 6] RFC 5974 QoS NSLP October 2010

                                   +-----------------+
                                   |      Local      |
                                   | Applications or |
                                   |Management (e.g.,|
                                   | for aggregates) |
                                   +-----------------+
                                            ^
                                            V
                                            V
             +----------+             +----------+      +---------+
             | QoS NSLP |             | Resource |      | Policy  |
             |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
             +----------+             +----------+      +---------+
               .  ^   |              *      ^
               |  V   .            *        ^
             +----------+        *          ^
             |   NTLP   |       *           ^
             |Processing|       *           V
             +----------+       *           V
               |      |         *           V
   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
               .      .         *           V
               |      |         *     .............................
               .      .         *     .   Traffic Control         .
               |      |         *     .                +---------+.
               .      .         *     .                |Admission|.
               |      |         *     .                | Control |.
     +----------+    +------------+   .                +---------+.
 <-.-|  Input   |    | Outgoing   |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
     |  Packet  |    | Interface  |   .+----------+    +---------+.
 ===>|Processing|====| Selection  |===.|  Packet  |====| Packet  |.==>
     |          |    |(Forwarding)|   .|Classifier|     Scheduler|.
     +----------+    +------------+   .+----------+    +---------+.
                                      .............................
         <.-.-> = signaling flow
         =====> = data flow (sender --> receiver)
         <<<>>> = control and configuration operations
         ****** = routing table manipulation
                     Figure 2: QoS NSLP in a Node
 This diagram shows an example implementation scenario where QoS
 conditioning is performed on the output interface.  However, this
 does not limit the possible implementations.  For example, in some
 cases, traffic conditioning may be performed on the incoming
 interface, or it may be split over the input and output interfaces.

Manner, et al. Experimental [Page 7] RFC 5974 QoS NSLP October 2010

 Also, the interactions with the Policy Control component may be more
 complex, involving interaction with the Resource Management Function,
 and the AAA infrastructure.
 From the perspective of a single node, the request for QoS may result
 from a local application request or from processing an incoming QoS
 NSLP message.  The request from a local application includes not only
 user applications but also network management and the policy control
 module.  For example, a request could come from multimedia
 applications, initiate a tunnel to handle an aggregate, interwork
 with some other reservation protocol (such as RSVP), and contain an
 explicit teardown triggered by a AAA policy control module.  In this
 sense, the model does not distinguish between hosts and routers.
 Incoming messages are captured during input packet processing and
 handled by GIST.  Only messages related to QoS are passed to the QoS
 NSLP.  GIST may also generate triggers to the QoS NSLP (e.g.,
 indications that a route change has occurred).  The QoS request is
 handled by the RMF, which coordinates the activities required to
 grant and configure the resource.  It also handles policy-specific
 aspects of QoS signaling.
 The grant processing involves two local decision modules, 'policy
 control' and 'admission control'.  Policy control determines whether
 the user is authorized to make the reservation.  Admission control
 determines whether the network of the node has sufficient available
 resources to supply the requested QoS.  If both checks succeed,
 parameters are set in the packet classifier and in the link-layer
 interface (e.g., in the packet scheduler) to obtain the desired QoS.
 Error notifications are passed back to the request originator.  The
 Resource Management Function may also manipulate the forwarding
 tables at this stage to select (or at least pin) a route; this must
 be done before interface-dependent actions are carried out (including
 sending outgoing messages over any new route), and is in any case
 invisible to the operation of the protocol.
 Policy control is expected to make use of the authentication
 infrastructure or the authentication protocols external to the node
 itself.  Some discussion can be found in a separate document on
 authorization issues [qos-auth].  More generally, the processing of
 policy and Resource Management Functions may be outsourced to an
 external node, leaving only 'stubs' co-located with the NSLP node;
 this is not visible to the protocol operation.  A more detailed
 discussion of authentication and authorization can be found in
 Section 3.1.3.

Manner, et al. Experimental [Page 8] RFC 5974 QoS NSLP October 2010

 Admission control, packet scheduling, and any part of policy control
 beyond simple authorization have to be implemented using specific
 definitions for types and levels of QoS.  A key assumption is made
 that the QoS NSLP is independent of the QoS parameters (e.g., IntServ
 service elements).  These are captured in a QoS model and interpreted
 only by the resource management and associated functions, and are
 opaque to the QoS NSLP itself.  QoS models are discussed further in
 Section 3.1.2.
 The final stage of processing for a resource request is to indicate
 to the QoS NSLP protocol processing that the required resources have
 been configured.  The QoS NSLP may generate an acknowledgment message
 in one direction, and may forward the resource request in the other.
 Message routing is carried out by the GIST module.  Note that while
 Figure 2 shows a unidirectional data flow, the signaling messages can
 pass in both directions through the node, depending on the particular
 message and orientation of the reservation.

3.1.1. Protocol Messages

 The QoS NSLP uses four message types:
 RESERVE: The RESERVE message is the only message that manipulates QoS
 NSLP reservation state.  It is used to create, refresh, modify, and
 remove such state.  The result of a RESERVE message is the same
 whether a message is received once or many times.
 QUERY: A QUERY message is used to request information about the data
 path without making a reservation.  This functionality can be used to
 make reservations or to support certain QoS models.  The information
 obtained from a QUERY may be used in the admission control process of
 a QNE (e.g., in case of measurement-based admission control).  Note
 that a QUERY does not change existing reservation state.
 RESPONSE: The RESPONSE message is used to provide information about
 the result of a previous QoS NSLP message.  This includes explicit
 confirmation of the state manipulation signaled in the RESERVE
 message, and the response to a QUERY message or an error code if the
 QNE or QNR is unable to provide the requested information or if the
 response is negative.  The RESPONSE message does not cause any
 reservation state to be installed or modified.
 NOTIFY: NOTIFY messages are used to convey information to a QNE.
 They differ from RESPONSE messages in that they are sent
 asynchronously and need not refer to any particular state or
 previously received message.  The information conveyed by a NOTIFY

Manner, et al. Experimental [Page 9] RFC 5974 QoS NSLP October 2010

 message is typically related to error conditions.  Examples would be
 notification to an upstream peer about state being torn down or
 notification when a reservation has been preempted.
 QoS NSLP messages are sent peer-to-peer.  This means that a QNE
 considers its adjacent upstream or downstream peer to be the source
 of each message.
 Each protocol message has a common header which indicates the message
 type and contains various flag bits.  Message formats are defined in
 Section 5.1.2.  Message processing rules are defined in Section 5.4.
 QoS NSLP messages contain three types of objects:
 1.  Control Information: Control information objects carry general
     information for the QoS NSLP processing, such as sequence numbers
     or whether a response is required.
 2.  QoS specifications (QSPECs): QSPEC objects describe the actual
     resources that are required and depend on the QoS model being
     used.  Besides any resource description, they may also contain
     other control information used by the RMF's processing.
 3.  Policy objects: Policy objects contain data used to authorize the
     reservation of resources.
 Object formats are defined in Section 5.1.3.  Object processing rules
 are defined in Section 5.3.

3.1.2. QoS Models and QoS Specifications

 The QoS NSLP provides flexibility over the exact patterns of
 signaling messages that are exchanged.  The decoupling of QoS NSLP
 and QSPEC allows the QoS NSLP to be ignorant about the ways in which
 traffic, resources, etc., are described, and it can treat the QSPEC
 as an opaque object.  Various QoS models can be designed, and these
 do not affect the specification of the QoS NSLP protocol.  Only the
 RMF specific to a given QoS model will need to interpret the QSPEC.
 The Resource Management Function (RMF) reserves resources for each
 flow.
 The QSPEC fulfills a similar purpose to the TSpec, RSpec, and AdSpec
 objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC
 2210 [RFC2210].  At each QNE, the content of the QSPEC is interpreted
 by the Resource Management Function and the Policy Control Function
 for the purposes of traffic and policy control (including admission
 control and configuration of the packet classifier and scheduler).

Manner, et al. Experimental [Page 10] RFC 5974 QoS NSLP October 2010

 The QoS NSLP does not mandate any particular behavior for the RMF,
 instead providing interoperability at the signaling-protocol level
 whilst leaving the validation of RMF behavior to contracts external
 to the protocol itself.  The RMF may make use of various elements
 from the QoS NSLP message, not only the QSPEC object.
 Still, this specification assumes that resource sharing is possible
 between flows with the same SESSION-ID that originate from the same
 QNI or between flows with a different SESSION-ID that are related
 through the BOUND-SESSION-ID object.  For flows with the same
 SESSION-ID, resource sharing is only applicable when the existing
 reservation is not just replaced (which is indicated by the REPLACE
 flag in the common header).  We assume that the QoS model supports
 resource sharing between flows.  A QoS Model may elect to implement a
 more general behavior of supporting relative operations on existing
 reservations, such as ADDING or SUBTRACTING a certain amount of
 resources from the current reservation.  A QoS Model may also elect
 to allow resource sharing more generally, e.g., between all flows
 with the same Differentiated Service Code Point (DSCP).
 The QSPEC carries a collection of objects that can describe QoS
 specifications in a number of different ways.  A generic template is
 defined in [RFC5975] and contains object formats for generally useful
 elements of the QoS description, which is designed to ensure
 interoperability when using the basic set of objects.  A QSPEC
 describing the resources requested will usually contain objects that
 need to be understood by all implementations, and it can also be
 enhanced with additional objects specific to a QoS model to provide a
 more exact definition to the RMF, which may be better able to use its
 specific resource management mechanisms (which may, e.g., be link
 specific) as a result.
 A QoS Model defines the behavior of the RMF, including inputs and
 outputs, and how QSPEC information is used to describe resources
 available, resources required, traffic descriptions, and control
 information required by the RMF.  A QoS Model also describes the
 minimum set of parameters QNEs should use in the QSPEC when signaling
 about this QoS Model.
 QoS Models may be local (private to one network), implementation/
 vendor specific, or global (implementable by different networks and
 vendors).  All QSPECs should follow the design of the QSPEC template.
 The definition of a QoS model may also have implications on how local
 behavior should be implemented in the areas where the QoS NSLP gives
 freedom to implementers.  For example, it may be useful to identify
 recommended behavior for how a forwarded RESERVE message relates to a
 received one, or for when additional signaling sessions should be

Manner, et al. Experimental [Page 11] RFC 5974 QoS NSLP October 2010

 started based on existing sessions, such as required for aggregate
 reservations.  In some cases, suggestions may be made on whether
 state that may optionally be retained should be held in particular
 scenarios.  A QoS model may specify reservation preemption, e.g., an
 incoming resource request may cause removal of an earlier established
 reservation.

3.1.3. Policy Control

 Getting access to network resources, e.g., network access in general
 or access to QoS, typically involves some kind of policy control.
 One example of this is authorization of the resource requester.
 Policy control for QoS NSLP resource reservation signaling is
 conceptually organized as illustrated below in Figure 3.
                                +-------------+
                                | Policy      |
                                | Decision    |
                                | Point (PDP) |
                                +------+------+
                                       |
                               /-\-----+-----/\
                           ////                \\\\
                         ||                        ||
                        |      Policy transport      |
                         ||                        ||
                           \\\\                ////
                               \-------+------/
                                       |
 +-------------+ QoS signaling  +------+------+
 |  Entity     |<==============>| QNE = Policy|<=========>
 |  requesting | Data Flow      | Enforcement |
 |  resource   |----------------|-Point (PEP)-|---------->
 +-------------+                +-------------+
         Figure 3: Policy Control with the QoS NSLP Signaling
 From the QoS NSLP point of view, the policy control model is
 essentially a two-party model between neighboring QNEs.  The actual
 policy decision may depend on the involvement of a third entity (the
 Policy Decision Point, PDP), but this happens outside of the QoS NSLP
 protocol by means of existing policy infrastructure (Common Open
 Policy Service (COPS), Diameter, etc.).  The policy control model for
 the entire end-to-end chain of QNEs is therefore one of transitivity,
 where each of the QNEs exchanges policy information with its QoS NSLP
 policy peer.

Manner, et al. Experimental [Page 12] RFC 5974 QoS NSLP October 2010

 The authorization of a resource request often depends on the identity
 of the entity making the request.  Authentication may be required.
 The GIST channel security mechanisms provide one way of
 authenticating the QoS NSLP peer that sent the request, and so may be
 used in making the authorization decision.
 Additional information might also be provided in order to assist in
 making the authorization decision.  This might include alternative
 methods of authenticating the request.
 The QoS NSLP does not currently contain objects to carry
 authorization information.  At the time of writing, there exists a
 separate individual work [NSIS-AUTH] that defines this functionality
 for the QoS NSLP and the NAT and firewall (NATFW) NSLP.
 It is generally assumed that policy enforcement is likely to
 concentrate on border nodes between administrative domains.  This may
 mean that nodes within the domain are "Policy-Ignorant Nodes" that
 perform no per-request authentication or authorization, relying on
 the border nodes to perform the enforcement.  In such cases, the
 policy management between ingress and egress edge of a domain relies
 on the internal chain of trust between the nodes in the domain.  If
 this is not acceptable, a separate signaling session can be set up
 between the ingress and egress edge nodes in order to exchange policy
 information.

3.2. Design Background

 This section presents some of the key functionality behind the
 specification of the QoS NSLP.

3.2.1. Soft States

 The NSIS protocol suite takes a soft-state approach to state
 management.  This means that reservation state in QNEs must be
 periodically refreshed.  The frequency with which state installation
 is refreshed is expressed in the REFRESH-PERIOD object.  This object
 contains a value in milliseconds indicating how long the state that
 is signaled for remains valid.  Maintaining the reservation beyond
 this lifetime can be done by sending a RESERVE message periodically.

3.2.2. Sender and Receiver Initiation

 The QoS NSLP supports both sender-initiated and receiver-initiated
 reservations.  For a sender-initiated reservation, RESERVE messages
 travel in the same direction as the data flow that is being signaled
 for (the QNI is at the side of the source of the data flow).  For a

Manner, et al. Experimental [Page 13] RFC 5974 QoS NSLP October 2010

 receiver-initiated reservation, RESERVE messages travel in the
 opposite direction (the QNI is at the side of the receiver of the
 data flow).
 Note: these definitions follow the definitions in Section 3.3.1 of
 RFC 4080 [RFC4080].  The main issue is about which node is in charge
 of requesting and maintaining the resource reservation.  In a
 receiver-initiated reservation, even though the sender sends the
 initial QUERY, the receiver is still in charge of making the actual
 resource request and maintaining the reservation.

3.2.3. Protection against Message Re-ordering and Duplication

 RESERVE messages affect the installed reservation state.  Unlike
 NOTIFY, QUERY, and RESPONSE messages, the order in which RESERVE
 messages are received influences the eventual reservation state that
 will be stored at a QNE; that is, the most recent RESERVE message
 replaces the current reservation.  Therefore, in order to protect
 against RESERVE message re-ordering or duplication, the QoS NSLP uses
 a Reservation Sequence Number (RSN).  The RSN has local significance
 only, i.e., between a QNE and its downstream peers.

3.2.4. Explicit Confirmations

 A QNE may require a confirmation that the end-to-end reservation is
 in place, or a reply to a query along the path.  For such requests,
 it must be able to keep track of which request each response refers
 to.  This is supported by including a Request Identification
 Information (RII) object in a QoS NSLP message.

3.2.5. Reduced Refreshes

 For scalability, the QoS NSLP supports an abbreviated form of refresh
 RESERVE message.  In this case, the refresh RESERVE references the
 reservation using the RSN and the SESSION-ID, and does not include
 the full reservation specification (including QSPEC).  By default,
 state refresh should be performed with reduced refreshes in order to
 save bytes during transmission.  Stateless QNEs will require full
 refresh since they do not store the whole reservation information.
 If the stateful QNE does not support reduced refreshes, or there is a
 mismatch between the local and received RSN, the stateful QNE must
 reply with a RESPONSE carrying an INFO-SPEC indicating the error.
 Furthermore, the QNE must stop sending reduced refreshes to this peer
 if the error indicates that support for this feature is lacking.

Manner, et al. Experimental [Page 14] RFC 5974 QoS NSLP October 2010

3.2.6. Summary Refreshes and Summary Tear

 For limiting the number of individual messages, the QoS NSLP supports
 summary refresh and summary tear messages.  When sending a refreshing
 RESERVE for a certain (primary) session, a QNE may include a SESSION-
 ID-LIST object where the QNE indicates (secondary) sessions that are
 also refreshed.  An RSN-LIST object must also be added.  The SESSION-
 IDs and RSNs are stacked in the objects such that the index in both
 stacks refer to the same reservation state, i.e., the SESSION-ID and
 RSN at index i in both objects refers to the same session.  If the
 receiving stateful QNE notices unknown SESSION-IDs or a mismatch with
 RSNs for a session, it will reply back to the upstream stateful QNE
 with an error.
 In order to tear down several sessions at once, a QNE may include
 SESSION-ID-LIST and RSN-LIST objects in a tearing reserve.  The
 downstream stateful QNE must then also tear down the other sessions
 indicated.  The downstream stateful QNE must silently ignore any
 unknown SESSION-IDs.
 GIST provides a SII-Handle for every downstream session.  The SII-
 Handle identifies a peer and should be the same for all sessions
 whose downstream peer is the same.  The QoS NSLP uses this
 information to decide whether summary refresh messages can be sent or
 when a summary tear is possible.

3.2.7. Message Scoping

 A QNE may use local policy when deciding whether to propagate a
 message or not.  For example, the local policy can define/configure
 that a QNE is, for a particular session, a QNI and/or a QNR.  The QoS
 NSLP also includes an explicit mechanism to restrict message
 propagation by means of a scoping mechanism.
 For a RESERVE or a QUERY message, two scoping flags limit the part of
 the path on which state is installed on the downstream nodes that can
 respond.  When the SCOPING flag is set to zero, it indicates that the
 scope is "whole path" (default).  When set to one, the scope is
 "single hop".  When the PROXY scope flag is set, the path is
 terminated at a pre-defined Proxy QNE (P-QNE).  This is similar to
 the Localized RSVP [lrsvp].
 The propagation of a RESPONSE message is limited by the RII object,
 which ensures that it is not forwarded back along the path further
 than the node that requested the RESPONSE.

Manner, et al. Experimental [Page 15] RFC 5974 QoS NSLP October 2010

3.2.8. Session Binding

 Session binding is defined as the enforcement of a relation between
 different QoS NSLP sessions (i.e., signaling flows with different
 SESSION-IDs (SIDs) as defined in GIST [RFC5971]).
 Session binding indicates a unidirectional dependency relation
 between two or more sessions by including a BOUND-SESSION-ID object.
 A session with SID_A (the binding session) can express its
 unidirectional dependency relation to another session with SID_B (the
 bound session) by including a BOUND-SESSION-ID object containing
 SID_B in its messages.
 The concept of session binding is used to indicate the unidirectional
 dependency relation between the end-to-end session and the aggregate
 session in case of aggregate reservations.  In case of bidirectional
 reservations, it is used to express the unidirectional dependency
 relation between the sessions used for forward and reverse
 reservation.  Typically, the dependency relation indicated by session
 binding is purely informative in nature and does not automatically
 trigger any implicit action in a QNE.  A QNE may use the dependency
 relation information for local resource optimization or to explicitly
 tear down reservations that are no longer useful.  However, by using
 an explicit binding code (see Section 5.1.3.4), it is possible to
 formalize this dependency relation, meaning that if the bound session
 (e.g., session with SID_B) is terminated, the binding session (e.g.,
 the session with SID_A) must be terminated also.
 A message may include more than one BOUND-SESSION-ID object.  This
 may happen, e.g., in certain aggregation and bidirectional
 reservation scenarios, where an end-to-end session has a
 unidirectional dependency relation with an aggregate session and at
 the same time it has a unidirectional dependency relation with
 another session used for the reverse path.

3.2.9. Message Binding

 QoS NSLP supports binding of messages in order to allow for
 expressing dependencies between different messages.  The message
 binding can indicate either a unidirectional or bidirectional
 dependency relation between two messages by including the MSG-ID
 object in one message ("binding message") and the BOUND-MSG-ID object
 in the other message ("bound message").  The unidirectional
 dependency means that only RESERVE messages are bound to each other
 whereas a bidirectional dependency means that there is also a
 dependency for the related RESPONSE messages.  The message binding
 can be used to speed up signaling by starting two signaling exchanges
 simultaneously that are synchronized later by using message IDs.

Manner, et al. Experimental [Page 16] RFC 5974 QoS NSLP October 2010

 This can be used as an optimization technique, for example, in
 scenarios where aggregate reservations are used.  Section 4.6
 provides more details.

3.2.10. Layering

 The QoS NSLP supports layered reservations.  Layered reservations may
 occur when certain parts of the network (domains) implement one or
 more local QoS models or when they locally apply specific transport
 characteristics (e.g., GIST unreliable transfer mode instead of
 reliable transfer mode).  They may also occur when several per-flow
 reservations are locally combined into an aggregate reservation.

3.2.10.1. Local QoS Models

 A domain may have local policies regarding QoS model implementation,
 i.e., it may map incoming traffic to its own locally defined QoS
 models.  The QSPEC allows this functionality, and the operation is
 transparent to the QoS NSLP.  The use of local QoS models within a
 domain is performed in the RMF.

3.2.10.2. Local Control Plane Properties

 The way signaling messages are handled is mainly determined by the
 parameters that are sent over the GIST-NSLP API and by the domain
 internal configuration.  A domain may have a policy to implement
 local transport behavior.  It may, for instance, elect to use an
 unreliable transport locally in the domain while still keeping end-
 to-end reliability intact.
 The QoS NSLP supports this situation by allowing two sessions to be
 set up for the same reservation.  The local session has the desired
 local transport properties and is interpreted in internal QNEs.  This
 solution poses two requirements: the end-to-end session must be able
 to bypass intermediate nodes, and the egress QNE needs to bind both
 sessions together.  Bypassing intermediate nodes is achieved with
 GIST.  The local session and the end-to-end session are bound at the
 egress QNE by means of the BOUND-SESSION-ID object.

3.2.10.3. Aggregate Reservations

 In some cases, it is desirable to create reservations for an
 aggregate, rather than on a per-flow basis, in order to reduce the
 amount of reservation state needed as well as the processing load for
 signaling messages.  Note that the QoS NSLP does not specify how
 reservations need to be combined in an aggregate or how end-to-end
 properties need to be computed, but only provides signaling support
 for aggregate reservations.

Manner, et al. Experimental [Page 17] RFC 5974 QoS NSLP October 2010

 The essential difference with the layering approaches described in
 Sections 3.2.10.1 and 3.2.10.2 is that the aggregate reservation
 needs a MRI that describes all traffic carried in the aggregate
 (e.g., a DSCP in case of IntServ over Diffserv).  The need for a
 different MRI mandates the use of two different sessions, as
 described in Section 3.2.10.2 and in the RSVP aggregation solution in
 RFC 3175 [RFC3175].
 Edge QNEs of the aggregation domain that want to maintain some end-
 to-end properties may establish a peering relation by sending the
 end-to-end message transparently over the domain (using the
 intermediate node bypass capability described above).  Updating the
 end-to-end properties in this message may require some knowledge of
 the aggregated session (e.g., for updating delay values).  For this
 purpose, the end-to-end session contains a BOUND-SESSION-ID carrying
 the SESSION-ID of the aggregate session.

3.2.11. Support for Request Priorities

 This specification acknowledges the fact that in some situations,
 some messages or reservations may be more important than others, and
 therefore it foresees mechanisms to give these messages or
 reservations priority.
 Priority of certain signaling messages over others may be required in
 mobile scenarios when a message loss during call setup is less
 harmful than during handover.  This situation only occurs when GIST
 or QoS NSLP processing is the congested part or scarce resource.
 Priority of certain reservations over others may be required when QoS
 resources are oversubscribed.  In that case, existing reservations
 may be preempted in order to make room for new higher-priority
 reservations.  A typical approach to deal with priority and
 preemption is through the specification of a setup priority and
 holding priority for each reservation.  The Resource Management
 Function at each QNE then keeps track of the resource consumption at
 each priority level.  Reservations are established when resources, at
 their setup priority level, are still available.  They may cause
 preemption of reservations with a lower holding priority than their
 setup priority.
 Support of reservation priority is a QSPEC parameter and therefore
 outside the scope of this specification.  The GIST specification
 provides a mechanism to support a number of levels of message
 priority that can be requested over the NSLP-GIST API.

Manner, et al. Experimental [Page 18] RFC 5974 QoS NSLP October 2010

3.2.12. Rerouting

 The QoS NSLP needs to adapt to route changes in the data path.  This
 assumes the capability to detect rerouting events, create a QoS
 reservation on the new path, and optionally tear down reservations on
 the old path.
 From an NSLP perspective, rerouting detection can be performed in two
 ways.  It can either come through NetworkNotification from GIST, or
 from information seen at the NSLP.  In the latter case, the QoS NSLP
 node is able to detect changes in its QoS NSLP peers by keeping track
 of a Source Identification Information (SII) handle that provides
 information similar in nature to the RSVP_HOP object described in RFC
 2205 [RFC2205].  When a RESERVE message with an existing SESSION-ID
 and a different SII is received, the QNE knows its upstream or
 downstream peer has changed, for sender-oriented and receiver-
 oriented reservations, respectively.
 Reservation on the new path happens when a RESERVE message arrives at
 the QNE beyond the point where the old and new paths diverge.  If the
 QoS NSLP suspects that a reroute has occurred, then a full RESERVE
 message (including the QSPEC) would be sent.  A refreshing RESERVE
 (with no QSPEC) will be identified as an error by a QNE on the new
 path, which does not have the reservation installed (i.e., it was not
 on the old path) or which previously had a different previous-hop
 QNE.  It will send back an error message that results in a full
 RESERVE message being sent.  Rapid recovery at the NSLP layer
 therefore requires short refresh periods.  Detection before the next
 RESERVE message arrives is only possible at the IP layer or through
 monitoring of GIST peering relations (e.g., by monitoring the Time to
 Live (TTL), i.e., the number of GIST hops between NSLP peers, or
 observing the changes in the outgoing interface towards GIST peer).
 These mechanisms can provide implementation-specific optimizations
 and are outside the scope of this specification.
 When the QoS NSLP is aware of the route change, it needs to set up
 the reservation on the new path.  This is done by sending a new
 RESERVE message.  If the next QNE is in fact unchanged, then this
 will be used to refresh/update the existing reservation.  Otherwise,
 it will lead to the reservation being installed on the new path.
 Note that the operation for a receiver-initiated reservation session
 differs a bit from the above description.  If the routing changes in
 the middle of the path, at some point (i.e., the divergence point)
 the QNE that notices that its downstream path has changed (indicated
 by a NetworkNotification from GIST), and it must send a QUERY with
 the R-flag downstream.  The QUERY will be processed as above, and at
 some point hits a QNE for which the path downstream towards the QNI

Manner, et al. Experimental [Page 19] RFC 5974 QoS NSLP October 2010

 remains (i.e., the convergence point).  This node must then send a
 full RESERVE upstream to set up the reservation state along the new
 path.  It should not send the QUERY further downstream, since this
 would have no real use.  Similarly, when the QNE that sent the QUERY
 receives the RESERVE, it should not send the RESERVE further
 upstream.
 After the reservation on the new path is set up, the branching node
 may want to tear down the reservation on the old path (sooner than
 would result from normal soft-state timeout).  This functionality is
 supported by keeping track of the old SII-Handle provided over the
 GIST API.  This handle can be used by the QoS NSLP to route messages
 explicitly to the next node.
 If the old path is downstream, the QNE can send a tearing RESERVE
 using the old SII-Handle.  If the old path is upstream, the QNE can
 send a NOTIFY with the code for "Route Change".  This is forwarded
 upstream until it hits a QNE that can issue a tearing RESERVE
 downstream.  A separate document discusses in detail the effect of
 mobility on the QoS NSLP signaling [NSIS-MOB].
 A QNI or a branch node may wish to keep the reservation on the old
 branch.  For instance, this could be the case when a mobile node has
 experienced a mobility event and wishes to keep reservation to its
 old attachment point in case it moves back there.  For this purpose,
 a REPLACE flag is provided in the QoS NSLP common header, which, when
 not set, indicates that the reservation on the old branch should be
 kept.
 Note that keeping old reservations affects the resources available to
 other nodes.  Thus, the operator of the access network must make the
 final decision on whether this behavior is allowed.  Also, the QNEs
 in the access network may add this flag even if the mobile node has
 not used the flag initially.
 The latency in detecting that a new downstream peer exists or that
 truncation has happened depends on GIST.  The default QUERY message
 transmission interval is 30 seconds.  More details on how NSLPs are
 able to affect the discovery of new peers or rerouting can be found
 in the GIST specification.

3.2.12.1. Last Node Behavior

 The design of the QoS NSLP allows reservations to be installed at a
 subset of the nodes along a path.  In particular, usage scenarios
 include cases where the data flow endpoints do not support the QoS
 NSLP.

Manner, et al. Experimental [Page 20] RFC 5974 QoS NSLP October 2010

 In the case where the data flow receiver does not support the QoS
 NSLP, some particular considerations must be given to node discovery
 and rerouting at the end of the signaling path.
 There are three cases for the last node on the signaling path:
 1)  the last node is the data receiver,
 2)  the last node is a configured proxy for the data receiver, or
 3)  the last node is not the data receiver and is not explicitly
     configured to act as a signaling proxy on behalf of the data
     receiver.
 Cases (1) and (2) can be handled by the QoS NSLP itself during the
 initial path setup, since the QNE knows that it should terminate the
 signaling.  Case (3) requires some assistance from GIST, which
 provides messages across the API to indicate that no further GIST
 nodes that support QoS NSLP are present downstream, and that probing
 of the downstream route change needs to continue once the reservation
 is installed to detect any changes in this situation.
 Two particular scenarios need to be considered in this third case.
 In the first, referred to as "Path Extension", rerouting occurs such
 that an additional QNE is inserted into the signaling path between
 the old last node and the data receiver, as shown in Figure 4.
         /-------\   Initial route
        /         v
            /-\
         /--|B|--\                +-+
        /   \-/   \               |x| = QoS NSLP aware
     +-+           /-\            +-+
 ----|A|           |D|
     +-+           \-/            /-\
        \   +-+   /               |x| = QoS NSLP unaware
         \--|C|--/                \-/
            +-+
        \         ^
         \-------/   Updated route
                       Figure 4: Path Extension
 When rerouting occurs, the data path changes from A-B-D to A-C-D.
 Initially the signaling path ends at A.  Despite initially being the
 last node, node A needs to continue to attempt to send messages
 downstream to probe for path changes, unless it has been explicitly

Manner, et al. Experimental [Page 21] RFC 5974 QoS NSLP October 2010

 configured as a signaling proxy for the data flow receiver.  This is
 required so that the signaling path change is detected, and C will
 become the new last QNE.
 In a second case, referred to as "Path Truncation", rerouting occurs
 such that the QNE that was the last node on the signaling path is no
 longer on the data path.  This is shown in Figure 5.
         /-------\   Initial route
        /         v
            +-+
         /--|B|--\                 +-+
        /   +-+   \                |x| = QoS NSLP aware
     +-+           /-\             +-+
 ----|A|           |D|
     +-+           \-/             /-\
        \   /-\   /                |x| = QoS NSLP unaware
         \--|C|--/                 \-/
            \-/
        \         ^
         \-------/   Updated route
                       Figure 5: Path Truncation
 When rerouting occurs, the data path again changes from A-B-D to
 A-C-D.  The signaling path initially ends at B, but this node is not
 on the new path.  In this case, the normal GIST path change detection
 procedures at A will detect the path change and notify the QoS NSLP.
 GIST will also notify the signaling application that no downstream
 GIST nodes supporting the QoS NSLP are present.  Node A will take
 over as the last node on the signaling path.

3.2.12.2. Handling Spurious Route Change Notifications

 The QoS NSLP is notified by GIST (with the NetworkNotification
 primitive) when GIST believes that a rerouting event may have
 occurred.  In some cases, events that are detected as possible route
 changes will turn out not to be.  The QoS NSLP will not always be
 able to detect this, even after receiving messages from the 'new'
 peer.
 As part of the RecvMessage API primitive, GIST provides an SII-Handle
 that can be used by the NSLP to direct a signaling message to a
 particular peer.  The current SII-Handle will change if the signaling
 peer changes.  However, it is not guaranteed to remain the same after
 a rerouting event where the peer does not change.  Therefore, the QoS
 NSLP mechanism for reservation maintenance after a route change

Manner, et al. Experimental [Page 22] RFC 5974 QoS NSLP October 2010

 includes robustness mechanisms to avoid accidentally tearing down a
 reservation in situations where the peer QNE has remained the same
 after a 'route change' notification from GIST.
 A simple example that illustrates the problem is shown in Figure 6
 below.
         (1)                         +-+
       /-----\                       |x| = QoS NSLP aware
     +-+     /-\ (3) +-+             +-+
 ----|A|     |B|-----|C|----
     +-+     \-/     +-+             /-\
       \-----/                       |x| = QoS NSLP unaware
         (2)                         \-/
                  Figure 6: Spurious Reroute Alerting
 In this example, the initial route A-B-C uses links (1) and (3).
 After link (1) fails, the path is rerouted using links (2) and (3).
 The set of QNEs along the path is unchanged (it is A-C in both cases,
 since B does not support the QoS NSLP).
 When the outgoing interface at A has changes, GIST may signal across
 its API to the NSLP with a NetworkNotification.  The QoS NSLP at A
 will then attempt to repair the path by installing the reservation on
 the path (2),(3).  In this case, however, the old and new paths are
 the same.
 To install the new reservation, A will send a RESERVE message, which
 GIST will transport to C (discovering the new next peer as
 appropriate).  The RESERVE also requests a RESPONSE from the QNR.
 When this RESERVE message is received through the RecvMessage API
 call from GIST at the QoS NSLP at C, the SII-Handle will be unchanged
 from its previous communications from A.
 A RESPONSE message will be sent by the QNR, and be forwarded from C
 to A.  This confirms that the reservation was installed on the new
 path.  The SII-Handle passed with the RecvMessage call from GIST to
 the QoS NSLP will be different to that seen previously, since the
 interface being used on A has changed.
 At this point, A can attempt to tear down the reservation on the old
 path.  The RESERVE message with the TEAR flag set is sent down the
 old path by using the GIST explicit routing mechanism and specifying
 the SII-Handle relating to the 'old' peer QNE.

Manner, et al. Experimental [Page 23] RFC 5974 QoS NSLP October 2010

 If RSNs were being incremented for each of these RESERVE and RESERVE-
 with-TEAR messages, the reservation would be torn down at C and any
 QNEs further along the path.  To avoid this, the RSN is used in a
 special way.  The RESERVE down the new path is sent with the new
 current RSN set to the old RSN plus 2.  The RESERVE-with-TEAR down
 the old path is sent with an RSN set to the new current RSN minus 1.
 This is the peer from which it was receiving RESERVE messages (see
 for more details).

3.2.13. Preemption

 The QoS NSLP provides building blocks to implement preemption.  This
 specification does not define how preemption should work, but only
 provides signaling mechanisms that can be used by QoS models.  For
 example, an INFO-SPEC object can be added to messages to indicate
 that the signaled session was preempted.  A BOUND-SESSION-ID object
 can carry the Session ID of the flow that caused the preemption of
 the signaled session.  How these are used by QoS models is out of
 scope of the QoS NSLP specification.

3.3. GIST Interactions

 The QoS NSLP uses GIST for delivery of all its messages.  Messages
 are passed from the NSLP to GIST via an API (defined in Appendix B of
 [RFC5971]), which also specifies additional information, including an
 identifier for the signaling application (e.g., 'QoS NSLP'), session
 identifier, MRI, and an indication of the intended direction (towards
 data sender or receiver).  On reception, GIST provides the same
 information to the QoS NSLP.  In addition to the NSLP message data
 itself, other meta-data (e.g., session identifier and MRI) can be
 transferred across this interface.
 The QoS NSLP keeps message and reservation state per session.  A
 session is identified by a Session Identifier (SESSION-ID).  The
 SESSION-ID is the primary index for stored NSLP state and needs to be
 constant and unique (with a sufficiently high probability) along a
 path through the network.  The QoS NSLP picks a value for Session-ID.
 This value is subsequently used by GIST and the QoS NSLP to refer to
 this session.
 Currently, the QoS NSLP specification considers mainly the path-
 coupled MRM.  However, extensions may specify how other types of MRMs
 may be applied in combination with the QoS NSLP.
 When GIST passes the QoS NSLP data to the NSLP for processing, it
 must also indicate the value of the 'D' (Direction) flag for that
 message in the MRI.

Manner, et al. Experimental [Page 24] RFC 5974 QoS NSLP October 2010

 The QoS NSLP does not provide any method of interacting with
 firewalls or Network Address Translators (NATs).  It assumes that a
 basic NAT traversal service is provided by GIST.

3.3.1. Support for Bypassing Intermediate Nodes

 The QoS NSLP may want to restrict the handling of its messages to
 specific nodes.  This functionality is needed to support layering
 (explained in Section 3.2.10), when only the edge QNEs of a domain
 process the message.  This requires a mechanism at the GIST level
 (which can be invoked by the QoS NSLP) to bypass intermediate nodes
 between the edges of the domain.
 The intermediate nodes are bypassed using multiple levels of the
 router alert option.  In that case, internal routers are configured
 to handle only certain levels of router alerts.  This is accomplished
 by marking this message at the ingress, i.e., modifying the QoS NSLP
 default NSLPID value to an NSLPID predefined value (see Section 6.6).
 The egress stops this marking process by reassigning the QoS NSLP
 default NSLPID value to the original RESERVE message.  The exact
 operation of modifying the NSLPID must be specified in the relevant
 QoS model specification.

3.3.2. Support for Peer Change Identification

 There are several circumstances where it is necessary for a QNE to
 identify the adjacent QNE peer, which is the source of a signaling
 application message.  For example, it may be to apply the policy that
 "state can only be modified by messages from the node that created
 it" or it might be that keeping track of peer identity is used as a
 (fallback) mechanism for rerouting detection at the NSLP layer.
 This functionality is implemented in the GIST service interface with
 SII-handle.  As shown in the above example, we assume the SII-
 handling will support both its own SII and its peer's SII.
 Keeping track of the SII of a certain reservation also provides a
 means for the QoS NSLP to detect route changes.  When a QNE receives
 a RESERVE referring to existing state but with a different SII, it
 knows that its upstream peer has changed.  It can then use the old
 SII to initiate a teardown along the old section of the path.  This
 functionality is supported in the GIST service interface when the
 peer's SII (which is stored on message reception) is passed to GIST
 upon message transmission.

Manner, et al. Experimental [Page 25] RFC 5974 QoS NSLP October 2010

3.3.3. Support for Stateless Operation

 Stateless or reduced-state QoS NSLP operation makes the most sense
 when some nodes are able to operate in a stateless way at the GIST
 level as well.  Such nodes should not worry about keeping reverse
 state, message fragmentation and reassembly (at GIST), congestion
 control, or security associations.  A stateless or reduced-state QNE
 will be able to inform the underlying GIST of this situation.  GIST
 service interface supports this functionality with the Retain-State
 attribute in the MessageReceived primitive.

3.3.4. Priority of Signaling Messages

 The QoS NSLP will generate messages with a range of performance
 requirements for GIST.  These requirements may result from a
 prioritization at the QoS NSLP (Section 3.2.11) or from the
 responsiveness expected by certain applications supported by the QoS
 NSLP.  GIST service interface supports this with the 'priority'
 transfer attribute.

3.3.5. Knowledge of Intermediate QoS-NSLP-Unaware Nodes

 In some cases, it is useful to know that there are routers along the
 path where QoS cannot be provided.  The GIST service interface
 supports this by keeping track of IP-TTL and Original-TTL in the
 RecvMessage primitive.  A difference between the two indicates the
 number of QoS-NSLP-unaware nodes.  In this case, the QNE that detects
 this difference should set the "B" (BREAK) flag.  If a QNE receives a
 QUERY or RESERVE message with the BREAK flag set, and then generates
 a QUERY, RESERVE, or RESPONSE message, it can set the BREAK flag in
 those messages.  There are however, situations where the egress QNE
 in a local domain may have some other means to provide QoS [RFC5975].
 For example, in a local domain that is aware of RMD-QOSM [RFC5977]
 (or a similar QoS Model) and that uses either NTLP stateless nodes or
 NSIS-unaware nodes, the end-to-end RESERVE or QUERY message bypasses
 these NTLP stateless or NSIS-unaware nodes.  However, the reservation
 within the local domain can be signaled by the RMD-QOSM (or a similar
 QoS Model).  In such situations, the "B" (BREAK) flag in the end-to-
 end RESERVE or QUERY message should not be set by the edges of the
 local domain.

4. Examples of QoS NSLP Operation

 The QoS NSLP can be used in a number of ways.  The examples here give
 an indication of some of the basic processing.  However, they are not
 exhaustive and do not attempt to cover the details of the protocol
 processing.

Manner, et al. Experimental [Page 26] RFC 5974 QoS NSLP October 2010

4.1. Sender-Initiated Reservation

 QNI        QNE        QNE        QNR
  |          |          |          |
  | RESERVE  |          |          |
  +--------->|          |          |
  |          | RESERVE  |          |
  |          +--------->|          |
  |          |          | RESERVE  |
  |          |          +--------->|
  |          |          |          |
  |          |          | RESPONSE |
  |          |          |<---------+
  |          | RESPONSE |          |
  |          |<---------+          |
  | RESPONSE |          |          |
  |<---------+          |          |
  |          |          |          |
  |          |          |          |
             Figure 7: Basic Sender-Initiated Reservation
 To make a new reservation, the QNI constructs a RESERVE message
 containing a QSPEC object, from its chosen QoS model, that describes
 the required QoS parameters.
 The RESERVE message is passed to GIST, which transports it to the
 next QNE.  There, it is delivered to the QoS NSLP processing, which
 examines the message.  Policy control and admission control decisions
 are made.  The exact processing also takes into account the QoS model
 being used.  The node performs appropriate actions (e.g., installing
 the reservation) based on the QSPEC object in the message.
 The QoS NSLP then generates a new RESERVE message (usually based on
 the one received).  This is passed to GIST, which forwards it to the
 next QNE.
 The same processing is performed at further QNEs along the path, up
 to the QNR.  The determination that a node is the QNR may be made
 directly (e.g., that node is the destination for the data flow), or
 using GIST functionality to determine that there are no more QNEs
 between this node and the data flow destination.
 Any node may include a request for a RESPONSE in its RESERVE
 messages.  It does so by including a Request Identification
 Information (RII) object in the RESERVE message.  If the message
 already includes an RII, an interested QNE must not add a new RII
 object or replace the old RII object.  Instead, it needs to remember

Manner, et al. Experimental [Page 27] RFC 5974 QoS NSLP October 2010

 the RII value so that it can match a RESPONSE message belonging to
 the RESERVE.  When it receives the RESPONSE, it forwards the RESPONSE
 upstream towards the RII originating node.
 In this example, the RESPONSE message is forwarded peer-to-peer along
 the reverse of the path that the RESERVE message took (using GIST
 path state), and so is seen by all the QNEs on this segment of the
 path.  It is only forwarded as far as the node that requested the
 RESPONSE originally.
 The reservation can subsequently be refreshed by sending further
 RESERVE messages containing the complete reservation information, as
 for the initial reservation.  The reservation can also be modified in
 the same way, by changing the QSPEC data to indicate a different set
 of resources to reserve.
 The overhead required to perform refreshes can be reduced, in a
 similar way to that proposed for RSVP in RFC 2961 [RFC2961].  Once a
 RESPONSE message has been received indicating the successful
 installation of a reservation, subsequent refreshing RESERVE messages
 can simply refer to the existing reservation, rather than including
 the complete reservation specification.

4.2. Sending a Query

 QUERY messages can be used to gather information from QNEs along the
 path.  For example, they can be used to find out what resources are
 available before a reservation is made.
 In order to perform a query along a path, the QNE constructs a QUERY
 message.  This message includes a QSPEC containing the actual query
 to be performed at QNEs along the path.  It also contains an RII
 object used to match the response back to the query, and an indicator
 of the query scope (next node, whole path, proxy).  The QUERY message
 is passed to GIST to forward it along the path.
 A QNE receiving a QUERY message should inspect it and create a new
 message based on it, with the query objects modified as required.
 For example, the query may request information on whether a flow can
 be admitted, and so a node processing the query might record the
 available bandwidth.  The new message is then passed to GIST for
 further forwarding (unless it knows it is the QNR or is the limit for
 the scope in the QUERY).
 At the QNR, a RESPONSE message must be generated if the QUERY message
 includes an RII object.  Various objects from the received QUERY
 message have to be copied into the RESPONSE message.  It is then
 passed to GIST to be forwarded peer-to-peer back along the path.

Manner, et al. Experimental [Page 28] RFC 5974 QoS NSLP October 2010

 Each QNE receiving the RESPONSE message should inspect the RII object
 to see if it 'belongs' to it (i.e., it was the one that originally
 created it).  If it does not, then it simply passes the message back
 to GIST to be forwarded upstream.
 If there was an error in processing a RESERVE, instead of an RII, the
 RESPONSE may carry an RSN.  Thus, a QNE must also be prepared to look
 for an RSN object if no RII was present, and act based on the error
 code set in the INFO-SPEC of the RESPONSE.

4.3. Basic Receiver-Initiated Reservation

 As described in the NSIS framework [RFC4080], in some signaling
 applications, a node at one end of the data flow takes responsibility
 for requesting special treatment -- such as a resource reservation --
 from the network.  Both ends then agree whether sender- or receiver-
 initiated reservation is to be done.  In case of a receiver-initiated
 reservation, both ends agree whether a "One Pass With Advertising"
 (OPWA) [opwa95] model is being used.  This negotiation can be
 accomplished using mechanisms that are outside the scope of NSIS.
 To make a receiver-initiated reservation, the QNR constructs a QUERY
 message, which MUST contain a QSPEC object from its chosen QoS model
 (see Figure 8).  The QUERY must have the RESERVE-INIT flag set.  This
 QUERY message does not need to trigger a RESPONSE message and
 therefore, the QNI must not include the RII object (Section 5.4.2) in
 the QUERY message.  The QUERY message may be used to gather
 information along the path, which is carried by the QSPEC object.  An
 example of such information is the "One Pass With Advertising" (OPWA)
 model [opwa95].  This QUERY message causes GIST reverse-path state to
 be installed.

Manner, et al. Experimental [Page 29] RFC 5974 QoS NSLP October 2010

  QNR        QNE        QNE        QNI
 sender                          receiver
   |          |          |          |
   | QUERY    |          |          |
   +--------->|          |          |
   |          | QUERY    |          |
   |          +--------->|          |
   |          |          | QUERY    |
   |          |          +--------->|
   |          |          |          |
   |          |          | RESERVE  |
   |          |          |<---------+
   |          | RESERVE  |          |
   |          |<---------+          |
   | RESERVE  |          |          |
   |<---------+          |          |
   |          |          |          |
   | RESPONSE |          |          |
   +--------->|          |          |
   |          | RESPONSE |          |
   |          +--------->|          |
   |          |          | RESPONSE |
   |          |          +--------->|
   |          |          |          |
            Figure 8: Basic Receiver-Initiated Reservation
 The QUERY message is transported by GIST to the next downstream QoS
 NSLP node.  There, it is delivered to the QoS NSLP processing, which
 examines the message.  The exact processing also takes into account
 the QoS model being used and may include gathering information on
 path characteristics that may be used to predict the end-to-end QoS.
 The QNE generates a new QUERY message (usually based on the one
 received).  This is passed to GIST, which forwards it to the next
 QNE.  The same processing is performed at further QNEs along the
 path, up to the flow receiver.  The receiver detects that this QUERY
 message carries the RESERVE-INIT flag and by using the information
 contained in the received QUERY message, such as the QSPEC,
 constructs a RESERVE message.
 The RESERVE is forwarded peer-to-peer along the reverse of the path
 that the QUERY message took (using GIST reverse-path state).  Similar
 to the sender-initiated approach, any node may include an RII in its
 RESERVE messages.  The RESPONSE is sent back to confirm that the
 resources are set up.  The reservation can subsequently be refreshed
 with RESERVE messages in the upstream direction.

Manner, et al. Experimental [Page 30] RFC 5974 QoS NSLP October 2010

4.4. Bidirectional Reservations

 The term "bidirectional reservation" refers to two different cases
 that are supported by this specification:
 o  Binding two sender-initiated reservations together, e.g., one
    sender-initiated reservation from QNE A to QNE B and another one
    from QNE B to QNE A (Figure 9).
 o  Binding a sender-initiated and a receiver-initiated reservation
    together, e.g., a sender-initiated reservation from QNE A towards
    QNE B, and a receiver-initiated reservation from QNE A towards QNE
    B for the data flow in the opposite direction (from QNE B to QNE
    A).  This case is particularly useful when one end of the
    communication has all required information to set up both sessions
    (Figure 10).
 Both ends have to agree on which bidirectional reservation type they
 need to use.  This negotiation can be accomplished using mechanisms
 that are outside the scope of NSIS.
 The scenario with two sender-initiated reservations is shown in
 Figure 9.  Note that RESERVE messages for both directions may visit
 different QNEs along the path because of asymmetric routing.  Both
 directions of the flows are bound by inserting the BOUND-SESSION-ID
 object at the QNI and QNR.  RESPONSE messages are optional and not
 shown in the picture for simplicity.
    A          QNE        QNE        B
    |          |  FLOW-1  |          |
    |===============================>|
    |RESERVE-1 |          |          |
 QNI+--------->|RESERVE-1 |          |
    |          +-------------------->|QNR
    |          |          |          |
    |          |  FLOW-2  |          |
    |<===============================|
    |          |          |RESERVE-2 |
    |  RESERVE-2          |<---------+QNI
 QNR|<--------------------+          |
    |          |          |          |
    Figure 9: Bidirectional Reservation for Sender+Sender Scenario

Manner, et al. Experimental [Page 31] RFC 5974 QoS NSLP October 2010

 The scenario with a sender-initiated and a receiver-initiated
 reservation is shown in Figure 10.  In this case, QNI A sends out two
 RESERVE messages, one for the sender-initiated and one for the
 receiver-initiated reservation.  Note that the sequence of the two
 RESERVE messages may be interleaved.
        A          QNE        QNE        B
        |          |  FLOW-1  |          |
        |===============================>|
        |RESERVE-1 |          |          |
     QNI+--------->|RESERVE-1 |          |
        |          +-------------------->|QNR
        |          |          |          |
        |          |  FLOW-2  |          |
        |<===============================|
        |          |          |  QUERY-2 |
        |          |  QUERY-2 |<---------+QNR
     QNI|<--------------------+          |
        |          |          |          |
        |RESERVE-2 |          |          |
     QNI+--------->|RESERVE-2 |          |
        |          +-------------------->|QNR
        |          |          |          |
   Figure 10: Bidirectional Reservation for Sender+Receiver Scenario

Manner, et al. Experimental [Page 32] RFC 5974 QoS NSLP October 2010

4.5. Aggregate Reservations

 In order to reduce signaling and per-flow state in the network, the
 reservations for a number of flows may be aggregated.
 QNI        QNE      QNE/QNI'     QNE'    QNR'/QNE      QNR
                   aggregator           deaggregator
  |          |          |          |          |          |
  | RESERVE  |          |          |          |          |
  +--------->|          |          |          |          |
  |          | RESERVE  |          |          |          |
  |          +--------->|          |          |          |
  |          |          | RESERVE  |          |          |
  |          |          +-------------------->|          |
  |          |          | RESERVE' |          |          |
  |          |          +=========>| RESERVE' |          |
  |          |          |          +=========>| RESERVE  |
  |          |          |          |          +--------->|
  |          |          |          | RESPONSE'|          |
  |          |          | RESPONSE'|<=========+          |
  |          |          |<=========+          |          |
  |          |          |          |          | RESPONSE |
  |          |          |          | RESPONSE |<---------+
  |          |          |<--------------------+          |
  |          | RESPONSE |          |          |          |
  |          |<---------+          |          |          |
  | RESPONSE |          |          |          |          |
  |<---------+          |          |          |          |
  |          |          |          |          |          |
  |          |          |          |          |          |
       Figure 11: Sender-Initiated Reservation with Aggregation
 An end-to-end per-flow reservation is initiated with the messages
 shown in Figure 11 as "RESERVE".
 At the aggregator, a reservation for the aggregated flow is initiated
 (shown in Figure 11 as "RESERVE'").  This may use the same QoS model
 as the end-to-end reservation but has an MRI identifying the
 aggregated flow (e.g., tunnel) instead of for the individual flows.
 This document does not specify how the QSPEC of the aggregate session
 can be derived from the QSPECs of the end-to-end sessions.
 The messages used for the signaling of the individual reservation
 need to be marked such that the intermediate routers will not inspect
 them.  In the QoS NSLP, the following marking policy is applied; see
 also RFC 3175.

Manner, et al. Experimental [Page 33] RFC 5974 QoS NSLP October 2010

 All routers use essentially the same algorithm for which messages
 they process, i.e., all messages at aggregation level 0.  However,
 messages have their aggregation level incremented on entry to an
 aggregation region and decremented on exit.  In this technique, the
 interior routers are not required to do any rewriting of the RAO
 values.  However, the aggregating/deaggregating routers must
 distinguish the interfaces and associated aggregation levels.  These
 routers also perform message rewriting at these boundaries.
 In particular, the Aggregator performs the marking by modifying the
 QoS NSLP default NSLPID value to an NSLPID predefined value; see
 Section 6.6.  A RAO value is then uniquely derivable from each
 predefined NSLPID.  However, the RAO does not have to have a one-to-
 one relation to a specific NSLPID.
           Aggregator                    Deaggregator
              +---+     +---+     +---+     +---+
              |QNI|-----|QNE|-----|QNE|-----|QNR|         aggregate
              +---+     +---+     +---+     +---+         reservation
 +---+     +---+     .....     .....     +---+     +---+
 |QNI|-----|QNE|-----.   .-----.   .-----|QNE|-----|QNR|  end-to-end
 +---+     +---+     .....     .....     +---+     +---+  reservation
                  Figure 12: Reservation Aggregation
 The deaggregator acts as the QNR for the aggregate reservation.
 Session binding information carried in the RESERVE message enables
 the deaggregator to associate the end-to-end and aggregate
 reservations with one another (using the BOUND-SESSION-ID).
 The key difference between this example and the one shown in
 Section 4.7.1 is that the flow identifier for the aggregate is
 expected to be different to that for the end-to-end reservation.  The
 aggregate reservation can be updated independently of the per-flow
 end-to-end reservations.

4.6. Message Binding

 Section 4.5 sketches the interaction of an aggregated end-to-end flow
 and an aggregate.  For this scenario, and probably others, it is
 useful to have a method for synchronizing the exchanges of signaling
 messages of different sessions.  This can be used to speed up
 signaling, because some message exchanges can be started
 simultaneously and can be processed in parallel until further
 processing of a message from one particular session depends on

Manner, et al. Experimental [Page 34] RFC 5974 QoS NSLP October 2010

 another message from a different session.  For instance, Figure 11
 shows a case where inclusion of a new reservation requires that the
 capacity of the encompassing aggregate be increased first.  So the
 RESERVE (bound message) for the individual flow arriving at the
 deaggregator should wait until the RESERVE' (binding message) for the
 aggregate arrived successfully (otherwise, the individual flow cannot
 be included in the existing aggregate and cannot be admitted).
 Another alternative would be to increase the aggregate first and then
 to reserve resources for a set of aggregated individual flows.  In
 this case, the binding and synchronization between the (RESERVE and
 RESERVE') messages are not needed.
 A message binding may be used (depending an the aggregators policy)
 as follows: a QNE (aggregator QNI' in Figure 14) generates randomly a
 128-bit MSG-ID (same rules apply as for generating a SESSION-ID) and
 includes it as BOUND-MSG-ID object into the bound signaling message
 (RESERVE (1) in Figure 13) that should wait for the arrival of a
 related binding signaling message (RESERVE' (3) in Figure 13) that
 carries the associated MSG-ID object.  The BOUND-SESSION-ID should
 also be set accordingly.  Only one MSG-ID or BOUND-MSG-ID object per
 message is allowed.  If the dependency relation between the two
 messages is bidirectional, then the Message_Binding_Type flag is SET
 (value is 1).  Otherwise, the Message_Binding_Type flag is UNSET.  In
 most cases, an RII object must be included in order to get a
 corresponding RESPONSE back.
 Depending on the arrival sequence of the bound signaling message
 (RESERVE (1) in Figure 13) and the "triggering" binding signaling
 message (RESERVE' (3) in Figure 13), different situations can be
 identified:
 o  The bound signaling (RESERVE (1)) arrives first.  The receiving
    QNE enqueues (probably after some pre-processing) the signaling
    (RESERVE (1)) message for the corresponding session.  It also
    starts a MsgIDWait timer in order to discard the message in case
    the related "triggering" message (RESERVE' in Figure 13) does not
    arrive.  The timeout period for this time SHOULD be set to the
    default retransmission timeout period (QOSNSLP_REQUEST_RETRY).  In
    case a retransmitted RESERVE message arrives before the timeout,
    it will simply override the waiting message (i.e., the latter is
    discarded, and the new message is now waiting with the MsgIDWait
    timer being reset).
 At the same time, the "triggering" message including a MSG-ID object,
 carrying the same value as the BOUND-MSG-ID object is sent by the
 same initiating QNE (QNI' in Figure 13).  The intermediate QNE' sees
 the MSG-ID object, but can determine that it is not the endpoint for
 the session (QNR') and therefore simply forwards the message after

Manner, et al. Experimental [Page 35] RFC 5974 QoS NSLP October 2010

 normal processing.  The receiving QNE (QNR') as endpoint for the
 aggregate session (i.e., deaggregator) interprets the MSG-ID object
 and looks for a corresponding waiting message with a BOUND-MSG-ID of
 the same value whose waiting condition is satisfied now.  Depending
 on successful processing of the RESERVE' (3), processing of the
 waiting RESERVE will be resumed, and the MsgIDWait timer will be
 stopped as soon as the related RESERVE' arrived.
    QNI        QNE      QNE/QNI'     QNE'    QNR'/QNE      QNR
                      aggregator           deaggregator
     |          |          |          |          |          |
     | RESERVE  |          |          |          |          |
     +--------->|          |          |          |          |
     |          | RESERVE  |          |          |          |
     |          +--------->|          |          |          |
     |          |          | RESERVE  |          |          |
     |          |          |   (1)    |          |          |
     |          |          +-------------------->|          |
     |          |          | RESERVE' |          |          |
     |          |          |   (2)    |          |          |
     |          |          +=========>| RESERVE' |          |
     |          |          |          |   (3)    |          |
     |          |          |          +=========>| RESERVE  |
     |          |          |          |          |   (4)    |
     |          |          |          |          +--------->|
     |          |          |          | RESPONSE'|          |
     |          |          | RESPONSE'|<=========+          |
     |          |          |<=========+          |          |
     |          |          |          |          | RESPONSE |
     |          |          |          | RESPONSE |<---------+
     |          |          |<--------------------+          |
     |          | RESPONSE |          |          |          |
     |          |<---------+          |          |          |
     | RESPONSE |          |          |          |          |
     |<---------+          |          |          |          |
     |          |          |          |          |          |
     |          |          |          |          |          |
 (1):     RESERVE:  SESSION-ID=F, BOUND-MSG-ID=x, BOUND-SESSION-ID=A
 (2)+(3): RESERVE': SESSION-ID=A, MSG-ID=x
 (4):     RESERVE:  SESSION-ID=F  (MSG-ID object was removed)
             Figure 13: Example for Using Message Binding

Manner, et al. Experimental [Page 36] RFC 5974 QoS NSLP October 2010

 Several further cases have to be considered in this context:
 o  "Triggering message" (3) arrives before waiting (bound) message
    (1): In this case, the processing of the triggering message
    depends on the value of the Message_Binding_Type flag.  If
    Message_Binding_Type is UNSET (value is 0), then the triggering
    message can be processed normally, but the MSG-ID and the result
    (success or failure) should be saved for the waiting message.
    Thus, the RESPONSE' can be sent by the QNR' immediately.  If the
    waiting message (1) finally arrives at the QNR', it can be
    detected that the waiting condition was already satisfied because
    the triggering message already arrived earlier.  If
    Message_Binding_Type is SET (value is 1), then the triggering
    message interprets the MSG-ID object and looks for the
    corresponding waiting message with a BOUND-MSG-ID of the same
    value, which in this case has not yet arrived.  It then starts a
    MsgIDWait timer in order to discard the message in case the
    related message (RESERVE (1) in Figure 14) does not arrive.
    Depending on successful processing of the RESERVE (1), processing
    of the waiting RESERVE' will be resumed, the MsgIDWait timer will
    be stopped as soon as the related RESERVE arrives and the
    RESPONSE' can be sent by the QNR' towards the QNI'.
 o  The "triggering message" (3) does not arrive at all: this may be
    due to message loss (which will cause a retransmission by the QNI'
    if the RII object is included) or due to a reservation failure at
    an intermediate node (QNE' in the example).  The MsgIDWait timeout
    will then simply discard the waiting message at QNR'.  In this
    case, the QNR' MAY send a RESPONSE message towards the QNI
    informing it that the synchronization of the two messages has
    failed.
 o  Retransmissions should use the same MSG-ID because usually only
    one of the two related messages is retransmitted.  As mentioned
    above: retransmissions will only occur if the RII object is set in
    the RESERVE.  If a retransmitted message with a MSG-ID arrives
    while a bound message with the same MSG-ID is still waiting, the
    retransmitted message will replace the bound message.
 For a receiving node, there are conceptually two lists indexed by
 message IDs.  One list contains the IDs and results of triggering
 messages (those carrying a MSG-ID object), the other list contains
 the IDs and message contents of the bound waiting messages (those who
 carried a BOUND-MSG-ID).  The former list is used when a triggering
 message arrives before the bound message.  The latter list is used
 when a bound message arrives before a triggering message.

Manner, et al. Experimental [Page 37] RFC 5974 QoS NSLP October 2010

4.7. Reduced-State or Stateless Interior Nodes

 This example uses a different QoS model within a domain, in
 conjunction with GIST and NSLP functionality that allows the interior
 nodes to avoid storing GIST and QoS NSLP state.  As a result, the
 interior nodes only store the QSPEC-related reservation state or even
 no state at all.  This allows the QoS model to use a form of
 "reduced-state" operation, where reservation states with a coarser
 granularity (e.g., per-class) are used, or a "stateless" operation
 where no QoS NSLP state is needed (or created).  This is useful,
 e.g., for measurement-based admission control schemes.
 The key difference between this example and the use of different QoS
 models in Section 4.5 is the transport characteristics for the
 reservation, i.e., GIST can be used in a different way for the edge-
 to-edge and hop-by-hop sessions.  The reduced-state reservation can
 be updated independently of the per-flow end-to-end reservations.

4.7.1. Sender-Initiated Reservation

 The QNI initiates a RESERVE message (see Figure 14).  At the QNEs on
 the edges of the stateless or reduced-state region, the processing is
 different and the nodes support two QoS models.  At the ingress, the
 original RESERVE message is forwarded but ignored by the stateless or
 reduced-state nodes.  This is accomplished by marking this message at
 the ingress, i.e., modifying the QoS NSLP default NSLPID value to an
 NSLPID predefined value (see Section 4.6).  The egress must reassign
 the QoS NSLP default NSLPID value to the original end-to-end RESERVE
 message.  An example of such operation is given in [RFC5977].
 The egress node is the next QoS-NSLP hop for the end-to-end RESERVE
 message.  Reliable GIST transfer mode can be used between the ingress
 and egress without requiring GIST state in the interior.  At the
 egress node, the RESERVE message is then forwarded normally.
 At the ingress, a second RESERVE' message is also built (Figure 14).
 This makes use of a QoS model suitable for a reduced-state or
 stateless form of operation (such as the RMD per-hop reservation).
 Since the original RESERVE and the RESERVE' messages are addressed
 identically, the RESERVE' message also arrives at the same egress QNE
 that was also traversed by the RESERVE message.  Message binding is
 used to synchronize the messages.
 When processed by interior (stateless) nodes, the QoS NSLP processing
 exercises its options to not keep state wherever possible, so that no
 per-flow QoS NSLP state is stored.  Some state, e.g., per class, for
 the QSPEC-related data may be held at these interior nodes.  The QoS
 NSLP also requests that GIST use different transport characteristics

Manner, et al. Experimental [Page 38] RFC 5974 QoS NSLP October 2010

 (e.g., sending of messages in unreliable GIST transfer mode).  It
 also requests the local GIST processing not to retain messaging
 association state or reverse message routing state.
 Nodes, such as those in the interior of the stateless or reduced-
 state domain, that do not retain reservation state cannot send back
 RESPONSE messages (and so cannot use the refresh reduction
 extension).
 At the egress node, the RESERVE' message is interpreted in
 conjunction with the reservation state from the end-to-end RESERVE
 message (using information carried in the message to correlate the
 signaling flows).  The RESERVE message is only forwarded further if
 the processing of the RESERVE' message was successful at all nodes in
 the local domain; otherwise, the end-to-end reservation is regarded
 as having failed to be installed.  This can be realized by using the
 message binding functionality described in Section 4.6 to synchronize
 the arrival of the bound signaling message (end-to-end RESERVE) and
 the binding signaling message (local RESERVE').
         QNE             QNE             QNE            QNE
       ingress         interior        interior        egress
   GIST stateful  GIST stateless  GIST stateless  GIST stateful
          |               A               B              |
  RESERVE |               |               |              |
 -------->| RESERVE       |               |              |
          +--------------------------------------------->|
          | RESERVE'      |               |              |
          +-------------->|               |              |
          |               | RESERVE'      |              |
          |               +-------------->|              |
          |               |               | RESERVE'     |
          |               |               +------------->|
          |               |               |  RESPONSE'   |
          |<---------------------------------------------+
          |               |               |              | RESERVE
          |               |               |              +-------->
          |               |               |              | RESPONSE
          |               |               |              |<--------
          |               |               |     RESPONSE |
          |<---------------------------------------------+
  RESPONSE|               |               |              |
 <--------|               |               |              |
  Figure 14: Sender-Initiated Reservation with Reduced-State Interior
                                 Nodes

Manner, et al. Experimental [Page 39] RFC 5974 QoS NSLP October 2010

 Resource management errors in the example above are reflected in the
 QSPEC and QoS model processing.  For example, if the RESERVE' fails
 at QNE A, it cannot send an error message back to the ingress QNE.
 Thus, the RESERVE' is forwarded along the intended path, but the
 QSPEC includes information for subsequent QNEs telling them an error
 happened upstream.  It is up to the QoS model to determine what to
 do.  Eventually, the RESERVE' will reach the egress QNE, and again,
 the QoS model then determines the response.

4.7.2. Receiver-Initiated Reservation

 Since NSLP neighbor relationships are not maintained in the reduced-
 state region, only sender-initiated signaling can be supported within
 the reduced-state region.  If a receiver-initiated reservation over a
 stateless or reduced-state domain is required, this can be
 implemented as shown in Figure 15.
         QNE            QNE            QNE
       ingress        interior        egress
   GIST stateful  GIST stateless  GIST stateful
          |               |               |
  QUERY   |               |               |
 -------->| QUERY         |               |
          +------------------------------>|
          |               |               | QUERY
          |               |               +-------->
          |               |               | RESERVE
          |               |               |<--------
          |               |      RESERVE  |
          |<------------------------------+
          | RESERVE'      | RESERVE'      |
          |-------------->|-------------->|
          |               |     RESPONSE' |
          |<------------------------------+
  RESERVE |               |               |
 <--------|               |               |
 Figure 15: Receiver-Initiated Reservation with Reduced-State Interior
                                 Nodes
 The RESERVE message that is received by the egress QNE of the
 stateless domain is sent transparently to the ingress QNE (known as
 the source of the QUERY message).  When the RESERVE message reaches
 the ingress, the ingress QNE needs to send a sender-initiated
 RESERVE' over the stateless domain.  The ingress QNE needs to wait
 for a RESPONSE'.  If the RESPONSE' notifies that the reservation was
 accomplished successfully, then the ingress QNE sends a RESERVE
 message further upstream.

Manner, et al. Experimental [Page 40] RFC 5974 QoS NSLP October 2010

4.8. Proxy Mode

 Besides the sender- and receiver-initiated reservations, the QoS NSLP
 includes a functionality we refer to as Proxy Mode.  Here a QNE is
 set by administrator assignment to work as a proxy QNE (P-QNE) for a
 certain region, e.g., for an administrative domain.  A node
 initiating the signaling may set the PROXY scope flag to indicate
 that the signaling is meant to be confined within the area controlled
 by the proxy, e.g., the local access network.
 The Proxy Mode has two uses.  First, it allows the QoS NSLP signaling
 to be confined to a pre-defined section of the path.  Second, it
 allows a node to make reservations for an incoming data flow.
 For outgoing data flows and sender-initiated reservations, the end
 host is the QNI, and sends a RESERVE with the PROXY scope flag set.
 The P-QNE is the QNR; it will receive the RESERVE, notice the PROXY
 scope flag is set and reply with a RESPONSE (if requested).  This
 operation is the same as illustrated in Figure 7.  The receiver-
 oriented reservation for outgoing flows works the same way as in
 Figure 8, except that the P-QNE is the QNI.
 For incoming data flows, the end host is the QNI, and it sends a
 RESERVE towards the data sender with the PROXY scope flag set.  Here
 the end host sets the MRI so that it indicates the end host as the
 receiver of the data, and sets the D-flag.
 GIST is able to send messages towards the data sender if there is
 existing message routing state or it is able to use the Upstream
 Q-mode Encapsulation.  In some cases, GIST will be unable to
 determine the appropriate next hop for the message, and so will
 indicate a failure to deliver it (by sending an error message).  This
 may occur, for example, if GIST attempts to determine an upstream
 next hop and there are multiple possible inbound routes that could be
 used.
 Bidirectional reservations can be used, as discussed in Section 4.4.
 The P-QNE will be the QNR or QNI for reservations.
 If the PROXY scope flag is 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.

Manner, et al. Experimental [Page 41] RFC 5974 QoS NSLP October 2010

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.

Manner, et al. Experimental [Page 42] RFC 5974 QoS NSLP October 2010

 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.

Manner, et al. Experimental [Page 43] RFC 5974 QoS NSLP October 2010

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.

Manner, et al. Experimental [Page 44] RFC 5974 QoS NSLP October 2010

 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.

Manner, et al. Experimental [Page 45] RFC 5974 QoS NSLP October 2010

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

Manner, et al. Experimental [Page 46] RFC 5974 QoS NSLP October 2010

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

Manner, et al. Experimental [Page 47] RFC 5974 QoS NSLP October 2010

 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.

Manner, et al. Experimental [Page 48] RFC 5974 QoS NSLP October 2010

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.

Manner, et al. Experimental [Page 49] RFC 5974 QoS NSLP October 2010

  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

Manner, et al. Experimental [Page 50] RFC 5974 QoS NSLP October 2010

 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

Manner, et al. Experimental [Page 51] RFC 5974 QoS NSLP October 2010

 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:

Manner, et al. Experimental [Page 52] RFC 5974 QoS NSLP October 2010

 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

Manner, et al. Experimental [Page 53] RFC 5974 QoS NSLP October 2010

 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

Manner, et al. Experimental [Page 54] RFC 5974 QoS NSLP October 2010

  • 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

Manner, et al. Experimental [Page 55] RFC 5974 QoS NSLP October 2010

  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.

Manner, et al. Experimental [Page 56] RFC 5974 QoS NSLP October 2010

 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

Manner, et al. Experimental [Page 57] RFC 5974 QoS NSLP October 2010

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

Manner, et al. Experimental [Page 58] RFC 5974 QoS NSLP October 2010

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.

Manner, et al. Experimental [Page 59] RFC 5974 QoS NSLP October 2010

     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.

Manner, et al. Experimental [Page 60] RFC 5974 QoS NSLP October 2010

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.

Manner, et al. Experimental [Page 61] RFC 5974 QoS NSLP October 2010

 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

Manner, et al. Experimental [Page 62] RFC 5974 QoS NSLP October 2010

 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.

Manner, et al. Experimental [Page 63] RFC 5974 QoS NSLP October 2010

 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:

Manner, et al. Experimental [Page 64] RFC 5974 QoS NSLP October 2010

 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.

5.3. Object Processing

 This section presents processing rules for individual QoS NSLP
 objects.

5.3.1. Reservation Sequence Number (RSN)

 A QNE's own RSN is a sequence number which applies to a particular
 signaling session (i.e., with a particular SESSION-ID).  It MUST be
 incremented for each new RESERVE message where the reservation for
 the session changes.  The RSN is manipulated using the serial number
 arithmetic rules from [RFC1982], which also defines wrapping rules
 and the meaning of 'equals', 'less than', and 'greater than' for
 comparing sequence numbers in a circular sequence space.
 The RSN starts at zero.  It is stored as part of the per-session
 state, and it carries on incrementing (i.e., it is not reset to zero)
 when a downstream peer change occurs.  (Note that Section 5.2.5.2
 provides some particular rules for use when a downstream peer
 changes.)
 The RSN object also contains an Epoch Identifier, which provides a
 method for determining when a peer has restarted (e.g., due to node
 reboot or software restart).  The exact method for providing this
 value is implementation defined.  Options include storing a serial
 number that is incremented on each restart, picking a random value on
 each restart, or using the restart time.
 On receiving a RESERVE message a QNE examines the Epoch Identifier to
 determine if the peer sending the message has restarted.  If the
 Epoch Identifier is different to that stored for the reservation then
 the RESERVE message MUST be treated as an updated reservation (even
 if the RSN is less than the current stored value), and the stored RSN
 and Epoch Identifier MUST be updated to the new values.

Manner, et al. Experimental [Page 65] RFC 5974 QoS NSLP October 2010

 When receiving a RESERVE message, a QNE uses the RSN given in the
 message to determine whether the state being requested is different
 to that already stored.  If the RSN is equal to that stored for the
 current reservation, the current state MUST be refreshed.  If the RSN
 is greater than the current stored value, the current reservation
 MUST be modified appropriately as specified in the QSPEC (provided
 that admission control and policy control succeed), and the stored
 RSN value updated to that for the new reservation.  If the RSN is
 greater than the current stored value and the RESERVE was a reduced
 refresh, the QNE SHOULD send upstream a transient error message "Full
 QSPEC required".  If the RSN is less than the current value, then it
 indicates an out-of-order message, and the RESERVE message MUST be
 discarded.
 If the QNE does not store per-session state (and so does not keep any
 previous RSN values), then it MAY ignore the value of the RSN.  It
 MUST also copy the same RSN into the RESERVE message (if any) that it
 sends as a consequence of receiving this one.

5.3.2. Request Identification Information (RII)

 A QNE sending QUERY or RESERVE messages may require a response to be
 sent.  It does so by including a Request Identification Information
 (RII) object.  When creating an RII object, the QNE MUST select the
 value for the RII such that it is probabilistically unique within the
 given session.  A RII object is typically set by the QNI.
 A number of choices are available when implementing this.
 Possibilities might include using a random value, or a node
 identifier together with a counter.  If the value collides with one
 selected by another QNE for a different QUERY, then RESPONSE messages
 may be incorrectly terminated, and may not be passed back to the node
 that requested them.
 The node that created the RII object MUST remember the value used in
 the RII in order to match back any RESPONSE it will receive.  The
 node SHOULD use a timer to identify situations where it has taken too
 long to receive the expected RESPONSE.  If the timer expires without
 receiving a RESPONSE, the node MAY perform a retransmission as
 discussed in Section 5.2.4.  In this case, the QNE MUST NOT generate
 any RESPONSE or NOTIFY message to notify this error.
 If an intermediate QNE wants to receive a response for an outgoing
 message, but the message already included an RII when it arrived, the
 QNE MUST NOT add a new RII object nor replace the old RII object, but
 MUST simply remember this RII in order to match a later RESPONSE
 message.  When it receives the RESPONSE, it forwards the RESPONSE
 upstream towards the RII originating node.  Note that only the node

Manner, et al. Experimental [Page 66] RFC 5974 QoS NSLP October 2010

 that originally created the RII can set up a retransmission timer.
 Thus, if an intermediate QNE decides to use the RII already contained
 in the message, it MUST NOT set up a retransmission timer, but rely
 on the retransmission timer set up by the QNE that inserted the RII.
 When receiving a message containing an RII object the node MUST send
 a RESPONSE if
    o The SCOPING flag is set ('next hop' scope),
    o The PROXY scope flag is set and the QNE is the P-QNE, or
    o This QNE is the last one on the path for the given session.
 and the QNE keeps per-session state for the given session.
 In the rare event that the QNE wants to request a response for a
 message that already included an RII, and this RII value conflicts
 with an existing RII value on the QNE, the node should interrupt the
 processing the message, send an error message upstream to indicate an
 RII collision, and request a retry with a new RII value.

5.3.3. BOUND-SESSION-ID

 As shown in the examples in Section 4, the QoS NSLP can relate
 multiple sessions together.  It does this by including the SESSION-ID
 from one session in a BOUND-SESSION-ID object in messages in another
 session.
 When receiving a message with a BOUND-SESSION-ID object, a QNE MUST
 copy the BOUND-SESSION-ID object into all messages it sends for the
 same session.  A QNE that stores per-session state MUST store the
 value of the BOUND-SESSION-ID.
 The BOUND-SESSION-ID is only indicative in nature.  However, a QNE
 implementation may use BOUND-SESSION-ID information to optimize
 resource allocation, e.g., for bidirectional reservations.  When
 receiving a teardown message (e.g., a RESERVE message with teardown
 semantics) for an aggregate reservation, the QNE may use this
 information to initiate a teardown for end-to-end sessions bound to
 the aggregate.  A QoS NSLP implementation MUST be ready to process
 more than one BOUND-SESSION-ID object within a single message.

5.3.4. REFRESH-PERIOD

 Refresh timer management values are carried by the REFRESH-PERIOD
 object, which has local significance only.  At the expiration of a
 "refresh timeout" period, each QNE independently examines its state

Manner, et al. Experimental [Page 67] RFC 5974 QoS NSLP October 2010

 and sends a refreshing RESERVE message to the next QNE peer where it
 is absorbed.  This peer-to-peer refreshing (as opposed to the QNI
 initiating a refresh that travels all the way to the QNR) allows QNEs
 to choose refresh intervals as appropriate for their environment.
 For example, it is conceivable that refreshing intervals in the
 backbone, where reservations are relatively stable, are much larger
 than in an access network.  The "refresh timeout" is calculated
 within the QNE and is not part of the protocol; however, it must be
 chosen to be compatible with the reservation lifetime as expressed by
 the REFRESH-PERIOD and with an assessment of the reliability of
 message delivery.
 The details of timer management and timer changes (slew handling and
 so on) are identical to the ones specified in Section 3.7 of RFC 2205
 [RFC2205].
 There are two time parameters relevant to each QoS NSLP state in a
 node: the refresh period R between generation of successive refreshes
 for the state by the neighbor node, and the local state's lifetime L.
 Each RESERVE message may contain a REFRESH-PERIOD object specifying
 the R value that was used to generate this (refresh) message.  This R
 value is then used to determine the value for L when the state is
 received and stored.  The values for R and L may vary from peer to
 peer.

5.3.5. INFO-SPEC

 The INFO-SPEC object is carried by the RESPONSE and NOTIFY messages,
 and it is used to report a successful, an unsuccessful, or an error
 situation.  In case of an error situation, the error messages SHOULD
 be generated even if no RII object is included in the RESERVE or in
 the QUERY messages.  Note that when the TEAR flag is set in the
 RESERVE message an error situation SHOULD NOT trigger the generation
 of a RESPONSE message.
 Six classes of INFO-SPEC objects are identified and specified in
 Section 5.1.3.6.  The message processing rules for each class are
 defined below.
 A RESPONSE message MUST carry INFO-SPEC objects towards the QNI.  The
 RESPONSE message MUST be forwarded unconditionally up to the QNI.
 The actions that SHOULD be undertaken by the QNI that receives the
 INFO-SPEC object are specified by the local policy of the QoS model
 supported by this QNE.  The default action is that the QNI that
 receives the INFO-SPEC object SHOULD NOT trigger any other QoS NSLP
 procedure.

Manner, et al. Experimental [Page 68] RFC 5974 QoS NSLP October 2010

 The Informational INFO-SPEC class MUST be generated by a stateful QoS
 NSLP QNE when an Informational error class is caught.  The
 Informational INFO-SPEC object MUST be carried by a RESPONSE or a
 NOTIFY message.
 In case of a unidirectional reservation, the Success INFO-SPEC class
 MUST be generated by a stateful QoS NSLP QNR when a RESERVE message
 is received and the reservation state installation or refresh
 succeeded.  In case of a bidirectional reservation, the INFO-SPEC
 object SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE
 message is received and the reservation state installation or refresh
 succeeded.  The Success INFO-SPEC object MUST be carried by a
 RESPONSE or a NOTIFY message.
 In case of a unidirectional reservation, the Protocol Error INFO-SPEC
 class MUST be generated by a stateful QoS NSLP QNE when a RESERVE or
 QUERY message is received by the QNE and a protocol error is caught.
 In case of a bidirectional reservation, the Protocol Error INFO-SPEC
 class SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE
 or QUERY message is received by the QNE and a protocol error is
 caught.  A RESPONSE message MUST carry this object, which MUST be
 forwarded unconditionally towards the upstream QNE that generated the
 RESERVE or QUERY message that triggered the generation of this INFO-
 SPEC object.  The default action for a stateless QoS NSLP QNE that
 detects such an error is that none of the QoS NSLP objects SHOULD be
 processed, and the RESERVE or QUERY message SHOULD be forwarded
 downstream.
 In case of a unidirectional reservation, the Transient Failure INFO-
 SPEC class MUST be generated by a stateful QoS NSLP QNE when a
 RESERVE or QUERY message is received by the QNE and one Transient
 failure error code is caught, or when an event happens that causes a
 transient error.  In case of a bidirectional reservation, the
 Transient Failure INFO-SPEC class SHOULD be generated by a stateful
 QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE
 and one Transient failure error code is caught.
 A RESPONSE message MUST carry this object, which MUST be forwarded
 unconditionally towards the upstream QNE that generated the RESERVE
 or QUERY message that triggered the generation of this INFO-SPEC
 object.  The transient RMF-related error MAY also be carried by a
 NOTIFY message.  The default action is that the QNE that receives
 this INFO-SPEC object SHOULD re-trigger the retransmission of the
 RESERVE or QUERY message that triggered the generation of the INFO-
 SPEC object.  The default action for a stateless QoS NSLP QNE that
 detects such an error is that none of the QoS NSLP objects SHOULD be
 processed and the RESERVE or QUERY message SHOULD be forwarded
 downstream.

Manner, et al. Experimental [Page 69] RFC 5974 QoS NSLP October 2010

 In case of a unidirectional reservation, the Permanent Failure INFO-
 SPEC class MUST be generated by a stateful QoS NSLP QNE when a
 RESERVE or QUERY message is received by a QNE and an internal or
 system error occurred, or authorization failed.  In case of a
 bidirectional reservation, the Permanent Failure INFO-SPEC class
 SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE or
 QUERY message is received by a QNE and an internal or system error
 occurred, or authorization failed.  A RESPONSE message MUST carry
 this object, which MUST be forwarded unconditionally towards the
 upstream QNE that generated the RESERVE or QUERY message that
 triggered this protocol error.  The internal, system, or permanent
 RMF-related errors MAY also be carried by a NOTIFY message.  The
 default action for a stateless QoS NSLP QNE that detects such an
 error is that none of the QoS NSLP objects SHOULD be processed and
 the RESERVE or QUERY message SHOULD be forwarded downstream.
 The QoS-specific error class may be used when errors outside the QoS
 NSLP itself occur that are related to the particular QoS model being
 used.  The processing rules of these errors are not specified in this
 document.

5.3.6. SESSION-ID-LIST

 A SESSION-ID-LIST is carried in RESERVE messages.  It is used in two
 cases, to refresh or to tear down the indicated sessions.  A SESSION-
 ID-LIST carries information about sessions that should be refreshed
 or torn down, in addition to the main (primary) session indicated in
 the RESERVE.
 If the primary SESSION-ID is not understood, the SESSION-ID-LIST
 object MUST NOT be processed.
 When a stateful QNE goes through the SESSION-ID-LIST, if it finds one
 or more unknown SESSION-ID values, it SHOULD construct an
 informational RESPONSE message back to the upstream stateful QNE with
 the error code for unknown SESSION-ID in SESSION-ID-LIST, and include
 all unknown SESSION-IDs in a SESSION-ID-LIST.
 If the RESERVE is a tear, for each session in the SESSION-ID-LIST,
 the stateful QNE MUST inform the RMF that the reservation is no
 longer required.  RSN values MUST also be interpreted in order to
 distinguish whether the tear down is valid, or whether it is
 referring to an old state, and, thus, should be silently discarded.
 If the RESERVE is a refresh, the stateful QNE MUST also process the
 RSN-LIST object as detailed in the next section.

Manner, et al. Experimental [Page 70] RFC 5974 QoS NSLP October 2010

 If the RESERVE is a tear, for each session in the SESSION-ID-LIST,
 the QNE MUST inform the RMF that the reservation is no longer
 required.  RSN values MUST be interpreted.
 Note that a stateless QNE cannot support summary or single reduced
 refreshes, and always needs full single refreshes.

5.3.7. RSN-LIST

 An RSN-LIST MUST be carried in RESERVE messages when a QNE wants to
 perform a refresh or teardown of several sessions with a single NSLP
 message.  The RSN-LIST object MUST be populated with RSN values of
 the same sessions and in the same order as indicated in the SESSION-
 ID-LIST.  Thus, entries in both objects at position X refer to the
 same session.
 If the primary session and RSN reference in the RESERVE were not
 understood, the stateful QNE MUST NOT process the RSN-LIST.  Instead,
 an error RESPONSE SHOULD be sent back to the upstream stateful QNE.
 On receiving an RSN-LIST object, the stateful QNE should check
 whether the number of items in the SESSION-ID-LIST and RSN-LIST
 objects match.  If there is a mismatch, the stateful QNE SHOULD send
 back a protocol error indicating a bad value in the object.
 While matching the RSN-LIST values to the SESSION-ID-LIST values, if
 one or more RSN values in the RSN-LIST are not in synch with the
 local values, the stateful QNE SHOULD construct an informational
 RESPONSE message with an error code for RSN mismatch in the RSN-LIST.
 The stateful QNE MUST include the erroneous SESSION-ID and RSN values
 in SESSION-ID-LIST and RSN-LIST objects in the RESPONSE.
 If no errors were found in processing the RSN-LIST, the stateful QNE
 refreshes the reservation states of all sessions -- the primary
 single session indicated in the refresh, and all sessions in the
 SESSION-ID-LIST.
 For each successfully processed session in the RESERVE, the stateful
 QNE performs a refresh of the reservation state.  Thus, even if some
 sessions were not in synch, the remaining sessions in the SESSION-ID-
 LIST and RSN-LIST are refreshed.

5.3.8. QSPEC

 The contents of the QSPEC depend on the QoS model being used.  A
 template for QSPEC objects can be found in [RFC5975].

Manner, et al. Experimental [Page 71] RFC 5974 QoS NSLP October 2010

 Upon reception, the complete QSPEC is passed to the Resource
 Management Function (RMF), along with other information from the
 message necessary for the RMF processing.  A QNE may also receive an
 INFO-SPEC that includes a partial or full QSPEC.  This will also be
 passed to the RMF.

5.4. Message Processing Rules

 This section provides rules for message processing.  Not all possible
 error situations are considered.  A general rule for dealing with
 erroneous messages is that a node should evaluate the situation
 before deciding how to react.  There are two ways to react to
 erroneous messages:
 a) Silently drop the message, or
 b) Drop the message, and reply with an error code to the sender.
 The default behavior, in order to protect the QNE from a possible
 denial-of-service attack, is to silently drop the message.  However,
 if the QNE is able to authenticate the sender, e.g., through GIST,
 the QNE may send a proper error message back to the neighbor QNE in
 order to let it know that there is an inconsistency in the states of
 adjacent QNEs.

5.4.1. RESERVE Messages

 The RESERVE message is used to manipulate QoS reservation state in
 QNEs.  A RESERVE message may create, refresh, modify, or remove such
 state.  A QNE sending a RESERVE MAY require a response to be sent by
 including a Request Identification Information (RII) object; see
 Section 5.3.2.
 RESERVE messages MUST only be sent towards the QNR.  A QNE that
 receives a RESERVE message checks the message format.  In case of
 malformed messages, the QNE MAY send a RESPONSE message with the
 appropriate INFO-SPEC.
 Before performing any state-changing actions, a QNE MUST determine
 whether the request is authorized.  The way to do this check depends
 on the authorization model being used.
 When the RESERVE is authorized, a QNE checks the COMMON-HEADER flags.
 If the TEAR flag is set, the message is a tearing RESERVE that
 indicates complete QoS NSLP state removal (as opposed to a
 reservation of zero resources).  On receiving such a RESERVE message,

Manner, et al. Experimental [Page 72] RFC 5974 QoS NSLP October 2010

 the QNE MUST inform the RMF that the reservation is no longer
 required.  The RSN value MUST be processed.  After this, there are
 two modes of operation:
 1.  If the tearing RESERVE did not include an RII, i.e., the QNI did
     not want a confirmation, the QNE SHOULD remove the QoS NSLP
     state.  It MAY signal to GIST (over the API) that reverse-path
     state for this reservation is no longer required.  Any errors in
     processing the tearing RESERVE SHOULD NOT be sent back towards
     the QNI since the upstream QNEs will already have removed their
     session states; thus, they are unable to do anything to the
     error.
 2.  If an RII was included, the stateful QNE SHOULD still keep the
     NSLP operational state until a RESPONSE for the tear going
     towards the QNI is received.  This operational state SHOULD be
     kept for one refresh interval, after which the NSLP operational
     state for the session is removed.  Depending on the QoS model,
     the tear message MAY include a QSPEC to further specify state
     removal.  If the QoS model requires a QSPEC, and none is
     provided, the QNE SHOULD reply with an error message and SHOULD
     NOT remove the reservation.
 If the tearing RESERVE includes a QSPEC, but none is required by the
 QoS model, the QNE MAY silently discard the QSPEC and proceed as if
 it did not exist in the message.  In general, a QoS NSLP
 implementation should carefully consider when an error message should
 be sent, and when not.  If the tearing RESERVE did not include an
 RII, then the upstream QNE has removed the RMF and NSLP states, and
 it will not be able to do anything to the error.  If an RII was
 included, the upstream QNE may still have the NSLP operational state,
 but no RMF state.
 If a QNE receives a tearing RESERVE for a session for which it still
 has the operational state, but the RMF state was removed, the QNE
 SHOULD accept the message and forward it downstream as if all is
 well.
 If the tearing RESERVE includes a SESSION-ID-LIST, the stateful QNE
 MUST process the object as described earlier in this document, and
 for each identified session, indicate to the RMF that the reservation
 is no longer required.
 If a QNE receives a refreshing RESERVE for a session for which it
 still has the operational state, but the RMF state was removed, the
 QNE MUST silently drop the message and not forward it downstream.

Manner, et al. Experimental [Page 73] RFC 5974 QoS NSLP October 2010

 As discussed in Section 5.2.5.2, to avoid incorrect removal of state
 after a rerouting event, a node receiving a RESERVE message that has
 the TEAR flag set and that does not come from the current peer QNE
 (identified by its SII) MUST be ignored and MUST NOT be forwarded.
 If the QNE has reservations that are bound and dependent to this
 session (they contain the SESSION-ID of this session in their BOUND-
 SESSION-ID object and use Binding Code 0x04), it MUST send a NOTIFY
 message for each of the reservations with an appropriate INFO-SPEC.
 If the QNE has reservations that are bound, but that they are not
 dependent to this session (the Binding Code in the BOUND-SESSION-ID
 object has one of the values: 0x01, 0x02, or 0x03), it MAY send a
 NOTIFY message for each of the reservations with an appropriate INFO-
 SPEC.  The QNE MAY elect to send RESERVE messages with the TEAR flag
 set for these reservations.
 The default behavior of a QNE that receives a RESERVE with a
 SESSION-ID for which it already has state installed but with a
 different flow ID is to replace the existing reservation (and to tear
 down the reservation on the old branch if the RESERVE is received
 with a different SII).
 In some cases, this may not be the desired behavior, so the QNI or a
 QNE MAY set the REPLACE flag in the common header to zero to indicate
 that the new session does not replace the existing one.
 A QNE that receives a RESERVE with the REPLACE flag set to zero but
 with the same SII will indicate REPLACE=0 to the RMF (where it will
 be used for the resource handling).  Furthermore, if the QNE
 maintains a QoS NSLP state, then it will also add the new flow ID in
 the QoS NSLP state.  If the SII is different, this means that the QNE
 is a merge point.  In that case, in addition to the operations
 specified above, the value REPLACE=0 is also indicating that a
 tearing RESERVE SHOULD NOT be sent on the old branch.
 When a QNE receives a RESERVE message with an unknown SESSION-ID and
 this message contains no QSPEC because it was meant as a refresh,
 then the node MUST send a RESPONSE message with an INFO-SPEC that
 indicates a missing QSPEC to the upstream peer ("Full QSPEC
 required").  The upstream peer SHOULD send a complete RESERVE (i.e.,
 one containing a QSPEC) on the new path (new SII).
 At a QNE, resource handling is performed by the RMF.  For sessions
 with the REPLACE flag set to zero, we assume that the QoS model
 includes directions to deal with resource sharing.  This may include
 adding the reservations or taking the maximum of the two or more
 complex mathematical operations.

Manner, et al. Experimental [Page 74] RFC 5974 QoS NSLP October 2010

 This resource-handling mechanism in the QoS model is also applicable
 to sessions that have different SESSION-IDs but that are related
 through the BOUND-SESSION-ID object.  Session replacement is not an
 issue here, but the QoS model may specify whether or not to let the
 sessions that are bound together share resources on common links.
 Finally, it is possible that a RESERVE is received with no QSPEC at
 all.  This is the case of a reduced refresh.  In this case, rather
 than sending a refreshing RESERVE with the full QSPEC, only the
 SESSION-ID and the RSN are sent to refresh the reservation.  Note
 that this mechanism just reduces the message size (and probably eases
 processing).  One RESERVE per session is still needed.  Such a
 reduced refresh may further include a SESSION-ID-LIST and RSN-LIST,
 which indicate further sessions to be refreshed along the primary
 session.  The processing of these objects was described earlier in
 this document.
 If the REPLACE flag is set, the QNE SHOULD update the reservation
 state according to the QSPEC contained in the message (if the QSPEC
 is missing, the QNE SHOULD indicate this error by replying with a
 RESPONSE containing the corresponding INFO-SPEC "Full QSPEC
 required").  It MUST update the lifetime of the reservation.  If the
 REPLACE flag is not set, a QNE SHOULD NOT remove the old reservation
 state if the SII that is passed by GIST over the API is different
 than the SII that was stored for this reservation.  The QNE MAY elect
 to keep sending refreshing RESERVE messages.
 If a stateful QoS NSLP QNE receives a RESERVE message with the BREAK
 flag set, then the BREAK flag of newly generated messages (e.g.,
 RESERVE or RESPONSE) MUST be set.  When a stateful QoS NSLP QNE
 receives a RESERVE message with the BREAK flag not set, then the IP-
 TTL and Original-TTL values in the GIST RecvMessage primitive MUST be
 monitored.  If they differ, it is RECOMMENDED to set the BREAK flag
 in newly generated messages (e.g., RESERVE or RESPONSE).  In
 situations where a QNE or a domain is able to provide QoS using other
 means (see Section 3.3.5), the BREAK flag SHOULD NOT be set.
 If the RESERVE message included an RII, and any of the following are
 true, the QNE MUST send a RESPONSE message:
 o  If the QNE is configured, for a particular session, to be a QNR,
 o  the SCOPING flag is set,
 o  the Proxy scope flag is set and the QNE is a P-QNE, or
 o  the QNE is the last QNE on the path to the destination.

Manner, et al. Experimental [Page 75] RFC 5974 QoS NSLP October 2010

 When a QNE receives a RESERVE message, its processing may involve
 sending out another RESERVE message.
 If a QNE has received a RESPONSE mandating the use of full refreshes
 from its downstream peer for a session, the QNE MUST continue to use
 full refresh messages.
 If the session of this message is bound to another session, then the
 RESERVE message MUST include the SESSION-ID of that other session in
 a BOUND-SESSION-ID object.  In the situation of aggregated tunnels,
 the aggregated session MAY not include the SESSION-ID of its bound
 sessions in BOUND-SESSION-ID(s).
 In case of receiver-initiated reservations, the RESERVE message must
 follow the same path that has been followed by the QUERY message.
 Therefore, GIST is informed, over the QoS NSLP/GIST API, to pass the
 message upstream, i.e., by setting GIST "D" flag; see GIST [RFC5971].
 The QNE MUST create a new RESERVE and send it to its next peer, when:
  1. A new resource setup was done,
  1. A new resource setup was not done, but the QOSM still defines that

a RESERVE must be propagated,

  1. The RESERVE is a refresh and includes a new MRI, or
  1. If the RESERVE-INIT flag is included in an arrived QUERY.
 If the QNE sent out a refresh RESERVE with the ACK-REQ flag set, and
 did not receive a RESPONSE from its immediate stateful peer within
 the retransmission period of QOSNSLP_RETRY_MAX, the QNE SHOULD send a
 NOTIFY to its immediate upstream stateful peer and indicate "Path
 truncated - Next peer dead" in the INFO-SPEC.  The ACK-REQ flag
 SHOULD NOT be added to a RESERVE that already include an RII object,
 since a confirmation from the QNR has already been requested.
 Finally, if a received RESERVE requested acknowledgement through the
 ACK-REQ flag in the COMMON HEADER flags and the processing of the
 message was successful, the stateful QNE SHOULD send back a RESPONSE
 with an INFO-SPEC carrying the acknowledgement success code.  The QNE
 MAY include the ACK-REQ flag in the next refresh message it will send
 for the session.  The use of the ACK-REQ-flag for diagnostic purposes
 is a policy issue.  An acknowledged refresh message can be used to
 probe the end-to-end path in order to check that it is still intact.

Manner, et al. Experimental [Page 76] RFC 5974 QoS NSLP October 2010

5.4.2. QUERY Messages

 A QUERY message is used to request information about the data path
 without making a reservation.  This functionality can be used to
 'probe' the network for path characteristics or for support of
 certain QoS models, or to initiate a receiver-initiated reservation.
 A QNE sending a QUERY indicates a request for a response by including
 a Request Identification Information (RII) object; see Section 5.3.2.
 A request to initiate a receiver-initiated reservation is done
 through the RESERVE-INIT flag; see Section 5.1.2.2.
 When a QNE receives a QUERY message the QSPEC is passed to the RMF
 for processing.  The RMF may return a modified QSPEC that is used in
 any QUERY or RESPONSE message sent out as a result of the QUERY
 processing.
 When processing a QUERY message, a QNE checks whether the RESERVE-
 INIT flag is set.  If the flag is set, the QUERY is used to install
 reverse-path state.  In this case, if the QNE is not the QNI, it
 creates a new QUERY message to send downstream.  The QSPEC MUST be
 passed to the RMF where it may be modified by the QoS-model-specific
 QUERY processing.  If the QNE is the QNI, the QNE creates a RESERVE
 message, which contains a QSPEC received from the RMF and which may
 be based on the received QSPEC.  If this node was not expecting to
 perform a receiver-initiated reservation, then an error MUST be sent
 back along the path.
 The QNE MUST generate a RESPONSE message and pass it back along the
 reverse of the path used by the QUERY if:
 o  an RII object is present,
 o  the QNE is the QNR,
 o  the SCOPING flag is set, or
 o  the PROXY scope flag is set, and the QNE is a P-QNE.
 If an RII object is present, and if the QNE is the QNR, the SCOPING
 flag is set or the PROXY scope flag is set and the QNE is a P-QNE,
 the QNE MUST generate a RESPONSE message and pass it back along the
 reverse of the path used by the QUERY.
 In other cases, the QNE MUST generate a QUERY message that is then
 forwarded further along the path using the same MRI, Session ID, and
 Direction as provided when the QUERY was received over the GIST API.

Manner, et al. Experimental [Page 77] RFC 5974 QoS NSLP October 2010

 The QSPEC to be used is that provided by the RMF as described
 previously.  When generating a QUERY to send out to pass the query
 further along the path, the QNE MUST copy the RII object (if present)
 unchanged into the new QUERY message.  A QNE that is also interested
 in the response to the query keeps track of the RII to identify the
 RESPONSE when it passes through it.
 Note that QUERY messages with the RESERVE-INIT flag set MUST be
 answered by the QNR.  This feature may be used, e.g., following
 handovers, to set up new path state in GIST and to request that the
 other party to send a RESERVE back on this new GIST path.
 If a stateful QoS NSLP QNE receives a QUERY message with the RESERVE-
 INIT flag and BREAK flag set, then the BREAK flag of newly generated
 messages (e.g., QUERY, RESERVE, or RESPONSE) MUST be set.  When a
 stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT
 flag set and BREAK flag not set, then the IP-TTL and Original-TTL
 values in GIST RecvMessage primitive MUST be monitored.  If they
 differ, it is RECOMMENDED to set the BREAK flag in newly generated
 messages (e.g., QUERY, RESERVE, or RESPONSE).  In situations where a
 QNE or a domain is able to provide QoS using other means (see
 Section 3.3.5), the BREAK flag SHOULD NOT be set.
 Finally, if a received QUERY requested acknowledgement through the
 ACK-REQ flag in the COMMON HEADER flags and the processing of the
 message was successful, the stateful QNE SHOULD send back a RESPONSE
 with an INFO-SPEC carrying the acknowledgement success code.

5.4.3. RESPONSE Messages

 The RESPONSE message is used to provide information about the result
 of a previous QoS NSLP message, e.g., confirmation of a reservation
 or information resulting from a QUERY.  The RESPONSE message does not
 cause any state to be installed, but may cause state(s) to be
 modified, e.g., if the RESPONSE contains information about an error.
 A RESPONSE message MUST be sent when the QNR processes a RESERVE or
 QUERY message containing an RII object or if the QNE receives a
 scoped RESERVE or a scoped QUERY.  In this case, the RESPONSE message
 MUST contain the RII object copied from the RESERVE or the QUERY.
 Also, if there is an error in processing a received RESERVE, a
 RESPONSE is sent indicating the nature of the error.  In this case,
 the RII and RSN, if available, MUST be included in the RESPONSE.
 On receipt of a RESPONSE message containing an RII object, the
 stateful QoS NSLP QNE MUST attempt to match it to the outstanding
 response requests for that signaling session.  If the match succeeds,
 then the RESPONSE MUST NOT be forwarded further along the path if it

Manner, et al. Experimental [Page 78] RFC 5974 QoS NSLP October 2010

 contains an Informational or Success INFO-SPEC class.  If the QNE did
 not insert this RII itself, it must forward the RESPONSE to the next
 peer.  Thus, for RESPONSEs indicating success, forwarding should only
 stop if the QNE inserted the RII by itself.  If the RESPONSE carries
 an INFO-SPEC indicating an error, forwarding SHOULD continue upstream
 towards the QNI by using RSNs as described in the next paragraph.
 On receipt of a RESPONSE message containing an RSN object, a stateful
 QoS NSLP QNE MUST compare the RSN to that of the appropriate
 signaling session.  If the match succeeds, then the INFO-SPEC MUST be
 processed.  If the INFO-SPEC object is used to send error
 notifications then the node MUST use the stored upstream peer RSN
 value, associated with the same session, and forward the RESPONSE
 message further along the path towards the QNI.
 If the INFO-SPEC is not used to notify error situations (see above),
 then if the RESPONSE message carries an RSN, the message MUST NOT be
 forwarded further along the path.
 If there is no match for RSN, the message SHOULD be silently dropped.
 On receipt of a RESPONSE message containing neither an RII nor an RSN
 object, the RESPONSE MUST NOT be forwarded further along the path.
 In the typical case, RESPONSE messages do not change the states
 installed in intermediate QNEs.  However, depending on the QoS model,
 there may be situations where states are affected, e.g.,
  1. if the RESPONSE includes an INFO-SPEC describing an error

situation resulting in reservations to be removed, or

  1. the QoS model allows a QSPEC to define [min,max] limits on the

resources requested, and downstream QNEs gave less resources than

    their upstream nodes, which means that the upstream nodes may
    release a part of the resource reservation.
 If a stateful QoS NSLP QNE receives a RESPONSE message with the BREAK
 flag set, then the BREAK flag of newly generated message (e.g.,
 RESPONSE) MUST be set.

5.4.4. NOTIFY Messages

 NOTIFY messages are used to convey information to a QNE
 asynchronously.  NOTIFY messages do not cause any state to be
 installed.  The decision to remove state depends on the QoS model.
 The exact operation depends on the QoS model.  A NOTIFY message does

Manner, et al. Experimental [Page 79] RFC 5974 QoS NSLP October 2010

 not directly cause other messages to be sent.  NOTIFY messages are
 sent asynchronously, rather than in response to other messages.  They
 may be sent in either direction (upstream or downstream).
 A special case of synchronous NOTIFY is when the upstream QNE is
 asked to use reduced refresh by setting the appropriate flag in the
 RESERVE.  The QNE receiving such a RESERVE MUST reply with a NOTIFY
 and a proper INFO-SPEC code indicating whether the QNE agrees to use
 reduced refresh between the upstream QNE.
 The Transient error code 0x07 "Reservation preempted" is sent to the
 QNI whose resources were preempted.  The NOTIFY message carries
 information to the QNI that one QNE no longer has a reservation for
 the session.  It is up to the QNI to decide what to do based on the
 QoS model being used.  The QNI would normally tear down the preempted
 reservation by sending a RESERVE with the TEAR flag set using the SII
 of the preempted reservation.  However, the QNI can follow other
 procedures as specified in its QoS Model.  More discussion on
 preemption can be found in the QSPEC Template [RFC5975] and the
 individual QoS Model specifications.

6. IANA Considerations

 This section provides guidance to the Internet Assigned Numbers
 Authority (IANA) regarding registration of values related to the QoS
 NSLP, in accordance with BCP 26, RFC 5226 [RFC5226].
 Per QoS NSLP, IANA has created a number of new registries:
  1. QoS NSLP Message Types
  2. QoS NSLP Binding Codes
  3. QoS NSLP Error Classes
    1. Informational Error Codes
    2. Success Error Codes
    3. Protocol Error Codes
    4. Transient Failure Codes
    5. Permanent Failure Codes
  4. QoS NSLP Error Source Identifiers
 IANA has also registered new values in a number of registries:
  1. NSLP Object Types
  2. NSLP Identifiers (under GIST Parameters)
  3. Router Alert Option Values (IPv4 and IPv6)

Manner, et al. Experimental [Page 80] RFC 5974 QoS NSLP October 2010

6.1. QoS NSLP Message Type

 The QoS NSLP Message Type is an 8-bit value.  This specification
 defines four QoS NSLP message types, which form the initial contents
 of this registry: RESERVE (0x01), QUERY (0x02), RESPONSE (0x03), and
 NOTIFY (0x04).
 The value 0 is reserved.  Values 240 to 255 are for Experimental/
 Private Use.  The registration procedure is IETF Review.
 When a new message type is defined, any message flags used with it
 must also be defined.

6.2. NSLP Message Objects

 A new registry has been created for NSLP Message Objects.  This is a
 12-bit field (giving values from 0 to 4095).  This registry is shared
 between a number of NSLPs.
 Registration procedures are as follows:
    0: Reserved
    1-1023: IETF Review
    1024-1999: Specification Required
 Allocation policies are as follows:
    2000-2047: Private/Experimental Use
    2048-4095: Reserved
 When a new object is defined, the extensibility bits (A/B) must also
 be defined.
 This document defines eleven new NSLP message objects.  These are
 described in Section 5.1.3: RII (0x001), RSN (0x002), REFRESH-PERIOD
 (0x003), BOUND-SESSION-ID (0x004), PACKET-CLASSIFIER (0x005), INFO-
 SPEC (0x006), SESSION-ID-LIST (0x007), RSN-LIST (0x008), MSG-ID
 (0x009), BOUND-MSG-ID (0x00A), and QSPEC (0x00B).
 Additional values are to be assigned from the IETF Review section of
 the NSLP Message Objects registry.

Manner, et al. Experimental [Page 81] RFC 5974 QoS NSLP October 2010

6.3. QoS NSLP Binding Codes

 A new registry has been created for the 8-bit Binding Codes used in
 the BOUND-SESSION-ID object.  The initial values for this registry
 are listed in Section 5.1.3.4.
 The registration procedure is IETF Review.  Value 0 is reserved.
 Values 128 to 159 are for Experimental/Private Use.  Other values are
 Reserved.

6.4. QoS NSLP Error Classes and Error Codes

 In addition, Error Classes and Error Codes for the INFO-SPEC object
 are defined.  These are described in Section 5.1.3.6.
 The Error Class is 4 bits in length.  The initial values are:
    0: Reserved
    1: Informational
    2: Success
    3: Protocol Error
    4: Transient Failure
    5: Permanent Failure
    6: QoS Model Error
    7: Signaling session failure (described in [RFC5973])
    8-15: Reserved
 Additional values are to be assigned based on IETF Review.
 The Error Code is 8 bits in length.  Each Error Code is assigned
 within a particular Error Class.  This requires the creation of a
 registry for Error Codes in each Error Class.  The Error Code 0 in
 each class is Reserved.
 Policies for the error code registries are as follows:
    0-63: IETF Review
    64-127: Specification Required

Manner, et al. Experimental [Page 82] RFC 5974 QoS NSLP October 2010

    128-191: Experimental/Private Use
    192-255: Reserved
 The initial assignments for the Error Code registries are given in
 Section 5.1.3.6.  Experimental and Reserved values are relevant to
 all Error classes.

6.5. QoS NSLP Error Source Identifiers

 Section 5.1.3.6 defines Error Source Identifiers, the type of which
 is identified by a 4-bit value.
 The value 0 is reserved.
 Values 1-3 are given in Section 5.1.3.6.
 Values 14 and 15 are for Experimental/Private Use.
 The registration procedure is Specification Required.

6.6. NSLP IDs and Router Alert Option Values

 This specification defines an NSLP for use with GIST.  Furthermore,
 it specifies that a number of NSLPID values are used for the support
 of bypassing intermediary nodes.  Consequently, new identifiers must
 be assigned for them from the GIST NSLP identifier registry.  As
 required by the QoS NSLP, 32 NSLPID values have been assigned,
 corresponding to QoS NSLP Aggregation Levels 0 to 31.
 The GIST specification also requires that NSLPIDs be associated with
 specific Router Alert Option (RAO) values (although multiple NSLPIDs
 may be associated with the same value).  For the purposes of the QoS
 NSLP, each of its NSLPID values should be associated with a different
 RAO value.  A block of 32 new IPv4 RAO values and a block of 32 new
 IPv6 RAO values have been assigned, corresponding to QoS NSLP
 Aggregation Levels 0 to 31.

7. Security Considerations

 The security requirement for the QoS NSLP is to protect the signaling
 exchange for establishing QoS reservations against identified
 security threats.  For the signaling problem as a whole, these
 threats have been outlined in NSIS threats [RFC4081]; the NSIS
 framework [RFC4080] assigns a subset of the responsibility to GIST,
 and the remaining threats need to be addressed by NSLPs.  The main
 issues to be handled can be summarized as:

Manner, et al. Experimental [Page 83] RFC 5974 QoS NSLP October 2010

 Authorization:
    The QoS NSLP must assure that the network is protected against
    theft-of-service by offering mechanisms to authorize the QoS
    reservation requester.  A user requesting a QoS reservation might
    want proper resource accounting and protection against spoofing
    and other security vulnerabilities that lead to denial of service
    and financial loss.  In many cases, authorization is based on the
    authenticated identity.  The authorization solution must provide
    guarantees that replay attacks are either not possible or limited
    to a certain extent.  Authorization can also be based on traits
    that enable the user to remain anonymous.  Support for user
    identity confidentiality can be accomplished.
 Message Protection:
    Signaling message content should be protected against
    modification, replay, injection, and eavesdropping while in
    transit.  Authorization information, such as authorization tokens,
    needs protection.  This type of protection at the NSLP layer is
    necessary to protect messages between NSLP nodes.
 Rate Limitation:
    QNEs should perform rate-limiting on the refresh messages that
    they send.  An attacker could send erroneous messages on purpose,
    forcing the QNE to constantly reply with an error message.
    Authentication mechanisms would help in figuring out if error
    situations should be reported to the sender, or silently ignored.
    If the sender is authenticated, the QNE should reply promptly.
 Prevention of Denial-of-Service Attacks:
    GIST and QoS NSLP nodes have finite resources (state storage,
    processing power, bandwidth).  The protocol mechanisms in this
    document try to minimize exhaustion attacks against these
    resources when performing authentication and authorization for QoS
    resources.
 To some extent, the QoS NSLP relies on the security mechanisms
 provided by GIST, which by itself relies on existing authentication
 and key exchange protocols.  Some signaling messages cannot be
 protected by GIST and hence should be used with care by the QoS NSLP.
 An API must ensure that the QoS NSLP implementation is aware of the
 underlying security mechanisms and must be able to indicate which
 degree of security is provided between two GIST peers.  If a level of
 security protection for QoS NSLP messages that is required goes
 beyond the security offered by GIST or underlying security

Manner, et al. Experimental [Page 84] RFC 5974 QoS NSLP October 2010

 mechanisms, additional security mechanisms described in this document
 must be used.  Due to the different usage environments and scenarios
 where NSIS is used, it is very difficult to make general statements
 without reducing its flexibility.

7.1. Trust Relationship Model

 This specification is based on a model that requires trust between
 neighboring NSLP nodes to establish a chain-of-trust along the QoS
 signaling path.  The model is simple to deploy, was used in previous
 QoS authorization environments (such as RSVP), and seems to provide
 sufficiently strong security properties.  We refer to this model as
 the New Jersey Turnpike.
 On the New Jersey Turnpike, motorists pick up a ticket at a toll
 booth when entering the highway.  At the highway exit, the ticket is
 presented and payment is made at the toll booth for the distance
 driven.  For QoS signaling in the Internet, this procedure is roughly
 similar.  In most cases, the data sender is charged for transmitted
 data traffic where charging is provided only between neighboring
 entities.

Manner, et al. Experimental [Page 85] RFC 5974 QoS NSLP October 2010

    +------------------+  +------------------+  +------------------+
    |          Network |  |          Network |  |          Network |
    |             X    |  |             Y    |  |             Z    |
    |                  |  |                  |  |                  |
    |              ----------->          ----------->              |
    |                  |  |                  |  |                  |
    |                  |  |                  |  |                  |
    +--------^---------+  +------------------+  +-------+----------+
             |                                          .
             |                                          .
             |                                          v
          +--+---+  Data                   Data      +--+---+
          | Node |  ==============================>  | Node |
          |  A   |  Sender                Receiver   |  B   |
          +------+                                   +------+
      Legend:
  1. —> Peering relationship that allows neighboring

networks/entities to charge each other for the

            QoS reservation and data traffic
      ====> Data flow
      .... Communication to the end host
                 Figure 16: New Jersey Turnpike Model
 The model shown in Figure 16 uses peer-to-peer relationships between
 different administrative domains as a basis for accounting and
 charging.  As mentioned above, based on the peering relationship, a
 chain-of-trust is established.  There are several issues that come to
 mind when considering this type of model:
 o  The model allows authorization on a request basis or on a per-
    session basis.  Authorization mechanisms are elaborated in
    Section 7.2.  The duration for which the QoS authorization is
    valid needs to be controlled.  Combining the interval with the
    soft-state interval is possible.  Notifications from the networks
    also seem to be a viable approach.
 o  The price for a QoS reservation needs to be determined somehow and
    communicated to the charged entity and to the network where the
    charged entity is attached.  Protocols providing "Advice of
    Charge" functionality are out of scope.

Manner, et al. Experimental [Page 86] RFC 5974 QoS NSLP October 2010

 o  This architecture is simple enough to allow a scalable solution
    (ignoring reverse charging, multicast issues, and price
    distribution).
 Charging the data sender as performed in the model simplifies
 security handling by demanding only peer-to-peer security protection.
 Node A would perform authentication and key establishment.  The
 established security association (together with the session key)
 would allow the user to protect QoS signaling messages.  The identity
 used during the authentication and key establishment phase would be
 used by Network X (see Figure 16) to perform the so-called policy-
 based admission control procedure.  In our context, this user
 identifier would be used to establish the necessary infrastructure to
 provide authorization and charging.  Signaling messages later
 exchanged between the different networks are then also subject to
 authentication and authorization.  However, the authenticated entity
 is thereby the neighboring network and not the end host.
 The New Jersey Turnpike model is attractive because of its
 simplicity.  S. Shenker, et al. [shenker] discuss various accounting
 implications and introduced the edge pricing model.  The edge pricing
 model shows similarity to the model described in this section, with
 the exception that mobility and the security implications are not
 addressed.

7.2. Authorization Model Examples

 Various authorization models can be used in conjunction with the QoS
 NSLP.

7.2.1. Authorization for the Two-Party Approach

 The two-party approach (Figure 17) is conceptually the simplest
 authorization model.
 +-------------+  QoS request     +--------------+
 |  Entity     |----------------->| Entity       |
 |  requesting |                  | authorizing  |
 |  resource   |granted / rejected| resource     |
 |             |<-----------------| request      |
 +-------------+                  +--------------+
           ^                           ^
           +...........................+
                   compensation
                     Figure 17: Two-Party Approach

Manner, et al. Experimental [Page 87] RFC 5974 QoS NSLP October 2010

 In this example, the authorization decision only involves the two
 entities, or makes use of previous authorization using an out-of-band
 mechanism to avoid the need for active participation of an external
 entity during the NSIS protocol execution.
 This type of model may be applicable, e.g., between two neighboring
 networks (inter-domain signaling) where a long-term contract (or
 other out-of-band mechanisms) exists to manage charging and provides
 sufficient information to authorize individual requests.

7.2.2. Token-Based Three-Party Approach

 An alternative approach makes use of tokens, such as those described
 in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the
 Open Settlement Protocol [osp].  Authorization tokens are used to
 associate two different signaling protocols runs (e.g., SIP and NSIS)
 and their authorization decision with each other.  The latter is a
 form of assertion or trait.  As an example, with the authorization
 token mechanism, some form of authorization is provided by the SIP
 proxy, which acts as the resource-authorizing entity in Figure 18.
 If the request is authorized, then the SIP signaling returns an
 authorization token that can be included in the QoS signaling
 protocol messages to refer to the previous authorization decision.
 The tokens themselves may take a number of different forms, some of
 which may require the entity performing the QoS reservation to query
 the external state.

Manner, et al. Experimental [Page 88] RFC 5974 QoS NSLP October 2010

   Authorization
   Token Request   +--------------+
   +-------------->| Entity C     | financial settlement
   |               | authorizing  | <..................+
   |               | resource     |                    .
   |        +------+ request      |                    .
   |        |      +--------------+                    .
   |        |                                          .
   |        |Authorization                             .
   |        |Token                                     .
   |        |                                          .
   |        |                                          .
   |        |                                          .
   |        |      QoS request                         .
 +-------------+ + Authz. Token   +--------------+     .
 |  Entity     |----------------->| Entity B     |     .
 |  requesting |                  | performing   |     .
 |  resource   |granted / rejected| QoS          |  <..+
 |      A      |<-----------------| reservation  |
 +-------------+                  +--------------+
              Figure 18: Token-Based Three-Party Approach
 For the digital money type of systems (e.g., OSP tokens), the token
 represents a limited amount of credit.  So, new tokens must be sent
 with later refresh messages once the credit is exhausted.

Manner, et al. Experimental [Page 89] RFC 5974 QoS NSLP October 2010

7.2.3. Generic Three-Party Approach

 Another method is for the node performing the QoS reservation to
 delegate the authorization decision to a third party, as illustrated
 in Figure 19.  The authorization decision may be performed on a per-
 request basis, periodically, or on a per-session basis.
                                  +--------------+
                                  | Entity C     |
                                  | authorizing  |
                                  | resource     |
                                  | request      |
                                  +-----------+--+
                                     ^        |
                                 QoS |        | QoS
                                authz|        |authz
                                 req.|        | res.
                    QoS              |        v
 +-------------+    request       +--+-----------+
 |  Entity     |----------------->| Entity B     |
 |  requesting |                  | performing   |
 |  resource   |granted / rejected| QoS          |
 |      A      |<-----------------| reservation  |
 +-------------+                  +--------------+
                    Figure 19: Three-Party Approach

7.3. Computing the Authorization Decision

 Whenever an authorization decision has to be made there is the
 question about which information serves as an input to the
 authorizing entity.  The following information items have been
 mentioned in the past for computing the authorization decision (in
 addition to the authenticated identity):
    Price
    QoS objects
    Policy rules
 Policy rules take into consideration attributes like time of day,
 subscription to certain services, membership, etc., when computing an
 authorization decision.
 The policies used to make the authorization are outside the scope of
 this document and are implementation/deployment specific.

Manner, et al. Experimental [Page 90] RFC 5974 QoS NSLP October 2010

8. Acknowledgments

 The authors would like to thank Eleanor Hepworth, Ruediger Geib,
 Roland Bless, Nemeth Krisztian, Markus Ott, Mayi Zoumaro-Djayoon,
 Martijn Swanink, and Ruud Klaver for their useful comments.  Roland,
 especially, has done deep reviews of the document, making sure the
 protocol is well defined.  Bob Braden provided helpful comments and
 guidance which were gratefully received.

9. Contributors

 This document combines work from three individual documents.  The
 following authors from these documents also contributed to this
 document: Robert Hancock (Siemens/Roke Manor Research), Hannes
 Tschofenig and Cornelia Kappler (Siemens AG), Lars Westberg and
 Attila Bader (Ericsson), and Maarten Buechli (Dante) and Eric
 Waegeman (Alcatel).  In addition, Roland Bless has contributed
 considerable amounts of text all along the writing of this
 specification.
 Sven Van den Bosch was the initial editor of earlier draft versions
 of this document.  Since version 06 of the document, Jukka Manner has
 taken the editorship.  Yacine El Mghazli (Alcatel) contributed text
 on AAA.  Charles Shen and Henning Schulzrinne suggested the use of
 the reason field in the BOUND-SESSION-ID.

10. References

10.1. Normative References

 [RFC1982]    Elz, R. and R. Bush, "Serial Number Arithmetic",
              RFC 1982, August 1996.
 [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5971]    Schulzrinne, H. and R. Hancock, "GIST: General Internet
              Signalling Transport", RFC 5971, October 2010.
 [RFC5975]    Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC
              Template for the Quality-of-Service NSIS Signaling Layer
              Protocol (NSLP)", RFC 5975, October 2010.

10.2. Informative References

 [NSIS-AUTH]  Manner, J., Stiemerling, M., Tschofenig, H., and R.
              Bless, Ed., "Authorization for NSIS Signaling Layer
              Protocols", Work in Progress, May 2010.

Manner, et al. Experimental [Page 91] RFC 5974 QoS NSLP October 2010

 [NSIS-MOB]   Sanda, T., Fu, X., Jeong, S., Manner, J., and H.
              Tschofenig, "NSIS Protocols operation in Mobile
              Environments", Work in Progress, May 2010.
 [RFC1633]    Braden, B., Clark, D., and S. Shenker, "Integrated
              Services in the Internet Architecture: an Overview",
              RFC 1633, June 1994.
 [RFC2205]    Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
              1 Functional Specification", RFC 2205, September 1997.
 [RFC2210]    Wroclawski, J., "The Use of RSVP with IETF Integrated
              Services", RFC 2210, September 1997.
 [RFC2961]    Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
              and S. Molendini, "RSVP Refresh Overhead Reduction
              Extensions", RFC 2961, April 2001.
 [RFC3175]    Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
              "Aggregation of RSVP for IPv4 and IPv6 Reservations",
              RFC 3175, September 2001.
 [RFC3520]    Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
              "Session Authorization Policy Element", RFC 3520,
              April 2003.
 [RFC3521]    Hamer, L-N., Gage, B., and H. Shieh, "Framework for
              Session Set-up with Media Authorization", RFC 3521,
              April 2003.
 [RFC3726]    Brunner, M., "Requirements for Signaling Protocols",
              RFC 3726, April 2004.
 [RFC4080]    Hancock, R., Karagiannis, G., Loughney, J., and S. Van
              den Bosch, "Next Steps in Signaling (NSIS): Framework",
              RFC 4080, June 2005.
 [RFC4081]    Tschofenig, H. and D. Kroeselberg, "Security Threats for
              Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
 [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.
 [RFC5234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

Manner, et al. Experimental [Page 92] RFC 5974 QoS NSLP October 2010

 [RFC5973]    Stiemerling, M., Tschofenig, H., Aoun, C., and E.
              Davies, "NAT/Firewall NSIS Signaling Layer Protocol
              (NSLP)", RFC 5973, October 2010.
 [RFC5977]    Bader, A., Westberg, L., Karagiannis, G., Kappler, C.,
              Tschofenig, H., and T. Phelan, "RMD-QOSM: The NSIS
              Quality-of-Service Model for Resource Management in
              Diffserv", RFC 5977, October 2010.
 [lrsvp]      Manner, J. and K. Raatikainen, "Localized QoS Management
              for Multimedia Applications in Wireless Access
              Networks", IASTED IMSA, Technical Specification 101 321,
              p. 193-200, August 2004.
 [opwa95]     Breslau, L., "Two Issues in Reservation Establishment",
              Proc. ACM SIGCOMM '95, Cambridge MA, August 1995.
 [osp]        ETSI, "Telecommunications and Internet Protocol
              Harmonization Over Networks (TIPHON); Open Settlement
              Protocol (OSP) for Inter-Domain pricing, authorization,
              and usage exchange", Technical Specification 101 321,
              version 4.1.1.
 [qos-auth]   Tschofenig, H., "QoS NSLP Authorization Issues", Work
              in Progress, June 2003.
 [shenker]    Shenker, S., et al., "Pricing in computer networks:
              Reshaping the research agenda", Proc. of TPRC 1995,
              1995.

Manner, et al. Experimental [Page 93] RFC 5974 QoS NSLP October 2010

Appendix A. Abstract NSLP-RMF API

 This appendix is purely informational and provides an abstract API
 between the QoS NSLP and the RMF.  It should not be taken as a strict
 rule for implementors, but rather it helps clarify the interface
 between the NSLP and RMF.

A.1. Triggers from QOS-NSLP towards RMF

 The QoS-NSLP triggers the RMF/QOSM functionality by using the
 sendrmf() primitive:
 int sendrmf(sid, nslp_req_type, qspec, authorization_info,
 NSLP_objects, filter, features_in, GIST_API_triggers,
 incoming_interface, outgoing_interface)
 o  sid: SESSION-ID - The NSIS session identifier
 o  nslp_req_type: indicates type of request:
  • RESERVE
  • QUERY
  • RESPONSE
  • NOTIFY
 o  qspec: the QSPEC object, if present
 o  authorization_info: the AUTH_SESSION object, if present
 o  NSLP_objects: data structure that contains a list with received
    QoS-NSLP objects.  This list can be used by, e.g., local
    applications, network management, or policy control modules:
  • RII
  • RSN
  • BOUND-SESSION-ID list
  • REFRESH-PERIOD
  • SESSION-ID-LIST
  • RSN-LIST

Manner, et al. Experimental [Page 94] RFC 5974 QoS NSLP October 2010

  • INFO-SPEC
  • MSG-ID
  • BOUND-MSG-ID
 o  filter: the information for packet filtering, based on the MRI and
    the PACKET-CLASSIFIER object.
 o  features_in: it represents the flags included in the common header
    of the received QOS-NSLP message, but also additional triggers:
  • BREAK
  • REQUEST REDUCED REFRESHES
  • RESERVE-INIT
  • TEAR
  • REPLACE
  • ACK-REQ
  • PROXY
  • SCOPING
  • synchronization_required: this attribute is set (see Sections

Section 4.6 and Section 4.7.1, for example) when the QoS-NSLP

       functionality supported by a QNE Egress receives a non-tearing
       RESERVE message that includes a MSG-ID or a BOUND-MSG-ID
       object, and the BINDING_CODE value of the BOUND-SESSION-ID
       object is equal to one of the following values:
       +  Tunnel and end-to-end sessions
       +  Aggregate sessions
  • GIST_API_triggers: it represents the attributes that are

provided by GIST to QoS-NSLP via the GIST API:

       +  NSLPID
       +  Routing-State-Check
       +  SII-Handle

Manner, et al. Experimental [Page 95] RFC 5974 QoS NSLP October 2010

       +  Transfer-Attributes
       +  GIST-Hop-Count
       +  IP-TTL
       +  IP-Distance
 o  incoming_interface: the ID of the incoming interface.  Used only
    when the QNE reserves resources on incoming interface.  Default is
    0 (no reservations on incoming interface)
 o  outgoing_interface: the ID of the outgoing interface.  Used only
    when the QNE reserves resources on outgoing interface.  Default is
    0 (no reservations on outgoing interface)

A.2. Triggers from RMF/QOSM towards QOS-NSLP

 The RMF triggers the QoS-NSLP functionality using the "recvrmf()" and
 "config()" primitives to perform either all or a subset of the
 features listed below.
 The recvrmf() primitive represents either a response to a request
 that has been sent via the API by the QoS-NSLP or an asynchronous
 notification.  Note that when the RMF/QOSM receives a request via the
 API from the QoS-NSLP function, one or more "recvrmf()" response
 primitives can be sent via the API towards QoS-NSLP.  In this way,
 the QOS-NSLP can generate one or more QoS-NSLP messages that can be
 used, for example, in the situation that the arrival of one end-to-
 end RESERVE triggers the generation of two (or more) RESERVE
 messages: an end-to-end RESERVE message and one (or more) intra-
 domain (local) RESERVE message.
 The config() primitive is used to configure certain features, such as
 QNE type, stateful or stateless operation, or bypassing of end-to-end
 messages.
 Note that the selection of the subset of triggers is controlled by
 the QoS Model.
 int recvrmf(sid, nslp_resp_type, qspec, authorization_info, status,
 NSLP_objects, filter, features_out, GIST_API_triggers
 incoming_interface, outgoing_interface)
 o  sid: SESSION-ID - The NSIS session identifier

Manner, et al. Experimental [Page 96] RFC 5974 QoS NSLP October 2010

 o  nslp_resp_type: indicates type of response:
  • RESERVE
  • QUERY
  • RESPONSE
  • NOTIFY
 o  qspec: the QSPEC object, if present
 o  authorization_info: the AUTHO_SESSION object, if present
 o  status: boolean that notifies the status of the reservation and
    can be used by QOS-NSLP to include in the INFO-SPEC object:
  • RESERVATION_SUCCESSFUL
  • TEAR_DOWN_SUCCESSFUL
  • NO RESOURCES
  • RESERVATION_FAILURE
  • RESERVATION_PREEMPTED: reservation was preempted
  • AUTHORIZATION_FAILED: authorizing the request failed
  • MALFORMED_QSPEC: request failed due to malformed qspec
  • SYNCHRONIZATION_FAILED: Mismatch synchronization between an

end-to-end RESERVE and an intra-domain RESERVE (see Sections

       Section 4.6 and Section 4.7.1)
  • CONGESTION_SITUATION: Possible congestion situation occurred on

downstream path

  • QoS Model Error
 o  NSLP_objects: data structure that contains a list with QoS-NSLP
    objects that can be used by QoS-NSLP when the QNE is a QNI, QNR,
    QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress:
  • RII
  • RSN

Manner, et al. Experimental [Page 97] RFC 5974 QoS NSLP October 2010

  • BOUND-SESSION-ID list
  • REFRESH-PERIOD
  • SESSION-ID-LIST
  • RSN-LIST
  • MSG-ID
  • BOUND-MSG-ID
 o  filter: it represents the MRM-related PACKET CLASSIFIER
 o  features_out: it represents (among others) the flags that can be
    used by the QOS-NSLP for newly generated QoS-NSLP messages:
  • BREAK
  • REQUEST REDUCED REFRESHES
  • RESERVE-INIT
  • TEAR
  • REPLACE
  • ACK-REQ
  • PROXY
  • SCOPING
  • BYPASSING - when the outgoing message should be bypassed, then

it includes the required bypassing level. Otherwise, it is

       empty.  It can be set only by QNI_Ingress, QNR_Ingress,
       QNI_Egress, or QNR_Egress.  It can be unset only by
       QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress.
  • BINDING () - when BINDING is required, then it includes a

BOUND-SESSION-ID list. Otherwise, it is empty. It can only be

       requested by the following QNE types: QNI, QNR, QNI_Ingress,
       QNR_Ingress, QNI_Egress, or QNR_Egress.

Manner, et al. Experimental [Page 98] RFC 5974 QoS NSLP October 2010

  • NEW_SID - it requests to generate a new session with a new

SESSION-ID. If the QoS-NSLP generates a new SESSION-ID, then

       the QoS-NSLP has to return the value of this new SESSION-ID to
       the RMF/QOSM.  It can be requested by a QNI, QNR, QNI_Ingress,
       QNI_Egress, QNR_Ingress, or QNR_Egress.
  • NEW_RSN - it requests to generate a new RSN. If the QoS-NSLP

generates a new RSN, then the QoS-NSLP has to return the value

       of this new RSN to the RMF/QOSM.
  • NEW_RII - it requests to generate a new RII. If the QoS-NSLP

generates a new RII, then the QoS-NSLP has to return the value

       of this new RII to the RMF/QOSM.
 o  GIST_API_triggers: it represents the attributes that are provided
    to GIST via QoS-NSLP via the GIST API:
  • NSLPID
  • SII-Handle
  • Transfer-Attributes
  • GIST-Hop-Count
  • IP-TTL
  • ROUTING-STATE-CHECK (if set, it requires that GIST create a

routing state)

 o  incoming_interface: the ID of the incoming interface.  Used only
    when the QNE reserves resources on the incoming interface.
    Default is 0 (no reservations on the incoming interface).
 o  outgoing_interface: the ID of the outgoing interface.  Used only
    when the QNE reserves resources on the outgoing interface.
    Default is 0 (no reservations on the outgoing interface).

A.3. Configuration Interface

 The config() function is meant for configuring per-session settings,
 from the RMF towards the NSLP.
 int config(sid, qne_type, state_type, bypassing_type)
 o  sid: SESSION-ID - The NSIS session identifier

Manner, et al. Experimental [Page 99] RFC 5974 QoS NSLP October 2010

 o  qne_type: it defines the type of a QNE
  • QNI
  • QNI_Ingress: the QNE is a QNI and an Ingress QNE
  • QNE: the QNE is not a QNI or QNR
  • QNE_Interior: the QNE is an Interior QNE, but it is not a QNI

or QNR

  • QNI_Egress: the QNE is a QNI and an Egress QNE
  • QNR
  • QNR_Ingress: the QNE is a QNR and an Ingress QNE
  • QNR_Egress: the QNE is a QNR and an Egress QNE
 o  state_type: it defines if the QNE keeps QoS-NSLP operational
    states
  • STATEFUL
  • STATELESS
 o  bypassing_type: it defines if a QNE bypasses end-to-end messages
    or not

Appendix B. Glossary

 AAA: Authentication, Authorization, and Accounting
 EAP: Extensible Authentication Protocol
 MRI: Message Routing Information (see [RFC5971])
 NAT: Network Address Translator
 NSLP: NSIS Signaling Layer Protocol (see [RFC4080])
 NTLP: NSIS Transport Layer Protocol (see [RFC4080])
 OPWA: One Pass With Advertising
 OSP: Open Settlement Protocol
 PIN: Policy-Ignorant Node

Manner, et al. Experimental [Page 100] RFC 5974 QoS NSLP October 2010

 QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2)
 QNI: the first node in the sequence of QNEs that issues a reservation
 request for a session (see Section 22)
 QNR: the last node in the sequence of QNEs that receives a
 reservation request for a session (see Section 22)
 QSPEC: Quality-of-Service Specification
 RII: Request Identification Information
 RMD: Resource Management for Diffserv
 RMF: Resource Management Function
 RSN: Reservation Sequence Number
 RSVP: Resource Reservation Protocol (see [RFC2205])
 SII: Source Identification Information
 SIP: Session Initiation Protocol
 SLA: Service Level Agreement

Manner, et al. Experimental [Page 101] RFC 5974 QoS NSLP October 2010

Authors' Addresses

 Jukka Manner
 Aalto University
 Department of Communications and Networking (Comnet)
 P.O. Box 13000
 FIN-00076 Aalto
 Finland
 Phone: +358 9 470 22481
 EMail: jukka.manner@tkk.fi
 URI:   http://www.netlab.tkk.fi/~jmanner/
 Georgios Karagiannis
 University of Twente/Ericsson
 P.O. Box 217
 Enschede  7500 AE
 The Netherlands
 EMail: karagian@cs.utwente.nl
 Andrew McDonald
 Roke Manor Research Ltd
 Old Salisbury Lane
 Romsey, Hampshire  S051 0ZN
 United Kingdom
 EMail: andrew.mcdonald@roke.co.uk

Manner, et al. Experimental [Page 102]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5974.txt · Last modified: 2010/10/06 17:48 (external edit)