idnits 2.17.1 draft-ietf-nsis-qos-nslp-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 29, 2010) is 5198 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-nsis-applicability-mobility-signaling-14 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-rmd-15 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manner 3 Internet-Draft Aalto University 4 Intended status: Experimental G. Karagiannis 5 Expires: August 2, 2010 University of Twente/Ericsson 6 A. McDonald 7 Siemens/Roke Manor Research 8 January 29, 2010 10 NSLP for Quality-of-Service Signaling 11 draft-ietf-nsis-qos-nslp-18.txt 13 Abstract 15 This specification describes the NSIS Signaling Layer Protocol (NSLP) 16 for signaling QoS reservations in the Internet. It is in accordance 17 with the framework and requirements developed in NSIS. Together with 18 GIST, it provides functionality similar to RSVP and extends it. The 19 QoS NSLP is independent of the underlying QoS specification or 20 architecture and provides support for different reservation models. 21 It is simplified by the elimination of support for multicast flows. 22 This specification explains the overall protocol approach, design 23 decisions made and provides examples. It specifies object, message 24 formats and processing rules. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on August 2, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1. Overall Approach . . . . . . . . . . . . . . . . . . . . . 7 70 3.1.1. Protocol Messages . . . . . . . . . . . . . . . . . . 10 71 3.1.2. QoS Models and QoS Specifications . . . . . . . . . . 11 72 3.1.3. Policy Control . . . . . . . . . . . . . . . . . . . . 13 73 3.2. Design Background . . . . . . . . . . . . . . . . . . . . 14 74 3.2.1. Soft States . . . . . . . . . . . . . . . . . . . . . 14 75 3.2.2. Sender and Receiver Initiation . . . . . . . . . . . . 14 76 3.2.3. Protection Against Message Re-ordering and 77 Duplication . . . . . . . . . . . . . . . . . . . . . 15 78 3.2.4. Explicit Confirmations . . . . . . . . . . . . . . . . 15 79 3.2.5. Reduced Refreshes . . . . . . . . . . . . . . . . . . 15 80 3.2.6. Summary Refreshes and Summary Tear . . . . . . . . . . 15 81 3.2.7. Message Scoping . . . . . . . . . . . . . . . . . . . 16 82 3.2.8. Session Binding . . . . . . . . . . . . . . . . . . . 16 83 3.2.9. Message Binding . . . . . . . . . . . . . . . . . . . 17 84 3.2.10. Layering . . . . . . . . . . . . . . . . . . . . . . . 17 85 3.2.11. Support for Request Priorities . . . . . . . . . . . . 19 86 3.2.12. Rerouting . . . . . . . . . . . . . . . . . . . . . . 19 87 3.2.13. Pre-emption . . . . . . . . . . . . . . . . . . . . . 25 88 3.3. GIST Interactions . . . . . . . . . . . . . . . . . . . . 25 89 3.3.1. Support for Bypassing Intermediate Nodes . . . . . . . 25 90 3.3.2. Support for Peer Change Identification . . . . . . . . 26 91 3.3.3. Support for Stateless Operation . . . . . . . . . . . 26 92 3.3.4. Priority of Signaling Messages . . . . . . . . . . . . 27 93 3.3.5. Knowledge of Intermediate QoS NSLP Unaware Nodes . . . 27 94 4. Examples of QoS NSLP Operation . . . . . . . . . . . . . . . . 27 95 4.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 28 96 4.2. Sending a Query . . . . . . . . . . . . . . . . . . . . . 29 97 4.3. Basic Receiver-initiated Reservation . . . . . . . . . . . 30 98 4.4. Bidirectional Reservations . . . . . . . . . . . . . . . . 32 99 4.5. Aggregate Reservations . . . . . . . . . . . . . . . . . . 33 100 4.6. Message Binding . . . . . . . . . . . . . . . . . . . . . 35 101 4.7. Reduced State or Stateless Interior Nodes . . . . . . . . 38 102 4.7.1. Sender-initiated Reservation . . . . . . . . . . . . . 39 103 4.7.2. Receiver-initiated Reservation . . . . . . . . . . . . 41 104 4.8. Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . 41 105 5. QoS NSLP Functional Specification . . . . . . . . . . . . . . 42 106 5.1. QoS NSLP Message and Object Formats . . . . . . . . . . . 42 107 5.1.1. Common Header . . . . . . . . . . . . . . . . . . . . 43 108 5.1.2. Message Formats . . . . . . . . . . . . . . . . . . . 44 109 5.1.3. Object Formats . . . . . . . . . . . . . . . . . . . . 48 110 5.2. General Processing Rules . . . . . . . . . . . . . . . . . 61 111 5.2.1. State Manipulation . . . . . . . . . . . . . . . . . . 61 112 5.2.2. Message Forwarding . . . . . . . . . . . . . . . . . . 62 113 5.2.3. Standard Message Processing Rules . . . . . . . . . . 62 114 5.2.4. Retransmissions . . . . . . . . . . . . . . . . . . . 63 115 5.2.5. Rerouting . . . . . . . . . . . . . . . . . . . . . . 63 116 5.3. Object Processing . . . . . . . . . . . . . . . . . . . . 65 117 5.3.1. Reservation Sequence Number (RSN) . . . . . . . . . . 65 118 5.3.2. Request Identification Information (RII) . . . . . . . 66 119 5.3.3. BOUND_SESSION_ID . . . . . . . . . . . . . . . . . . . 67 120 5.3.4. REFRESH_PERIOD . . . . . . . . . . . . . . . . . . . . 68 121 5.3.5. INFO_SPEC . . . . . . . . . . . . . . . . . . . . . . 68 122 5.3.6. SESSION_ID_LIST . . . . . . . . . . . . . . . . . . . 70 123 5.3.7. RSN_LIST . . . . . . . . . . . . . . . . . . . . . . . 71 124 5.3.8. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . 72 125 5.4. Message Processing Rules . . . . . . . . . . . . . . . . . 72 126 5.4.1. RESERVE Messages . . . . . . . . . . . . . . . . . . . 72 127 5.4.2. QUERY Messages . . . . . . . . . . . . . . . . . . . . 77 128 5.4.3. RESPONSE Messages . . . . . . . . . . . . . . . . . . 78 129 5.4.4. NOTIFY Messages . . . . . . . . . . . . . . . . . . . 79 130 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 131 6.1. QoS NSLP Message Type . . . . . . . . . . . . . . . . . . 80 132 6.2. NSLP Message Objects . . . . . . . . . . . . . . . . . . . 81 133 6.3. QoS NSLP Binding Codes . . . . . . . . . . . . . . . . . . 81 134 6.4. QoS NSLP Error Classes and Error Codes . . . . . . . . . . 81 135 6.5. QoS NSLP Error Source Identifiers . . . . . . . . . . . . 82 136 6.6. NSLP IDs and Router Alert Option Values . . . . . . . . . 83 137 7. Security Considerations . . . . . . . . . . . . . . . . . . . 83 138 7.1. Trust Relationship Model . . . . . . . . . . . . . . . . . 84 139 7.2. Authorization Model Examples . . . . . . . . . . . . . . . 86 140 7.2.1. Authorization for the Two Party Approach . . . . . . . 86 141 7.2.2. Token-based Three Party Approach . . . . . . . . . . . 87 142 7.2.3. Generic Three Party Approach . . . . . . . . . . . . . 88 143 7.3. Computing the Authorization Decision . . . . . . . . . . . 89 145 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 89 146 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 90 147 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 90 148 10.1. Normative References . . . . . . . . . . . . . . . . . . . 90 149 10.2. Informative References . . . . . . . . . . . . . . . . . . 90 150 Appendix A. Abstract NSLP-RMF API . . . . . . . . . . . . . . . . 92 151 A.1. Triggers from QOS-NSLP towards RMF . . . . . . . . . . . . 92 152 A.2. Triggers from RMF/QOSM towards QOS-NSLP . . . . . . . . . 94 153 A.3. Configuration interface . . . . . . . . . . . . . . . . . 96 154 Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 97 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 98 157 1. Introduction 159 This document defines a Quality of Service (QoS) NSIS Signaling Layer 160 Protocol (NSLP), henceforth referred to as the "QoS NSLP". This 161 protocol establishes and maintains state at nodes along the path of a 162 data flow for the purpose of providing some forwarding resources for 163 that flow. It is intended to satisfy the QoS-related requirements of 164 RFC 3726 [RFC3726]. This QoS NSLP is part of a larger suite of 165 signaling protocols, whose structure is outlined in the NSIS 166 framework [RFC4080]; this defines a common NSIS Transport Layer 167 Protocol (NTLP). The abstract NTLP has been developed into a 168 concrete protocol, GIST (General Internet Signaling Transport) 169 [I-D.ietf-nsis-ntlp]. The QoS NSLP relies on GIST to carry out many 170 aspects of signaling message delivery. 172 The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 173 [RFC2205], and uses soft-state peer-to-peer refresh messages as the 174 primary state management mechanism (i.e., state installation/refresh 175 is performed between pairs of adjacent NSLP nodes, rather than in an 176 end-to-end fashion along the complete signaling path). The QoS NSLP 177 extends the set of reservation mechanisms to meet the requirements of 178 RFC 3726 [RFC3726], in particular support of sender or receiver- 179 initiated reservations, as well as, a type of bi-directional 180 reservation and support of reservations between arbitrary nodes, 181 e.g., edge-to-edge, end-to-access, etc. On the other hand, there is 182 currently no support for IP multicast. 184 A distinction is made between the operation of the signaling protocol 185 and the information required for the operation of the Resource 186 Management Function (RMF). This document describes the signaling 187 protocol, whilst [I-D.ietf-nsis-qspec] describes the RMF-related 188 information carried in the QSPEC (QoS Specification) object in QoS 189 NSLP messages. This is similar to the decoupling between RSVP and 190 the IntServ architecture, RFC 1633 [RFC1633]. The QSPEC carries 191 information on resources available, resources required, traffic 192 descriptions and other information required by the RMF. 194 This document is structured as follows. The overall protocol design 195 is outlined in Section 3.1. The operation and use of the QoS NSLP is 196 described in more detail in the rest of Section 3. Section 4 then 197 clarifies the protocol by means of a number of examples. These 198 sections should be read by people interested in the overall protocol 199 capabilities. The functional specification in Section 5 contains 200 more detailed object and message formats and processing rules and 201 should be the basis for implementers. The subsequent sections 202 describe IANA allocation issues, and security considerations. 204 2. Terminology 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in RFC 2119 [RFC2119]. 210 The terminology defined by GIST [I-D.ietf-nsis-ntlp] applies to this 211 draft. 213 In addition, the following terms are used: 215 QNE: an NSIS Entity (NE), which supports the QoS NSLP. 217 QNI: the first node in the sequence of QNEs that issues a reservation 218 request for a session. 220 QNR: the last node in the sequence of QNEs that receives a 221 reservation request for a session. 223 P-QNE: Proxy-QNE, a node set to reply to messages with the PROXY 224 scope flag set. 226 Session: A session defines an association between a QNI and QNR 227 related to a data flow. Intermediate QNEs on the path, the QNI and 228 the QNR use the same identifier to refer to the state stored for the 229 association. The same QNI and QNR may have more than one session 230 active at any one time. 232 Session Identification (SESSION_ID, SID): This is a cryptographically 233 random and (probabilistically) globally unique identifier of the 234 application layer session that is associated with a certain flow. 235 Often there will only be one data flow for a given session, but in 236 mobility/multihoming scenarios there may be more than one and they 237 may be differently routed [RFC4080]. 239 Source or message source: The one of two adjacent NSLP peers that is 240 sending a signaling message (maybe the upstream or the downstream 241 peer). Note that this is not necessarily the QNI. 243 QoS NSLP operation state: State used/kept by the QoS NSLP processing 244 to handle messaging aspects. 246 QoS reservation state: State used/kept by Resource Management 247 Function to describe reserved resources for a session. 249 Flow ID: This is essentially the Message Routing Information (MRI) 251 in GIST for path-coupled signaling. 253 Figure 1 shows the components that have a role in a QoS NSLP 254 signaling session. The flow sender and receiver would in most cases 255 be part of the QNI and QNR nodes. Yet, these may be separate nodes, 256 too. 258 QoS NSLP nodes 259 IP address (QoS unaware NSIS nodes are IP address 260 = Flow not shown) = Flow 261 Source | | | Destination 262 Address | | | Address 263 V V V 264 +--------+ Data +------+ +------+ +------+ +--------+ 265 | Flow |-------|------|------|------|-------|------|---->| Flow | 266 | Sender | Flow | | | | | | |Receiver| 267 +--------+ | QNI | | QNE | | QNR | +--------+ 268 | | | | | | 269 +------+ +------+ +------+ 270 =====================> 271 <===================== 272 Signaling 273 Flow 275 Figure 1: Components of the QoS NSLP architecture 277 A glossary of terms and abbreviations used in this document can be 278 found in Appendix B. 280 3. Protocol Overview 282 3.1. Overall Approach 284 This section presents a logical model for the operation of the QoS 285 NSLP and associated provisioning mechanisms within a single node. 286 The model is shown in Figure 2. 288 +---------------+ 289 | Local | 290 |Applications or| 291 |Management (e.g| 292 |for aggregates)| 293 +---------------+ 294 ^ 295 V 296 V 297 +----------+ +----------+ +---------+ 298 | QoS NSLP | | Resource | | Policy | 299 |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control | 300 +----------+ +----------+ +---------+ 301 . ^ | * ^ 302 | V . * ^ 303 +----------+ * ^ 304 | NTLP | * ^ 305 |Processing| * V 306 +----------+ * V 307 | | * V 308 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 309 . . * V 310 | | * ............................. 311 . . * . Traffic Control . 312 | | * . +---------+. 313 . . * . |Admission|. 314 | | * . | Control |. 315 +----------+ +------------+ . +---------+. 316 <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> 317 | Packet | | Interface | .+----------+ +---------+. 318 ===>|Processing|====| Selection |===.| Packet |====| Packet |.==> 319 | | |(Forwarding)| .|Classifier| Scheduler|. 320 +----------+ +------------+ .+----------+ +---------+. 321 ............................. 322 <.-.-> = signaling flow 323 =====> = data flow (sender --> receiver) 324 <<<>>> = control and configuration operations 325 ****** = routing table manipulation 327 Figure 2: QoS NSLP in a Node 329 This diagram shows an example implementation scenario where QoS 330 conditioning is performed on the output interface. However, this 331 does not limit the possible implementations. For example, in some 332 cases traffic conditioning may be performed on the incoming 333 interface, or it may be split over the input and output interfaces. 334 Also, the interactions with the Policy Control component may be more 335 complex, involving interaction with the Resource Management Function, 336 and the AAA infrastructure. 338 From the perspective of a single node, the request for QoS may result 339 from a local application request, or from processing an incoming QoS 340 NSLP message. The request from a local application includes not only 341 user applications (e.g., multimedia applications) but also network 342 management (e.g. initiating a tunnel to handle an aggregate, or 343 interworking with some other reservation protocol - such as RSVP) and 344 the policy control module (e.g., for explicit teardown triggered by 345 AAA). In this sense, the model does not distinguish between hosts 346 and routers. 348 Incoming messages are captured during input packet processing and 349 handled by GIST. Only messages related to QoS are passed to the QoS 350 NSLP. GIST may also generate triggers to the QoS NSLP (e.g., 351 indications that a route change has occurred). The QoS request is 352 handled by the RMF, which coordinates the activities required to 353 grant and configure the resource. It also handles policy-specific 354 aspects of QoS signaling. 356 The grant processing involves two local decision modules, 'policy 357 control' and 'admission control'. Policy control determines whether 358 the user is authorized to make the reservation. Admission control 359 determines whether the network of the node has sufficient available 360 resources to supply the requested QoS. If both checks succeed, 361 parameters are set in the packet classifier and in the link layer 362 interface (e.g., in the packet scheduler) to obtain the desired QoS. 363 Error notifications are passed back to the request originator. The 364 resource management function may also manipulate the forwarding 365 tables at this stage, to select (or at least pin) a route; this must 366 be done before interface-dependent actions are carried out (including 367 sending outgoing messages over any new route), and is in any case 368 invisible to the operation of the protocol. 370 Policy control is expected to make use of the authentication 371 infrastructure or the authentication protocols external to the node 372 itself. Some discussion can be found in a separate document on 373 authorization issues [qos-auth]. More generally, the processing of 374 policy and resource management functions may be outsourced to an 375 external node leaving only 'stubs' co-located with the NSLP node; 376 this is not visible to the protocol operation. A more detailed 377 discussion of authentication and authorization can be found in 378 Section 3.1.3. 380 Admission control, packet scheduling, and any part of policy control 381 beyond simple authorization have to be implemented using specific 382 definitions for types and levels of QoS. A key assumption is made 383 that the QoS NSLP is independent of the QoS parameters (e.g., IntServ 384 service elements). These are captured in a QoS Model and interpreted 385 only by the resource management and associated functions, and are 386 opaque to the QoS NSLP itself. QoS Models are discussed further in 387 Section 3.1.2. 389 The final stage of processing for a resource request is to indicate 390 to the QoS NSLP protocol processing that the required resources have 391 been configured. The QoS NSLP may generate an acknowledgment message 392 in one direction, and may forward the resource request in the other. 393 Message routing is carried out by the GIST module. Note that while 394 Figure 2 shows a unidirectional data flow, the signaling messages can 395 pass in both directions through the node, depending on the particular 396 message and orientation of the reservation. 398 3.1.1. Protocol Messages 400 The QoS NSLP uses four message types: 402 RESERVE: The RESERVE message is the only message that manipulates QoS 403 NSLP reservation state. It is used to create, refresh, modify and 404 remove such state. The result of a RESERVE message is the same 405 whether a message is received once or many times. 407 QUERY: A QUERY message is used to request information about the data 408 path without making a reservation. This functionality can be used to 409 reservations or for support of certain QoS models. The information 410 obtained from a QUERY may be used in the admission control process of 411 a QNE (e.g., in case of measurement-based admission control). Note 412 that a QUERY does not change existing reservation state. 414 RESPONSE: The RESPONSE message is used to provide information about 415 the result of a previous QoS NSLP message. This includes explicit 416 confirmation of the state manipulation signaled in the RESERVE 417 message, the response to a QUERY message or an error code if the QNE 418 or QNR is unable to provide the requested information or if the 419 response is negative. The RESPONSE message does not cause any 420 reservation state to be installed or modified. 422 NOTIFY: NOTIFY messages are used to convey information to a QNE. 423 They differ from RESPONSE messages in that they are sent 424 asynchronously and need not refer to any particular state or 425 previously received message. The information conveyed by a NOTIFY 426 message is typically related to error conditions. Examples would be 427 notification to an upstream peer about state being torn down or to 428 indicate when a reservation has been preempted. 430 QoS NSLP messages are sent peer-to-peer. This means that a QNE 431 considers its adjacent upstream or downstream peer to be the source 432 of each message. 434 Each protocol message has a common header which indicates the message 435 type and contains various flag bits. Message formats are defined in 436 Section 5.1.2. Message processing rules are defined in Section 5.4. 438 QoS NSLP messages contain three types of objects: 440 1. Control Information: Control information objects carry general 441 information for the QoS NSLP processing, such as sequence numbers or 442 whether a response is required. 444 2. QoS specifications (QSPECs): QSPEC objects describe the actual 445 resources that are required and depend on the QoS model being used. 446 Besides any resource description they may also contain other control 447 information used by the RMF's processing. 449 3. Policy objects: Policy objects contain data used to authorize the 450 reservation of resources. 452 Object formats are defined in Section 5.1.3. Object processing rules 453 are defined in Section 5.3. 455 3.1.2. QoS Models and QoS Specifications 457 The QoS NSLP provides flexibility over the exact patterns of 458 signaling messages that are exchanged. The decoupling of QoS NSLP 459 and QSPEC allows the QoS NSLP to be ignorant about the ways in which 460 traffic, resources, etc. are described, and it can treat the QSPEC as 461 an opaque object. Various QoS models can be designed, and these do 462 not affect the specification of the QoS NSLP protocol. Only the RMF 463 specific to a given QoS model will need to interpret the QSPEC. The 464 Resource Management Function (RMF) reserves resources for each flow. 466 The QSPEC fulfills a similar purpose to the TSpec, RSpec and AdSpec 467 objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC 468 2210 [RFC2210]. At each QNE, the content of the QSPEC is interpreted 469 by the Resource Management Function and the Policy Control Function 470 for the purposes of traffic and policy control (including admission 471 control and configuration of the packet classifier and scheduler). 473 The QoS NSLP does not mandate any particular behavior for the RMF, 474 instead providing interoperability at the signaling protocol level 475 whilst leaving the validation of RMF behavior to contracts external 476 to the protocol itself. The RMF may make use of various elements 477 from the QoS NSLP message, not only the QSPEC object. 479 Still, this specification assumes that resource sharing is possible 480 between flows with the same SESSION_ID that originate from the same 481 QNI or between flows with a different SESSION_ID that are related 482 through the BOUND_SESSION_ID object. For flows with the same 483 SESSION_ID, resource sharing is only applicable when the existing 484 reservation is not just replaced (which is indicated by the REPLACE 485 flag in the common header). We assume that the QoS model supports 486 resource sharing between flows. A QoS Model may elect to implement a 487 more general behavior of supporting relative operations on existing 488 reservations, such as ADDING or SUBTRACTING a certain amount of 489 resources from the current reservation. A QoS Model may also elect 490 to allow resource sharing more generally, e.g., between all flows 491 with the same Differentiated Service Code Point (DSCP). 493 The QSPEC carries a collection of objects that can describe QoS 494 specifications in a number of different ways. A generic template is 495 defined in [I-D.ietf-nsis-qspec] and contains object formats for 496 generally useful elements of the QoS description, which is designed 497 to ensure interoperability when using the basic set of objects. A 498 QSPEC describing the resources requested will usually contain objects 499 which need to be understood by all implementations, and it can also 500 be enhanced with additional objects specific to a QoS model to 501 provide a more exact definition to the RMF, which may be better able 502 to use its specific resource management mechanisms (which may, e.g., 503 be link specific) as a result. 505 A QoS Model defines the behavior of the RMF, including inputs and 506 outputs, and how QSPEC information is used to describe resources 507 available, resources required, traffic descriptions, and control 508 information required by the RMF. A QoS Model also describes the 509 minimum set of parameters QNEs should use in the QSPEC when signaling 510 about this QoS Model. 512 QoS Models may be local (private to one network), implementation/ 513 vendor specific, or global (implementable by different networks and 514 vendors). All QSPECs should follow the design of the QSPEC template. 516 The definition of a QoS model may also have implications on how local 517 behavior should be implemented in the areas where the QoS NSLP gives 518 freedom to implementers. For example, it may be useful to identify 519 recommended behavior for how a RESERVE message that is forwarded 520 relates to that received, or when additional signaling sessions 521 should be started based on existing sessions, such as required for 522 aggregate reservations. In some cases, suggestions may be made on 523 whether state that may optionally be retained should be held in 524 particular scenarios. A QoS model may specify reservation 525 preemption, e.g., an incoming resource request may cause removal of 526 an earlier established reservation. 528 3.1.3. Policy Control 530 Getting access to network resources, e.g., network access in general 531 or access to QoS, typically involves some kind of policy control. 532 One example of this is authorization of the resource requester. 533 Policy control for QoS NSLP resource reservation signaling is 534 conceptually organized as illustrated below in Figure 3. 536 +-------------+ 537 | Policy | 538 | Decision | 539 | Point (PDP) | 540 +------+------+ 541 | 542 /-\-----+-----/\ 543 //// \\\\ 544 || || 545 | Policy transport | 546 || || 547 \\\\ //// 548 \-------+------/ 549 | 550 +-------------+ QoS signaling +------+------+ 551 | Entity |<==============>| QNE = Policy|<=========> 552 | requesting | Data Flow | Enforcement | 553 | resource |----------------|-Point (PEP)-|----------> 554 +-------------+ +-------------+ 556 Figure 3: Policy control with the QoS NSLP signaling 558 From the QoS NSLP point of view, the policy control model is 559 essentially a two-party model between neighboring QNEs. The actual 560 policy decision may depend on the involvement of a third entity (the 561 policy decision point, PDP), but this happens outside of the QoS NSLP 562 protocol by means of existing policy infrastructure (COPS, Diameter, 563 etc). The policy control model for the entire end-to-end chain of 564 QNEs is therefore one of transitivity, where each of the QNEs 565 exchanges policy information with its QoS NSLP policy peer. 567 The authorization of a resource request often depends on the identity 568 of the entity making the request. Authentication may be required. 569 The GIST channel security mechanisms provide one way of 570 authenticating the QoS NSLP peer which sent the request, and so may 571 be used in making the authorization decision. 573 Additional information might also be provided in order to assist in 574 making the authorization decision. This might include alternative 575 methods of authenticating the request. 577 The QoS NSLP does not currently contain objects to carry 578 authorization information. At the time of writing, there exists a 579 separate individual work [I-D.manner-nsis-nslp-auth] that defines 580 this functionality for the QoS NSLP and the NATFW NSLP. 582 It is generally assumed that policy enforcement is likely to 583 concentrate on border nodes between administrative domains. This may 584 mean that nodes within the domain are "Policy Ignorant Nodes" that 585 perform no per-request authentication or authorization, relying on 586 the border nodes to perform the enforcement. In such cases, the 587 policy management between ingress and egress edge of a domain relies 588 on the internal chain of trust between the nodes in the domain. If 589 this is not acceptable, a separate signaling session can be set up 590 between the ingress and egress edge nodes in order to exchange policy 591 information. 593 3.2. Design Background 595 This section presents some of the key functionality behind the 596 specification of the QoS NSLP. 598 3.2.1. Soft States 600 The NSIS protocol suite takes a soft-state approach to state 601 management. This means that reservation state in QNEs must be 602 periodically refreshed. The frequency with which state installation 603 is refreshed is expressed in the REFRESH_PERIOD object. This object 604 contains a value in milliseconds indicating how long the state that 605 is signaled for remains valid. Maintaining the reservation beyond 606 this lifetime can be done by sending a RESERVE message periodically. 608 3.2.2. Sender and Receiver Initiation 610 The QoS NSLP supports both sender-initiated and receiver-initiated 611 reservations. For a sender-initiated reservation, RESERVE messages 612 travel in the same direction as the data flow that is being signaled 613 for (the QNI is at the side of the source of the data flow). For a 614 receiver-initiated reservation, RESERVE messages travel in the 615 opposite direction (the QNI is at the side of the receiver of the 616 data flow). 618 Note: these definitions follow the definitions in Section 3.3.1. of 619 RFC 4080 [RFC4080]. The main issue is, which node is in charge of 620 requesting and maintaining the resource reservation. In a receiver- 621 initiated reservation, even though the sender sends the initial 622 QUERY, the receiver is still in charge of making the actual resource 623 request, and maintaining the reservation. 625 3.2.3. Protection Against Message Re-ordering and Duplication 627 RESERVE messages affect the installed reservation state. Unlike 628 NOTIFY, QUERY and RESPONSE messages, the order in which RESERVE 629 messages are received influences the eventual reservation state that 630 will be stored at a QNE, that is, the most recent RESERVE message 631 replaces the current reservation. Therefore, in order to protect 632 against RESERVE message re-ordering or duplication, the QoS NSLP uses 633 a Reservation Sequence Number (RSN). The RSN has local significance 634 only, i.e., between a QNE and its downstream peers. 636 3.2.4. Explicit Confirmations 638 A QNE may require a confirmation that the end-to-end reservation is 639 in place, or a reply to a query along the path. For such requests, 640 it must be able to keep track of which request each response refers 641 to. This is supported by including a Request Identification 642 Information (RII) object in a QoS NSLP message. 644 3.2.5. Reduced Refreshes 646 For scalability, the QoS NSLP supports an abbreviated form of refresh 647 RESERVE message. In this case, the refresh RESERVE references the 648 reservation using the RSN and the SESSION_ID, and does not include 649 the full reservation specification (including QSPEC). By default 650 state refresh should be performed with reduced refreshes in order to 651 save bytes during transmission. Stateless QNEs will require full 652 refresh since they do not store the whole reservation information. 654 If the stateful QNE does not support reduced refreshes, or there is a 655 mismatch between the local and received RSN, the stateful QNE must 656 reply with an RESPONSE carrying an INFO_SPEC indicating the error. 657 Furthermore, the QNE must stop sending reduced refreshes to this peer 658 if the error indicates lacking support for this feature. 660 3.2.6. Summary Refreshes and Summary Tear 662 For limiting the number of individual messages, the QoS NSLP supports 663 a summary refresh and summary tear messages. When sending a 664 refreshing RESERVE for a certain (primary) session, a QNE may include 665 a SESSION_ID_LIST object where the QNE indicates (secondary) sessions 666 that are also refreshed. An RSN_LIST object must also be added. The 667 SESSION IDs and RSNs are stacked in the objects such that the index 668 in both stacks refer to the same reservation state, i.e., the 669 SESSION_ID and RSN at index i in both objects refers to the same 670 session. If the receiving stateful QNE notices unknown SESSION IDs 671 or a mismatch with RSNs for a session, it will reply back to the 672 upstream stateful QNE with an error. 674 In order to tear down several sessions at once, a QNE may include 675 SESSION_ID_LIST and RSN_LIST objects in a tearing reserve. The 676 downstream stateful QNE must then also tear the other sessions 677 indicated. The downstream stateful QNE must silently ignore any 678 unknown SESSION IDs. 680 GIST provides a SII_HANDLE for every downstream session. The 681 SII_HANDLE identifies a peer, and should be the same for all sessions 682 whose downstream peer is the same. The QoS NSLP uses this 683 information to decide whether summary refresh messages can be sent, 684 or when a summary tear is possible. 686 3.2.7. Message Scoping 688 A QNE may use local policy when deciding whether to propagate a 689 message or not. For example, the local policy can define/configure 690 that a QNE is, for a particular session, a QNI and/or a QNR. The QoS 691 NSLP also includes an explicit mechanism to restrict message 692 propagation by means of a scoping mechanism. 694 For a RESERVE or a QUERY message, two scoping flags limit the part of 695 the path on which state is installed on the downstream nodes that can 696 respond. When the SCOPING flag is set to zero, it indicates that the 697 scope is "whole path" (default). When set to one, the scope is 698 "single hop". When the PROXY scope flag is set, the path is 699 terminated at a pre-defined Proxy QNE (P-QNE). This is similar to 700 the Localized RSVP [lrsvp]. 702 The propagation of a RESPONSE message is limited by the RII object, 703 which ensures that it is not forwarded back along the path further 704 than the node that requested the RESPONSE. 706 3.2.8. Session Binding 708 Session binding is defined as the enforcement of a relation between 709 different QoS NSLP sessions (i.e., signaling flows with different 710 SESSION_ID (SID) as defined in GIST [I-D.ietf-nsis-ntlp]). 712 Session binding indicates an unidirectional dependency relation 713 between two or more sessions by including a BOUND_SESSION_ID object. 714 A session with SID_A (the binding session) can express its 715 unidirectional dependency relation to another session with SID_B (the 716 bound session) by including a BOUND_SESSION_ID object containing 717 SID_B in its messages. 719 The concept of session binding is used to indicate the unidirectional 720 dependency relation between the end-to-end session and the aggregate 721 session in case of aggregate reservations. In case of bidirectional 722 reservations, it is used to express the unidirectional dependency 723 relation between the sessions used for forward and reverse 724 reservation. Typically, the dependency relation indicated by session 725 binding is purely informative in nature and does not automatically 726 trigger any implicit action in a QNE. A QNE may use the dependency 727 relation information for local resource optimization or to explicitly 728 tear down reservations that are no longer useful. However, by using 729 an explicit binding code, see Section 5.1.3.4, it is possible to 730 formalise this dependency relation, meaning that if the bound session 731 (e.g., session with SID_B) is terminated also the binding session 732 (e.g., the session with SID_A) must be terminated. 734 A message may include more than one BOUND_SESSION_ID object. This 735 may happen, e.g., in certain aggregation and bi-directional 736 reservation scenarios, where an end-to-end session has an 737 unidirectional dependency relation with an aggregate session and at 738 the same time it has an unidirectional dependency relation with 739 another session used for the reverse path. 741 3.2.9. Message Binding 743 QoS NSLP supports binding of messages in order to allow for 744 expressing dependencies between different messages. The message 745 binding can indicate either a unidirectional or bidirectional 746 dependency relation between two messages by including in one of the 747 message the MSG_ID object ("binding message") and in the other 748 message ("bound message") the BOUND_MSG_ID object. The 749 unidirectional dependency means that only RESERVE messages are bound 750 to each other whereas a bidirectional dependency means that there is 751 also a dependency for the related RESPONSE messages. The message 752 binding can be used to speed up signaling by starting two signaling 753 exchanges simultaneously that are synchronized later by using message 754 IDs. This can be used as an optimization technique for example in 755 scenarios where aggregate reservations are used. Section 4.6 756 provides more details. 758 3.2.10. Layering 760 The QoS NSLP supports layered reservations. Layered reservations may 761 occur when certain parts of the network (domains) implement one or 762 more local QoS models, or when they locally apply specific transport 763 characteristics (e.g., GIST unreliable transfer mode instead of 764 reliable transfer mode). They may also occur when several per-flow 765 reservations are locally combined into an aggregate reservation. 767 3.2.10.1. Local QoS Models 769 A domain may have local policies regarding QoS model implementation, 770 i.e., it may map incoming traffic to its own locally defined QoS 771 models. The QSPEC allows this functionality, and the operation is 772 transparent to the QoS NSLP. The use of local QoS models within a 773 domain is performed in the RMF. 775 3.2.10.2. Local Control Plane Properties 777 The way signaling messages are handled is mainly determined by the 778 parameters that are sent over GIST-NSLP API and by the domain 779 internal configuration. A domain may have a policy to implement 780 local transport behavior. It may, for instance, elect to use an 781 unreliable transport locally in the domain while still keeping end- 782 to-end reliability intact. 784 The QoS NSLP supports this situation by allowing two sessions to be 785 set up for the same reservation. The local session has the desired 786 local transport properties and is interpreted in internal QNEs. This 787 solution poses two requirements: the end-to-end session must be able 788 to bypass intermediate nodes and the egress QNE needs to bind both 789 sessions together. Bypassing intermediate nodes is achieved with 790 GIST. The local session and the end-to-end session are bound at the 791 egress QNE by means of the BOUND_SESSION_ID object. 793 3.2.10.3. Aggregate Reservations 795 In some cases it is desirable to create reservations for an 796 aggregate, rather than on a per-flow basis, in order to reduce the 797 amount of reservation state needed, as well as, the processing load 798 for signaling messages. Note that the QoS NSLP does not specify how 799 reservations need to be combined in an aggregate or how end-to-end 800 properties need to be computed but only provides signaling support 801 for it. 803 The essential difference with the layering approaches described in 804 Section 3.2.10.1 and Section 3.2.10.2 is that the aggregate 805 reservation needs a MRI that describes all traffic carried in the 806 aggregate (e.g., a DSCP in case of IntServ over DiffServ). The need 807 for a different MRI mandates the use of two different sessions, 808 similar to Section 3.2.10.3 and to the RSVP aggregation solution in 809 RFC 3175 [RFC3175]. 811 Edge QNEs of the aggregation domain that want to maintain some end- 812 to-end properties may establish a peering relation by sending the 813 end-to-end message transparently over the domain (using the 814 intermediate node bypass capability described above). Updating the 815 end-to-end properties in this message may require some knowledge of 816 the aggregated session (e.g., for updating delay values). For this 817 purpose, the end-to-end session contains a BOUND_SESSION_ID carrying 818 the SESSION_ID of the aggregate session. 820 3.2.11. Support for Request Priorities 822 This specification acknowledges the fact that in some situations, 823 some messages or some reservations may be more important than others 824 and therefore foresees mechanisms to give these messages or 825 reservations priority. 827 Priority of certain signaling messages over others may be required in 828 mobile scenarios when a message loss during call set-up is less 829 harmful than during handover. This situation only occurs when GIST 830 or QoS NSLP processing is the congested part or scarce resource. 832 Priority of certain reservations over others may be required when QoS 833 resources are oversubscribed. In that case, existing reservations 834 may be preempted in order to make room for new higher-priority 835 reservations. A typical approach to deal with priority and 836 preemption is through the specification of a setup priority and 837 holding priority for each reservation. The resource management 838 function at each QNE then keeps track of the resource consumption at 839 each priority level. Reservations are established when resources, at 840 their setup priority level, are still available. They may cause 841 preemption of reservations with a lower holding priority than their 842 setup priority. 844 Support of reservation priority is a QSPEC parameter and therefore 845 outside the scope of this specification. The GIST specification 846 provides a mechanism to support a number of levels of message 847 priority that can be requested over the NSLP-GIST API. 849 3.2.12. Rerouting 851 The QoS NSLP needs to adapt to route changes in the data path. This 852 assumes the capability to detect rerouting events, create a QoS 853 reservation on the new path and optionally tear down reservations on 854 the old path. 856 From an NSLP perspective, rerouting detection can be performed in two 857 ways. It can either come through NetworkNotification from GIST, or 858 from information seen at the NSLP. In the latter case, the QoS NSLP 859 node is able to detect changes in its QoS NSLP peers by keeping track 860 of a Source Identification Information (SII) handle that provides 861 information similar in nature to the RSVP_HOP object described in RFC 862 2205 [RFC2205]. When a RESERVE message with an existing SESSION_ID 863 and a different SII is received, the QNE knows its upstream or 864 downstream peer has changed, for sender-oriented and receiver- 865 oriented reservations, respectively. 867 Reservation on the new path happens when a RESERVE message arrives at 868 the QNE beyond the point where the old and new paths diverge. If the 869 QoS NSLP suspects that a reroute has occurred, then a full RESERVE 870 message (including the QSPEC) would be sent. A refreshing RESERVE 871 (with no QSPEC) will be identified as an error by a QNE on the new 872 path which does not have the reservation installed (i.e. it was not 873 on the old path) or which previously had a different previous-hop 874 QNE. It will send back an error message which results in a full 875 RESERVE message being sent. Rapid recovery at the NSLP layer 876 therefore requires short refresh periods. Detection before the next 877 RESERVE message arrives is only possible at the IP layer or through 878 monitoring of GIST peering relations (e.g., by TTL counting the 879 number of GIST hops between NSLP peers or the observing changes in 880 the outgoing interface towards GIST peer). These mechanisms can 881 provide implementation specific optimizations, and are outside the 882 scope of this specification. 884 When the QoS NSLP is aware of the route change, it needs to set up 885 the reservation on the new path. This is done by sending a new 886 RESERVE message. If the next QNE is, in fact, unchanged then this 887 will be used to refresh/update the existing reservation. Otherwise 888 it will lead to the reservation being installed on the new path. 890 Note that the operation for a receiver-initiated reservation session 891 differs a bit from the above description. If the routing changes in 892 the middle of the path, the QNE that notices that its downstream path 893 changed (indicated by a NetworkNotification from GIST), the 894 divergence point, must send a QUERY with the R-flag downstream. It 895 will be processed as above, and at some point hits a QNE for which 896 the path downstream towards the QNI remains (the convergence point). 897 This node must then send a full RESERVE upstream to set up the 898 reservation state along the new path. It should not send the QUERY 899 further downstream, since this would have no real use. Similarly, 900 when the QNE that sent the QUERY receives the RESERVE, it should not 901 send the RESERVE further upstream. 903 After the reservation on the new path is set up, the branching node 904 may want to tear down the reservation on the old path (sooner than 905 would result from normal soft-state time-out). This functionality is 906 supported by keeping track of the old SII-Handle provided over the 907 GIST API. This handle can be used by the QoS NSLP to route messages 908 explicitly to the next node. 910 If the old path is downstream, the QNE can send a tearing RESERVE 911 using the old SII-Handle. If the old path is upstream, the QNE can 912 send a NOTIFY with the code for "Route Change". This is forwarded 913 upstream until it hits a QNE that can issue a tearing RESERVE 914 downstream. A separate document discusses in detail the effect of 915 mobility on the QoS NSLP signaling 916 [I-D.ietf-nsis-applicability-mobility-signaling]. 918 A QNI or a branch node may wish to keep the reservation on the old 919 branch. This could for instance be the case when a mobile node has 920 experienced a mobility event and wishes to keep reservation to its 921 old attachment point in case it moves back there. For this purpose, 922 a REPLACE flag is provided in the QoS NSLP common header, which, when 923 not set, indicates that the reservation on the old branch should be 924 kept. 926 Note that keeping old reservations affects the resources available to 927 other nodes. Thus, the operator of the access network must make the 928 final decision on whether this behavior is allowed. Also, the QNEs 929 in the access network may add this flag even if the mobile node has 930 not used the flag initially. 932 The latency in detecting that a new down stream peer exist, or that 933 truncation has happened depends on GIST. The default Query message 934 transmission interval is 30 seconds. More details on how NSLPs are 935 able to affect the discovery of new peers or rerouting can be found 936 in the GIST specification. 938 3.2.12.1. Last Node Behavior 940 The design of the QoS NSLP allows reservations to be installed at a 941 subset of the nodes along a path. In particular, usage scenarios 942 include cases where the data flow endpoints do not support the QoS 943 NSLP. 945 In the case where the data flow receiver does not support the QoS 946 NSLP, some particular considerations must be given to node discovery 947 and rerouting at the end of the signaling path. 949 There are three cases for the last node on the signaling path: 1) 950 Last node is the data receiver 2) Last node is a configured proxy for 951 the data receiver 3) Last node is not the data receiver and is not 952 explicitly configured to act as a signaling proxy on behalf of the 953 data receiver. 955 Cases (1) and (2) can be handled by the QoS NSLP itself during the 956 initial path setup, since the QNE knows that it should terminate the 957 signaling. Case (3) requires some assistance from GIST which 958 provides messages across the API to indicate that no further QoS NSLP 959 supporting GIST nodes are present downstream, and downstream route 960 change probing needs to continue once the reservation is installed to 961 detect any changes in this situation. 963 Two particular scenarios need to be considered in this third case. 964 In the first, referred to as "Path Extension", rerouting occurs such 965 that an additional QNE is inserted into the signaling path between 966 the old last node and the data receiver, as shown in Figure 4. 968 /-------\ Initial route 969 / v 970 /-\ 971 /--|B|--\ +-+ 972 / \-/ \ |x| = QoS NSLP aware 973 +-+ /-\ +-+ 974 ----|A| |D| 975 +-+ \-/ /-\ 976 \ +-+ / |x| = QoS NSLP unaware 977 \--|C|--/ \-/ 978 +-+ 979 \ ^ 980 \-------/ Updated route 982 Figure 4: Path Extension 984 When rerouting occurs, the data path changes from A-B-D to A-C-D. 985 Initially the signaling path ends at A. Despite initially being the 986 last node, node A needs to continue to attempt to send messages 987 downstream to probe for path changes, unless it has been explicitly 988 configured as a signaling proxy for the data flow receiver. This is 989 required so that the signaling path change is detected, and C will 990 become the new last QNE. 992 In a second case, referred to as "Path Truncation", rerouting occurs 993 such that the QNE that was the last node on the signaling path is no 994 longer on the data path. This is shown in Figure 5. 996 /-------\ Initial route 997 / v 998 +-+ 999 /--|B|--\ +-+ 1000 / +-+ \ |x| = QoS NSLP aware 1001 +-+ /-\ +-+ 1002 ----|A| |D| 1003 +-+ \-/ /-\ 1004 \ /-\ / |x| = QoS NSLP unaware 1005 \--|C|--/ \-/ 1006 \-/ 1007 \ ^ 1008 \-------/ Updated route 1010 Figure 5: Path Truncation 1012 When rerouting occurs, the data path again changes from A-B-D to A-C- 1013 D. The signaling path initially ends at B, but this node is not on 1014 the new path. In this case, the normal GIST path change detection 1015 procedures at A will detect the path change and notify the QoS NSLP. 1016 GIST will also notify the signaling application that no downstream 1017 GIST nodes supporting the QoS NSLP are present. Node A will take 1018 over as the last node on the signaling path. 1020 3.2.12.2. Handling Spurious Route Change Notifications 1022 The QoS NSLP is notified by GIST (with the NetworkNotification 1023 primitive) when GIST believes that a rerouting event may have 1024 occurred. In some cases, events that are detected as possible route 1025 changes will turn out not to be. The QoS NSLP will not always be 1026 able to detect this, even after receiving messages from the 'new' 1027 peer. 1029 As part of the RecvMessage API primitive, GIST provides an SII-Handle 1030 which can be used by the NSLP to direct a signaling message to a 1031 particular peer. The current SII-Handle will change if the signaling 1032 peer changes. However, it is not guaranteed to remain the same after 1033 a rerouting event where the peer does not change. Therefore, the QoS 1034 NSLP mechanism for reservation maintenance after a route change 1035 includes robustness mechanisms to avoid accidentally tearing down a 1036 reservation in situations where the peer QNE has remained the same 1037 after a 'route change' notification from GIST. 1039 A simple example that illustrates the problem is shown in Figure 6 1040 below. 1042 (1) +-+ 1043 /-----\ |x| = QoS NSLP aware 1044 +-+ /-\ (3) +-+ +-+ 1045 ----|A| |B|-----|C|---- 1046 +-+ \-/ +-+ /-\ 1047 \-----/ |x| = QoS NSLP unaware 1048 (2) \-/ 1050 Figure 6: Spurious reroute alerting 1052 In this example the initial route A-B-C uses links (1) and (3). 1053 After link (1) fails, the path is rerouted using links (2) and (3). 1054 The set of QNEs along the path is unchanged (it is A-C in both cases, 1055 since B does not support the QoS NSLP). 1057 When the outgoing interface at A has changes, GIST may signal across 1058 its API to the NSLP with a NetworkNotification. The QoS NSLP at A 1059 will then attempt to repair the path by installing the reservation on 1060 the path (2),(3). In this case, however, the old and new paths are 1061 the same. 1063 To install the new reservation A will send a RESERVE message, which 1064 GIST will transport to C (discovering the new next peer as 1065 appropriate). The RESERVE also requests a RESPONSE from the QNR. 1066 When this RESERVE message is received through the RecvMessage API 1067 call from GIST at the QoS NSLP at C, the SII-Handle will be unchanged 1068 from its previous communications from A. 1070 A RESPONSE message will be sent by the QNR, and be forwarded from C 1071 to A. This confirms that the reservation was installed on the new 1072 path. The SII-Handle passed with the RecvMessage call from GIST to 1073 the QoS NSLP will be different to that seen previously, since the 1074 interface being used on A has changed. 1076 At this point A can attempt to tear down the reservation on the old 1077 path. The RESERVE message with the TEAR flag set is sent down the 1078 old path by using the GIST explicit routing mechanism and specifying 1079 the SII-Handle relating to the 'old' peer QNE. 1081 If RSNs were being incremented for each of these RESERVE and RESERVE- 1082 with-TEAR messages the reservation would be torn down at C and any 1083 QNEs further along the path. To avoid this the RSN is used in a 1084 special way. The RESERVE down the new path is sent with the new 1085 current RSN set to the old RSN plus 2. The RESERVE-with-TEAR down 1086 the old path is sent with an RSN set to the new current RSN minus 1. 1087 This is the peer from which it was receiving RESERVE messages (see 1088 Section 5.2.5.2 for more details). 1090 3.2.13. Pre-emption 1092 The QoS NSLP provides building blocks to implement pre-emption. This 1093 specification does not define how pre-emption should work, but only 1094 provides signaling mechanisms that can be used by QoS Models. For 1095 example, an INFO_SPEC object can be added to messages to indicate 1096 that the signaled session was pre-empted. A BOUND_SESSION_ID object 1097 can carry the Session ID of the flow that caused the pre-emption to 1098 happen for the signaled session. How these are used by QoS Models is 1099 out of scope of the QoS NSLP specification. 1101 3.3. GIST Interactions 1103 The QoS NSLP uses GIST for delivery of all its messages. Messages 1104 are passed from the NSLP to GIST via an API (defined in Appendix B of 1105 [I-D.ietf-nsis-ntlp]), which also specifies additional information, 1106 including an identifier for the signaling application (e.g., 'QoS 1107 NSLP'), session identifier, MRI, and an indication of the intended 1108 direction - towards data sender or receiver. On reception, GIST 1109 provides the same information to the QoS NSLP. In addition to the 1110 NSLP message data itself, other meta-data (e.g. session identifier 1111 and MRI) can be transferred across this interface. 1113 The QoS NSLP keeps message and reservation state per session. A 1114 session is identified by a Session Identifier (SESSION_ID). The 1115 SESSION_ID is the primary index for stored NSLP state and needs to be 1116 constant and unique (with a sufficiently high probability) along a 1117 path through the network. The QoS NSLP picks a value for Session-ID. 1119 This value is subsequently used by GIST and the QoS NSLP to refer to 1120 this session. 1122 Currently, the QoS NSLP specification considers mainly the path- 1123 coupled MRM. However, extensions may specify how other types of MRMs 1124 may be applied in combination with the QoS NSLP. 1126 When GIST passes the QoS NSLP data to the NSLP for processing, it 1127 must also indicate the value of the 'D' (Direction) flag for that 1128 message in the MRI. 1130 The QoS NSLP does not provide any method of interacting with 1131 firewalls or Network Address Translators (NATs). It assumes that a 1132 basic NAT traversal service is provided by GIST. 1134 3.3.1. Support for Bypassing Intermediate Nodes 1136 The QoS NSLP may want to restrict the handling of its messages to 1137 specific nodes. This functionality is needed to support layering 1138 (explained in Section 3.2.10), when only the edge QNEs of a domain 1139 process the message. This requires a mechanism at GIST level (which 1140 can be invoked by the QoS NSLP) to bypass intermediate nodes between 1141 the edges of the domain. 1143 The intermediate nodes are bypassed using multiple levels of the 1144 router alert option. In that case, internal routers are configured 1145 to handle only certain levels of router alerts. This is accomplished 1146 by marking the signaling messages, i.e., modifying the QoS NSLP 1147 default NSLP-ID value to another NSLP-ID predefined value. The 1148 marking is accomplished by the ingress edge by modifying the QoS NSLP 1149 default NSLP-ID value to a NSLP-ID predefined value, see Section 6.6. 1150 The egress stops this marking process by reassigning the QoS NSLP 1151 default NSLP-ID value to the original RESERVE message. The exact 1152 operation of modifying the NSLP-ID must be specified in the relevant 1153 QoS model specification. 1155 3.3.2. Support for Peer Change Identification 1157 There are several circumstances where it is necessary for a QNE to 1158 identify the adjacent QNE peer, which is the source of a signaling 1159 application message; e.g., it may be to apply the policy that "state 1160 can only be modified by messages from the node that created it" or it 1161 might be that keeping track of peer identity is used as a (fallback) 1162 mechanism for rerouting detection at the NSLP layer. 1164 This functionality is implemented in GIST service interface with SII- 1165 handle. As shown in the above example, we assume the SII- handling 1166 will support both own SII and peer SII. 1168 Keeping track of the SII of a certain reservation also provides a 1169 means for the QoS NSLP to detect route changes. When a QNE receives 1170 a RESERVE referring to existing state but with a different SII, it 1171 knows that its upstream peer has changed. It can then use the old 1172 SII to initiate a teardown along the old section of the path. This 1173 functionality is supported in GIST service interface when the peer's 1174 SII which is stored on message reception is passed to GIST upon 1175 message transmission. 1177 3.3.3. Support for Stateless Operation 1179 Stateless or reduced state QoS NSLP operation makes the most sense 1180 when some nodes are able to operate in a stateless way at GIST level 1181 as well. Such nodes should not worry about keeping reverse state, 1182 message fragmentation and reassembly (at GIST), congestion control or 1183 security associations. A stateless or reduced state QNE will be able 1184 to inform the underlying GIST of this situation. GIST service 1185 interface supports this functionality with the Retain-State attribute 1186 in the MessageReceived primitive. 1188 3.3.4. Priority of Signaling Messages 1190 The QoS NSLP will generate messages with a range of performance 1191 requirements for GIST. These requirements may result from a 1192 prioritization at the QoS NSLP (Section 3.2.11) or from the 1193 responsiveness expected by certain applications supported by the QoS 1194 NSLP. GIST service interface supports this with the 'priority' 1195 transfer attribute. 1197 3.3.5. Knowledge of Intermediate QoS NSLP Unaware Nodes 1199 In some cases it is useful to know that there are routers along the 1200 path where QoS cannot be provided. The GIST service interface 1201 supports this by keeping track of IP-TTL and Original-TTL in the 1202 RecvMessage primitive. A difference between the two indicates the 1203 number of QoS NSLP unaware nodes. In this case the QNE that detects 1204 this difference should set the "B" (BREAK) flag. If a QNE generates 1205 a QUERY, RESERVE or RESPONSE message, after receiving a QUERY or 1206 RESERVE message with a "Break" flag set, it can set the "B" (BREAK) 1207 flag in these messages. There are however, situations where the 1208 egress QNE in a local domain may have some other means to provide QoS 1209 [I-D.ietf-nsis-qspec]. For example, in an RMD-QOSM 1210 [I-D.ietf-nsis-rmd] (or RMD-QOSM like) aware local domain that uses 1211 either NTLP stateless nodes or NSIS unaware nodes the end to end 1212 RESERVE or QUERY message bypasses these NTLP stateless or NSIS 1213 unaware nodes. However, the reservation within the local domain can 1214 be signaled by the RMD-QOSM (or RMD-QOSM like QOSM). In such 1215 situations, the "B" (BREAK) flag in the end to end RESERVE or QUERY 1216 message should not be set by the edges of the local domain. 1218 4. Examples of QoS NSLP Operation 1220 The QoS NSLP can be used in a number of ways. The examples given 1221 here give an indication of some of the basic processing. However, 1222 they are not exhaustive and do not attempt to cover the details of 1223 the protocol processing. 1225 4.1. Sender-initiated Reservation 1227 QNI QNE QNE QNR 1228 | | | | 1229 | RESERVE | | | 1230 +--------->| | | 1231 | | RESERVE | | 1232 | +--------->| | 1233 | | | RESERVE | 1234 | | +--------->| 1235 | | | | 1236 | | | RESPONSE | 1237 | | |<---------+ 1238 | | RESPONSE | | 1239 | |<---------+ | 1240 | RESPONSE | | | 1241 |<---------+ | | 1242 | | | | 1243 | | | | 1245 Figure 7: Basic Sender Initiated Reservation 1247 To make a new reservation, the QNI constructs a RESERVE message 1248 containing a QSPEC object, from its chosen QoS model, which describes 1249 the required QoS parameters. 1251 The RESERVE message is passed to GIST which transports it to the next 1252 QNE. There it is delivered to the QoS NSLP processing which examines 1253 the message. Policy control and admission control decisions are 1254 made. The exact processing also takes into account the QoS model 1255 being used. The node performs appropriate actions (e.g., installing 1256 reservation) based on the QSPEC object in the message. 1258 The QoS NSLP then generates a new RESERVE message (usually based on 1259 the one received). This is passed to GIST, which forwards it to the 1260 next QNE. 1262 The same processing is performed at further QNEs along the path, up 1263 to the QNR. The determination that a node is the QNR may be made 1264 directly (e.g., that node is the destination for the data flow), or 1265 using GIST functionality to determine that there are no more QNEs 1266 between this node and the data flow destination. 1268 Any node may include a request for a RESPONSE in its RESERVE 1269 messages. It does so by including a Request Identification 1270 Information (RII) object in the RESERVE message. If the message 1271 already includes an RII, an interested QNE must not add a new RII 1272 object nor replace the old RII object. Instead it needs to remember 1273 the RII value so that it can match a RESPONSE message belonging to 1274 the RESERVE. When it receives the RESPONSE, it forwards the RESPONSE 1275 upstream towards the RII originating node. 1277 In this example, the RESPONSE message is forwarded peer-to-peer along 1278 the reverse of the path that the RESERVE message took (using GIST 1279 path state), and so is seen by all the QNEs on this segment of the 1280 path. It is only forwarded as far as the node which requested the 1281 RESPONSE originally. 1283 The reservation can subsequently be refreshed by sending further 1284 RESERVE messages containing the complete reservation information, as 1285 for the initial reservation. The reservation can also be modified in 1286 the same way, by changing the QSPEC data to indicate a different set 1287 of resources to reserve. 1289 The overhead required to perform refreshes can be reduced, in a 1290 similar way to that proposed for RSVP in RFC 2961 [RFC2961]. Once a 1291 RESPONSE message has been received indicating the successful 1292 installation of a reservation, subsequent refreshing RESERVE messages 1293 can simply refer to the existing reservation, rather than including 1294 the complete reservation specification. 1296 4.2. Sending a Query 1298 QUERY messages can be used to gather information from QNEs along the 1299 path. For example, they can be used to find out what resources are 1300 available before a reservation is made. 1302 In order to perform a query along a path, the QNE constructs a QUERY 1303 message. This message includes a QSPEC containing the actual query 1304 to be performed at QNEs along the path. It also contains an RII 1305 object used to match the response back to the query, and an indicator 1306 of the query scope (next node, whole path, proxy). The QUERY message 1307 is passed to GIST to forward it along the path. 1309 A QNE receiving a QUERY message should inspect it and create a new 1310 message, based on that received with the query objects modified as 1311 required. For example, the query may request information on whether 1312 a flow can be admitted, and so a node processing the query might 1313 record the available bandwidth. The new message is then passed to 1314 GIST for further forwarding (unless it knows it is the QNR, or is the 1315 limit for the scope in the QUERY). 1317 At the QNR, a RESPONSE message must be generated if the QUERY message 1318 includes a Request Identification Information (RII) object. Various 1319 objects from the received QUERY message have to be copied into the 1320 RESPONSE message. It is then passed to GIST to be forwarded peer-to- 1321 peer back along the path. 1323 Each QNE receiving the RESPONSE message should inspect the RII object 1324 to see if it 'belongs' to it (i.e., it was the one that originally 1325 created it). If it does not then it simply passes the message back 1326 to GIST to be forwarded upstream. 1328 If there was an error in processing a RESERVE, instead of an RII, the 1329 RESPONSE may carry an RSN. Thus, a QNE must also be prepared to look 1330 for an RSN object if no RII was present, and act based on the error 1331 code set in the INFO_SPEC of the RESPONSE. 1333 4.3. Basic Receiver-initiated Reservation 1335 As described in the NSIS framework [RFC4080] in some signaling 1336 applications, a node at one end of the data flow takes responsibility 1337 for requesting special treatment - such as a resource reservation - 1338 from the network. Both ends then agree whether sender or receiver- 1339 initiated reservation is to be done. In case of a receiver initiated 1340 reservation, both ends agree whether a "One Pass With Advertising" 1341 (OPWA) [opwa95] model is being used. This negotiation can be 1342 accomplished using mechanisms that are outside the scope of NSIS. 1344 To make a receiver-initiated reservation, the QNR constructs a QUERY 1345 message, which MUST contain a QSPEC object from its chosen QoS model 1346 (see Figure 8). The QUERY must have the RESERVE-INIT flag set. This 1347 QUERY message does not need to trigger a RESPONSE message and 1348 therefore, the QNI must not include the RII object (Section 5.4.2) in 1349 the QUERY message. The QUERY message may be used to gather 1350 information along the path, which is carried by the QSPEC object. An 1351 example of such information is the "One Pass With Advertising" (OPWA) 1352 [opwa95]. This QUERY message causes GIST reverse-path state to be 1353 installed. 1355 QNR QNE QNE QNI 1356 sender receiver 1357 | | | | 1358 | QUERY | | | 1359 +--------->| | | 1360 | | QUERY | | 1361 | +--------->| | 1362 | | | QUERY | 1363 | | +--------->| 1364 | | | | 1365 | | | RESERVE | 1366 | | |<---------+ 1367 | | RESERVE | | 1368 | |<---------+ | 1369 | RESERVE | | | 1370 |<---------+ | | 1371 | | | | 1372 | RESPONSE | | | 1373 +--------->| | | 1374 | | RESPONSE | | 1375 | +--------->| | 1376 | | | RESPONSE | 1377 | | +--------->| 1378 | | | | 1380 Figure 8: Basic Receiver Initiated Reservation 1382 The QUERY message is transported by GIST to the next downstream QoS 1383 NSLP node. There it is delivered to the QoS NSLP processing which 1384 examines the message. The exact processing also takes into account 1385 the QoS model being used and may include gathering information on 1386 path characteristics that may be used to predict the end-to-end QoS. 1388 The QNE generates a new QUERY message (usually based on the one 1389 received). This is passed to GIST, which forwards it to the next 1390 QNE. The same processing is performed at further QNEs along the 1391 path, up to the flow receiver. The receiver detects that this QUERY 1392 message carries the RESERVE-INIT flag and by using the information 1393 contained in the received QUERY message, such as the QSPEC, 1394 constructs a RESERVE message. 1396 The RESERVE is forwarded peer-to-peer along the reverse of the path 1397 that the QUERY message took (using GIST reverse path state). Similar 1398 to the sender-initiated approach, any node may include an RII in its 1399 RESERVE messages. The RESPONSE is sent back to confirm the resources 1400 are set up. The reservation can subsequently be refreshed with 1401 RESERVE messages in the upstream direction. 1403 4.4. Bidirectional Reservations 1405 The term "bidirectional reservation" refers to two different cases 1406 that are supported by this specification: 1408 o Binding two sender-initiated reservations together, e.g., one 1409 sender-initiated reservation from QNE A to QNE B and another one from 1410 QNE B to QNE A ( Figure 9). 1412 o Binding a sender-initiated and a receiver-initiated reservation 1413 together, e.g., a sender-initiated reservation from QNE A towards QNE 1414 B, and a receiver-initiated reservation from QNE A towards QNE B for 1415 the data flow in the opposite direction (from QNE B to QNE A). This 1416 case is particularly useful when one end of the communication has all 1417 required information to set up both sessions ( Figure 10). 1419 Both ends have to agree on which bi-directional reservation type they 1420 need to use. This negotiation can be accomplished using mechanisms 1421 that are outside the scope of NSIS. 1423 The scenario with two sender-initiated reservations is shown in 1424 Figure 9. Note that RESERVE messages for both directions may visit 1425 different QNEs along the path because of asymmetric routing. Both 1426 directions of the flows are bound by inserting the BOUND_SESSION_ID 1427 object at the QNI and QNR. RESPONSE messages are optional and not 1428 shown in the picture for simplicity. 1430 A QNE QNE B 1431 | | FLOW-1 | | 1432 |===============================>| 1433 |RESERVE-1 | | | 1434 QNI+--------->|RESERVE-1 | | 1435 | +-------------------->|QNR 1436 | | | | 1437 | | FLOW-2 | | 1438 |<===============================| 1439 | | |RESERVE-2 | 1440 | RESERVE-2 |<---------+QNI 1441 QNR|<--------------------+ | 1442 | | | | 1444 Figure 9: Bi-directional reservation for sender+sender scenario 1446 The scenario with a sender-initiated and a receiver-initiated 1447 reservation is shown in Figure 10. In this case, QNI A sends out two 1448 RESERVE messages, one for the sender-initiated and one for the 1449 receiver-initiated reservation. Note that the sequence of the two 1450 RESERVE messages may be interleaved. 1452 A QNE QNE B 1453 | | FLOW-1 | | 1454 |===============================>| 1455 |RESERVE-1 | | | 1456 QNI+--------->|RESERVE-1 | | 1457 | +-------------------->|QNR 1458 | | | | 1459 | | FLOW-2 | | 1460 |<===============================| 1461 | | | QUERY-2 | 1462 | | QUERY-2 |<---------+QNR 1463 QNI|<--------------------+ | 1464 | | | | 1465 |RESERVE-2 | | | 1466 QNI+--------->|RESERVE-2 | | 1467 | +-------------------->|QNR 1468 | | | | 1470 Figure 10: Bi-directional reservation for sender+receiver scenario 1472 4.5. Aggregate Reservations 1474 In order to reduce signaling and per-flow state in the network, the 1475 reservations for a number of flows may be aggregated. 1477 QNI QNE QNE/QNI' QNE' QNR'/QNE QNR 1478 aggregator deaggregator 1479 | | | | | | 1480 | RESERVE | | | | | 1481 +--------->| | | | | 1482 | | RESERVE | | | | 1483 | +--------->| | | | 1484 | | | RESERVE | | | 1485 | | +-------------------->| | 1486 | | | RESERVE' | | | 1487 | | +=========>| RESERVE' | | 1488 | | | +=========>| RESERVE | 1489 | | | | +--------->| 1490 | | | | RESPONSE'| | 1491 | | | RESPONSE'|<=========+ | 1492 | | |<=========+ | | 1493 | | | | | RESPONSE | 1494 | | | | RESPONSE |<---------+ 1495 | | |<--------------------+ | 1496 | | RESPONSE | | | | 1497 | |<---------+ | | | 1498 | RESPONSE | | | | | 1499 |<---------+ | | | | 1500 | | | | | | 1501 | | | | | | 1503 Figure 11: Sender Initiated Reservation with Aggregation 1505 An end-to-end per-flow reservation is initiated with the messages 1506 shown in Figure 11 as "RESERVE". 1508 At the aggregator a reservation for the aggregated flow is initiated 1509 (shown in Figure 11 as "RESERVE'"). This may use the same QoS model 1510 as the end-to-end reservation but has an MRI identifying the 1511 aggregated flow (e.g., tunnel) instead of for the individual flows. 1513 This document does not specify how the QSPEC of the aggregate session 1514 can be derived from the QSPECs of the end-to-end sessions. 1516 The messages used for the signaling of the individual reservation 1517 need to be marked such that the intermediate routers will not inspect 1518 them. In the QoS NSLP the following marking possibility is applied, 1519 see also RFC3175. 1521 All routers use essentially the same algorithm for which messages 1522 they process, i.e. all messages at aggregation level 0. However, 1523 messages have their aggregation level incremented on entry to an 1524 aggregation region and decremented on exit. In this technique the 1525 interior routers are not required to do any rewriting of the RAO 1526 values. However, the aggregating/deaggregating routers must be 1527 configured with which of their interfaces lie at which aggregation 1528 level, and also requires consistent message rewriting at these 1529 boundaries. 1531 In particular, the Aggregator performs the marking by modifying the 1532 QoS NSLP default NSLP-ID value to a NSLP-ID predefined value, see 1533 Section 6.6. A RAO value is then uniquely derivable from each 1534 predefined NSLP-ID. However, the RAO does not have to have a one-to- 1535 one relation to a specific NSLP-ID. 1537 Aggregator Deaggregator 1539 +---+ +---+ +---+ +---+ 1540 |QNI|-----|QNE|-----|QNE|-----|QNR| aggregate 1541 +---+ +---+ +---+ +---+ reservation 1543 +---+ +---+ ..... ..... +---+ +---+ 1544 |QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end 1545 +---+ +---+ ..... ..... +---+ +---+ reservation 1547 Figure 12: Reservation aggregation 1549 The deaggregator acts as the QNR for the aggregate reservation. 1550 Session binding information carried in the RESERVE message enables 1551 the deaggregator to associate the end-to-end and aggregate 1552 reservations with one another (using the BOUND_SESSION_ID). 1554 The key difference between this example and the one shown in Section 1555 4.1 is that the flow identifier for the aggregate is expected to be 1556 different to that for the end-to-end reservation. The aggregate 1557 reservation can be updated independently of the per-flow end-to-end 1558 reservations. 1560 4.6. Message Binding 1562 Section 4.5 sketches the interaction of an aggregated end-to-end flow 1563 and an aggregate. For this scenario, and probably others, it is 1564 useful to have a method for synchronizing signaling message exchanges 1565 of different sessions. This can be used to speed up signaling, 1566 because some message exchanges can be started simultaneously and can 1567 be processed in parallel until further processing of a message from 1568 one particular session depends on another message from a different 1569 session. For instance, in Figure 11 there is a case where inclusion 1570 of a new reservation requires to increase the capacity of the 1571 encompassing aggregate first. So the RESERVE (bound message) for the 1572 individual flow arriving at the deaggregator should wait until the 1573 RESERVE' (binding message) for the aggregate arrived successfully 1574 (otherwise the individual flow could not be included into the 1575 existing aggregate and cannot be admitted). Another alternative 1576 would be to increase the aggregate first and then to reserve 1577 resources for a set of aggregated individual flows. In this case the 1578 binding and synchronization between the (RESERVE and RESERVE') 1579 messages is not needed. 1581 A message binding may be used (depending an the aggregators policy) 1582 as follows: a QNE (aggregator QNI' in Figure 14) generates randomly a 1583 128-bit MSG_ID (same rules apply as for generating a SESSION_ID) and 1584 includes it as BOUND_MSG_ID object into the bound signaling message 1585 (RESERVE (1) in Figure 13) that should wait for the arrival of a 1586 related binding signaling message (RESERVE' (3) in Figure 13) that 1587 carries the associated MSG_ID object. The BOUND_SESSION_ID should 1588 also be set accordingly. Only one MSG_ID or BOUND_MSG_ID object per 1589 message is allowed. If the dependency relation between the two 1590 messages is bidirectional then the Message_Binding_Type flag is SET 1591 (value is 1). Otherwise, the Message_Binding_Type flag is UNSET. In 1592 most cases an RII object must be included in order to get a 1593 corresponding RESPONSE back. 1595 Depending on the arrival sequence of the bound signaling message 1596 (RESERVE (1) in Figure 13) and the "triggering" binding signaling 1597 message (RESERVE' (3) in Figure 13) different situations can be 1598 identified: 1600 o The bound signaling (RESERVE (1)) arrives first. The receiving 1601 QNE enqueues (probably after some pre-processing) the signaling 1602 (RESERVE (1)) message for the corresponding session. It also 1603 starts a MsgIDWait timer in order to discard the message in case 1604 the related "triggering" message (RESERVE' in Figure 13) does not 1605 arrive. The timeout period for this time SHOULD be set to the 1606 default retransmission timeout period (QOSNSLP_REQUEST_RETRY). In 1607 case a retransmitted RESERVE message arrives before the timeout it 1608 will simply override the waiting message (i.e. the latter is 1609 discarded and the new message is now waiting with the MsgIDWait 1610 timer being reset). 1612 At the same time, the "triggering" message including a MSG_ID object, 1613 carrying the same value as the BOUND_MSG_ID object is sent by the 1614 same initiating QNE (QNI' in Figure 13). The intermediate QNE' sees 1615 the MSG_ID object, but can determine that it is not the endpoint for 1616 the session (QNR') and therefore simply forwards the message after 1617 normal processing. The receiving QNE (QNR') as endpoint for the 1618 aggregate session (i.e., deaggregator) interprets the MSG_ID object 1619 and looks for a corresponding waiting message with a BOUND_MSG_ID of 1620 the same value whose waiting condition is satisfied now. Depending 1621 on successful processing of the RESERVE' (3), processing of the 1622 waiting RESERVE will be resumed and the MsgIDWait timer will be 1623 stopped as soon as the related RESERVE' arrived. 1625 QNI QNE QNE/QNI' QNE' QNR'/QNE QNR 1626 aggregator deaggregator 1627 | | | | | | 1628 | RESERVE | | | | | 1629 +--------->| | | | | 1630 | | RESERVE | | | | 1631 | +--------->| | | | 1632 | | | RESERVE | | | 1633 | | | (1) | | | 1634 | | +-------------------->| | 1635 | | | RESERVE' | | | 1636 | | | (2) | | | 1637 | | +=========>| RESERVE' | | 1638 | | | | (3) | | 1639 | | | +=========>| RESERVE | 1640 | | | | | (4) | 1641 | | | | +--------->| 1642 | | | | RESPONSE'| | 1643 | | | RESPONSE'|<=========+ | 1644 | | |<=========+ | | 1645 | | | | | RESPONSE | 1646 | | | | RESPONSE |<---------+ 1647 | | |<--------------------+ | 1648 | | RESPONSE | | | | 1649 | |<---------+ | | | 1650 | RESPONSE | | | | | 1651 |<---------+ | | | | 1652 | | | | | | 1653 | | | | | | 1655 (1): RESERVE: SESSION_ID=F, BOUND_MSG_ID=x, BOUND_SESSION_ID=A 1656 (2)+(3): RESERVE': SESSION_ID=A, MSG_ID=x 1657 (4): RESERVE: SESSION_ID=F (MSG_ID object was removed) 1659 Figure 13: Example for using message binding 1661 Several further cases have to be considered in this context: 1663 o "Triggering message" (3) arrives before waiting (bound) message 1664 (1): In this case the processing of the triggering message depends 1665 on the value of the Message_Binding_Type flag. If 1666 Message_Binding_Type is UNSET (value is 0) then the triggering 1667 message can be processed normally, but the MSG_ID and the result 1668 (success or failure) should be saved for the waiting message. 1669 Thus the RESPONSE' can be sent by the QNR' immediately. If the 1670 waiting message (1) finally arrives at the QNR', it can be 1671 detected that the waiting condition was already satisfied, because 1672 the triggering message already arrived earlier. If 1673 Message_Binding_Type is SET (value is 1) then the triggering 1674 message interprets the MSG_ID object and looks for the 1675 corresponding waiting message with a BOUND_MSG_ID of the same 1676 value, which in this case has not yet arrived. It then starts a 1677 MsgIDWait timer in order to discard the message in case the 1678 related message (RESERVE (1) in Figure 14) does not arrive. 1679 Depending on successful processing of the RESERVE (1), processing 1680 of the waiting RESERVE' will be resumed, the MsgIDWait timer will 1681 be stopped as soon as the related RESERVE arrived and the 1682 RESPONSE' can be sent by the QNR' towards the QNI'. 1683 o The "triggering message" (3) does not arrive at all: this may be 1684 the case due to message loss (which will cause a retransmission by 1685 the QNI' if the RII object is included) or due to a reservation 1686 failure at an intermediate node (QNE' in the example). The 1687 MsgIDWait timeout will then simply discard the waiting message at 1688 QNR'. In this case the QNR' MAY send a RESPONSE message towards 1689 the QNI informing that the synchronisation of the two messages has 1690 failed. 1691 o Retransmissions should use the same MSG_ID, because usually only 1692 one message of the two related messages is retransmitted. As 1693 mentioned above: retransmissions will only occur if the RII object 1694 is set in the RESERVE. If a retransmitted message with a MSG_ID 1695 arrives while a bound message with the same MSG_ID is still 1696 waiting, the retransmitted message will replace the bound message. 1698 For a receiving node there are conceptually two lists indexed by 1699 message IDs. One list contains the IDs and results of triggering 1700 messages (those carrying a MSG_ID object), the other list contains 1701 the IDs and message contents of the bound waiting messages (those who 1702 carried a BOUND_MSG_ID). The former list is used when a triggering 1703 message arrives before the bound message. The latter list is used 1704 when a bound message arrives before a triggering message. 1706 4.7. Reduced State or Stateless Interior Nodes 1708 This example uses a different QoS model within a domain, in 1709 conjunction with GIST and NSLP functionality which allows the 1710 interior nodes to avoid storing GIST and QoS NSLP state. As a result 1711 the interior nodes only store the QSPEC-related reservation state, or 1712 even no state at all. This allows the QoS model to use a form of 1713 "reduced-state" operation, where reservation states with a coarser 1714 granularity (e.g., per-class) are used, or a "stateless" operation 1715 where no QoS NSLP state is needed (or created). This is usefull e.g. 1716 for measurement-based admission control schemes. 1718 The key difference between this example and the use of different QoS 1719 models in Section 4.5 is that the transport characteristics for the 1720 reservation, i.e., GIST can be used in a different way for the edge- 1721 to-edge and hop-by-hop sessions. The reduced state reservation can 1722 be updated independently of the per-flow end-to-end reservations. 1724 4.7.1. Sender-initiated Reservation 1726 The QNI initiates a RESERVE message (see Fig. 14). At the QNEs on 1727 the edges of the stateless or reduced-state region the processing is 1728 different and the nodes support two QoS models. At the ingress the 1729 original RESERVE message is forwarded but ignored by the stateless or 1730 reduced-state nodes. This is accomplished by marking this message, 1731 i.e., modifying the QoS NSLP default NSLP-ID value to another NSLP-ID 1732 predefined value (see Section 4.6). The marking must be accomplished 1733 by the ingress by modifying the QoS_NSLP default NSLP-ID value to a 1734 NSLP-ID predefined value. The egress must reassign the QoS NSLP 1735 default NSLP-ID value to the original end-to-end RESERVE message. An 1736 example of such operation is given in [I-D.ietf-nsis-rmd]. 1738 The egress node is the next QoS NSLP hop for the end-to-end RESERVE 1739 message. Reliable GIST transfer mode can be used between the ingress 1740 and egress without requiring GIST state in the interior. At the 1741 egress node the RESERVE message is then forwarded normally. 1743 At the ingress a second RESERVE' message is also built (Fig. 14). 1744 This makes use of a QoS model suitable for a reduced state or 1745 stateless form of operation (such as the RMD per hop reservation). 1746 Since the original RESERVE and the RESERVE' messages are addressed 1747 identically, the RESERVE' message also arrives at the same egress QNE 1748 that was also traversed by the RESERVE message. Message binding is 1749 used to synchronize the messages. 1751 When processed by interior (stateless) nodes the QoS NSLP processing 1752 exercises its options to not keep state wherever possible, so that no 1753 per flow QoS NSLP state is stored. Some state, e.g., per class, for 1754 the QSPEC related data may be held at these interior nodes. The QoS 1755 NSLP also requests that GIST use different transport characteristics 1756 (e.g., sending of messages in unreliable GIST transfer mode). It 1757 also requests the local GIST processing not to retain messaging 1758 association state or reverse message routing state. 1760 Nodes, such as those in the interior of the stateless or reduced- 1761 state domain, that do not retain reservation state cannot send back 1762 RESPONSE messages (and so cannot use the refresh reduction 1763 extension). 1765 At the egress node the RESERVE' message is interpreted in conjunction 1766 with the reservation state from the end-to-end RESERVE message (using 1767 information carried in the message to correlate the signaling flows). 1768 The RESERVE message is only forwarded further if the processing of 1769 the RESERVE' message was successful at all nodes in the local domain, 1770 otherwise the end-to-end reservation is regarded as having failed to 1771 be installed. This can be realized by using the message binding 1772 functionality described in Section 4.6 to synchronize the arrival of 1773 the bound signaling message (end-to-end RESERVE) and the binding 1774 signaling message (local RESERVE'). 1776 QNE QNE QNE QNE 1777 ingress interior interior egress 1778 GIST stateful GIST stateless GIST stateless GIST stateful 1779 | A B | 1780 RESERVE | | | | 1781 -------->| RESERVE | | | 1782 +--------------------------------------------->| 1783 | RESERVE' | | | 1784 +-------------->| | | 1785 | | RESERVE' | | 1786 | +-------------->| | 1787 | | | RESERVE' | 1788 | | +------------->| 1789 | | | RESPONSE' | 1790 |<---------------------------------------------+ 1791 | | | | RESERVE 1792 | | | +--------> 1793 | | | | RESPONSE 1794 | | | |<-------- 1795 | | | RESPONSE | 1796 |<---------------------------------------------+ 1797 RESPONSE| | | | 1798 <--------| | | | 1800 Figure 14: Sender-initiated reservation with Reduced State Interior 1801 Nodes 1803 Resource management errors in the example above are reflected in the 1804 QSPEC and QoS Model processing. For example, if the RESERVE' fails 1805 at QNE A, it can no send an error message back to the ingress QNE. 1806 Thus, the RESERVE' is forwarded along the intended path, but the 1807 QSPEC includes information for subsequent QNEs telling them an error 1808 happened upstream. It is up to the QoS model to determine what to 1809 do. Eventually, the RESERVE' will reach the egress QNE, and again, 1810 the QoS model then determines the response. 1812 4.7.2. Receiver-initiated Reservation 1814 Since NSLP neighbor relationships are not maintained in the reduced- 1815 state region, only sender-initiated signaling can be supported within 1816 the reduced state region. If a receiver-initiated reservation over a 1817 stateless or reduced state domain is required this can be implemented 1818 as shown in Figure 15. 1820 QNE QNE QNE 1821 ingress interior egress 1822 GIST stateful GIST stateless GIST stateful 1823 | | | 1824 QUERY | | | 1825 -------->| QUERY | | 1826 +------------------------------>| 1827 | | | QUERY 1828 | | +--------> 1829 | | | RESERVE 1830 | | |<-------- 1831 | | RESERVE | 1832 |<------------------------------+ 1833 | RESERVE' | RESERVE' | 1834 |-------------->|-------------->| 1835 | | RESPONSE' | 1836 |<------------------------------+ 1837 RESERVE | | | 1838 <--------| | | 1840 Figure 15: Receiver-initiated reservation with Reduced State Interior 1841 Nodes 1843 The RESERVE message that is received by the egress QNE of the 1844 stateless domain is sent transparently to the ingress QNE (known as 1845 the source of the QUERY message). When the RESERVE message reaches 1846 the ingress, the ingress QNE needs to send a sender- initiated 1847 RESERVE' over the stateless domain. The ingress QNE needs to wait 1848 for a RESPONSE'. If the RESPONSE' notifies that the reservation was 1849 accomplished successfully then the ingress QNE sends a RESERVE 1850 message further upstream. 1852 4.8. Proxy Mode 1854 Besides the sender- and receiver-initiated reservations, the QoS NSLP 1855 includes a functionality we refer to as Proxy Mode. Here a QNE is 1856 set by administrator assignment to work as a proxy QNE (P-QNE) for a 1857 certain region, e.g., for an administrative domain. A node 1858 initiating the signaling may set the PROXY scope flag to indicate 1859 that the signaling is meant to be confined within the area controlled 1860 by the proxy, e.g., the local access network. 1862 The Proxy Mode has two uses. First it allows to confine the QoS NSLP 1863 signaling to a pre-defined section of the path. Secondly, it allows 1864 a node to make reservations for an incoming data flow. 1866 For outgoing data flows and sender-initiated reservations, the end 1867 host is the QNI, and sends a RESERVE with the PROXY scope flag set. 1868 The P-QNE is the QNR, it will receive the RESERVE, notice the PROXY 1869 scope flag is set and reply with a RESPONSE (if requested). This 1870 operation is the same as illustrated in Figure 7. The receiver- 1871 oriented reservation for outgoing flows works the same way as in 1872 Figure 8, the P-QNE is the QNI. 1874 For incoming data flows, the end host is the QNI, and it sends a 1875 RESERVE towards the data sender with the PROXY scope flag set. Here 1876 the end host sets the MRI so that it indicates the end host as the 1877 receiver of the data, and sets the D-flag. 1879 GIST is able to send messages towards the data sender if there is 1880 existing message routing state or it is able to use the Upstream Q- 1881 mode Encapsulation. In some cases GIST will be unable to determine 1882 the appropriate next hop for the message, and so will indicate a 1883 failure to deliver it (by sending an error message). This may occur, 1884 for example, if GIST attempts to determine an upstream next hop and 1885 there are multiple possible inbound routes that could be used. 1887 Bi-directional reservations, as discussed in Section 4.4. The P-QNE 1888 will be the QNR or QNI for reservations. 1890 If the PROXY scope flag is set in an incoming QoS NSLP message, the 1891 QNE must set the same flag in all QoS NSLP messages it sends that are 1892 related to this session. 1894 5. QoS NSLP Functional Specification 1896 5.1. QoS NSLP Message and Object Formats 1898 A QoS NSLP message consists of a common header, followed by a body 1899 consisting of a variable number of variable-length, typed "objects". 1900 The common header and other objects are encapsulated together in a 1901 GIST NSLP-Data object. The following subsections define the formats 1902 of the common header and each of the QoS NSLP message types. In the 1903 message formats, the common header is denoted as COMMON_HEADER. 1905 For each QoS NSLP message type, there is a set of rules for the 1906 permissible choice of object types. These rules are specified using 1907 the Augmented Backus-Naur Form (ABNF) specified in RFC 5234 1908 [RFC5234]. The ABNF implies an order for the objects in a message. 1909 However, in many (but not all) cases, object order makes no logical 1910 difference. An implementation SHOULD create messages with the 1911 objects in the order shown here, but MUST accept the objects in any 1912 order. 1914 5.1.1. Common Header 1916 All GIST NSLP-Data objects for the QoS NSLP MUST contain this common 1917 header as the first 32 bits of the object (this is not the same as 1918 the GIST Common Header). 1920 0 1 2 3 1921 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 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Message Type | Message Flags | Generic Flags | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 The fields in the common header are as follows: 1928 Msg Type: 8 bits 1930 1 = RESERVE 1932 2 = QUERY 1934 3 = RESPONSE 1936 4 = NOTIFY 1938 Message-specific flags: 8 bits 1940 These flags are defined as part of the specfication of individual 1941 messages, and, thus, are different with each message type. 1943 Generic flags: 16 bits 1945 Generic flags have the same meaning for all message types. There 1946 exist currently four generic flags, the (next hop) Scoping flag (S), 1947 the Proxy scope flag (P), the Acknowledgement Requested flag (A), and 1948 the Break flag (B). 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | Reserved |B|A|P|S| 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 SCOPING (S) - when set, indicates that the message is scoped and 1955 should not travel down the entire path but only as far as the next 1956 QNE (scope="next hop"). By default, this flag is not set (default 1957 scope="whole path"). 1959 PROXY (P) - when set, indicates that the message is scoped, and 1960 should not travel down the entire path but only as far as the P-QNE. 1961 By default, this flag is not set. 1963 ACK-REQ (A) - when set, indicates that the message should be 1964 acknowledged by the receiving peer. The flag is only used between 1965 stateful peers, and only used with RESERVE and QUERY messages. 1966 Currently, the flag is only used with refresh messages. By default 1967 the flag is not set. 1969 BREAK (B) - when set, indicates that there are routers along the path 1970 where QoS cannot be provided. 1972 The set of appropriate flags depends on the particular message being 1973 processed. Any bit not defined as a flag for a particular message 1974 MUST be set to zero on sending and MUST be ignored on receiving. 1976 The ACK-REQ flag is useful when a QNE wants to make sure the messages 1977 received by the downstream QNE are truly processed by the QoS NSLP, 1978 not just delivered by GIST. This is useful for faster dead peer 1979 diagnostics on the NSLP layer. This liveliness test can only be used 1980 with refresh RESERVE messages. The ACK-REQ-flag must not be set for 1981 RESERVE messages that already include an RII object, since a 1982 confirmation has already been requested from the QNR. Reliable 1983 transmission of messages between two QoS NSLP peer should be handled 1984 by GIST, not the NSLP by itself. 1986 5.1.2. Message Formats 1988 5.1.2.1. RESERVE 1990 The format of a RESERVE message is as follows: 1992 RESERVE = COMMON_HEADER 1993 RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ] 1994 [ SESSION_ID_LIST [ RSN_LIST ] ] 1995 [ MSG_ID / BOUND_MSG_ID ] [ INFO_SPEC ] 1996 [ [ PACKET_CLASSIFIER ] QSPEC ] 1998 The RSN is the only mandatory object and MUST always be present in 1999 all cases. A QSPEC MUST be included in the initial RESERVE sent 2000 towards the QNR. A PACKET_CLASSIFIER MAY be provided. If the 2001 PACKET_CLASSIFIER is not provided, then the full set of information 2002 provided in the GIST MRI for the session should be used for packet 2003 classification purposes. 2005 Subsequent RESERVE messages meant as reduced refreshes, where no 2006 QSPEC is provided, MUST NOT include a PACKET_CLASSIFIER either. 2008 There are no requirements on transmission order, although the above 2009 order is recommended. 2011 Two message-specific flags are defined for use in the common header 2012 with the RESERVE message. These are: 2014 +-+-+-+-+-+-+-+-+ 2015 |Reserved |T|R| 2016 +-+-+-+-+-+-+-+-+ 2018 TEAR (T) - when set, indicates that reservation state and QoS NSLP 2019 operation state should be torn down. The former is indicated to the 2020 RMF. Depending on the QoS model, the tear message may include a 2021 QSPEC to further specify state removal, e.g., for an aggregation, the 2022 QSPEC may specify the amount of resources removed from the aggregate. 2024 REPLACE (R) - when set the flag has two uses. First, it indicates 2025 that a RESERVE with different MRI (but same SID) replaces an existing 2026 one, so the old one MAY be torn down immediately. This is the 2027 default situation. This flag may be unset to indicate a desire from 2028 an upstream node to keep an existing reservation on an old branch in 2029 place. Second, this flag is also used to indicate whether the 2030 reserved resources on the old branch should be torn down or not when 2031 a data path change happens. In this case, the MRI is the same and 2032 only the route path changes. 2034 If the REFRESH_PERIOD is not present, a default value of 30 seconds 2035 is assumed. 2037 If the session of this message is bound to another session, then the 2038 RESERVE message MUST include the SESSION_ID of that other session in 2039 a BOUND_SESSION_ID object. In the situation of aggregated tunnels, 2040 the aggregated session MAY not include the SESSION_ID of its bound 2041 sessions in BOUND_SESSION_ID(s). 2043 The negotiation of whether to perform sender or receiver-initiated 2044 signaling is done outside the QoS NSLP. Yet, in theory, it is 2045 possible that a "reservation collision" may occur if the sender 2046 believes that a sender-initiated reservation should be performed for 2047 a flow, whilst the other end believes that it should be starting a 2048 receiver- initiated reservation. If different session identifiers 2049 are used then this error condition is transparent to the QoS NSLP 2050 though it may result in an error from the RMF, otherwise the removal 2051 of the duplicate reservation is left to the QNIs/QNRs for the two 2052 sessions. 2054 If a reservation is already installed and a RESERVE message is 2055 received with the same session identifier from the other direction 2056 (i.e., going upstream where the reservation was installed by a 2057 downstream RESERVE message, or vice versa) then an error indicating 2058 "RESERVE received from wrong direction" MUST be sent in a RESPONSE 2059 message to the signaling message source for this second RESERVE. 2061 A refresh right along the path can be forced by requesting a RESPONSE 2062 from the far end (i.e., by including an RII object in the RESERVE 2063 message). Without this, a refresh RESERVE would not trigger RESERVE 2064 messages to be sent further along the path, as each hop has its own 2065 refresh timer. 2067 A QNE may ask for confirmation of tear operation by including an RII 2068 object. QoS NSLP retransmissions SHOULD be disabled. A QNE sending 2069 a tearing RESERVE with an RII included MAY ask GIST to use reliable 2070 transport. When the QNE sends out a tearing RESERVE, it MUST NOT 2071 send refresh messages anymore. 2073 If the routing path changed due to mobility and the mobile node's IP 2074 address changed, and it sent a Mobile IP binding update, the 2075 resulting refresh is a new RESERVE. This RESERVE includes a new MRI 2076 and will be propagated end-to-end; there is no need to force end-to- 2077 end forwarding by including an RII. 2079 Note: It is possible for a host to use this mechanism to constantly 2080 force the QNEs on the path to send refreshing RESERVE messages. It 2081 may, therefore, be appropriate for QNEs to perform rate limiting on 2082 the refresh messages that they send. 2084 5.1.2.2. QUERY 2086 The format of a QUERY message is as follows: 2087 QUERY = COMMON_HEADER 2088 [ RII ][ *BOUND_SESSION_ID ] 2089 [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC [ QSPEC ] 2091 QUERY messages MUST always include a QSPEC. QUERY messages MAY 2092 include a PACKET_CLASSIFIER when the message is used to trigger a 2093 receiver-initiated reservation. If a PACKET_CLASSIFIER is not 2094 included then the full GIST MRI should be used for packet 2095 classification purposes in the subsequent RESERVE. A QUERY message 2096 MAY contain a second QSPEC object. 2098 A QUERY message for requesting information about network resources 2099 MUST contain an RII object to match an incoming RESPONSE to the 2100 QUERY. 2102 The QSPEC object describes what is being queried for and may contain 2103 objects that gather information along the data path. There are no 2104 requirements on transmission order, although the above order is 2105 recommended. 2107 One message-specific flags are defined for use in the common header 2108 with the QUERY message. This is: 2110 +-+-+-+-+-+-+-+-+ 2111 |Reserved |R| 2112 +-+-+-+-+-+-+-+-+ 2114 RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger 2115 for the recipient to make a resource reservation by sending a 2116 RESERVE. 2118 If the session of this message is bound to another session, then the 2119 RESERVE message MUST include the SESSION_ID of that other session in 2120 a BOUND_SESSION_ID object. In the situation of aggregated tunnels, 2121 the aggregated session MAY not include the SESSION_ID of its bound 2122 sessions in BOUND_SESSION_ID(s). 2124 5.1.2.3. RESPONSE 2126 The format of a RESPONSE message is as follows: 2128 RESPONSE = COMMON_HEADER 2129 [ RII / RSN ] INFO_SPEC [SESSION_ID_LIST [ RSN_LIST ] ] 2130 [ QSPEC ] 2132 A RESPONSE message MUST contain an INFO_SPEC object which indicates 2133 the success of a reservation installation or an error condition. 2134 Depending on the value of the INFO_SPEC, the RESPONSE MAY also 2135 contain a QSPEC object. The value of an RII or an RSN object was 2136 provided by some previous QNE. There are no requirement on 2137 transmission order, although the above order is recommended. 2139 No message-specific flags are defined for use in the common header 2140 with the RESPONSE message. 2142 5.1.2.4. NOTIFY 2144 The format of a NOTIFY message is as follows: 2146 NOTIFY = COMMON_HEADER 2147 INFO_SPEC [ QSPEC ] 2149 A NOTIFY message MUST contain an INFO_SPEC object indicating the 2150 reason for the notification. Depending on the INFO_SPEC value, it 2151 MAY contain a QSPEC object providing additional information. 2153 No message-specific flags are defined for use with the NOTIFY 2154 message. 2156 5.1.3. Object Formats 2158 The QoS NSLP uses a Type-Length-Value (TLV) object format similar to 2159 that used by GIST. Every object consists of one or more 32-bit words 2160 with a one-word header. For convenience the standard object header 2161 is shown here: 2163 0 1 2 3 2164 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 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 |A|B|r|r| Type |r|r|r|r| Length | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 The value for the Type field comes from the shared NSLP object type 2170 space, the various objects are presented in subsequent sections. The 2171 Length field is given in units of 32 bit words and measures the 2172 length of the Value component of the TLV object (i.e., it does not 2173 include the standard header). 2175 The bits marked 'A' and 'B' are flags used to signal the desired 2176 treatment for objects whose treatment has not been defined in the 2177 protocol specification (i.e., whose Type field is unknown at the 2178 receiver). The following four categories of object have been 2179 identified, and are described here. 2181 AB=00 ("Mandatory"): If the object is not understood, the entire 2182 message containing it MUST be rejected, and an error message sent 2183 back. 2185 AB=01 ("Ignore"): If the object is not understood, it MUST be deleted 2186 and the rest of the message processed as usual. 2188 AB=10 ("Forward"): If the object is not understood, it MUST be 2189 retained unchanged in any message forwarded as a result of message 2190 processing, but not stored locally. 2192 AB=11 ("Refresh"): If the object is not understood, it should be 2193 incorporated into the locally stored QoS NSLP signaling application 2194 operational state for this flow/session, forwarded in any resulting 2195 message, and also used in any refresh or repair message which is 2196 generated locally. The contents of this object does not need to be 2197 interpreted, and should only be stored as bytes on the QNE. 2199 The remaining bits marked 'r' are reserved. These SHALL be set to 0 2200 and SHALL be ignored on reception. The extensibility flags AB are 2201 similar to those used in the GIST specification. All objects defined 2202 in this specification MUST be understood by all QNEs, thus, they MUST 2203 have the AB-bits set to "00". A QoS NSLP implementation must 2204 recognize objects of the following types: RII, RSN, REFRESH_PERIOD, 2205 BOUND_SESSION_ID, INFO_SPEC, and QSPEC. 2207 The object header is followed by the Value field, which varies for 2208 different objects. The format of the Value field for currently 2209 defined objects is specified below. 2211 The object diagrams here use '//' to indicate a variable sized field. 2213 5.1.3.1. Request Identification Information (RII) 2215 Type: 0x01 2217 Length: Fixed - 1 32-bit word 2219 Value: An identifier which MUST be (probabilistically) unique within 2220 the context of a SESSION_ID, and SHOULD be different every time a 2221 RESPONSE is desired. Used by a QNE to match back a RESPONSE to a 2222 request in a RESERVE or QUERY message. 2224 0 1 2 3 2225 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 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 | Request Identification Information (RII) | 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 5.1.3.2. Reservation Sequence Number (RSN) 2232 Type: 0x02 2234 Length: Fixed - 2 32-bit words 2236 Value: An incrementing sequence number that indicates the order in 2237 which state modifying actions are performed by a QNE, and an epoch 2238 identifier to allow the identification of peer restarts. The RSN has 2239 local significance only, i.e., between a QNE and its downstream 2240 stateful peers. The RSN is not reset when the downstream peer 2241 changes. 2243 0 1 2 3 2244 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 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | Reservation Sequence Number (RSN) | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 | Epoch Identifier | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 5.1.3.3. Refresh Period (REFRESH_PERIOD) 2253 Type: 0x03 2255 Length: Fixed - 1 32-bit word 2257 Value: The refresh timeout period R used to generate this message; in 2258 milliseconds. 2260 0 1 2 3 2261 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 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 | Refresh Period (R) | 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 5.1.3.4. Bound Session ID (BOUND_SESSION_ID) 2268 Type: 0x04 2270 Length: Fixed - 5 32-bit words 2272 Value: contains an 8-bit Binding_Code that indicates the nature of 2273 binding. The rest specifies the SESSION_ID (as specified in GIST 2274 [I-D.ietf-nsis-ntlp]) of the session that MUST be bound to the 2275 session associated with the message carrying this object. 2277 0 1 2 3 2278 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 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | RESERVED | Binding Code | 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 | | 2283 + + 2284 | | 2285 + Session ID + 2286 | | 2287 + + 2288 | | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 Currently defined Binding Codes are: 2292 o 0x01 - Tunnel and end-to-end sessions 2294 o 0x02 - Bi-directional sessions 2296 o 0x03 - Aggregate sessions 2298 o 0x04 - Dependent sessions (binding session is alive only if the 2299 other session is also alive) 2301 o 0x05 - Indicated session caused pre-emption 2303 More binding codes maybe defined based on the above four atomic 2304 binding actions. Note a message may include more than one 2305 BOUND_SESSION_ID object. This may be needed in case one needs to 2306 define more specifically the reason for binding, or if the session 2307 depends on more than one other session (with possibly different 2308 reasons). Note that a session with e.g., SID_A (the binding session) 2309 can express its unidirectional dependency relation to another session 2310 with e.g., SID_B (the bound session) by including a BOUND_SESSION_ID 2311 object containing SID_B in its messages. 2313 5.1.3.5. Packet Classifier (PACKET_CLASSIFIER) 2315 Type: 0x05 2317 Length: Variable 2319 Value: Contains a variable length MRM-specific data 2321 0 1 2 3 2322 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 2323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2324 // Method-specific classifier data (variable) // 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 At this stage, the QoS NSLP only uses the path-coupled routing MRM. 2328 The method-specific classifier data is four bytes long and consists 2329 of a set of flags: 2331 0 1 2 3 2332 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 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 |X|Y|P|T|F|S|A|B| Reserved | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 The flags are: 2339 X - Source Address and Prefix 2341 Y - Destination Address and Prefix 2343 P - Protocol 2345 T - DiffServ Code Point 2347 F - Flow Label 2349 S - SPI 2351 A - Source Port 2353 B - Destination Port 2355 The flags indicate which fields from the MRI MUST be used by the 2356 packet classifier. This allows a subset of the information in the 2357 MRI to be used for identifying the set of packets which are part of 2358 the reservation. Flags MUST only be set if the data is present in 2359 the MRI (i.e., where there is a corresponding flag in the GIST MRI, 2360 the flag can only be set if the corresponding GIST MRI flag is set). 2361 It should be noted that some flags in the PACKET_CLASSIFIER (X and Y) 2362 relate to data that is always present in the MRI, but are optional to 2363 use for QoS NSLP packet classification. The appropriate set of flags 2364 set may depend, to some extent, on the QoS model being used. 2366 As mentioned earlier in this section, the QoS NSLP is currently only 2367 defined for use with the Path-Coupled Message Routing Mechanism (MRM) 2368 in GIST. Future work may extend the QoS NSLP to additional routing 2369 mechanisms. Such MRMs must include sufficient information in the MRI 2370 to allow the subset of packets for which QoS is to be provided to be 2371 identified. When QoS NSLP is extended to support a new MRM, 2372 appropriate method-specific classifier data for the PACKET_CLASSIFIER 2373 object MUST be defined. 2375 5.1.3.6. Information Object (INFO_SPEC) and Error Codes 2377 Type: 0x06 2379 Length: Variable 2381 Value: Contains 8-bit reserved bits, a 8-bit error code, a 4-bit 2382 error class, a 4-bit error source identifier type, and an 8-bit error 2383 source identifier length (in 32-bit words), an error source 2384 identifier and optionally variable length error-specific information. 2386 0 1 2 3 2387 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 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | Reserved | Error Code |E-Class|ESI Typ| ESI-Length | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 // Error Source Identifier // 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 // Optional error-specific information // 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 Class Field: 2398 The four E-Class bits of the object indicate the error severity 2399 class. The currently defined severity classes are: 2401 o 0x1 - Informational 2403 o 0x2 - Success 2405 o 0x3 - Protocol Error 2407 o 0x4 - Transient Failure 2409 o 0x5 - Permanent Failure 2411 o 0x6 - QoS Model Error 2413 Error field: 2415 Within each error severity class a number of Error Code values are 2416 defined. 2418 o Informational: 2420 * 0x01 - Unknown BOUND_SESSION_ID: the message refers to an unknown 2421 SESSION_ID in its BOUND_SESSION_ID object. 2423 * 0x02 - Route Change: possible route change occurred on downstream 2424 path. 2426 * 0x03 - Reduced refreshes not supported, full QSPEC required. 2428 * 0x04 - Congestion situation: Possible congestion situation occurred 2429 on downstream path. 2431 * 0x05 - Unknown SESSION ID in SESSION_ID_LIST 2433 * 0x06 - Mismatching RSN in RSN LIST 2434 o Success: 2436 * 0x01 - Reservation successful 2438 * 0x02 - Tear down successful 2440 * 0x03 - Acknowledgement 2442 * 0x04 - Refresh successful 2444 o Protocol Error: 2446 * 0x01 - Illegal message type: the type given in the Message Type 2447 field of the common header is unknown. 2449 * 0x02 - Wrong message length: the length given for the message does 2450 not match the length of the message data. 2452 * 0x03 - Bad flags value: an undefined flag or combination of flags 2453 was set in the generic flags 2455 * 0x04 - Bad flags value: an undefined flag or combination of flags 2456 was set in the message-specific flags 2458 * 0x05 - Mandatory object missing: an object required in a message of 2459 this type was missing. 2461 * 0x06 - Illegal object present: an object was present which must not 2462 be used in a message of this type. 2464 * 0x07 - Unknown object present: an object of an unknown type was 2465 present in the message. 2467 * 0x08 - Wrong object length: the length given for the object did not 2468 match the length of the object data present. 2470 * 0x09 - RESERVE received from wrong direction. 2472 * 0x0a - Unknown object field value: a field in an object had an 2473 unknown value. 2475 * 0x0b - Duplicate object present. 2477 * 0x0c - Malformed QSPEC. 2479 * 0x0d - Unknown MRI. 2481 * 0x0e - Erroneous value in the TLV object's value field. 2483 * 0x0f - Incompatible QSPEC 2485 o Transient Failure: 2487 * 0x01 - No GIST reverse-path forwarding state 2489 * 0x02 - No path state for RESERVE, when doing a receiver- oriented 2490 reservation 2492 * 0x03 - RII conflict 2494 * 0x04 - Full QSPEC required 2496 * 0x05 - Mismatch synchronization between end-to-end RESERVE and 2497 intra-domain RESERVE 2499 * 0x06 - Reservation preempted 2501 * 0x07 - Reservation failure 2503 * 0x08 - Path truncated - Next peer dead 2505 o Permanent Failure: 2507 * 0x01 - Internal or system error 2509 * 0x02 - Authorization failure 2511 o QoS Model Error: 2513 This error class can be used by QoS Models to add error codes 2514 specific to the QoS Model being used. All these errors and events 2515 are created outside the QoS NSLP itself. The error codes in this 2516 class are defined in QoS model specifications. Note that this error 2517 class may also include codes that are not purely errors, but rather 2518 some non-fatal information. 2520 Error Source Identifier 2522 The Error Source Identifier is for diagnostic purposes and its 2523 inclusion is OPTIONAL. It is suggested that implementations use this 2524 for the IP address, host name or other identifier of the QNE 2525 generating the INFO_SPEC to aid diagnostic activities. A QNE SHOULD 2526 NOT be used in any other purpose other than error logging or 2527 presenting to the user as part of any diagnostic information. A QNE 2528 SHOULD NOT attempt to send a message to that address. 2530 If no Error Source Identifier is included, the Error Source 2531 Identifier Type field must be zero. 2533 Currently three Error Source Identifiers have been defined: IPv4, 2534 IPv6 and FQDN. 2536 Error Source Identifier: IPv4 2538 Error Source Identifier Type: 0x1 2540 0 1 2 3 2541 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 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | 32-bit IPv4 address | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 Error Source Identifier: IPv6 2548 Error Source Identifier Type: 0x2 2550 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 2551 1 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | | 2555 + + 2556 | | 2557 + 128-bit IPv6 address + 2558 | | 2559 + + 2560 | | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 Error Source Identifier: FQDN name in UTF-8 2565 Error Source Identifier Type: 0x3 2567 0 1 2 3 2568 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 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 // FQDN Name // 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 If the length of the FQDN name is not a multiple of 32-bits, the 2574 field is padded with zero octets to the next 32-bit boundary. 2576 If a QNE encounters protocol errors, it MAY include additional 2577 information, mainly for diagnostic purposes. Additional information 2578 MAY be included if the type of an object is erroneous, or a field has 2579 an erroneous value. 2581 If the type of an object is erroneous, the following Optional error- 2582 specific information may be included at the end of the INFO_SPEC. 2584 Object Type Info: 2586 0 1 2 3 2587 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 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 | Object Type | Reserved | 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 This object provides information about the type of object which 2593 caused the error. 2595 If a field in an object had an incorrect value, the following 2596 Optional error-specific information may be added at the end of the 2597 INFO_SPEC. 2599 Object Value Info: 2601 0 1 2 3 2602 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 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 | Rsvd | Real Object Length | Offset | 2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 // Object // 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 Real Object Length: Since the length in the original TLV header may 2610 be inaccurate, this field provides the actual length of the object 2611 (including the TLV Header) included in the error message. 2613 Offset: Indicates which part of the erroneous object is included. 2614 When this field is set to "0", the complete object is included. If 2615 Offset is bigger than "0", the erroneous object from offset 2616 (calculated from the beginning of the object) up to the end of the 2617 object is included. 2619 Object: The invalid TLV object (including the TLV Header). 2621 This object carries information about a TLV object which was found to 2622 be invalid in the original message. An error message may contain 2623 more than one Object Value Info object. 2625 5.1.3.7. SESSION ID List (SESSION_ID_LIST) 2627 Type: 0x07 2629 Length: Variable 2631 Value: A list of 128-bit SESSION IDs used in summary refresh and 2632 summary tear messages. All SESSION IDs are concatenated together. 2634 0 1 2 3 2635 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 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | | 2638 + + 2639 | | 2640 + Session ID 1 + 2641 | | 2642 + + 2643 | | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 : : 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 | | 2648 + + 2649 | | 2650 + Session ID n + 2651 | | 2652 + + 2653 | | 2654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 5.1.3.8. Reservation Sequence Number (RSN) List (RSN_LIST) 2658 Type: 0x08 2660 Length: Variable 2662 Value: A list of 32-bit Reservation Sequence Number (RSN) values. 2663 All RSN are concatenated together. 2665 0 1 2 3 2666 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 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 | Epoch Identifier | 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 | Reservation Sequence Number 1 (RSN1) | 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 : : 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | Reservation Sequence Number n (RSNn) | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 5.1.3.9. Message ID (MSG_ID) 2679 Type: 0x09 2681 Length: Fixed - 5 32-bit words 2683 Value: contains an 1-bit Message_Binding_Type (D) that indicates the 2684 dependency relation of a message binding. The rest specifies a 128 2685 bit randomly generated value that "uniquely" identifies this 2686 particular message. 2688 0 1 2 3 2689 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 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | RESERVED |D| 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | | 2694 + + 2695 | | 2696 + Message ID + 2697 | | 2698 + + 2699 | | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 The Message Binding Codes are: 2704 * 0 - Unidirectional binding dependency 2706 * 1 - Bi-directional binding dependency 2708 5.1.3.10. Bound Message ID (BOUND_MSG_ID) 2710 Type: 0x0A 2712 Length: Fixed - 5 32-bit words 2713 Value: contains an 1-bit Message_Binding_Type (D) that indicates the 2714 dependency relation of a message binding. The rest specifies a 128 2715 bit randomly generated value that refers to a Message ID in another 2716 message. 2718 0 1 2 3 2719 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 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 | RESERVED |D| 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | | 2724 + + 2725 | | 2726 + Bound Message ID + 2727 | | 2728 + + 2729 | | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 The Message Binding Codes are: 2734 * 0 - Unidirectional binding dependency 2736 * 1 - Bi-directional binding dependency 2738 5.1.3.11. QoS Specification (QSPEC) 2740 Type: 0x0B 2742 Length: Variable 2744 Value: Variable length QSPEC (QoS specification) information, which 2745 is QoS Model dependent. 2747 The contents and encoding rules for this object are specified in 2748 other documents. See [I-D.ietf-nsis-qspec]. 2750 0 1 2 3 2751 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 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | | 2754 // QSPEC Data // 2755 | | 2756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 5.2. General Processing Rules 2760 This section provides the general processing rules used by QoS-NSLP. 2761 The triggers communicated between RM/QOSM and QoS-NSLP 2762 functionalities are given in Appenices A.1, A.2 and A.3. 2764 5.2.1. State Manipulation 2766 The processing of a message and its component objects involves 2767 manipulating the QoS NSLP and reservation state of a QNE. 2769 For each flow, a QNE stores (RMF-related) reservation state which 2770 depends on the QoS model / QSPEC used and QoS NSLP operation state 2771 which includes non-persistent state (e.g., the API parameters while a 2772 QNE is processing a message) and persistent state which is kept as 2773 long as the session is active. 2775 The persistent QoS NSLP state is conceptually organized in a table 2776 with the following structure. The primary key (index) for the table 2777 is the SESSION_ID: 2779 SESSION_ID 2781 A 128-bit identifier. 2783 The state information for a given key includes: 2785 Flow ID 2787 Based on GIST MRI. Several entries are possible in case of mobility 2788 events. 2790 SII-Handle for each upstream and downstream peer 2792 The SII-Handle is a local identifier generated by GIST and passed 2793 over the API. It is a handle that allows to refer to a particular 2794 GIST next hop. See SII-Handle in [I-D.ietf-nsis-ntlp] for more 2795 information. 2797 RSN from the upstream peer 2799 The RSN is a 32 bit counter. 2801 The latest local RSN 2803 A 32 bit counter. 2805 List of RII for outstanding responses with processing information. 2807 The RII is a 32 bit number. 2809 State lifetime 2811 The state lifetime indicates how long the state that is being 2812 signaled for remains valid. 2814 List of bound sessions 2816 A list of BOUND_SESSION_ID 128-bit identifiers for each session bound 2817 to this state. 2819 Scope of the signaling 2821 If the Proxy scope is used, a flag is needed to identify all 2822 signaling of this session as being scoped. 2824 Adding the state requirements of all these items gives an upper bound 2825 on the state to be kept by a QNE. The need to keep state depends on 2826 the desired functionality at the NSLP layer. 2828 5.2.2. Message Forwarding 2830 QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP 2831 does not have the concept of a message being sent directly to the end 2832 of the path. Instead, messages are received by a QNE, which may then 2833 send another message (which may be identical to the received message, 2834 or contain some subset of objects from it) to continue in the same 2835 direction (i.e., towards QNI or QNR) as the message received. 2837 The decision on whether to generate a message to forward may be 2838 affected by the value of the SCOPING or PROXY flags, or by the 2839 presence of an RII object. 2841 5.2.3. Standard Message Processing Rules 2843 If a mandatory object is missing from a message then the receiving 2844 QNE MUST NOT propagate the message any further. It MUST construct a 2845 RESPONSE message indicating the error condition and send it back to 2846 the peer QNE that sent the message. 2848 If a message contains an object of an unrecognised type, then the 2849 behavior depends on the AB extensibility flags. 2851 If the Proxy scope flag was set in an incoming QoS NSLP message, the 2852 QNE must set the same flag in all QoS NSLP messages it sends that are 2853 related to this session. 2855 5.2.4. Retransmissions 2857 Retransmissions may happen end-to-end, e.g., between QNI and QNR 2858 (using an RII object), or peer-to-peer, between two adjacent QNEs. 2859 When a QNE transmits a RESERVE with an RII object set, it waits for a 2860 RESPONSE from the responding QNE. QoS NSLP messages for which a 2861 response is requested by including an RII object, but fail to elicit 2862 a response are retransmitted. Similarly, a QNE may include the ACK- 2863 REQ-flag to request confirmation of a refresh message reception from 2864 its immediate peer. The retransmitted message should be exactly the 2865 same as the original message, e.g., the RSN is not modified with each 2866 retransmission. 2868 The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY wait 2869 period. Retransmissions MUST be made with exponentially increasing 2870 wait intervals (doubling the wait each time). QoS NSLP messages 2871 SHOULD be retransmitted until either a RESPONSE (which might be an 2872 error) has been obtained, or until QOSNSLP_RETRY_MAX seconds after 2873 the initial transmission. In the latter case, a failure SHOULD be 2874 indicated to the signaling application. The default values for the 2875 above-mentioned timers are: 2877 QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial 2878 retransmit of the message 2880 QOSNSLP_RETRY_MAX: 30 seconds Give up retrying to send the message 2882 Retransmissions SHOULD be disabled for tear messages. 2884 5.2.5. Rerouting 2886 5.2.5.1. Last Node Behavior 2888 As discussed in Section 3.2.12 some care needs to be taken to handle 2889 cases where the last node on the path may change. 2891 A node that is the last node on the path, but not the data receiver 2892 (or an explicitly configured proxy for it), MUST continue to attempt 2893 to send messages downstream to probe for path changes. This must be 2894 done in order to handle the "Path Extension" case described in 2895 Section 3.2.12.1. 2897 A node on the path, that was not previously the last node, MUST take 2898 over as the last node on the signaling path if GIST path change 2899 detection identifies that there are no further downstream nodes on 2900 the path. This must be done in order to handle the "Path Truncation" 2901 case described in Section 3.2.12.1. 2903 5.2.5.2. Avoiding Mistaken Teardown 2905 In order to handle the spurious route change problem described in 2906 Section 3.2.12.2, the RSN must be used in a particular way when 2907 maintaining the reservation after a route change is believed to have 2908 occurred. 2910 We assume that the current RSN (RSN[current]) is initially RSN0. 2912 When a route change is believed to have occurred, the QNE SHOULD send 2913 a RESERVE message, including the full QSPEC. This must contain an 2914 RSN which is RSN[current] = RSN0 + 2. It SHOULD include an RII, to 2915 request a response from the QNR. An SII-Handle MUST NOT be specified 2916 when passing this message over the API to GIST, so that it is 2917 correctly routed to the new peer QNE. 2919 When the QNE receives the RESPONSE message that relates to the 2920 RESERVE message sent down the new path, it SHOULD send a RESERVE 2921 message with the TEAR flag sent down the old path. To do so, it MUST 2922 request GIST to use its explicit routing mechanism and the QoS NSLP 2923 MUST supply an SII-Handle relating to the old peer QNE. When sending 2924 this RESERVE message it MUST contain an RSN which is RSN[current] - 2925 1. (RSN[current] remains unchanged). 2927 If the RESPONSE received after sending the RESERVE down the new path 2928 contains the code "Refresh successful" in the INFO_SPEC, then the QNE 2929 MAY elect not to send the tearing RESERVE, since this indicates that 2930 the path is unchanged. 2932 5.2.5.3. Upstream Route Change Notification 2934 GIST may notify the QoS NSLP that a possible upstream route change 2935 has occurred over the GIST API. On receiving such a notification, 2936 the QoS NSLP SHOULD send a NOTIFY message with Informational code 2937 0x02 for signaling sessions associated with the identified MRI. If 2938 this is sent, it MUST be sent to the old peer using the GIST explicit 2939 routing mechanism through the use of the SII-Handle. 2941 On receiving such a NOTIFY message, the QoS NSLP SHOULD use the 2942 InvalidateRoutingState API call to inform GIST that routing state may 2943 be out of date. The QoS NSLP SHOULD send a NOTIFY message upstream. 2944 The NOTIFY message should be propagated back to the QNI or QNR. 2946 5.2.5.4. Route Change Oscillation 2948 In some circumstances a route change may occur, but the path then 2949 falls back to the original route. 2951 After a route change the routers on the old path will continue to 2952 refresh the reservation until soft state times out, or an explicit 2953 TEAR is received. 2955 After detecting an upstream route change a QNE SHOULD consider the 2956 new upstream peer as current and not fall back to the old upstream 2957 peer unless: 2959 - it stops receiving refreshes from the old upstream peer for at 2960 least the soft state timeout period and then starts receiving 2961 messages from the old upstream peer again 2963 - or, it stops receiving refreshes from the new upstream peer for at 2964 least the soft state timeout period. 2966 GIST routing state keeps track of the latest upstream peer it has 2967 seen, and so may spuriously indicate route changes occur when the old 2968 upstream peer refreshes its routing state until the state at that 2969 node is explicitly torn down or times out. 2971 5.3. Object Processing 2973 This section presents processing rules for individual QoS NSLP 2974 objects. 2976 5.3.1. Reservation Sequence Number (RSN) 2978 A QNE's own RSN is a sequence number which applies to a particular 2979 signaling session (i.e., with a particular SESSION_ID). It MUST be 2980 incremented for each new RESERVE message where the reservation for 2981 the session changes. The RSN is manipulated using the serial number 2982 arithmetic rules from [RFC1982], which also defines wrapping rules 2983 and the meaning of 'equals', 'less than' and 'greater than' for 2984 comparing sequence numbers in a circular sequence space. 2986 The RSN starts at zero. It is stored as part of the per-session 2987 state and it carries on incrementing (i.e., it is not reset to zero) 2988 when a downstream peer change occurs. (Note that section 5.2.5.2 2989 provides some particular rules for use when a downstream peer 2990 changes.) 2992 The RSN object also contains an Epoch Identifier, which provides a 2993 method for determining when a peer has restarted (e.g., due to node 2994 reboot or software restart). The exact method for providing this 2995 value is implementation defined. Options include storing a serial 2996 number which is incremented on each restart, picking a random value 2997 on each restart or using the restart time. 2999 On receiving a RESERVE message a QNE examines the Epoch Identifier to 3000 determine if the peer sending the message has restarted. If the 3001 Epoch Identifier is different to that stored for the reservation then 3002 the RESERVE message MUST be treated as an updated reservation (even 3003 if the RSN is less than the current stored value), and the stored RSN 3004 and Epoch Identifier MUST be updated to the new values. 3006 When receiving a RESERVE message a QNE uses the RSN given in the 3007 message to determine whether the state being requested is different 3008 to that already stored. If the RSN is equal to that stored for the 3009 current reservation the current state MUST be refreshed. If the RSN 3010 is greater than the current stored value, the current reservation 3011 MUST be modified appropriately as specified in the QSPEC (provided 3012 that admission control and policy control succeed), and the stored 3013 RSN value updated to that for the new reservation. If the RSN is 3014 greater than the current stored value and the RESERVE was a reduced 3015 refresh, the QNE SHOULD send upstream a transient error message "Full 3016 QSPEC required". If the RSN is less than the current value, then it 3017 indicates an out-of-order message and the RESERVE message MUST be 3018 discarded. 3020 If the QNE does not store per-session state (and so does not keep any 3021 previous RSN values) then it MAY ignore the value of the RSN. It 3022 MUST also copy the same RSN into the RESERVE message (if any) it 3023 sends as a consequence of receiving this one. 3025 5.3.2. Request Identification Information (RII) 3027 A QNE sending QUERY or RESERVE messages may require a response to be 3028 sent. It does so by including a Request Identification Information 3029 (RII) object. When creating an RII object the QNE MUST select the 3030 value for the RII such that it is probabilistically unique within the 3031 given session. A RII object is typically set by the QNI. 3033 A number of choices are available when implementing this. 3034 Possibilities might include using a random value, or a node 3035 identifier together with a counter. If the value collides with one 3036 selected by another QNE for a different QUERY then RESPONSE messages 3037 may be incorrectly terminated, and may not be passed back to the node 3038 that requested them. 3040 The node that created the RII object MUST remember the value used in 3041 the RII to match back any RESPONSE it will receive. The node SHOULD 3042 use a timer to identify situations where it has taken too long to 3043 receive the expected RESPONSE. If the timer expires without 3044 receiving a RESPONSE it MAY perform a retransmission as discussed in 3045 Section 5.2.4. In this case this QNE MUST NOT generate any RESPONSE 3046 or NOTIFY message to notify this error. 3048 If an intermediate QNE wants to receive a response for an outgoing 3049 message, but the message already included an RII when it arrived, the 3050 QNE MUST NOT add a new RII object nor replace the old RII object, but 3051 MUST simply remember this RII to match a later RESPONSE message. 3052 When it receives the RESPONSE, it forwards the RESPONSE upstream 3053 towards the RII originating node. Note that only the node that 3054 originally created the RII can set up a retransmission timer. Thus, 3055 if an intermediate QNE decides to use the RII already contained in 3056 the message, it MUST NOT set up a retransmission timer, but rely on 3057 the retransmission timer set up by the QNE that inserted the RII. 3059 When receiving a message containing an RII object the node MUST send 3060 a RESPONSE if 3062 o The SCOPING flag is set ('next hop' scope), 3064 o The PROXY scope flag is set and the QNE is the P-QNE, or 3066 o This QNE is the last one on the path for the given session. 3068 and the QNE keeps per-session state for the given session. 3070 In the rare event that the QNE wants to request a response for a 3071 message that already included an RII, and this RII value conflicts 3072 with an existing RII value on the QNE, the node should interrupt the 3073 processing the message, and send an error message upstream to 3074 indicate an RII collision, and request a retry with a new RII value. 3076 5.3.3. BOUND_SESSION_ID 3078 As shown in the examples in Section 4, the QoS NSLP can relate 3079 multiple sessions together. It does this by including the SESSION_ID 3080 from one session in a BOUND_SESSION_ID object in messages in another 3081 session. 3083 When receiving a message with a BOUND_SESSION_ID object, a QNE MUST 3084 copy the BOUND_SESSION_ID object into all messages it sends for the 3085 same session. A QNE that stores per-session state MUST store the 3086 value of the BOUND_SESSION_ID. 3088 The BOUND_SESSION_ID is only indicative in nature. However, a QNE 3089 implementation may use BOUND_SESSION_ID information to optimize 3090 resource allocation, e.g., for bidirectional reservations. When 3091 receiving a tear down message (e.g., a RESERVE message with tear down 3092 semantic) for an aggregate reservation, it may use this information 3093 to initiate a tear down for end-to-end sessions bound to the 3094 aggregate. A QoS NSLP implementation MUST be ready to process more 3095 than one BOUND_SESSION_ID object within a single message. 3097 5.3.4. REFRESH_PERIOD 3099 Refresh timer management values are carried by the REFRESH_PERIOD 3100 object which has local significance only. At the expiration of a 3101 "refresh timeout" period, each QNE independently examines its state 3102 and sends a refreshing RESERVE message to the next QNE peer where it 3103 is absorbed. This peer-to-peer refreshing (as opposed to the QNI 3104 initiating a refresh which travels all the way to the QNR) allows 3105 QNEs to choose refresh intervals as appropriate for their 3106 environment. For example, it is conceivable that refreshing 3107 intervals in the backbone, where reservations are relatively stable, 3108 are much larger than in an access network. The "refresh timeout" is 3109 calculated within the QNE and is not part of the protocol; however, 3110 it must be chosen to be compatible with the reservation lifetime as 3111 expressed by the REFRESH_PERIOD, and an assessment of the reliability 3112 of message delivery. 3114 The details of timer management and timer changes (slew handling and 3115 so on) are identical to the ones specified in Section 3.7 of RFC 2205 3116 [RFC2205]. 3118 There are two time parameters relevant to each QoS NSLP state in a 3119 node: the refresh period R between generation of successive refreshes 3120 for the state by the neighbor node, and the local state's lifetime L. 3121 Each RESERVE message may contain a REFRESH_PERIOD object specifying 3122 the R value that was used to generate this (refresh) message. This R 3123 value is then used to determine the value for L when the state is 3124 received and stored. The values for R and L may vary from peer to 3125 peer. 3127 5.3.5. INFO_SPEC 3129 The INFO_SPEC object is carried by the RESPONSE and NOTIFY messages 3130 and it is used to report a successful, an unsuccessful, or an error 3131 situation. In case of an error situation the error messages SHOULD 3132 be generated even if no RII object is included in the RESERVE or in 3133 the QUERY messages. Note that when the TEAR flag is set in the 3134 RESERVE message an error situation SHOULD NOT trigger the generation 3135 of a RESPONSE message. 3137 Six classes of INFO_SPEC objects are identified and specified in 3138 Section 5.1.3.6. The message processing rules for each class are 3139 defined below. 3141 A RESPONSE message MUST carry INFO_SPEC objects towards the QNI. The 3142 RESPONSE message MUST be forwarded unconditionally up to the QNI. 3143 The actions that SHOULD be undertaken by the QNI that receives the 3144 INFO_SPEC object are specified by the local policy of the QoS model 3145 supported by this QNE. The default action is that the QNI that 3146 receives the INFO_SPEC object SHOULD NOT trigger any other QoS NSLP 3147 procedure. 3149 The Informational INFO_SPEC class MUST be generated by a stateful QoS 3150 NSLP QNE when an Informational error class is caught. The 3151 Informational INFO-SPEC object MUST be carried by a RESPONSE or a 3152 NOTIFY message. 3154 In case of an unidirectional reservation, the Success INFO_SPEC class 3155 MUST be generated by a stateful QoS NSLP QNR when a RESERVE message 3156 is received and the reservation state installation or refresh 3157 succeeded. In case of a bi-directional reservation the INFO-SPEC 3158 object SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE 3159 message is received and the reservation state installation or refresh 3160 succeeded. The Success INFO-SPEC object MUST be carried by a 3161 RESPONSE or a NOTIFY message. 3163 In case of an unidirectional reservation, the Protocol Error 3164 INFO_SPEC class MUST be generated by a stateful QoS NSLP QNE when a 3165 RESERVE or QUERY message is received by the QNE and a protocol error 3166 is caught. In case of a bi-directional reservation, the Protocol 3167 Error INFO_SPEC class SHOULD be generated by a stateful QoS NSLP QNE 3168 when a RESERVE or QUERY message is received by the QNE and a protocol 3169 error is caught. A RESPONSE message MUST carry this object, which 3170 MUST be forwarded unconditionally towards the upstream QNE that 3171 generated the RESERVE or QUERY message that triggered the generation 3172 of this INFO_SPEC object. The default action for a stateless QoS 3173 NSLP QNE that detects such an error is that none of the QoS NSLP 3174 objects SHOULD be processed and the RESERVE or QUERY message SHOULD 3175 be forwarded downstream. 3177 In case of an unidirectional reservation, the Transient Failure 3178 INFO_SPEC class MUST be generated by a stateful QoS NSLP QNE when a 3179 RESERVE or QUERY message is received by the QNE and one Transient 3180 failure error code is caught, or when an event happens that causes a 3181 transient error. In case of a bi-directional reservation, the 3182 Transient Failure INFO_SPEC class SHOULD be generated by a stateful 3183 QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE 3184 and one Transient failure error code is caught. 3186 A RESPONSE message MUST carry this object, which MUST be forwarded 3187 unconditionally towards the upstream QNE that generated the RESERVE 3188 or QUERY message that triggered the generation of this INFO_SPEC 3189 object. The transient RMF-related error MAY also be carried by a 3190 NOTIFY message. The default action is that the QNE that receives 3191 this INFO_SPEC object SHOULD re-trigger the retransmission of the 3192 RESERVE or QUERY message that triggered the generation of the 3193 INFO_SPEC object. The default action for a stateless QoS NSLP QNE 3194 that detects such an error is that none of the QoS NSLP objects 3195 SHOULD be processed and the RESERVE or QUERY message SHOULD be 3196 forwarded downstream. 3198 In case of an unidirectional reservation, the Permanent Failure 3199 INFO_SPEC class MUST be generated by a stateful QoS NSLP QNE when a 3200 RESERVE or QUERY message is received by a QNE and an internal or 3201 system error occured, or authorization failed. In case of a bi- 3202 directional reservation, the Permanent Failure INFO_SPEC class SHOULD 3203 be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY 3204 message is received by a QNE and an internal or system error occured, 3205 or authorization failed. A RESPONSE message MUST carry this object, 3206 which MUST be forwarded unconditionally towards the upstream QNE that 3207 generated the RESERVE or QUERY message that triggered this protocol 3208 error. The permanent RMF-related, the internal or system errors MAY 3209 also be carried by a NOTIFY message. The default action for a 3210 stateless QoS NSLP QNE that detects such an error is that none of the 3211 QoS NSLP objects SHOULD be processed and the RESERVE or QUERY message 3212 SHOULD be forwarded downstream. 3214 The QoS-specific error class may be used when errors outside the QoS 3215 NSLP itself occur that are related to the particular QoS Model being 3216 used. The processing rules of these errors are not specified in this 3217 document. 3219 5.3.6. SESSION_ID_LIST 3221 A SESSION_ID_LIST is carried in RESERVE messages. It is used in two 3222 cases, to refresh or to tear down the indicated sessions. A 3223 SESSION_ID_LIST carries information about sessions that should be 3224 refreshed or torn down, in addition to the main (primary) session 3225 indicated in the RESERVE. 3227 If the primary SESSION_ID is not understood, the SESSION_ID_LIST 3228 object MUST NOT be processed. 3230 When a stateful QNE goes through the SESSION_ID_LIST, if it finds one 3231 or more unknown SESSION ID values, it SHOULD construct an 3232 informational RESPONSE message back to the upstream stateful QNE with 3233 error code for unknown SESSION ID in SESSION_ID_LIST, and include all 3234 uknown SESSION IDs in a SESSION_ID_LIST. 3236 If the RESERVE is a tear, for each session in the SESSION_ID_LIST, 3237 the stateful QNE MUST inform the RMF that the reservation is no 3238 longer required. RSN values MUST also be interpreted in order to 3239 distinguish whether the tear down is valid, or whether it is refering 3240 to an old state, and, thus, should be silently discarded. 3242 If the RESERVE is a refresh, the stateful QNE MUST also process the 3243 RSN_LIST object as detailed in the next section. 3245 If the RESERVE is a tear, for each session in the SESSION_ID_LIST, 3246 the QNE MUST inform the RMF that the reservation is no longer 3247 required. RSN values MUST be interpreted. 3249 Note that a stateless QNE can not support summary or single reduced 3250 refreshes, and always needs full single refreshes. 3252 5.3.7. RSN_LIST 3254 An RSN_LIST MUST be carried in RESERVE messages when a QNE wants to 3255 perform a refresh or tear-down of several sessions with a single NSLP 3256 message. The RSN_LIST object MUST be populated with RSN values of 3257 the same sessions and in the same order as indicated in the 3258 SESSION_ID_LIST. Thus, entries in both objects at position X refer 3259 to the same session. 3261 If the primary session and RSN reference in the RESERVE were not 3262 understood, the stateful QNE MUST NOT process the RSN_LIST. Instead 3263 an error RESPONSE SHOULD be sent back to the upstream stateful QNE. 3265 On receiving an RSN_LIST object, the stateful QNE should check 3266 whether the number of items in the SESSION_ID_LIST and RSN_LIST 3267 objects match. If there is a mismatch, the stateful QNE SHOULD send 3268 back a protocol error indicating a bad value in the object. 3270 While matching the RSN_LIST values to the SESSION_ID_LIST values, if 3271 one or more RSN values in the RSN_LIST are not in synch with the 3272 local values, the stateful QNE SHOULD construct an informational 3273 RESPONSE message with an error code for RSN mismatch in RSN_LIST. 3274 The stateful QNE MUST include the erroneous SESSION ID and RSN values 3275 in SESSION_ID_LIST and RSN_LIST objects in the RESPONSE. 3277 If no errors were found in processing the RSN_LIST, the stateful QNE 3278 refreshes the reservation states of all sessions, both the primary 3279 single session indicated in the refresh, and all sessions in the 3280 SESSION_ID_LIST. 3282 For each successfully processed session in the RESERVE, the stateful 3283 QNE performs a refresh of the reservation state. Thus, even if some 3284 sessions were not in synch, the remaining sessions in the 3285 SESSION_ID_LIST and RSN_LIST are refreshed. 3287 5.3.8. QSPEC 3289 The contents of the QSPEC depends on the QoS model being used. A 3290 template for QSPEC objects can be found in [I-D.ietf-nsis-qspec]. 3292 Upon reception, the complete QSPEC is passed to the Resource 3293 Management Function (RMF), along with other information from the 3294 message necessary for the RMF processing. A QNE may also receive an 3295 INFO_SPEC that includes a partial or full QSPEC. This will also be 3296 passed to the RMF. 3298 5.4. Message Processing Rules 3300 This section provides rules for message processing. Not all possible 3301 error situations are considered. A general rule for dealing with 3302 erroneous messages is that a node should evaluate the situation 3303 before deciding how to react. There are two ways to react to 3304 erroneous messages: 3306 a) Silently drop the message, or 3308 b) Drop the message, and reply with an error code to the sender. 3310 The default behavior, in order to protect the QNE from a possible DoS 3311 attack, is to silently drop the message. However, if the QNE is able 3312 to authenticate the sender, e.g., through GIST, the QNE may send a 3313 proper error message back to the neighbor QNE in order to let it know 3314 that there is an inconsistency in the states of adjacent QNEs. 3316 5.4.1. RESERVE Messages 3318 The RESERVE message is used to manipulate QoS reservation state in 3319 QNEs. A RESERVE message may create, refresh, modify or remove such 3320 state. A QNE sending a RESERVE MAY require a response to be sent by 3321 including a Request Identification Information (RII) object, see 3322 Section 5.3.2. 3324 RESERVE messages MUST only be sent towards the QNR. A QNE that 3325 receives a RESERVE message checks the message format. In case of 3326 malformed messages, the QNE MAY send a RESPONSE message with the 3327 appropriate INFO_SPEC. 3329 Before performing any state changing actions a QNE MUST determine 3330 whether the request is authorized. The way to do this check depends 3331 on the authorization model being used. 3333 When the RESERVE is authorized, a QNE checks the COMMON_HEADER flags. 3334 If the TEAR flag is set, the message is a tearing RESERVE which 3335 indicates complete QoS NSLP state removal (as opposed to a 3336 reservation of zero resources). On receiving such a RESERVE message 3337 the QNE MUST inform the RMF that the reservation is no longer 3338 required. The RSN value MUST be processed. After this, there are 3339 two modes of operation: 3341 1. If the tearing RESERVE did not include an RII, i.e., the QNI did 3342 not want a confirmation, the QNE SHOULD remove the QoS NSLP state. 3343 It MAY signal to GIST (over the API) that reverse path state for this 3344 reservation is no longer required. Any errors in processing the 3345 tearing RESERVE SHOULD NOT be sent back towards the QNI since the 3346 upstream QNEs will already have removed their session states, thus, 3347 they are unable to do anything to the error. 3349 2. If an RII was included, the stateful QNE SHOULD still keep the 3350 NSLP operational state until a RESPONSE for the tear going towards 3351 the QNI is received. This operational state SHOULD be kept for one 3352 refresh interval, after which the NSLP operational state for the 3353 session is removed. Depending on the QoS model, the tear message MAY 3354 include a QSPEC to further specify state removal. If the QoS model 3355 requires a QSPEC, and none is provided, the QNE SHOULD reply with an 3356 error message, and SHOULD NOT remove the reservation. 3358 If the tearing RESERVE includes a QSPEC, but none is required by the 3359 QoS model, the QNE MAY silently discard the QSPEC and proceed as if 3360 it did not exist in the message. In general, a QoS NSLP 3361 implementation should carefully consider, when an error message 3362 should be sent, and when not. If the tearing RESERVE did not include 3363 an RII, then the upstream QNE has removed the RMF and NSLP states, 3364 and will not be able to do anything to the error. If an RII was 3365 included, the upstream QNE may still have the NSLP operational state, 3366 but no RMF state. 3368 If a QNE receives a tearing RESERVE for a session it still has the 3369 operational state, but the RMF state was removed, the QNE SHOULD 3370 accept the message and forward it downstream as if all is well. 3372 If the tearing RESERVE includes a SESSION_ID_LIST, the stateful QNE 3373 MUST process the object as described earlier in this document, and 3374 for each identified session, indicate to the RMF that the reservation 3375 is no longer required. 3377 If a QNE receives a refreshing RESERVE for a session it still has the 3378 operational state, but the RMF state was removed, the QNE MUST 3379 silently drop the message and not forward it downstream. 3381 As discussed in Section 5.2.5.2, to avoid incorrect removal of state 3382 after a rerouting event, a node receiving a RESERVE message with the 3383 TEAR flag set which does not come from the current peer QNE, 3384 identified by its SII, MUST be ignored and MUST NOT be forwarded. 3386 If the QNE has reservations which are bound and dependent to this 3387 session (they contain the SESSION_ID of this session in their 3388 BOUND_SESSION_ID object and use Binding Code: 0x04), it MUST send a 3389 NOTIFY message for each of the reservations with an appropriate 3390 INFO_SPEC. If the QNE has reservations which are bound, but which 3391 they are not dependent to this session (the Binding Code in the 3392 BOUND_SESSION_ID object has one of the values: 0x01, 0x02, 0x03), it 3393 MAY send a NOTIFY message for each of the reservations with an 3394 appropriate INFO_SPEC. The QNE MAY elect to send RESERVE messages 3395 with the TEAR flag set for these reservations. 3397 The default behavior of a QNE that receives a RESERVE with a 3398 SESSION_ID for which it already has state installed but with a 3399 different flow ID is to replace the existing reservation (and tear 3400 down the reservation on the old branch if the RESERVE is received 3401 with a different SII). 3403 In some cases, this may not be the desired behavior. In that case, 3404 the QNI or a QNE MAY set the REPLACE flag in the common header to 3405 zero to indicate that the new session does not replace the existing 3406 one. 3408 A QNE that receives a RESERVE with the REPLACE flag set to zero but 3409 with the same SII, will indicate REPLACE=0 to the RMF (where it will 3410 be used for the resource handling). Furthermore, if the QNE 3411 maintains a QoS NSLP state then it will also add the new flow ID in 3412 the QoS NSLP state. If the SII is different, this means that the QNE 3413 is a merge point. In that case, in addition to the operations 3414 specified above, the value REPLACE=0 is also indicating that a 3415 tearing RESERVE SHOULD NOT be sent on the old branch. 3417 When a QNE receives a RESERVE message with an unknown SESSION_ID and 3418 this message contains no QSPEC because it was meant as a refresh then 3419 the node MUST send a RESPONSE message with an INFO_SPEC that 3420 indicates a missing QSPEC to the upstream peer ("Full QSPEC 3421 required"). The upstream peer SHOULD send a complete RESERVE (i.e., 3422 one containing a QSPEC) on the new path (new SII). 3424 At a QNE, resource handling is performed by the RMF. For sessions 3425 with the REPLACE flag set to zero, we assume that the QoS model 3426 includes directions to deal with resource sharing. This may include, 3427 adding the reservations, or taking the maximum of the two or more 3428 complex mathematical operations. 3430 This resource handling mechanism in the QoS Model is also applicable 3431 to sessions with different SESSION_ID but related through the 3432 BOUND_SESSION_ID object. Session replacement is not an issue here, 3433 but the QoS Model may specify whether to let the sessions that are 3434 bound together share resources on common links or not. 3436 Finally, it is possible that a RESERVE is received with no QSPEC at 3437 all. This is the case of a reduced refresh. In this case, rather 3438 than sending a refreshing RESERVE with the full QSPEC, only the 3439 SESSION_ID and the RSN are sent to refresh the reservation. Note 3440 that this mechanism just reduces the message size (and probably eases 3441 processing). One RESERVE per session is still needed. Such a 3442 reduced refresh may further include a SESSION_ID_LIST and RSN_LIST, 3443 which indicate further sessions to be refreshed along the primary 3444 session. The processing of these objects were described earlier in 3445 this document. 3447 If the REPLACE flag is set, the QNE SHOULD update the reservation 3448 state according to the QSPEC contained in the message (if the QSPEC 3449 is missing the QNE SHOULD indicate this error by replying with a 3450 RESPONSE containing the corresponding INFO_SPEC "Full QSPEC 3451 required"). It MUST update the lifetime of the reservation. If the 3452 REPLACE flag is not set, a QNE SHOULD NOT remove the old reservation 3453 state if the SII which is passed by GIST over the API is different 3454 than the SII that was stored for this reservation. The QNE MAY elect 3455 to keep sending refreshing RESERVE messages. 3457 If a stateful QoS NSLP QNE receives a RESERVE message with the BREAK 3458 flag set then the BREAK flag of new generated messages (e.g., RESERVE 3459 or RESPONSE) MUST be set. When a stateful QoS NSLP QNE receives a 3460 RESERVE message with the BREAK flag not set then the IP-TTL and 3461 Original-TTL values in GIST RecvMessage primitive MUST be monitored. 3462 If they differ, it is RECOMMENDED to set the BREAK flag in new 3463 generated messages (e.g., RESERVE or RESPONSE). In situations where 3464 a QNE or a domain is able to provide QoS using other means, see 3465 Section 3.3.5, then the BREAK flag SHOULD NOT be set. 3467 If the RESERVE message included an RII, and any of the following are 3468 true, the QNE MUST send a RESPONSE message: 3470 o If the QNE is configured, for a particular session, to be a QNR, 3472 o the SCOPING flag is set, 3474 o the Proxy scope flag is set and the QNE is a P-QNE, or 3476 o the QNE is the last QNE on the path to the destination. 3478 When a QNE receives a RESERVE message, its processing may involve 3479 sending out another RESERVE message. 3481 If a QNE has received a RESPONSE mandating the use of full refreshes 3482 from its downstream peer for a session, the QNE MUST continue to use 3483 full refresh messages. 3485 If the session of this message is bound to another session, then the 3486 RESERVE message MUST include the SESSION_ID of that other session in 3487 a BOUND_SESSION_ID object. In the situation of aggregated tunnels, 3488 the aggregated session MAY not include the SESSION_ID of its bound 3489 sessions in BOUND_SESSION_ID(s). 3491 In case of receiver-initiated reservations, the RESERVE message must 3492 follow the same path that has been followed by the QUERY message. 3493 Therefore, GIST is informed, over the QoS NSLP/GIST API, to pass the 3494 message upstream, i.e., by setting GIST "D" flag, see GIST 3495 [I-D.ietf-nsis-ntlp]. 3497 The QNE MUST create a new RESERVE and send it to its next peer, when: 3499 - A new resource set up was done, 3501 - A new resource set up was not done, but the QOSM still defines that 3502 a RESERVE must be propagated, 3504 - The RESERVE is a refresh and includes new MRI, or 3506 - If the RESERVE-INIT flag is included in an arrived QUERY. 3508 If the QNE sent out a refresh RESERVE with the ACK-REQ-flag set, and 3509 did not receive a RESPONSE from its immediate stateful peer within 3510 the retransmission period of QOSNSLP_RETRY_MAX, the QNE SHOULD send a 3511 NOTIFY to its immediate upstream sateful peer and indicate "Path 3512 truncated - Next peer dead" in the INFO_SPEC. The ACK-REQ-flag 3513 SHOULD NOT be added to a RESERVE that already include an RII object, 3514 since a confirmation from the QNR has already been requested. 3516 Finally, if a received RESERVE requested acknowledgement through the 3517 ACK-REQ-flag in the COMMON HEADER flags and the processing of the 3518 message was successul, the stateful QNE SHOULD send back a RESPONSE 3519 with an INFO_SPEC carrying the acknowledgement success code. The QNE 3520 MAY include the ACK-REQ-flag in the next refresh message it will send 3521 for the session. The use of the ACK-REQ-flag for diagnostics 3522 purposes is a policy issue, i.e., using an acknowledged refresh 3523 message as a hint to further probe the end-to-end path can be used 3524 simply as a hint to check that the end-to-end path is still intact. 3526 5.4.2. QUERY Messages 3528 A QUERY message is used to request information about the data path 3529 without making a reservation. This functionality can be used to 3530 'probe' the network for path characteristics or for support of 3531 certain QoS models, or for initiating a receiver-initiated 3532 reservation. 3534 A QNE sending a QUERY indicates a request for a response by including 3535 a Request Identification Information (RII) object, see Section 5.3.2. 3536 A request to initiate a receiver-initiated reservation is done 3537 through the RESERVE-INIT flag, see Section 5.1.2.2. 3539 When a QNE receives a QUERY message the QSPEC is passed to the RMF 3540 for processing. The RMF may return a modified QSPEC that is used in 3541 any QUERY or RESPONSE message sent out as a result of the QUERY 3542 processing. 3544 When processing a QUERY message, a QNE checks whether the RESERVE- 3545 INIT flag is set. If the flag is set, the QUERY is used to install 3546 reverse path state. In this case, if the QNE is not the QNI, it 3547 creates a new QUERY message to send downstream. The QSPEC MUST be 3548 passed to the RMF where it may be modified by the QoS Model specific 3549 QUERY processing. If the QNE is the QNI, the QNE creates a RESERVE 3550 message, which contains a QSPEC received from the RMF and which may 3551 be based on the received QSPEC. If this node was not expecting to 3552 perform a receiver-initiated reservation then an error MUST be sent 3553 back along the path. 3555 If an RII object is present, and if the QNE is the QNR, the SCOPING 3556 flag is set or the PROXY scope flag is set and the QNE is a P-QNE, 3557 the QNE MUST generate a RESPONSE message and pass it back along the 3558 reverse of the path used by the QUERY. 3560 In other cases, the QNE MUST generate a QUERY message which is then 3561 forwarded further along the path using the same MRI, Session ID and 3562 Direction as provided when the QUERY was received over the GIST API. 3564 The QSPEC to be used is that provided by the RMF as described 3565 previously. When generating a QUERY to send out to pass the query 3566 further along the path, the QNE MUST copy the RII object (if present) 3567 unchanged into the new QUERY message. A QNE that is also interested 3568 in the response to the query keeps track of the RII to identify the 3569 RESPONSE when it passes through it. 3571 Note that QUERY messages with the RESERVE-INIT flag set MUST be 3572 answered by the QNR. This feature may be used, e.g., following 3573 handovers, to set up new path state in GIST, and request the other 3574 party to send a RESERVE back on this new GIST path. 3576 If a stateful QoS NSLP QNE receives a QUERY message with the RESERVE- 3577 INIT flag and BREAK flag set then the BREAK flag of new generated 3578 messages (e.g., QUERY, RESERVE or RESPONSE) MUST be set. When a 3579 stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT 3580 flag set and BREAK flag not set then the IP-TTL and Original-TTL 3581 values in GIST RecvMessage primitive MUST be monitored. If they 3582 differ, it is RECOMMENDED to set the BREAK flag in new generated 3583 messages (e.g., QUERY, RESERVE or RESPONSE). In situations where a 3584 QNE or a domain is able to provide QoS using other means, see Section 3585 3.3.5, then the BREAK flag SHOULD NOT be set. 3587 Finally, if a received QUERY requested acknowledgement through the 3588 ACK-REQ-flag in the COMMON HEADER flags and the processing of the 3589 message was successul, the stateful QNE SHOULD send back a RESPONSE 3590 with an INFO_SPEC carrying the acknowledgement success code. 3592 5.4.3. RESPONSE Messages 3594 The RESPONSE message is used to provide information about the result 3595 of a previous QoS NSLP message, e.g., confirmation of a reservation 3596 or information resulting from a QUERY. The RESPONSE message does not 3597 cause any state to be installed, but may cause state(s) to be 3598 modified, e.g., if the RESPONSE contains information about an error. 3600 A RESPONSE message MUST be sent when the QNR processes a RESERVE or 3601 QUERY message containing an RII object or if the QNE receives a 3602 scoped RESERVE or a scoped QUERY. In this case, the RESPONSE message 3603 MUST contain the RII object copied from the RESERVE or the QUERY. 3604 Also, if there is an error in processing a received RESERVE, a 3605 RESPONSE is sent indicating the nature of the error. In this case, 3606 the RII and RSN, if available, MUST be included in the RESPONSE. 3608 On receipt of a RESPONSE message containing an RII object, the 3609 stateful QoS NSLP QNE MUST attempt to match it to the outstanding 3610 response requests for that signaling session. If the match succeeds, 3611 then the RESPONSE MUST NOT be forwarded further along the path if it 3612 contains an INFO_SPEC class informational or success. If the QNE did 3613 not insert this RII itself, if must forward the RESPONSE to the next 3614 peer. Thus, for RESPONSES indicating success, forwarding should only 3615 stop if the QNE inserted the RII by itself, If the RESPONSE carries 3616 an INFO_SPEC indicating an error, forwarding SHOULD continue upstream 3617 towards the QNI by using RSNs as described in the next paragraph. 3619 On receipt of a RESPONSE message containing an RSN object, a stateful 3620 QoS NSLP QNE MUST compare the RSN to that of the appropriate 3621 signaling session. If the match succeeds then the INFO_SPEC MUST be 3622 processed. If the INFO_SPEC object is used to notify errors then the 3623 node MUST use the stored upstream peer RSN value, associated with the 3624 same session, and forward the RESPONSE message further along the path 3625 towards the QNI. 3627 If the INFO_SPEC is not used to notify error situations, see above, 3628 then if the RESPONSE message carries an RSN, the message MUST NOT be 3629 forwarded further along the path. 3631 If there is no match for RSN, the message SHOULD be silently dropped. 3633 On receipt of a RESPONSE message containing neither an RII nor an RSN 3634 object, the RESPONSE MUST NOT be forwarded further along the path. 3636 In the typical case RESPONSE messages do not change the states 3637 installed in intermediate QNEs. However, depending on the QoS model, 3638 there may be situations where states are affected, e.g., 3640 - if the RESPONSE includes an INFO_SPEC describing an error situation 3641 resulting in reservations to be removed, or 3643 - the QoS model allows a QSPEC to define [min,max] limits on the 3644 resources requested, and downstream QNEs gave less resources than 3645 their upstream nodes, which means that the upstream nodes may release 3646 a part of the resource reservation. 3648 If a stateful QoS NSLP QNE receives a RESPONSE message with the BREAK 3649 flag set then the BREAK flag of new generated message (e.g., 3650 RESPONSE) MUST be set. 3652 5.4.4. NOTIFY Messages 3654 NOTIFY messages are used to convey information to a QNE 3655 asynchronously. NOTIFY messages do not cause any state to be 3656 installed. The decision to remove state depends on the QoS model. 3657 The exact operation depends on the QoS model. A NOTIFY message does 3658 not directly cause other messages to be sent. NOTIFY messages are 3659 sent asynchronously, rather than in response to other messages. They 3660 may be sent in either direction (upstream or downstream). 3662 A special case of synchronous NOTIFY is when the upstream QNE asked 3663 to use reduced refresh by setting the appropriate flag in the 3664 RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY 3665 and a proper INFO_SPEC code whether the QNE agrees to use reduced 3666 refresh between the upstream QNE. 3668 The Transient error code 0x07 "Reservation preempted" is sent to the 3669 QNI whose resources were preempted. The NOTIFY message carries 3670 information to the QNI that one QNE no longer has a reservation for 3671 the session. It is up to the QNI to decide what to do based on the 3672 QoS Model being used. The QNI would normally tear down the preempted 3673 reservation by sending a RESERVE with the TEAR flag set using the SII 3674 of the preempted reservation. However, the QNI can follow other 3675 procedures as specified in its QoS Model. More discussion on 3676 preemption can be found in the QSPEC Template [I-D.ietf-nsis-qspec] 3677 and the individual QoS Model specifications. 3679 6. IANA Considerations 3681 This section provides guidance to the Internet Assigned Numbers 3682 Authority (IANA) regarding registration of values related to the QoS 3683 NSLP, in accordance with BCP 26 RFC 5226 [RFC5226]. 3685 The QoS NSLP requires IANA to create a number of new registries: 3687 - QoS NSLP Message Types 3689 - QoS NSLP Binding Codes 3691 - QoS NSLP Error Classes and Error Codes 3693 It also requires registration of new values in a number of 3694 registries: 3696 - NSLP Object Types - GIST NSLP-ID - Router Alert Option Values (IPv4 3697 and IPv6) 3699 6.1. QoS NSLP Message Type 3701 The QoS NSLP Message Type is an 8 bit value. This specification 3702 defines four QoS NSLP message types, which form the initial contents 3703 of this registry: RESERVE (0x01), QUERY (0x02), RESPONSE (0x03) and 3704 NOTIFY (0x04). 3706 The value 0 is reserved. Values 1-239 are to be allocated by IETF 3707 Review. Values 240 to 255 are for Experimental/Private Use. 3709 When a new message type is defined, any message flags used with it 3710 must also be defined. 3712 6.2. NSLP Message Objects 3714 [Delete this part if already done by another NSLP: 3716 A new registry is to be created for NSLP Message Objects. This is a 3717 12-bit field (giving values from 0 to 4095). This registry is shared 3718 between a number of NSLPs. Allocation policies are as follows: 3720 0: Reserved 3722 1-1023: IETF Review 3724 1024-1999: Specification Required 3726 2000-2047: Private/Experimental Use 3728 2048-4095: Reserved 3730 When a new object is defined, the extensbility bits (A/B) must also 3731 be defined.] 3733 This document defines eleven new NSLP objects. These are described 3734 in Section 5.1.3: RII (0x01), RSN (0x02), REFRESH_PERIOD (0x03), 3735 BOUND_SESSION_ID (0x04), PACKET_CLASSIFIER (0x05), INFO_SPEC (0x06), 3736 SESSION ID LIST (0x07), RSN LIST (0x08), MSG_ID (0x09), BOUND_MSG_ID 3737 (0x0A), and QSPEC (0x0B). 3739 Values are to be assigned from the IETF Review section of the NSLP 3740 Object Type registry. 3742 6.3. QoS NSLP Binding Codes 3744 A new registry is to be created for the 8-bit Binding Codes used in 3745 the BOUND_SESSION_ID object. The initial values for this registry 3746 are listed in Section 5.1.3.4. 3748 Value 0 is reserved. Values 1 to 127 are to be assigned based on a 3749 policy of Specification Required. Values 128 to 159 are for 3750 Exerimental/Private Use. Other values are Reserved. 3752 6.4. QoS NSLP Error Classes and Error Codes 3754 In addition Error Classes and Error Codes for the INFO_SPEC object 3755 are defined. These are described in Section 5.1.3.6. 3757 The Error Class is 4-bits in length. The initial values are: 3759 0: Reserved 3761 1: Informational 3763 2: Success 3765 3: Protocol Error 3767 4: Transient Failure 3769 5: Permanent Failure 3771 6: QoS Model Error 3773 7-15: Reserved 3775 New values are to be assigned based on IETF Review. 3777 The Error Code is 8 bits in length. Each Error Codes are assigned 3778 within a particular Error Class. This requires the creation of a 3779 registry for Error Codes in each Error Class. The error code 0 in 3780 each class is Reserved. 3782 Policies for the error code registries are as follows: 3784 0-63: IETF Review 3786 64-127: Specification Required 3788 128-191: Experimental/Private Use 3790 192-255: Reserved 3792 The initial assignments for the Error Code registries are given in 3793 Section 5.1.3.6. Experimental and Reserved values are relevant to 3794 all Error classes. 3796 6.5. QoS NSLP Error Source Identifiers 3798 Section 5.1.3.6 defines Error Source Identifiers, the type of which 3799 is identified by a 4 bit value. 3801 The value 0 is reserved. 3803 Values 1-3 are given in Section 5.1.3.6. 3805 Values 4-13 are assigned on a basis of Specification Required. 3807 Values 14 and 15 are for Experimental/Private Use. 3809 6.6. NSLP IDs and Router Alert Option Values 3811 This specification defines an NSLP for use with GIST. Furthermore it 3812 specifies that a number of NSLP-ID values are used for the support of 3813 bypassing intermediary nodes. Consequently, new identifiers must be 3814 assigned for them from the GIST NSLP identifier registry. The QoS 3815 NSLP requires that 32 NSLP-ID values be assigned, corresponding to 3816 QoS NSLP Aggregation Levels 0 to 31. 3818 The GIST specification also requires that NSLP-IDs be associated with 3819 specific Router Alert Option (RAO) values (although multiple NSLP-IDs 3820 may be associated with the same value). For the purposes of the QoS 3821 NSLP, each of its NSLP-ID values should be associated with a 3822 different RAO value. This requires that a block of 32 new IPv4 RAO 3823 values and a block of 32 new IPv6 RAO values be assigned, 3824 corresponding to QoS NSLP Aggregation Levels 0 to 31. 3826 7. Security Considerations 3828 The security requirement for the QoS NSLP is to protect the signaling 3829 exchange for establishing QoS reservations against identified 3830 security threats. For the signaling problem as a whole, these 3831 threats have been outlined in NSIS threats [RFC4081]; the NSIS 3832 framework [RFC4080] assigns a subset of the responsibility to GIST 3833 and the remaining threats need to be addressed by NSLPs. The main 3834 issues to be handled can be summarized as: 3836 Authorization: 3838 The QoS NSLP must assure that the network is protected against theft- 3839 of-service by offering mechanisms to authorize the QoS reservation 3840 requester. A user requesting a QoS reservation might want proper 3841 resource accounting and protection against spoofing and other 3842 security vulnerabilities which lead to denial of service and 3843 financial loss. In many cases authorization is based on the 3844 authenticated identity. The authorization solution must provide 3845 guarantees that replay attacks are either not possible or limited to 3846 a certain extent. Authorization can also be based on traits which 3847 enables the user to remain anonymous. Support for user identity 3848 confidentiality can be accomplished. 3850 Message Protection: 3852 Signaling message content should be protected against modification, 3853 replay, injection and eavesdropping while in transit. Authorization 3854 information, such as authorization tokens, need protection. This 3855 type of protection at the NSLP layer is necessary to protect messages 3856 between NSLP nodes. 3858 Rate Limitation: 3860 QNEs should perform rate limiting on the refresh messages that they 3861 send. An attacker could send erroneous messages on purpose, forcing 3862 the QNE to constantly reply with an error message. Authentication 3863 mechanisms would help in figuring out if error situations should be 3864 reported to the sender, or silently ignored. If the sender is 3865 authenticated, the QNE should reply promptly. 3867 Prevention of Denial of Service Attacks: 3869 GIST and QoS NSLP nodes have finite resources (state storage, 3870 processing power, bandwidth). The protocol mechanisms in this 3871 document try to minimize exhaustion attacks against these resources 3872 when performing authentication and authorization for QoS resources. 3874 To some extent the QoS NSLP relies on the security mechanisms 3875 provided by GIST which by itself relies on existing authentication 3876 and key exchange protocols. Some signaling messages cannot be 3877 protected by GIST and hence should be used with care by the QoS NSLP. 3878 An API must ensure that the QoS NSLP implementation is aware of the 3879 underlying security mechanisms and must be able to indicate which 3880 degree of security is provided between two GIST peers. If a level of 3881 security protection for QoS NSLP messages is required which goes 3882 beyond the security offered by GIST or underlying security 3883 mechanisms, additional security mechanisms described in this document 3884 must be used. The different usage environments and the different 3885 scenarios where NSIS is used make it very difficult to make general 3886 statements without reducing its flexibility. 3888 7.1. Trust Relationship Model 3890 This specification is based on a model which requires trust between 3891 neighboring NSLP nodes to establish a chain-of-trust along the QoS 3892 signaling path. The model is simple to deploy, was used in previous 3893 QoS authorization environments (such as RSVP) and seems to provide 3894 sufficiently strong security properties. We refer to this model as 3895 the New Jersey Turnpike. 3897 On the New Jersey Turnpike, motorists pick up a ticket at a toll 3898 booth when entering the highway. At the highway exit the ticket is 3899 presented and payment is made at the toll booth for the distance 3900 driven. For QoS signaling in the Internet this procedure is roughly 3901 similar. In most cases the data sender is charged for transmitted 3902 data traffic where charging is provided only between neighboring 3903 entities. 3905 +------------------+ +------------------+ +------------------+ 3906 | Network | | Network | | Network | 3907 | X | | Y | | Z | 3908 | | | | | | 3909 | -----------> -----------> | 3910 | | | | | | 3911 | | | | | | 3912 +--------^---------+ +------------------+ +-------+----------+ 3913 | . 3914 | . 3915 | v 3916 +--+---+ Data Data +--+---+ 3917 | Node | ==============================> | Node | 3918 | A | Sender Receiver | B | 3919 +------+ +------+ 3921 Legend: 3923 ----> Peering relationship which allows neighboring 3924 networks/entities to charge each other for the 3925 QoS reservation and data traffic 3927 ====> Data flow 3929 .... Communication to the end host 3931 Figure 16: New Jersey Turnpike Model 3933 The model shown in Figure 16 uses peer-to-peer relationships between 3934 different administrative domains as a basis for accounting and 3935 charging. As mentioned above, based on the peering relationship a 3936 chain-of-trust is established. There are several issues which come 3937 to mind when considering this type of model: 3939 o The model allows authorization on a request basis or on a per- 3940 session basis. Authorization mechanisms are elaborated in Section 3941 4.9. The duration for which the QoS authorization is valid needs to 3942 be controlled. Combining the interval with the soft-state interval 3943 is possible. Notifications from the networks also seem to be viable 3944 approach. 3946 o The price for a QoS reservation needs to be determined somehow and 3947 communicated to the charged entity and to the network where the 3948 charged entity is attached. Protocols providing Advice of Charge 3949 functionality are out of scope. 3951 o This architecture is simple enough to allow a scalable solution 3952 (ignoring reverse charging, multicast issues and price distribution). 3954 Charging the data sender as performed in the model simplifies 3955 security handling by demanding only peer-to-peer security protection. 3956 Node A would perform authentication and key establishment. The 3957 established security association (together with the session key) 3958 would allow the user to protect QoS signaling messages. The identity 3959 used during the authentication and key establishment phase would be 3960 used by Network X (see Figure 16) to perform the so-called policy- 3961 based admission control procedure. In our context this user 3962 identifier would be used to establish the necessary infrastructure to 3963 provide authorization and charging. Signaling messages later 3964 exchanged between the different networks are then also subject to 3965 authentication and authorization. The authenticated entity thereby 3966 is, however, the neighboring network and not the end host. 3968 The New Jersey Turnpike model is attractive because of its 3969 simplicity. S. Schenker et. al. [shenker] discuss various accounting 3970 implications and introduced the edge pricing model. The edge pricing 3971 model shows similarity to the model described in this section with 3972 the exception that mobility and the security implications itself are 3973 not addressed. 3975 7.2. Authorization Model Examples 3977 Various authorization models can be used in conjunction with the QoS 3978 NSLP. 3980 7.2.1. Authorization for the Two Party Approach 3982 The two party approach (Figure 17) is conceptually the simplest 3983 authorization model. 3985 +-------------+ QoS request +--------------+ 3986 | Entity |----------------->| Entity | 3987 | requesting | | authorizing | 3988 | resource |granted / rejected| resource | 3989 | |<-----------------| request | 3990 +-------------+ +--------------+ 3991 ^ ^ 3992 +...........................+ 3993 compensation 3994 Figure 17: Two party approach 3996 In this example the authorization decision only involves the two 3997 entities, or makes use of previous authorization using an out-of-band 3998 mechanism to avoid the need for active participation of an external 3999 entity during the NSIS protocol execution. 4001 This type of model may be applicable, e.g., between two neighboring 4002 networks (inter-domain signaling) where a long-term contract (or 4003 other out-of-band mechanisms) exists to manage charging and provides 4004 sufficient information to authorize individual requests. 4006 7.2.2. Token-based Three Party Approach 4008 An alternative approach makes use of tokens, such as those described 4009 in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the 4010 Open Settlement Protocol [osp]. Authorization tokens are used to 4011 associate two different signaling protocols runs (e.g., SIP and NSIS) 4012 and their authorization decision with each other. The latter is a 4013 form of assertion or trait. As an example, with the authorization 4014 token mechanism, some form of authorization is provided by the SIP 4015 proxy, which acts as the resource authorizing entity in Figure 18. 4016 If the request is authorized, then the SIP signaling returns an 4017 authorization token which can be included in the QoS signaling 4018 protocol messages to refer to the previous authorization decision. 4019 The tokens themselves may take a number of different forms, some of 4020 which may require the entity performing the QoS reservation to query 4021 external state. 4023 Authorization 4024 Token Request +--------------+ 4025 +-------------->| Entity C | financial settlement 4026 | | authorizing | <..................+ 4027 | | resource | . 4028 | +------+ request | . 4029 | | +--------------+ . 4030 | | . 4031 | |Authorization . 4032 | |Token . 4033 | | . 4034 | | . 4035 | | . 4036 | | QoS request . 4037 +-------------+ + Authz. Token +--------------+ . 4038 | Entity |----------------->| Entity B | . 4039 | requesting | | performing | . 4040 | resource |granted / rejected| QoS | <..+ 4041 | A |<-----------------| reservation | 4042 +-------------+ +--------------+ 4044 Figure 18: Token based three party approach 4046 For the digital money type of systems (e.g., OSP tokens), the token 4047 represents a limited amount of credit. So, new tokens must be sent 4048 with later refresh messages once the credit is exhausted. 4050 7.2.3. Generic Three Party Approach 4052 Another method is for the node performing the QoS reservation to 4053 delegate the authorization decision to a third party, as illustrated 4054 in Figure 19. The authorization decision may be performed on a per- 4055 request basis, periodically, or on a per-session basis. 4057 +--------------+ 4058 | Entity C | 4059 | authorizing | 4060 | resource | 4061 | request | 4062 +-----------+--+ 4063 ^ | 4064 QoS | | QoS 4065 authz| |authz 4066 req.| | res. 4067 QoS | v 4068 +-------------+ request +--+-----------+ 4069 | Entity |----------------->| Entity B | 4070 | requesting | | performing | 4071 | resource |granted / rejected| QoS | 4072 | A |<-----------------| reservation | 4073 +-------------+ +--------------+ 4075 Figure 19: Three party approach 4077 7.3. Computing the Authorization Decision 4079 Whenever an authorization decision has to be made then there is the 4080 question which information serves as an input to the authorizing 4081 entity. The following information items have been mentioned in the 4082 past for computing the authorization decision (in addition to the 4083 authenticated identity): 4085 Price 4087 QoS objects 4089 Policy rules 4091 Policy rules include attributes like time of day, subscription to 4092 certain services, membership, etc. into consideration when computing 4093 an authorization decision. 4095 The policies used to make the authorization are outside the scope of 4096 this document and implementation/deployment specific. 4098 8. Acknowledgments 4100 The authors would like to thank Eleanor Hepworth, Ruediger Geib, 4101 Roland Bless, Nemeth Krisztian, Markus Ott, Mayi Zoumaro-Djayoon, 4102 Martijn Swanink, and Ruud Klaver for their useful comments. Roland, 4103 especially, has done deep reviews of the document, making sure the 4104 protocol is well defined. Bob Braden provided helpful comments and 4105 guidance which were gratefully received. 4107 9. Contributors 4109 This draft combines work from three individual drafts. The following 4110 authors from these drafts also contributed to this document: Robert 4111 Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia 4112 Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and 4113 Maarten Buechli (Dante) and Eric Waegeman (Alcatel). In addition, 4114 Roland Bless has contributed considerable amounts of text all along 4115 the writing of this specification. 4117 Sven Van den Bosch was the first editor of the draft. Since version 4118 06 of the draft, Jukka Manner has taken the editorship. Yacine El 4119 Mghazli (Alcatel) contributed text on AAA. Charles Shen and Henning 4120 Schulzrinne suggested the use of the reason field in the 4121 BOUND_SESSION_ID. 4123 10. References 4125 10.1. Normative References 4127 [I-D.ietf-nsis-ntlp] 4128 Schulzrinne, H. and M. Stiemerling, "GIST: General 4129 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 4130 (work in progress), June 2009. 4132 [I-D.ietf-nsis-qspec] 4133 Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC 4134 Template", draft-ietf-nsis-qspec-24 (work in progress), 4135 January 2010. 4137 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 4138 August 1996. 4140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4141 Requirement Levels", BCP 14, RFC 2119, March 1997. 4143 10.2. Informative References 4145 [I-D.ietf-nsis-applicability-mobility-signaling] 4146 Sanda, T., Fu, X., Jeong, S., Manner, J., and H. 4147 Tschofenig, "Applicability Statement of NSIS Protocols in 4148 Mobile Environments", 4149 draft-ietf-nsis-applicability-mobility-signaling-14 (work 4150 in progress), January 2010. 4152 [I-D.ietf-nsis-rmd] 4153 Bader, A., Westberg, L., Karagiannis, G., Kappler, C., 4154 Tschofenig, H., Phelan, T., Takacs, A., and A. Csaszar, 4155 "RMD-QOSM - The Resource Management in Diffserv QOS 4156 Model", draft-ietf-nsis-rmd-15 (work in progress), 4157 July 2009. 4159 [I-D.manner-nsis-nslp-auth] 4160 Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, 4161 "Authorization for NSIS Signaling Layer Protocols", 4162 draft-manner-nsis-nslp-auth-04 (work in progress), 4163 July 2008. 4165 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 4166 Services in the Internet Architecture: an Overview", 4167 RFC 1633, June 1994. 4169 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 4170 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 4171 Functional Specification", RFC 2205, September 1997. 4173 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 4174 Services", RFC 2210, September 1997. 4176 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 4177 and S. Molendini, "RSVP Refresh Overhead Reduction 4178 Extensions", RFC 2961, April 2001. 4180 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 4181 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 4182 RFC 3175, September 2001. 4184 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 4185 "Session Authorization Policy Element", RFC 3520, 4186 April 2003. 4188 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 4189 Session Set-up with Media Authorization", RFC 3521, 4190 April 2003. 4192 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 4193 RFC 3726, April 2004. 4195 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 4196 Bosch, "Next Steps in Signaling (NSIS): Framework", 4197 RFC 4080, June 2005. 4199 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 4200 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 4202 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4203 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 4204 May 2008. 4206 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 4207 Specifications: ABNF", STD 68, RFC 5234, January 2008. 4209 [lrsvp] Manner, J. and K. Raatikainen, "Localized QoS Management 4210 for Multimedia Applications in Wireless Access Networks. 4211 IASTED, IMSA, August, 2004, pp. 193-200.". 4213 [opwa95] Breslau, L., "Two Issues in Reservation Establishment, 4214 Proc. ACM SIGCOMM '95 , Cambridge , MA , August 1995.". 4216 [osp] ETSI, ""Telecommunications and Internet protocol 4217 harmonization over networks (tiphon); open settlement 4218 protocol (osp) for inter- domain pricing, authorization, 4219 and usage exchange", Technical Specification 101 321, 4220 version 2.1.0.". 4222 [qos-auth] 4223 Tschofenig, H., "QoS NSLP Authorization Issues. Work in 4224 Progress.". 4226 [shenker] Shenker, S. and et al., ""Pricing in computer networks: 4227 Reshaping the research agenda", Proc. of TPRC 1995, 4228 1995.". 4230 Appendix A. Abstract NSLP-RMF API 4232 This appendix is purely informational and provides an abstract API 4233 between the QoS NSLP and the RMF. It should not be taken as a strict 4234 rule of implementors, but rather help clarify the interface between 4235 the NSLP and RMF. 4237 A.1. Triggers from QOS-NSLP towards RMF 4239 The QoS-NSLP triggers the RMF/QOSM functionality by using the 4240 sendrmf() primitive: 4242 int sendrmf(sid, nslp_req_type, qspec, authorization_info, 4243 NSLP_objects, filter, features_in, GIST_API_triggers, 4244 incoming_interface, outgoing_interface) 4245 o sid: SESSION_ID - The NSIS session identifier 4246 o nslp_req_type: indicates type of request: 4247 * RESERVE 4248 * QUERY 4249 * RESPONSE 4250 * NOTIFY 4251 o qspec: the QSPEC object, if present 4252 o authorization_info: the AUTH_SESSION object, if present 4253 o NSLP_objects: data structure that contains a list with received 4254 QoS-NSLP objects. This list can be used by e.g., Local 4255 application, Management, Policy control: 4256 * RII 4257 * RSN 4258 * BOUND_SESSION_ID list 4259 * REFRESH_PERIOD 4260 * SESSION_ID_LIST 4261 * RSN_LIST 4262 * INFO_SPEC 4263 * MSG_ID 4264 * BOUND_MSG_ID 4265 o filter: the information for packet filtering, based on the MRI and 4266 the PACKET_CLASSIFIER object. 4267 o features_in: it represents the flags included in the common header 4268 of the received QOS-NSLP message, but also additional 4269 o triggers: 4270 * BREAK 4271 * REQUEST REDUCED REFRESHES 4272 * RESERVE-INIT 4273 * TEAR 4274 * REPLACE 4275 * ACK-REQ 4276 * PROXY 4277 * SCOPING 4278 * synchronization_required: this attribute is set (see e.g., 4279 Section 4.6 and 4.7.1) when the QoS-NSLP functionality 4280 supported by a QNE Egress receives a non tearing RESERVE 4281 message that includes a MSG_ID or a BOUND_MSG_ID object and the 4282 BINDING_CODE value of the BOUND_SESSION_ID object is equal to 4283 one of the following values: 4284 + Tunnel and end-to-end sessions 4285 + Aggregate sessions 4286 * GIST_API_triggers: it represents the attributes that are 4287 provided by GIST to QoS-NSLP via the GIST API: 4288 + NSLPID 4289 + Routing-State-Check 4290 + SII-Handle 4291 + Transfer-Attributes 4292 + GIST-Hop-Count 4293 + IP-TTL 4294 + IP-Distance 4295 o incoming_interface: the ID of the incoming interface. Used only 4296 when the QNE reserves resources on incoming interface. Default is 4297 0 (no reservations on incoming interface) 4298 o outgoing_interface: the ID of the outgoing interface. Used only 4299 when the QNE reserves resources on outgoing interface. Default is 4300 0 (no reservations on outgoing interface) 4302 A.2. Triggers from RMF/QOSM towards QOS-NSLP 4304 The RMF triggers the QoS-NSLP functionality using the "recvrmf()" and 4305 "config()" primitives to perform either all or a subset of the 4306 features listed below. 4308 The recvrmf() primitive represents either a response to a request 4309 that has been sent via the API by the QoS-NSLP or an asynchronous 4310 notification. Note that when the RMF/QOSM receives a request via the 4311 API from the QoS-NSLP function, then one or more than one "recvrmf()" 4312 response primitives can be sent via the API towards QoS-NSLP. In 4313 this way the QOS-NSLP can generate one, or more than one, QoS-NSLP 4314 messages that can be for example, used in the situation that the 4315 arrival of one end-to-end RESERVE triggers the generation of two (or 4316 more) RESERVE messages, an end-to-end RESERVE message and one (or 4317 more) intra-domain (local) RESERVE message. 4319 The config() primitive is used to configure certain features, such as 4320 QNE type, statefullness, bypassing support. 4322 Note that the selection of the subset of triggers is controlled by 4323 the QoS Model. 4325 int recvrmf(sid, nslp_resp_type, qspec, authorization_info, status, 4326 NSLP_objects, filter, features_out, GIST_API_triggers 4327 incoming_interface, outgoing_interface) 4329 o sid: SESSION_ID - The NSIS session identifier 4330 o nslp_resp_type: indicates type of response: 4331 * RESERVE 4332 * QUERY 4333 * RESPONSE 4334 * NOTIFY 4335 o qspec: the QSPEC object, if present 4336 o authorization_info: the AUTHO_SESSION object, if present 4337 o status: boolean that notifies the status of the reservation and 4338 can be used by QOS-NSLP to include in the INFO_SPEC object: 4339 * RESERVATION_SUCCESSFUL 4340 * TEAR_DOWN_SUCCESSFUL 4341 * NO RESOURCES 4342 * RESERVATION_FAILURE 4343 * RESERVATION_PREEMPTED: reservation was pre-empted 4344 * AUTHORIZATION_FAILED: authorizing the request failed 4345 * MALFORMED_QSPEC: request failed due to malformed qspec 4346 * SYNCHRONISATION_FAILED: Mismatch synchronization between an 4347 end-to-end RESERVE and an intra-domain RESERVE (see Section 4.6 4348 and 4.7.1) 4349 * CONGESTION_SITUATION: Possible congestion situation occurred on 4350 downstream path 4351 * QOS Model Error 4352 o NSLP_objects: data structure that contains a list with QoS-NSLP 4353 objects that can be used by QoS-NSLP, when the QNE is a QNI, QNR, 4354 QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress: 4355 * RII 4356 * RSN 4357 * BOUND_SESSION_ID list 4358 * REFRESH_PERIOD 4359 * SESSION_ID_LIST 4360 * RSN_LIST 4361 * MSG_ID 4362 * BOUND_MSG_ID 4363 o filter: it represents the MRM related PACKET CLASSIFIER 4364 o features_out: it represents among others the flags that can be 4365 used by the QOS-NSLP for new generated QoS-NSLP messages: 4366 * BREAK 4367 * REQUEST REDUCED REFRESHES 4368 * RESERVE-INIT 4369 * TEAR 4370 * REPLACE 4371 * ACK-REQ 4372 * PROXY 4373 * SCOPING 4374 * BYPASSING: when the outgoing message should be bypassed then it 4375 includes the required bypassing level. Otherwise it is empty. 4376 It can be set only by QNI_Ingress, QNR_Ingress, QNI_Egress, 4377 QNR_Egress. It can be unset only by QNI_Ingress, QNR_Ingress, 4378 QNI_Egress, QNR_Egress. 4379 * BINDING () when BINDING is required then it includes a 4380 BOUND_SESSION_ID list. Otherwise it is empty. It can only be 4381 requested by the following QNE types: QNI, QNR, QNI_Ingress, 4382 QNR_Ingress, QNI_Egress, QNR_Egress. 4384 * NEW_SID - it requests to generate a new session with a new 4385 SESSION_ID. If the QoS-NSLP generates a new SESSION_ID then 4386 the QoS-NSLP has to return the value of this new SESSION_ID to 4387 the RMF/QOSM. It can be requested by a QNI, QNR, QNI_Ingress, 4388 QNI_Egress, QNR_Ingress, QNR_Egress. 4389 * NEW_RSN - it requests to generate a new RSN. If the QoS-NSLP 4390 generates a new RSN then the QoS-NSLP has to return the value 4391 of this new RSN to the RMF/QOSM. 4392 * NEW_RII - it requests to generate a new RII. If the QoS-NSLP 4393 generates a new RII then the QoS-NSLP has to return the value 4394 of this new RII to the RMF/QOSM. 4395 o GIST_API_triggers: it represents the attributes that are provided 4396 to GIST via QoS-NSLP via the GIST API 4397 * NSLPID 4398 * SII-Handle 4399 * Transfer-Attributes 4400 * GIST-Hop-Count 4401 * IP-TTL 4402 * ROUTING-STATE-CHECK (if set it requires from GIST to create a 4403 routing state) 4404 o incoming_interface: the ID of the incoming interface. Used only 4405 when the QNE reserves resources on incoming interface. Default is 4406 0 (no reservations on incoming interface) 4407 o outgoing_interface: the ID of the outgoing interface. Used only 4408 when the QNE reserves resources on outgoing interface. Default is 4409 0 (no reservations on outgoing interface) 4411 A.3. Configuration interface 4413 The config() function is meant for configuring per-session settings, 4414 from the RMF towards the NSLP. 4416 int config(sid, qne_type, state_type, bypassing_type) 4418 o sid: SESSION_ID - The NSIS session identifier 4419 o qne_type: it defines the type of a QNE 4420 * QNI 4421 * QNI_Ingress: the QNE is a QNI and an Ingress QNE 4422 * QNE: the QNE is not a QNI or QNR 4423 * QNE_Interior: the QNE is an Interior QNE, but it is not a QNI 4424 or QNR 4425 * QNI_Egress: the QNE is a QNI and an Egress QNE 4426 * QNR 4427 * QNR_Ingress: the QNE is a QNR and an Ingress QNE 4428 * QNR_Egress: the QNE is a QNR and an Egress QNE 4429 o state_type: it defines if the QNE keeps QoS-NSLP operational 4430 states 4431 * STATEFULL 4432 * STATELESS 4433 o bypassing_type: it defines if a QNE bypasses end-to-end messages 4434 or not 4436 Appendix B. Glossary 4438 AAA: Authentication, Authorization and Accounting 4440 EAP: Extensible Authentication Protocol 4442 MRI: Message Routing Information (see [I-D.ietf-nsis-ntlp]) 4444 NAT: Network Address Translator 4446 NSLP: NSIS Signaling Layer Protocol (see [RFC4080]) 4448 NTLP: NSIS Transport Layer Protocol (see [RFC4080]) 4450 OPWA: One Pass With Advertising 4452 OSP: Open Settlement Protocol 4454 PIN: Policy Ignorant Node 4456 QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2) 4458 QNI: the first node in the sequence of QNEs that issues a reservation 4459 request for a session (see Section 2) 4461 QNR: the last node in the sequence of QNEs that receives a 4462 reservation request for a session (see Section 2) 4464 QSPEC: Quality of Service Specification 4466 RII: Request Identification Information 4468 RMD: Resource Management for DiffServ 4470 RMF: Resource Management Function 4472 RSN: Reservation Sequence Number 4474 RSVP: Resource Reservation Protocol (see [RFC2205]) 4476 SII: Source Identification Information 4477 SIP: Session Initiation Protocol 4479 SLA: Service Level Agreement 4481 Authors' Addresses 4483 Jukka Manner 4484 Aalto University 4485 Department of Communications and Networking (Comnet) 4486 P.O. Box 13000 4487 00076 Aalto 4488 Finland 4490 Phone: +358 9 470 22481 4491 Email: jukka.manner@tkk.fi 4493 Georgios Karagiannis 4494 University of Twente/Ericsson 4495 P.O. Box 217 4496 Enschede 7500 AE 4497 The Netherlands 4499 Email: karagian@cs.utwente.nl 4501 Andrew McDonald 4502 Siemens/Roke Manor Research 4503 Roke Manor Research Ltd. 4504 Romsey, Hants S051 0ZN 4505 UK 4507 Email: andrew.mcdonald@roke.co.uk