idnits 2.17.1 draft-ietf-nsis-qos-nslp-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4508. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A RESPONSE message MUST carry INFO_SPEC objects towards the QNI. The RESPONSE message MUST be forwarded unconditionally up to the QNI. The actions that SHOULD be undertaken by the QNI that receives the INFO_SPEC object are specified by the local policy of the QoS model supported by this QNE. The default action is that the QNI that receives the INFO_SPEC object SHOULD not trigger any other QoS NSLP procedure. -- 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 (February 7, 2008) is 5922 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-15 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-18 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qspec (ref. 'I-D.ietf-nsis-qspec') == Outdated reference: A later version (-20) exists of draft-ietf-nsis-applicability-mobility-signaling-08 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-rmd-12 == Outdated reference: A later version (-04) exists of draft-manner-nsis-nslp-auth-03 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manner 3 Internet-Draft TKK 4 Intended status: Standards Track G. Karagiannis 5 Expires: August 10, 2008 University of Twente/Ericsson 6 A. McDonald 7 Siemens/Roke Manor Research 8 February 7, 2008 10 NSLP for Quality-of-Service Signaling 11 draft-ietf-nsis-qos-nslp-16.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 10, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This specification describes the NSIS Signaling Layer Protocol (NSLP) 45 for signaling QoS reservations in the Internet. It is in accordance 46 with the framework and requirements developed in NSIS. Together with 47 GIST, it provides functionality similar to RSVP and extends it. The 48 QoS NSLP is independent of the underlying QoS specification or 49 architecture and provides support for different reservation models. 50 It is simplified by the elimination of support for multicast flows. 51 This specification explains the overall protocol approach, design 52 decisions made and provides examples. It specifies object, message 53 formats and processing rules. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Overall Approach . . . . . . . . . . . . . . . . . . . . . 7 61 3.1.1. Protocol Messages . . . . . . . . . . . . . . . . . . 10 62 3.1.2. QoS Models and QoS Specifications . . . . . . . . . . 11 63 3.1.3. Policy Control . . . . . . . . . . . . . . . . . . . . 13 64 3.2. Design Background . . . . . . . . . . . . . . . . . . . . 14 65 3.2.1. Soft States . . . . . . . . . . . . . . . . . . . . . 14 66 3.2.2. Sender and Receiver Initiation . . . . . . . . . . . . 14 67 3.2.3. Protection Against Message Re-ordering and 68 Duplication . . . . . . . . . . . . . . . . . . . . . 15 69 3.2.4. Explicit Confirmations . . . . . . . . . . . . . . . . 15 70 3.2.5. Reduced Refreshes . . . . . . . . . . . . . . . . . . 15 71 3.2.6. Summary Refreshes and Summary Tear . . . . . . . . . . 15 72 3.2.7. Message Scoping . . . . . . . . . . . . . . . . . . . 16 73 3.2.8. Session Binding . . . . . . . . . . . . . . . . . . . 16 74 3.2.9. Message Binding . . . . . . . . . . . . . . . . . . . 17 75 3.2.10. Layering . . . . . . . . . . . . . . . . . . . . . . . 17 76 3.2.11. Support for Request Priorities . . . . . . . . . . . . 19 77 3.2.12. Rerouting . . . . . . . . . . . . . . . . . . . . . . 19 78 3.2.13. Pre-emption . . . . . . . . . . . . . . . . . . . . . 24 79 3.3. GIST Interactions . . . . . . . . . . . . . . . . . . . . 24 80 3.3.1. Support for Bypassing Intermediate Nodes . . . . . . . 25 81 3.3.2. Support for Peer Change Identification . . . . . . . . 25 82 3.3.3. Support for Stateless Operation . . . . . . . . . . . 26 83 3.3.4. Priority of Signaling Messages . . . . . . . . . . . . 26 84 3.3.5. Knowledge of Intermediate QoS NSLP Unaware Nodes . . . 26 85 4. Examples of QoS NSLP Operation . . . . . . . . . . . . . . . . 27 86 4.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 27 87 4.2. Sending a Query . . . . . . . . . . . . . . . . . . . . . 28 88 4.3. Basic Receiver-initiated Reservation . . . . . . . . . . . 29 89 4.4. Bidirectional Reservations . . . . . . . . . . . . . . . . 31 90 4.5. Aggregate Reservations . . . . . . . . . . . . . . . . . . 32 91 4.6. Message Binding . . . . . . . . . . . . . . . . . . . . . 34 92 4.7. Reduced State or Stateless Interior Nodes . . . . . . . . 37 93 4.7.1. Sender-initiated Reservation . . . . . . . . . . . . . 38 94 4.7.2. Receiver-initiated Reservation . . . . . . . . . . . . 39 95 4.8. Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . 40 97 5. QoS NSLP Functional Specification . . . . . . . . . . . . . . 41 98 5.1. QoS NSLP Message and Object Formats . . . . . . . . . . . 41 99 5.1.1. Common Header . . . . . . . . . . . . . . . . . . . . 42 100 5.1.2. Message Formats . . . . . . . . . . . . . . . . . . . 43 101 5.1.3. Object Formats . . . . . . . . . . . . . . . . . . . . 47 102 5.2. General Processing Rules . . . . . . . . . . . . . . . . . 59 103 5.2.1. State Manipulation . . . . . . . . . . . . . . . . . . 60 104 5.2.2. Message Forwarding . . . . . . . . . . . . . . . . . . 61 105 5.2.3. Standard Message Processing Rules . . . . . . . . . . 61 106 5.2.4. Retransmissions . . . . . . . . . . . . . . . . . . . 61 107 5.2.5. Rerouting . . . . . . . . . . . . . . . . . . . . . . 62 108 5.3. Object Processing . . . . . . . . . . . . . . . . . . . . 64 109 5.3.1. Reservation Sequence Number (RSN) . . . . . . . . . . 64 110 5.3.2. Request Identification Information (RII) . . . . . . . 65 111 5.3.3. BOUND_SESSION_ID . . . . . . . . . . . . . . . . . . . 66 112 5.3.4. REFRESH_PERIOD . . . . . . . . . . . . . . . . . . . . 67 113 5.3.5. INFO_SPEC . . . . . . . . . . . . . . . . . . . . . . 67 114 5.3.6. SESSION_ID_LIST . . . . . . . . . . . . . . . . . . . 69 115 5.3.7. RSN_LIST . . . . . . . . . . . . . . . . . . . . . . . 70 116 5.3.8. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . 71 117 5.4. Message Processing Rules . . . . . . . . . . . . . . . . . 71 118 5.4.1. RESERVE Messages . . . . . . . . . . . . . . . . . . . 71 119 5.4.2. QUERY Messages . . . . . . . . . . . . . . . . . . . . 76 120 5.4.3. RESPONSE Messages . . . . . . . . . . . . . . . . . . 77 121 5.4.4. NOTIFY Messages . . . . . . . . . . . . . . . . . . . 78 122 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 123 6.1. QoS NSLP Message Type . . . . . . . . . . . . . . . . . . 79 124 6.2. NSLP Message Objects . . . . . . . . . . . . . . . . . . . 79 125 6.3. QoS NSLP Binding Codes . . . . . . . . . . . . . . . . . . 80 126 6.4. QoS NSLP Error Classes and Error Codes . . . . . . . . . . 80 127 6.5. QoS NSLP Error Source Identifiers . . . . . . . . . . . . 81 128 6.6. NSLP IDs and Router Alert Option Values . . . . . . . . . 81 129 7. Security Considerations . . . . . . . . . . . . . . . . . . . 82 130 7.1. Trust Relationship Model . . . . . . . . . . . . . . . . . 83 131 7.2. Authorization Model Examples . . . . . . . . . . . . . . . 85 132 7.2.1. Authorization for the Two Party Approach . . . . . . . 85 133 7.2.2. Token-based Three Party Approach . . . . . . . . . . . 86 134 7.2.3. Generic Three Party Approach . . . . . . . . . . . . . 87 135 7.3. Computing the Authorization Decision . . . . . . . . . . . 87 136 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 88 137 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 88 138 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88 139 10.1. Normative References . . . . . . . . . . . . . . . . . . . 88 140 10.2. Informative References . . . . . . . . . . . . . . . . . . 89 141 Appendix A. Abstract NSLP-RMF API . . . . . . . . . . . . . . . . 90 142 A.1. Triggers from QOS-NSLP towards RMF . . . . . . . . . . . . 90 143 A.2. Triggers from RMF/QOSM towards QOS-NSLP . . . . . . . . . 92 144 A.3. Configuration interface . . . . . . . . . . . . . . . . . 94 146 Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 95 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96 148 Intellectual Property and Copyright Statements . . . . . . . . . . 97 150 1. Introduction 152 This document defines a Quality of Service (QoS) NSIS Signaling Layer 153 Protocol (NSLP), henceforth referred to as the "QoS NSLP". This 154 protocol establishes and maintains state at nodes along the path of a 155 data flow for the purpose of providing some forwarding resources for 156 that flow. It is intended to satisfy the QoS-related requirements of 157 RFC 3726 [RFC3726]. This QoS NSLP is part of a larger suite of 158 signaling protocols, whose structure is outlined in the NSIS 159 framework [RFC4080]; this defines a common NSIS Transport Layer 160 Protocol (NTLP). The abstract NTLP has been developed into a 161 concrete protocol, GIST (General Internet Signaling Transport) 162 [I-D.ietf-nsis-ntlp]. The QoS NSLP relies on GIST to carry out many 163 aspects of signaling message delivery. 165 The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 166 [RFC2205], and uses soft-state peer-to-peer refresh messages as the 167 primary state management mechanism (i.e., state installation/refresh 168 is performed between pairs of adjacent NSLP nodes, rather than in an 169 end-to-end fashion along the complete signaling path). The QoS NSLP 170 extends the set of reservation mechanisms to meet the requirements of 171 RFC 3726 [RFC3726], in particular support of sender or receiver- 172 initiated reservations, as well as, a type of bi-directional 173 reservation and support of reservations between arbitrary nodes, 174 e.g., edge-to-edge, end-to-access, etc. On the other hand, there is 175 currently no support for IP multicast. 177 A distinction is made between the operation of the signaling protocol 178 and the information required for the operation of the Resource 179 Management Function (RMF). This document describes the signaling 180 protocol, whilst [I-D.ietf-nsis-qspec] describes the RMF-related 181 information carried in the QSPEC (QoS Specification) object in QoS 182 NSLP messages. This is similar to the decoupling between RSVP and 183 the IntServ architecture, RFC 1633 [RFC1633]. The QSPEC carries 184 information on resources available, resources required, traffic 185 descriptions and other information required by the RMF. 187 This document is structured as follows. The overall protocol design 188 is outlined in Section 3.1. The operation and use of the QoS NSLP is 189 described in more detail in the rest of Section 3. Section 4 then 190 clarifies the protocol by means of a number of examples. These 191 sections should be read by people interested in the overall protocol 192 capabilities. The functional specification in Section 5 contains 193 more detailed object and message formats and processing rules and 194 should be the basis for implementers. The subsequent sections 195 describe IANA allocation issues, and security considerations. 197 2. Terminology 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in RFC 2119 [RFC2119]. 203 The terminology defined by GIST [I-D.ietf-nsis-ntlp] applies to this 204 draft. 206 In addition, the following terms are used: 208 QNE: an NSIS Entity (NE), which supports the QoS NSLP. 210 QNI: the first node in the sequence of QNEs that issues a reservation 211 request for a session. 213 QNR: the last node in the sequence of QNEs that receives a 214 reservation request for a session. 216 P-QNE: Proxy-QNE, a node set to reply to messages with the PROXY 217 scope flag set. 219 Session: A session defines an association between a QNI and QNR 220 related to a data flow. Intermediate QNEs on the path, the QNI and 221 the QNR use the same identifier to refer to the state stored for the 222 association. The same QNI and QNR may have more than one session 223 active at any one time. 225 Session Identification (SESSION_ID, SID): This is a cryptographically 226 random and (probabilistically) globally unique identifier of the 227 application layer session that is associated with a certain flow. 228 Often there will only be one data flow for a given session, but in 229 mobility/multihoming scenarios there may be more than one and they 230 may be differently routed [RFC4080]. 232 Source or message source: The one of two adjacent NSLP peers that is 233 sending a signaling message (maybe the upstream or the downstream 234 peer). Note that this is not necessarily the QNI. 236 QoS NSLP operation state: State used/kept by the QoS NSLP processing 237 to handle messaging aspects. 239 QoS reservation state: State used/kept by Resource Management 240 Function to describe reserved resources for a session. 242 Flow ID: This is essentially the Message Routing Information (MRI) 244 in GIST for path-coupled signaling. 246 Figure 1 shows the components that have a role in a QoS NSLP 247 signaling session. The flow sender and receiver would in most cases 248 be part of the QNI and QNR nodes. Yet, these may be separate nodes, 249 too. 251 QoS NSLP nodes 252 IP address (QoS unaware NSIS nodes are IP address 253 = Flow not shown) = Flow 254 Source | | | Destination 255 Address | | | Address 256 V V V 257 +--------+ Data +------+ +------+ +------+ +--------+ 258 | Flow |-------|------|------|------|-------|------|---->| Flow | 259 | Sender | Flow | | | | | | |Receiver| 260 +--------+ | QNI | | QNE | | QNR | +--------+ 261 | | | | | | 262 +------+ +------+ +------+ 263 =====================> 264 <===================== 265 Signaling 266 Flow 268 Figure 1: Components of the QoS NSLP architecture 270 A glossary of terms and abbreviations used in this document can be 271 found in Appendix B. 273 3. Protocol Overview 275 3.1. Overall Approach 277 This section presents a logical model for the operation of the QoS 278 NSLP and associated provisioning mechanisms within a single node. 279 The model is shown in Figure 2. 281 +---------------+ 282 | Local | 283 |Applications or| 284 |Management (e.g| 285 |for aggregates)| 286 +---------------+ 287 ^ 288 V 289 V 290 +----------+ +----------+ +---------+ 291 | QoS NSLP | | Resource | | Policy | 292 |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control | 293 +----------+ +----------+ +---------+ 294 . ^ | * ^ 295 | V . * ^ 296 +----------+ * ^ 297 | NTLP | * ^ 298 |Processing| * V 299 +----------+ * V 300 | | * V 301 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 302 . . * V 303 | | * ............................. 304 . . * . Traffic Control . 305 | | * . +---------+. 306 . . * . |Admission|. 307 | | * . | Control |. 308 +----------+ +------------+ . +---------+. 309 <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> 310 | Packet | | Interface | .+----------+ +---------+. 311 ===>|Processing|====| Selection |===.| Packet |====| Packet |.==> 312 | | |(Forwarding)| .|Classifier| Scheduler|. 313 +----------+ +------------+ .+----------+ +---------+. 314 ............................. 315 <.-.-> = signaling flow 316 =====> = data flow (sender --> receiver) 317 <<<>>> = control and configuration operations 318 ****** = routing table manipulation 320 Figure 2: QoS NSLP in a Node 322 This diagram shows an example implementation scenario where QoS 323 conditioning is performed on the output interface. However, this 324 does not limit the possible implementations. For example, in some 325 cases traffic conditioning may be performed on the incoming 326 interface, or it may be split over the input and output interfaces. 327 Also, the interactions with the Policy Control component may be more 328 complex, involving interaction with the Resource Management Function, 329 and the AAA infrastructure. 331 From the perspective of a single node, the request for QoS may result 332 from a local application request, or from processing an incoming QoS 333 NSLP message. The request from a local application includes not only 334 user applications (e.g., multimedia applications) but also network 335 management (e.g. initiating a tunnel to handle an aggregate, or 336 interworking with some other reservation protocol - such as RSVP) and 337 the policy control module (e.g., for explicit teardown triggered by 338 AAA). In this sense, the model does not distinguish between hosts 339 and routers. 341 Incoming messages are captured during input packet processing and 342 handled by GIST. Only messages related to QoS are passed to the QoS 343 NSLP. GIST may also generate triggers to the QoS NSLP (e.g., 344 indications that a route change has occurred). The QoS request is 345 handled by the RMF, which coordinates the activities required to 346 grant and configure the resource. It also handles policy-specific 347 aspects of QoS signaling. 349 The grant processing involves two local decision modules, 'policy 350 control' and 'admission control'. Policy control determines whether 351 the user is authorized to make the reservation. Admission control 352 determines whether the network of the node has sufficient available 353 resources to supply the requested QoS. If both checks succeed, 354 parameters are set in the packet classifier and in the link layer 355 interface (e.g., in the packet scheduler) to obtain the desired QoS. 356 Error notifications are passed back to the request originator. The 357 resource management function may also manipulate the forwarding 358 tables at this stage, to select (or at least pin) a route; this must 359 be done before interface-dependent actions are carried out (including 360 sending outgoing messages over any new route), and is in any case 361 invisible to the operation of the protocol. 363 Policy control is expected to make use of the authentication 364 infrastructure or the authentication protocols external to the node 365 itself. Some discussion can be found in a separate document on 366 authorization issues [qos-auth]. More generally, the processing of 367 policy and resource management functions may be outsourced to an 368 external node leaving only 'stubs' co-located with the NSLP node; 369 this is not visible to the protocol operation. A more detailed 370 discussion of authentication and authorization can be found in 371 Section 3.1.3. 373 Admission control, packet scheduling, and any part of policy control 374 beyond simple authorization have to be implemented using specific 375 definitions for types and levels of QoS. A key assumption is made 376 that the QoS NSLP is independent of the QoS parameters (e.g., IntServ 377 service elements). These are captured in a QoS Model and interpreted 378 only by the resource management and associated functions, and are 379 opaque to the QoS NSLP itself. QoS Models are discussed further in 380 Section 3.1.2. 382 The final stage of processing for a resource request is to indicate 383 to the QoS NSLP protocol processing that the required resources have 384 been configured. The QoS NSLP may generate an acknowledgment message 385 in one direction, and may forward the resource request in the other. 386 Message routing is carried out by the GIST module. Note that while 387 Figure 2 shows a unidirectional data flow, the signaling messages can 388 pass in both directions through the node, depending on the particular 389 message and orientation of the reservation. 391 3.1.1. Protocol Messages 393 The QoS NSLP uses four message types: 395 RESERVE: The RESERVE message is the only message that manipulates QoS 396 NSLP reservation state. It is used to create, refresh, modify and 397 remove such state. The result of a RESERVE message is the same 398 whether a message is received once or many times. 400 QUERY: A QUERY message is used to request information about the data 401 path without making a reservation. This functionality can be used to 402 reservations or for support of certain QoS models. The information 403 obtained from a QUERY may be used in the admission control process of 404 a QNE (e.g., in case of measurement-based admission control). Note 405 that a QUERY does not change existing reservation state. 407 RESPONSE: The RESPONSE message is used to provide information about 408 the result of a previous QoS NSLP message. This includes explicit 409 confirmation of the state manipulation signaled in the RESERVE 410 message, the response to a QUERY message or an error code if the QNE 411 or QNR is unable to provide the requested information or if the 412 response is negative. The RESPONSE message does not cause any 413 reservation state to be installed or modified. 415 NOTIFY: NOTIFY messages are used to convey information to a QNE. 416 They differ from RESPONSE messages in that they are sent 417 asynchronously and need not refer to any particular state or 418 previously received message. The information conveyed by a NOTIFY 419 message is typically related to error conditions. Examples would be 420 notification to an upstream peer about state being torn down or to 421 indicate when a reservation has been preempted. 423 QoS NSLP messages are sent peer-to-peer. This means that a QNE 424 considers its adjacent upstream or downstream peer to be the source 425 of each message. 427 Each protocol message has a common header which indicates the message 428 type and contains various flag bits. Message formats are defined in 429 Section 5.1.2. Message processing rules are defined in Section 5.4. 431 QoS NSLP messages contain three types of objects: 433 1. Control Information: Control information objects carry general 434 information for the QoS NSLP processing, such as sequence numbers or 435 whether a response is required. 437 2. QoS specifications (QSPECs): QSPEC objects describe the actual 438 resources that are required and depend on the QoS model being used. 439 Besides any resource description they may also contain other control 440 information used by the RMF's processing. 442 3. Policy objects: Policy objects contain data used to authorize the 443 reservation of resources. 445 Object formats are defined in Section 5.1.3. Object processing rules 446 are defined in Section 5.3. 448 3.1.2. QoS Models and QoS Specifications 450 The QoS NSLP provides flexibility over the exact patterns of 451 signaling messages that are exchanged. The decoupling of QoS NSLP 452 and QSPEC allows the QoS NSLP to be ignorant about the ways in which 453 traffic, resources, etc. are described, and it can treat the QSPEC as 454 an opaque object. Various QoS models can be designed, and these do 455 not affect the specification of the QoS NSLP protocol. Only the RMF 456 specific to a given QoS model will need to interpret the QSPEC. The 457 Resource Management Function (RMF) reserves resources for each flow. 459 The QSPEC fulfills a similar purpose to the TSpec, RSpec and AdSpec 460 objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC 461 2210 [RFC2210]. At each QNE, the content of the QSPEC is interpreted 462 by the Resource Management Function and the Policy Control Function 463 for the purposes of traffic and policy control (including admission 464 control and configuration of the packet classifier and scheduler). 466 The QoS NSLP does not mandate any particular behavior for the RMF, 467 instead providing interoperability at the signaling protocol level 468 whilst leaving the validation of RMF behavior to contracts external 469 to the protocol itself. The RMF may make use of various elements 470 from the QoS NSLP message, not only the QSPEC object. 472 Still, this specification assumes that resource sharing is possible 473 between flows with the same SESSION_ID that originate from the same 474 QNI or between flows with a different SESSION_ID that are related 475 through the BOUND_SESSION_ID object. For flows with the same 476 SESSION_ID, resource sharing is only applicable when the existing 477 reservation is not just replaced (which is indicated by the REPLACE 478 flag in the common header). We assume that the QoS model supports 479 resource sharing between flows. A QoS Model may elect to implement a 480 more general behavior of supporting relative operations on existing 481 reservations, such as ADDING or SUBTRACTING a certain amount of 482 resources from the current reservation. A QoS Model may also elect 483 to allow resource sharing more generally, e.g., between all flows 484 with the same DSCP. 486 The QSPEC carries a collection of objects that can describe QoS 487 specifications in a number of different ways. A generic template is 488 defined in [I-D.ietf-nsis-qspec] and contains object formats for 489 generally useful elements of the QoS description, which is designed 490 to ensure interoperability when using the basic set of objects. A 491 QSPEC describing the resources requested will usually contain objects 492 which need to be understood by all implementations, and it can also 493 be enhanced with additional objects specific to a QoS model to 494 provide a more exact definition to the RMF, which may be better able 495 to use its specific resource management mechanisms (which may, e.g., 496 be link specific) as a result. 498 A QoS Model defines the behavior of the RMF, including inputs and 499 outputs, and how QSPEC information is used to describe resources 500 available, resources required, traffic descriptions, and control 501 information required by the RMF. A QoS Model also describes the 502 minimum set of parameters QNEs should use in the QSPEC when signaling 503 about this QoS Model. 505 QoS Models may be local (private to one network), implementation/ 506 vendor specific, or global (implementable by different networks and 507 vendors). All QSPECs should follow the design of the QSPEC template. 509 The definition of a QoS model may also have implications on how local 510 behavior should be implemented in the areas where the QoS NSLP gives 511 freedom to implementers. For example, it may be useful to identify 512 recommended behavior for how a RESERVE message that is forwarded 513 relates to that received, or when additional signaling sessions 514 should be started based on existing sessions, such as required for 515 aggregate reservations. In some cases, suggestions may be made on 516 whether state that may optionally be retained should be held in 517 particular scenarios. A QoS model may specify reservation 518 preemption, e.g., an incoming resource request may cause removal of 519 an earlier established reservation. 521 3.1.3. Policy Control 523 Getting access to network resources, e.g., network access in general 524 or access to QoS, typically involves some kind of policy control. 525 One example of this is authorization of the resource requester. 526 Policy control for QoS NSLP resource reservation signaling is 527 conceptually organized as illustrated below in Figure 3. 529 +-------------+ 530 | Policy | 531 | Decision | 532 | Point (PDP) | 533 +------+------+ 534 | 535 /-\-----+-----/\ 536 //// \\\\ 537 || || 538 | Policy transport | 539 || || 540 \\\\ //// 541 \-------+------/ 542 | 543 +-------------+ QoS signaling +------+------+ 544 | Entity |<==============>| QNE = Policy|<=========> 545 | requesting | Data Flow | Enforcement | 546 | resource |----------------|-Point (PEP)-|----------> 547 +-------------+ +-------------+ 549 Figure 3: Policy control with the QoS NSLP signaling 551 From the QoS NSLP point of view, the policy control model is 552 essentially a two-party model between neighboring QNEs. The actual 553 policy decision may depend on the involvement of a third entity (the 554 policy decision point, PDP), but this happens outside of the QoS NSLP 555 protocol by means of existing policy infrastructure (COPS, Diameter, 556 etc). The policy control model for the entire end-to-end chain of 557 QNEs is therefore one of transitivity, where each of the QNEs 558 exchanges policy information with its QoS NSLP policy peer. 560 The authorization of a resource request often depends on the identity 561 of the entity making the request. Authentication may be required. 562 The GIST channel security mechanisms provide one way of 563 authenticating the QoS NSLP peer which sent the request, and so may 564 be used in making the authorization decision. 566 Additional information might also be provided in order to assist in 567 making the authorization decision. This might include alternative 568 methods of authenticating the request. 570 The QoS NSLP does not contain objects to carry authorization 571 information. At the time of writing, there exists a separate work 572 [I-D.manner-nsis-nslp-auth] that defines this functionality for the 573 QoS NSLP and the NATFW NSLP. 575 It is generally assumed that policy enforcement is likely to 576 concentrate on border nodes between administrative domains. This may 577 mean that nodes within the domain are "Policy Ignorant Nodes" that 578 perform no per-request authentication or authorization, relying on 579 the border nodes to perform the enforcement. In such cases, the 580 policy management between ingress and egress edge of a domain relies 581 on the internal chain of trust between the nodes in the domain. If 582 this is not acceptable, a separate signaling session can be set up 583 between the ingress and egress edge nodes in order to exchange policy 584 information. 586 3.2. Design Background 588 This section presents some of the key functionality behind the 589 specification of the QoS NSLP. 591 3.2.1. Soft States 593 The NSIS protocol suite takes a soft-state approach to state 594 management. This means that reservation state in QNEs must be 595 periodically refreshed. The frequency with which state installation 596 is refreshed is expressed in the REFRESH_PERIOD object. This object 597 contains a value in milliseconds indicating how long the state that 598 is signaled for remains valid. Maintaining the reservation beyond 599 this lifetime can be done by sending a RESERVE message periodically. 601 3.2.2. Sender and Receiver Initiation 603 The QoS NSLP supports both sender-initiated and receiver-initiated 604 reservations. For a sender-initiated reservation, RESERVE messages 605 travel in the same direction as the data flow that is being signaled 606 for (the QNI is at the side of the source of the data flow). For a 607 receiver-initiated reservation, RESERVE messages travel in the 608 opposite direction (the QNI is at the side of the receiver of the 609 data flow). 611 Note: these definitions follow the definitions in Section 3.3.1. of 612 RFC 4080 [RFC4080]. The main issue is, which node is in charge of 613 requesting and maintaining the resource reservation. In a receiver- 614 initiated reservation, even though the sender sends the initial 615 QUERY, the receiver is still in charge of making the actual resource 616 request, and maintaining the reservation. 618 3.2.3. Protection Against Message Re-ordering and Duplication 620 RESERVE messages affect the installed reservation state. Unlike 621 NOTIFY, QUERY and RESPONSE messages, the order in which RESERVE 622 messages are received influences the eventual reservation state that 623 will be stored at a QNE, that is, the most recent RESERVE message 624 replaces the current reservation. Therefore, in order to protect 625 against RESERVE message re-ordering or duplication, the QoS NSLP uses 626 a Reservation Sequence Number (RSN). The RSN has local significance 627 only, i.e., between a QNE and its downstream peers. 629 3.2.4. Explicit Confirmations 631 A QNE may require a confirmation that the end-to-end reservation is 632 in place, or a reply to a query along the path. For such requests, 633 it must be able to keep track of which request each response refers 634 to. This is supported by including a Request Identification 635 Information (RII) object in a QoS NSLP message. 637 3.2.5. Reduced Refreshes 639 For scalability, the QoS NSLP supports an abbreviated form of refresh 640 RESERVE message. In this case, the refresh RESERVE references the 641 reservation using the RSN and the SESSION_ID, and does not include 642 the full reservation specification (including QSPEC). By default 643 state refresh should be performed with reduced refreshes in order to 644 save bytes during transmission. Stateless QNEs will require full 645 refresh since they do not store the whole reservation information. 647 If the stateful QNE does not support reduced refreshes, or there is a 648 mismatch between the local and received RSN, the stateful QNE must 649 reply with an RESPONSE carrying an INFO_SPEC indicating the error. 650 Furthermore, the QNE must stop sending reduced refreshes to this peer 651 if the error indicates lacking support for this feature. 653 3.2.6. Summary Refreshes and Summary Tear 655 For limiting the number of individual messages, the QoS NSLP supports 656 a summary refresh and summary tear messages. When sending a 657 refreshing RESERVE for a certain (primary) session, a QNE may include 658 a SESSION_ID_LIST object where the QNE indicates (secondary) sessions 659 that are also refreshed. An RSN_LIST object must also be added. The 660 SESSION IDs and RSNs are stacked in the objects such that the index 661 in both stacks refer to the same reservation state, i.e., the 662 SESSION_ID and RSN at index i in both objects refers to the same 663 session. If the receiving stateful QNE notices unknown SESSION IDs 664 or a mismatch with RSNs for a session, it will reply back to the 665 upstream stateful QNE with an error. 667 In order to tear down several sessions at once, a QNE may include 668 SESSION_ID_LIST and RSN_LIST objects in a tearing reserve. The 669 downstream stateful QNE must then also tear the other sessions 670 indicated. The downstream stateful QNE must silently ignore any 671 unknown SESSION IDs. 673 GIST provides a SII_HANDLE for every downstream session. The 674 SII_HANDLE identifies a peer, and should be the same for all sessions 675 whose downstream peer is the same. The QoS NSLP uses this 676 information to decide whether summary refresh messages can be sent, 677 or when a summary tear is possible. 679 3.2.7. Message Scoping 681 A QNE may use local policy when deciding whether to propagate a 682 message or not. For example, the local policy can define/configure 683 that a QNE is, for a particular session, a QNI and/or a QNR. The QoS 684 NSLP also includes an explicit mechanism to restrict message 685 propagation by means of a scoping mechanism. 687 For a RESERVE or a QUERY message, two scoping flags limit the part of 688 the path on which state is installed on the downstream nodes that can 689 respond. When the SCOPING flag is set to zero, it indicates that the 690 scope is "whole path" (default). When set to one, the scope is 691 "single hop". When the PROXY scope flag is set, the path is 692 terminated at a pre-defined Proxy QNE (P-QNE). This is similar to 693 the Localized RSVP [lrsvp]. 695 The propagation of a RESPONSE message is limited by the RII object, 696 which ensures that it is not forwarded back along the path further 697 than the node that requested the RESPONSE. 699 3.2.8. Session Binding 701 Session binding is defined as the enforcement of a relation between 702 different QoS NSLP sessions (i.e., signaling flows with different 703 SESSION_ID (SID) as defined in GIST [I-D.ietf-nsis-ntlp]). 705 Session binding indicates an unidirectional dependency relation 706 between two or more sessions by including a BOUND_SESSION_ID object. 707 A session with SID_A (the binding session) can express its 708 unidirectional dependency relation to another session with SID_B (the 709 bound session) by including a BOUND_SESSION_ID object containing 710 SID_B in its messages. 712 The concept of session binding is used to indicate the unidirectional 713 dependency relation between the end-to-end session and the aggregate 714 session in case of aggregate reservations. In case of bidirectional 715 reservations, it is used to express the unidirectional dependency 716 relation between the sessions used for forward and reverse 717 reservation. Typically, the dependency relation indicated by session 718 binding is purely informative in nature and does not automatically 719 trigger any implicit action in a QNE. A QNE may use the dependency 720 relation information for local resource optimization or to explicitly 721 tear down reservations that are no longer useful. However, by using 722 an explicit binding code, see Section 5.1.3.4, it is possible to 723 formalise this dependency relation, meaning that if the bound session 724 (e.g., session with SID_B) is terminated also the binding session 725 (e.g., the session with SID_A) must be terminated. 727 A message may include more than one BOUND_SESSION_ID object. This 728 may happen, e.g., in certain aggregation and bi-directional 729 reservation scenarios, where an end-to-end session has an 730 unidirectional dependency relation with an aggregate session and at 731 the same time it has an unidirectional dependency relation with 732 another session used for the reverse path. 734 3.2.9. Message Binding 736 QoS NSLP supports binding of messages in order to allow for 737 expressing dependencies between different messages. The message 738 binding can indicate either a unidirectional or bidirectional 739 dependency relation between two messages by including in one of the 740 message the MSG_ID object ("binding message") and in the other 741 message ("bound message") the BOUND_MSG_ID object. The 742 unidirectional dependency means that only RESERVE messages are bound 743 to each other whereas a bidirectional dependency means that there is 744 also a dependency for the related RESPONSE messages. The message 745 binding can be used to speed up signaling by starting two signaling 746 exchanges simultaneously that are synchronized later by using message 747 IDs. This can be used as an optimization technique for example in 748 scenarios where aggregate reservations are used. Section 4.6 749 provides more details. 751 3.2.10. Layering 753 The QoS NSLP supports layered reservations. Layered reservations may 754 occur when certain parts of the network (domains) implement one or 755 more local QoS models, or when they locally apply specific transport 756 characteristics (e.g., GIST unreliable transfer mode instead of 757 reliable transfer mode). They may also occur when several per-flow 758 reservations are locally combined into an aggregate reservation. 760 3.2.10.1. Local QoS Models 762 A domain may have local policies regarding QoS model implementation, 763 i.e., it may map incoming traffic to its own locally defined QoS 764 models. The QSPEC allows this functionality, and the operation is 765 transparent to the QoS NSLP. The use of local QoS models within a 766 domain is performed in the RMF. 768 3.2.10.2. Local Control Plane Properties 770 The way signaling messages are handled is mainly determined by the 771 parameters that are sent over GIST-NSLP API and by the domain 772 internal configuration. A domain may have a policy to implement 773 local transport behavior. It may, for instance, elect to use an 774 unreliable transport locally in the domain while still keeping end- 775 to-end reliability intact. 777 The QoS NSLP supports this situation by allowing two sessions to be 778 set up for the same reservation. The local session has the desired 779 local transport properties and is interpreted in internal QNEs. This 780 solution poses two requirements: the end-to-end session must be able 781 to bypass intermediate nodes and the egress QNE needs to bind both 782 sessions together. Bypassing intermediate nodes is achieved with 783 GIST. The local session and the end-to-end session are bound at the 784 egress QNE by means of the BOUND_SESSION_ID object. 786 3.2.10.3. Aggregate Reservations 788 In some cases it is desirable to create reservations for an 789 aggregate, rather than on a per-flow basis, in order to reduce the 790 amount of reservation state needed, as well as, the processing load 791 for signaling messages. Note that the QoS NSLP does not specify how 792 reservations need to be combined in an aggregate or how end-to-end 793 properties need to be computed but only provides signaling support 794 for it. 796 The essential difference with the layering approaches described in 797 Section 3.2.10.1 and Section 3.2.10.2 is that the aggregate 798 reservation needs a MRI that describes all traffic carried in the 799 aggregate (e.g., a DSCP in case of IntServ over DiffServ). The need 800 for a different MRI mandates the use of two different sessions, 801 similar to Section 3.2.10.3 and to the RSVP aggregation solution in 802 RFC 3175 [RFC3175]. 804 Edge QNEs of the aggregation domain that want to maintain some end- 805 to-end properties may establish a peering relation by sending the 806 end-to-end message transparently over the domain (using the 807 intermediate node bypass capability described above). Updating the 808 end-to-end properties in this message may require some knowledge of 809 the aggregated session (e.g., for updating delay values). For this 810 purpose, the end-to-end session contains a BOUND_SESSION_ID carrying 811 the SESSION_ID of the aggregate session. 813 3.2.11. Support for Request Priorities 815 This specification acknowledges the fact that in some situations, 816 some messages or some reservations may be more important than others 817 and therefore foresees mechanisms to give these messages or 818 reservations priority. 820 Priority of certain signaling messages over others may be required in 821 mobile scenarios when a message loss during call set-up is less 822 harmful than during handover. This situation only occurs when GIST 823 or QoS NSLP processing is the congested part or scarce resource. 825 Priority of certain reservations over others may be required when QoS 826 resources are oversubscribed. In that case, existing reservations 827 may be preempted in order to make room for new higher-priority 828 reservations. A typical approach to deal with priority and 829 preemption is through the specification of a setup priority and 830 holding priority for each reservation. The resource management 831 function at each QNE then keeps track of the resource consumption at 832 each priority level. Reservations are established when resources, at 833 their setup priority level, are still available. They may cause 834 preemption of reservations with a lower holding priority than their 835 setup priority. 837 Support of reservation priority is a QSPEC parameter and therefore 838 outside the scope of this specification. The GIST specification 839 provides a mechanism to support a number of levels of message 840 priority that can be requested over the NSLP-GIST API. 842 3.2.12. Rerouting 844 The QoS NSLP needs to adapt to route changes in the data path. This 845 assumes the capability to detect rerouting events, create a QoS 846 reservation on the new path and optionally tear down reservations on 847 the old path. 849 From an NSLP perspective, rerouting detection can be performed in two 850 ways. It can either come through NetworkNotification from GIST, or 851 from information seen at the NSLP. In the latter case, the QoS NSLP 852 node is able to detect changes in its QoS NSLP peers by keeping track 853 of a Source Identification Information (SII) handle that provides 854 information similar in nature to the RSVP_HOP object described in RFC 855 2205 [RFC2205]. When a RESERVE message with an existing SESSION_ID 856 and a different SII is received, the QNE knows its upstream or 857 downstream peer has changed, for sender-oriented and receiver- 858 oriented reservations, respectively. 860 Reservation on the new path happens when a RESERVE message arrives at 861 the QNE beyond the point where the old and new paths diverge. If the 862 QoS NSLP suspects that a reroute has occurred, then a full RESERVE 863 message (including the QSPEC) would be sent. A refreshing RESERVE 864 (with no QSPEC) will be identified as an error by a QNE on the new 865 path which does not have the reservation installed (i.e. it was not 866 on the old path) or which previously had a different previous-hop 867 QNE. It will send back an error message which results in a full 868 RESERVE message being sent. Rapid recovery at the NSLP layer 869 therefore requires short refresh periods. Detection before the next 870 RESERVE message arrives is only possible at the IP layer or through 871 monitoring of GIST peering relations (e.g., by TTL counting the 872 number of GIST hops between NSLP peers or the observing changes in 873 the outgoing interface towards GIST peer). These mechanisms can 874 provide implementation specific optimizations, and are outside the 875 scope of this specification. 877 When the QoS NSLP is aware of the route change, it needs to set up 878 the reservation on the new path. This is done by sending a new 879 RESERVE message. If the next QNE is, in fact, unchanged then this 880 will be used to refresh/update the existing reservation. Otherwise 881 it will lead to the reservation being installed on the new path. 883 Note that the operation for a receiver-initiated reservation session 884 differs a bit from the above description. If the routing changes in 885 the middle of the path, the QNE that notices that its downstream path 886 changed, the divergence point, must send a QUERY with the R-flag 887 downstream. It will be processed as above, and at some point hits a 888 QNE for which the path downstream towards the QNI remains (the 889 convergence point). This node must then send a full RESERVE upstream 890 to set up the reservation state along the new path. It should not 891 send the QUERY further downstream, since this would have no real use. 892 Similarly, when the QNE that sent the QUERY receives the RESERVE, it 893 should not send the RESERVE further upstream. 895 After the reservation on the new path is set up, the branching node 896 may want to tear down the reservation on the old path (sooner than 897 would result from normal soft-state time-out). This functionality is 898 supported by keeping track of the old SII-Handle provided over the 899 GIST API. This handle can be used by the QoS NSLP to route messages 900 explicitly to the next node. 902 If the old path is downstream, the QNE can send a tearing RESERVE 903 using the old SII-Handle. If the old path is upstream, the QNE can 904 send a NOTIFY with the code for "Route Change". This is forwarded 905 upstream until it hits a QNE that can issue a tearing RESERVE 906 downstream. A separate document discusses in detail the effect of 907 mobility on the QoS NSLP signaling 908 [I-D.ietf-nsis-applicability-mobility-signaling]. 910 A QNI or a branch node may wish to keep the reservation on the old 911 branch. This could for instance be the case when a mobile node has 912 experienced a mobility event and wishes to keep reservation to its 913 old attachment point in case it moves back there. For this purpose, 914 a REPLACE flag is provided in the QoS NSLP common header, which, when 915 not set, indicates that the reservation on the old branch should be 916 kept. 918 Note that keeping old reservations affects the resources available to 919 other nodes. Thus, the operator of the access network must make the 920 final decision on whether this behavior is allowed. Also, the QNEs 921 in the access network may add this flag even if the mobile node has 922 not used the flag initially. 924 3.2.12.1. Last Node Behavior 926 The design of the QoS NSLP allows reservations to be installed at a 927 subset of the nodes along a path. In particular, usage scenarios 928 include cases where the data flow endpoints do not support the QoS 929 NSLP. 931 In the case where the data flow receiver does not support the QoS 932 NSLP, some particular considerations must be given to node discovery 933 and rerouting at the end of the signaling path. 935 There are three cases for the last node on the signaling path: 1) 936 Last node is the data receiver 2) Last node is a configured proxy for 937 the data receiver 3) Last node is not the data receiver and is not 938 explicitly configured to act as a signaling proxy on behalf of the 939 data receiver. 941 Cases (1) and (2) can be handled by the QoS NSLP itself during the 942 initial path setup, since the QNE knows that it should terminate the 943 signaling. Case (3) requires some assistance from GIST which 944 provides messages across the API to indicate that no further QoS NSLP 945 supporting GIST nodes are present downstream, and downstream route 946 change probing needs to continue once the reservation is installed to 947 detect any changes in this situation. 949 Two particular scenarios need to be considered in this third case. 950 In the first, referred to as "Path Extension", rerouting occurs such 951 that an additional QNE is inserted into the signaling path between 952 the old last node and the data receiver, as shown in Figure 4. 954 /-------\ Initial route 955 / v 956 /-\ 957 /--|B|--\ +-+ 958 / \-/ \ |x| = QoS NSLP aware 959 +-+ /-\ +-+ 960 ----|A| |D| 961 +-+ \-/ /-\ 962 \ +-+ / |x| = QoS NSLP unaware 963 \--|C|--/ \-/ 964 +-+ 965 \ ^ 966 \-------/ Updated route 968 Figure 4: Path Extension 970 When rerouting occurs, the data path changes from A-B-D to A-C-D. 971 Initially the signaling path ends at A. Despite initially being the 972 last node, node A needs to continue to attempt to send messages 973 downstream to probe for path changes, unless it has been explicitly 974 configured as a signaling proxy for the data flow receiver. This is 975 required so that the signaling path change is detected, and C will 976 become the new last QNE. 978 In a second case, referred to as "Path Truncation", rerouting occurs 979 such that the QNE that was the last node on the signaling path is no 980 longer on the data path. This is shown in Figure 5. 982 /-------\ Initial route 983 / v 984 +-+ 985 /--|B|--\ +-+ 986 / +-+ \ |x| = QoS NSLP aware 987 +-+ /-\ +-+ 988 ----|A| |D| 989 +-+ \-/ /-\ 990 \ /-\ / |x| = QoS NSLP unaware 991 \--|C|--/ \-/ 992 \-/ 993 \ ^ 994 \-------/ Updated route 996 Figure 5: Path Truncation 998 When rerouting occurs, the data path again changes from A-B-D to A-C- 999 D. The signaling path initially ends at B, but this node is not on 1000 the new path. In this case, the normal GIST path change detection 1001 procedures at A will detect the path change and notify the QoS NSLP. 1002 GIST will also notify the signaling application that no downstream 1003 GIST nodes supporting the QoS NSLP are present. Node A will take 1004 over as the last node on the signaling path. 1006 3.2.12.2. Handling Spurious Route Change Notifications 1008 The QoS NSLP is notified by GIST (with the NetworkNotification 1009 primitive) when GIST believes that a rerouting event may have 1010 occurred. In some cases, events that are detected as possible route 1011 changes will turn out not to be. The QoS NSLP will not always be 1012 able to detect this, even after receiving messages from the 'new' 1013 peer. 1015 As part of the RecvMessage API primitive, GIST provides an SII-Handle 1016 which can be used by the NSLP to direct a signaling message to a 1017 particular peer. The current SII-Handle will change if the signaling 1018 peer changes. However, it is not guaranteed to remain the same after 1019 a rerouting event where the peer does not change. Therefore, the QoS 1020 NSLP mechanism for reservation maintenance after a route change 1021 includes robustness mechanisms to avoid accidentally tearing down a 1022 reservation in situations where the peer QNE has remained the same 1023 after a 'route change' notification from GIST. 1025 A simple example that illustrates the problem is shown in Figure 6 1026 below. 1028 (1) +-+ 1029 /-----\ |x| = QoS NSLP aware 1030 +-+ /-\ (3) +-+ +-+ 1031 ----|A| |B|-----|C|---- 1032 +-+ \-/ +-+ /-\ 1033 \-----/ |x| = QoS NSLP unaware 1034 (2) \-/ 1036 Figure 6: Spurious reroute alerting 1038 In this example the initial route A-B-C uses links (1) and (3). 1039 After link (1) fails, the path is rerouted using links (2) and (3). 1040 The set of QNEs along the path is unchanged (it is A-C in both cases, 1041 since B does not support the QoS NSLP). 1043 When the outgoing interface at A has changes, GIST may signal across 1044 its API to the NSLP with a NetworkNotification. The QoS NSLP at A 1045 will then attempt to repair the path by installing the reservation on 1046 the path (2),(3). In this case, however, the old and new paths are 1047 the same. 1049 To install the new reservation A will send a RESERVE message, which 1050 GIST will transport to C (discovering the new next peer as 1051 appropriate). The RESERVE also requests a RESPONSE from the QNR. 1052 When this RESERVE message is received through the RecvMessage API 1053 call from GIST at the QoS NSLP at C, the SII-Handle will be unchanged 1054 from its previous communications from A. 1056 A RESPONSE message will be sent by the QNR, and be forwarded from C 1057 to A. This confirms that the reservation was installed on the new 1058 path. The SII-Handle passed with the RecvMessage call from GIST to 1059 the QoS NSLP will be different to that seen previously, since the 1060 interface being used on A has changed. 1062 At this point A can attempt to tear down the reservation on the old 1063 path. The RESERVE message with the TEAR flag set is sent down the 1064 old path by using the GIST explicit routing mechanism and specifying 1065 the SII-Handle relating to the 'old' peer QNE. 1067 If RSNs were being incremented for each of these RESERVE and RESERVE- 1068 with-TEAR messages the reservation would be torn down at C and any 1069 QNEs further along the path. To avoid this the RSN is used in a 1070 special way. The RESERVE down the new path is sent with the new 1071 current RSN set to the old RSN plus 2. The RESERVE-with-TEAR down 1072 the old path is sent with an RSN set to the new current RSN minus 1. 1073 This is the peer from which it was receiving RESERVE messages (see 1074 Section 5.2.5.2 for more details). 1076 3.2.13. Pre-emption 1078 The QoS NSLP provides building blocks to implement pre-emption. This 1079 specification does not define how pre-emption should work, but only 1080 provides signaling mechanisms that can be used by QoS Models. For 1081 example, an INFO_SPEC object can be added to messages to indicate 1082 that the signaled session was pre-empted. A BOUND_SESSION_ID object 1083 can carry the Session ID of the flow that caused the pre-emption to 1084 happen for the signaled session. How these are used by QoS Models is 1085 out of scope of the QoS NSLP specification. 1087 3.3. GIST Interactions 1089 The QoS NSLP uses GIST for delivery of all its messages. Messages 1090 are passed from the NSLP to GIST via an API (defined in Appendix B of 1091 [I-D.ietf-nsis-ntlp]), which also specifies additional information, 1092 including an identifier for the signaling application (e.g., 'QoS 1093 NSLP'), session identifier, MRI, and an indication of the intended 1094 direction - towards data sender or receiver. On reception, GIST 1095 provides the same information to the QoS NSLP. In addition to the 1096 NSLP message data itself, other meta-data (e.g. session identifier 1097 and MRI) can be transferred across this interface. 1099 The QoS NSLP keeps message and reservation state per session. A 1100 session is identified by a Session Identifier (SESSION_ID). The 1101 SESSION_ID is the primary index for stored NSLP state and needs to be 1102 constant and unique (with a sufficiently high probability) along a 1103 path through the network. The QoS NSLP picks a value for Session-ID. 1105 This value is subsequently used by GIST and the QoS NSLP to refer to 1106 this session. 1108 Currently, the QoS NSLP specification considers mainly the path- 1109 coupled MRM. However, extensions may specify how other types of MRMs 1110 may be applied in combination with the QoS NSLP. 1112 When GIST passes the QoS NSLP data to the NSLP for processing, it 1113 must also indicate the value of the 'D' (Direction) flag for that 1114 message in the MRI. 1116 The QoS NSLP does not provide any method of interacting with 1117 firewalls or Network Address Translators (NATs). It assumes that a 1118 basic NAT traversal service is provided by GIST. 1120 3.3.1. Support for Bypassing Intermediate Nodes 1122 The QoS NSLP may want to restrict the handling of its messages to 1123 specific nodes. This functionality is needed to support layering 1124 (explained in Section 3.2.10), when only the edge QNEs of a domain 1125 process the message. This requires a mechanism at GIST level (which 1126 can be invoked by the QoS NSLP) to bypass intermediate nodes between 1127 the edges of the domain. 1129 The intermediate nodes are bypassed using multiple levels of the 1130 router alert option. In that case, internal routers are configured 1131 to handle only certain levels of router alerts. This is accomplished 1132 by marking the signaling messages, i.e., modifying the QoS NSLP 1133 default NSLP-ID value to another NSLP-ID predefined value. The 1134 marking is accomplished by the ingress edge by modifying the QoS NSLP 1135 default NSLP-ID value to a NSLP-ID predefined value, see Section 6.6. 1136 The egress stops this marking process by reassigning the QoS NSLP 1137 default NSLP-ID value to the original RESERVE message. The exact 1138 operation of modifying the NSLP-ID must be specified in the relevant 1139 QoS model specification. 1141 3.3.2. Support for Peer Change Identification 1143 There are several circumstances where it is necessary for a QNE to 1144 identify the adjacent QNE peer, which is the source of a signaling 1145 application message; e.g., it may be to apply the policy that "state 1146 can only be modified by messages from the node that created it" or it 1147 might be that keeping track of peer identity is used as a (fallback) 1148 mechanism for rerouting detection at the NSLP layer. 1150 This functionality is implemented in GIST service interface with SII- 1151 handle. As shown in the above example, we assume the SII- handling 1152 will support both own SII and peer SII. 1154 Keeping track of the SII of a certain reservation also provides a 1155 means for the QoS NSLP to detect route changes. When a QNE receives 1156 a RESERVE referring to existing state but with a different SII, it 1157 knows that its upstream peer has changed. It can then use the old 1158 SII to initiate a teardown along the old section of the path. This 1159 functionality is supported in GIST service interface when the peer's 1160 SII which is stored on message reception is passed to GIST upon 1161 message transmission. 1163 3.3.3. Support for Stateless Operation 1165 Stateless or reduced state QoS NSLP operation makes the most sense 1166 when some nodes are able to operate in a stateless way at GIST level 1167 as well. Such nodes should not worry about keeping reverse state, 1168 message fragmentation and reassembly (at GIST), congestion control or 1169 security associations. A stateless or reduced state QNE will be able 1170 to inform the underlying GIST of this situation. GIST service 1171 interface supports this functionality with the Retain-State attribute 1172 in the MessageReceived primitive. 1174 3.3.4. Priority of Signaling Messages 1176 The QoS NSLP will generate messages with a range of performance 1177 requirements for GIST. These requirements may result from a 1178 prioritization at the QoS NSLP (Section 3.2.11) or from the 1179 responsiveness expected by certain applications supported by the QoS 1180 NSLP. GIST service interface supports this with the 'priority' 1181 transfer attribute. 1183 3.3.5. Knowledge of Intermediate QoS NSLP Unaware Nodes 1185 In some cases it is useful to know that there are routers along the 1186 path where QoS cannot be provided. The GIST service interface 1187 supports this by keeping track of IP-TTL and Original-TTL in the 1188 RecvMessage primitive. A difference between the two indicates the 1189 number of QoS NSLP unaware nodes. In this case the QNE that detects 1190 this difference should set the "B" (BREAK) flag. If a QNE generates 1191 a QUERY, RESERVE or RESPONSE message, after receiving a QUERY or 1192 RESERVE message with a "Break" flag set, it can set the "B" (BREAK) 1193 flag in these messages. There are however, situations where the 1194 egress QNE in a local domain may have some other means to provide QoS 1195 [I-D.ietf-nsis-qspec]. For example, in an RMD-QOSM 1196 [I-D.ietf-nsis-rmd] (or RMD-QOSM like) aware local domain that uses 1197 either NTLP stateless nodes or NSIS unaware nodes the end to end 1198 RESERVE or QUERY message bypasses these NTLP stateless or NSIS 1199 unaware nodes. However, the reservation within the local domain can 1200 be signaled by the RMD-QOSM (or RMD-QOSM like QOSM). In such 1201 situations, the "B" (BREAK) flag in the end to end RESERVE or QUERY 1202 message should not be set by the edges of the local domain. 1204 4. Examples of QoS NSLP Operation 1206 The QoS NSLP can be used in a number of ways. The examples given 1207 here give an indication of some of the basic processing. However, 1208 they are not exhaustive and do not attempt to cover the details of 1209 the protocol processing. 1211 4.1. Sender-initiated Reservation 1213 QNI QNE QNE QNR 1214 | | | | 1215 | RESERVE | | | 1216 +--------->| | | 1217 | | RESERVE | | 1218 | +--------->| | 1219 | | | RESERVE | 1220 | | +--------->| 1221 | | | | 1222 | | | RESPONSE | 1223 | | |<---------+ 1224 | | RESPONSE | | 1225 | |<---------+ | 1226 | RESPONSE | | | 1227 |<---------+ | | 1228 | | | | 1229 | | | | 1231 Figure 7: Basic Sender Initiated Reservation 1233 To make a new reservation, the QNI constructs a RESERVE message 1234 containing a QSPEC object, from its chosen QoS model, which describes 1235 the required QoS parameters. 1237 The RESERVE message is passed to GIST which transports it to the next 1238 QNE. There it is delivered to the QoS NSLP processing which examines 1239 the message. Policy control and admission control decisions are 1240 made. The exact processing also takes into account the QoS model 1241 being used. The node performs appropriate actions (e.g., installing 1242 reservation) based on the QSPEC object in the message. 1244 The QoS NSLP then generates a new RESERVE message (usually based on 1245 the one received). This is passed to GIST, which forwards it to the 1246 next QNE. 1248 The same processing is performed at further QNEs along the path, up 1249 to the QNR. The determination that a node is the QNR may be made 1250 directly (e.g., that node is the destination for the data flow), or 1251 using GIST functionality to determine that there are no more QNEs 1252 between this node and the data flow destination. 1254 Any node may include a request for a RESPONSE in its RESERVE 1255 messages. It does so by including a Request Identification 1256 Information (RII) object in the RESERVE message. If the message 1257 already includes an RII, an interested QNE must not add a new RII 1258 object nor replace the old RII object. Instead it needs to remember 1259 the RII value so that it can match a RESPONSE message belonging to 1260 the RESERVE. When it receives the RESPONSE, it forwards the RESPONSE 1261 upstream towards the RII originating node. 1263 In this example, the RESPONSE message is forwarded peer-to-peer along 1264 the reverse of the path that the RESERVE message took (using GIST 1265 path state), and so is seen by all the QNEs on this segment of the 1266 path. It is only forwarded as far as the node which requested the 1267 RESPONSE originally. 1269 The reservation can subsequently be refreshed by sending further 1270 RESERVE messages containing the complete reservation information, as 1271 for the initial reservation. The reservation can also be modified in 1272 the same way, by changing the QSPEC data to indicate a different set 1273 of resources to reserve. 1275 The overhead required to perform refreshes can be reduced, in a 1276 similar way to that proposed for RSVP in RFC 2961 [RFC2961]. Once a 1277 RESPONSE message has been received indicating the successful 1278 installation of a reservation, subsequent refreshing RESERVE messages 1279 can simply refer to the existing reservation, rather than including 1280 the complete reservation specification. 1282 4.2. Sending a Query 1284 QUERY messages can be used to gather information from QNEs along the 1285 path. For example, they can be used to find out what resources are 1286 available before a reservation is made. 1288 In order to perform a query along a path, the QNE constructs a QUERY 1289 message. This message includes a QSPEC containing the actual query 1290 to be performed at QNEs along the path. It also contains an RII 1291 object used to match the response back to the query, and an indicator 1292 of the query scope (next node, whole path, proxy). The QUERY message 1293 is passed to GIST to forward it along the path. 1295 A QNE receiving a QUERY message should inspect it and create a new 1296 message, based on that received with the query objects modified as 1297 required. For example, the query may request information on whether 1298 a flow can be admitted, and so a node processing the query might 1299 record the available bandwidth. The new message is then passed to 1300 GIST for further forwarding (unless it knows it is the QNR, or is the 1301 limit for the scope in the QUERY). 1303 At the QNR, a RESPONSE message must be generated if the QUERY message 1304 includes a Request Identification Information (RII) object. Various 1305 objects from the received QUERY message have to be copied into the 1306 RESPONSE message. It is then passed to GIST to be forwarded peer-to- 1307 peer back along the path. 1309 Each QNE receiving the RESPONSE message should inspect the RII object 1310 to see if it 'belongs' to it (i.e., it was the one that originally 1311 created it). If it does not then it simply passes the message back 1312 to GIST to be forwarded upstream. 1314 If there was an error in processing a RESERVE, instead of an RII, the 1315 RESPONSE may carry an RSN. Thus, a QNE must also be prepared to look 1316 for an RSN object if no RII was present, and act based on the error 1317 code set in the INFO_SPEC of the RESPONSE. 1319 4.3. Basic Receiver-initiated Reservation 1321 As described in the NSIS framework [RFC4080] in some signaling 1322 applications, a node at one end of the data flow takes responsibility 1323 for requesting special treatment - such as a resource reservation - 1324 from the network. Both ends then agree whether sender or receiver- 1325 initiated reservation is to be done. In case of a receiver initiated 1326 reservation, both ends agree whether a "One Pass With Advertising" 1327 (OPWA) [opwa95] model is being used. This negotiation can be 1328 accomplished using mechanisms that are outside the scope of NSIS. 1330 To make a receiver-initiated reservation, the QNR constructs a QUERY 1331 message, which may contain a QSPEC object from its chosen QoS model 1332 (see Figure 8). The QUERY must have the RESERVE-INIT flag set. This 1333 QUERY message does not need to trigger a RESPONSE message and 1334 therefore, the QNI must not include the RII object (Section 5.4.2) in 1335 the QUERY message. The QUERY message may be used to gather 1336 information along the path, which is carried by the QSPEC object. An 1337 example of such information is the "One Pass With Advertising" (OPWA) 1338 [opwa95]. This QUERY message causes GIST reverse-path state to be 1339 installed. 1341 QNR QNE QNE QNI 1342 sender receiver 1343 | | | | 1344 | QUERY | | | 1345 +--------->| | | 1346 | | QUERY | | 1347 | +--------->| | 1348 | | | QUERY | 1349 | | +--------->| 1350 | | | | 1351 | | | RESERVE | 1352 | | |<---------+ 1353 | | RESERVE | | 1354 | |<---------+ | 1355 | RESERVE | | | 1356 |<---------+ | | 1357 | | | | 1358 | RESPONSE | | | 1359 +--------->| | | 1360 | | RESPONSE | | 1361 | +--------->| | 1362 | | | RESPONSE | 1363 | | +--------->| 1364 | | | | 1366 Figure 8: Basic Receiver Initiated Reservation 1368 The QUERY message is transported by GIST to the next downstream QoS 1369 NSLP node. There it is delivered to the QoS NSLP processing which 1370 examines the message. The exact processing also takes into account 1371 the QoS model being used and may include gathering information on 1372 path characteristics that may be used to predict the end-to-end QoS. 1374 The QNE generates a new QUERY message (usually based on the one 1375 received). This is passed to GIST, which forwards it to the next 1376 QNE. The same processing is performed at further QNEs along the 1377 path, up to the flow receiver. The receiver detects that this QUERY 1378 message carries the RESERVE-INIT flag and by using the information 1379 contained in the received QUERY message, such as the QSPEC, 1380 constructs a RESERVE message. 1382 The RESERVE is forwarded peer-to-peer along the reverse of the path 1383 that the QUERY message took (using GIST reverse path state). Similar 1384 to the sender-initiated approach, any node may include an RII in its 1385 RESERVE messages. The RESPONSE is sent back to confirm the resources 1386 are set up. The reservation can subsequently be refreshed with 1387 RESERVE messages in the upstream direction. 1389 4.4. Bidirectional Reservations 1391 The term "bidirectional reservation" refers to two different cases 1392 that are supported by this specification: 1394 o Binding two sender-initiated reservations together, e.g., one 1395 sender-initiated reservation from QNE A to QNE B and another one from 1396 QNE B to QNE A ( Figure 9). 1398 o Binding a sender-initiated and a receiver-initiated reservation 1399 together, e.g., a sender-initiated reservation from QNE A towards QNE 1400 B, and a receiver-initiated reservation from QNE A towards QNE B for 1401 the data flow in the opposite direction (from QNE B to QNE A). This 1402 case is particularly useful when one end of the communication has all 1403 required information to set up both sessions ( Figure 10). 1405 Both ends have to agree on which bi-directional reservation type they 1406 need to use. This negotiation can be accomplished using mechanisms 1407 that are outside the scope of NSIS. 1409 The scenario with two sender-initiated reservations is shown in 1410 Figure 9. Note that RESERVE messages for both directions may visit 1411 different QNEs along the path because of asymmetric routing. Both 1412 directions of the flows are bound by inserting the BOUND_SESSION_ID 1413 object at the QNI and QNR. RESPONSE messages are optional and not 1414 shown in the picture for simplicity. 1416 A QNE QNE B 1417 | | FLOW-1 | | 1418 |===============================>| 1419 |RESERVE-1 | | | 1420 QNI+--------->|RESERVE-1 | | 1421 | +-------------------->|QNR 1422 | | | | 1423 | | FLOW-2 | | 1424 |<===============================| 1425 | | |RESERVE-2 | 1426 | RESERVE-2 |<---------+QNI 1427 QNR|<--------------------+ | 1428 | | | | 1430 Figure 9: Bi-directional reservation for sender+sender scenario 1432 The scenario with a sender-initiated and a receiver-initiated 1433 reservation is shown in Figure 10. In this case, QNI B sends out two 1434 RESERVE messages, one for the sender-initiated and one for the 1435 receiver-initiated reservation. Note that the sequence of the two 1436 RESERVE messages may be interleaved. 1438 A QNE QNE B 1439 | | FLOW-1 | | 1440 |===============================>| 1441 | QUERY-1 | | | 1442 QNI+--------->| QUERY-1 | | 1443 | +-------------------->|QNR 1444 | | | | 1445 | |RESERVE-1 | | 1446 |RESERVE-1 +<--------------------|QNR 1447 QNI+<---------| | | 1448 | | | | 1449 | | FLOW-2 | | 1450 |<===============================| 1451 | | |RESERVE-2 | 1452 |RESERVE-2 | |<---------+QNI 1453 QNR|<--------------------+ | 1454 | | | | 1456 Figure 10: Bi-directional reservation for sender+receiver scenario 1458 4.5. Aggregate Reservations 1460 In order to reduce signaling and per-flow state in the network, the 1461 reservations for a number of flows may be aggregated. 1463 QNI QNE QNE/QNI' QNE' QNR'/QNE QNR 1464 aggregator deaggregator 1465 | | | | | | 1466 | RESERVE | | | | | 1467 +--------->| | | | | 1468 | | RESERVE | | | | 1469 | +--------->| | | | 1470 | | | RESERVE | | | 1471 | | +-------------------->| | 1472 | | | RESERVE' | | | 1473 | | +=========>| RESERVE' | | 1474 | | | +=========>| RESERVE | 1475 | | | | +--------->| 1476 | | | | RESPONSE'| | 1477 | | | RESPONSE'|<=========+ | 1478 | | |<=========+ | | 1479 | | | | | RESPONSE | 1480 | | | | RESPONSE |<---------+ 1481 | | |<--------------------+ | 1482 | | RESPONSE | | | | 1483 | |<---------+ | | | 1484 | RESPONSE | | | | | 1485 |<---------+ | | | | 1486 | | | | | | 1487 | | | | | | 1489 Figure 11: Sender Initiated Reservation with Aggregation 1491 An end-to-end per-flow reservation is initiated with the messages 1492 shown in Figure 11 as "RESERVE". 1494 At the aggregator a reservation for the aggregated flow is initiated 1495 (shown in Figure 11 as "RESERVE'"). This may use the same QoS model 1496 as the end-to-end reservation but has an MRI identifying the 1497 aggregated flow (e.g., tunnel) instead of for the individual flows. 1499 This document does not specify how the QSPEC of the aggregate session 1500 can be derived from the QSPECs of the end-to-end sessions. 1502 The messages used for the signaling of the individual reservation 1503 need to be marked such that the intermediate routers will not inspect 1504 them. In the QoS NSLP the following marking possibility is applied, 1505 see also RFC3175. 1507 All routers use essentially the same algorithm for which messages 1508 they process, i.e. all messages at aggregation level 0. However, 1509 messages have their aggregation level incremented on entry to an 1510 aggregation region and decremented on exit. In this technique the 1511 interior routers are not required to do any rewriting of the RAO 1512 values. However, the aggregating/deaggregating routers must be 1513 configured with which of their interfaces lie at which aggregation 1514 level, and also requires consistent message rewriting at these 1515 boundaries. 1517 In particular, the Aggregator performs the marking by modifying the 1518 QoS NSLP default NSLP-ID value to a NSLP-ID predefined value, see 1519 Section 6.6. A RAO value is then uniquely derivable from each 1520 predefined NSLP-ID. However, the RAO does not have to have a one-to- 1521 one relation to a specific NSLP-ID. 1523 Aggregator Deaggregator 1525 +---+ +---+ +---+ +---+ 1526 |QNI|-----|QNE|-----|QNE|-----|QNR| aggregate 1527 +---+ +---+ +---+ +---+ reservation 1529 +---+ +---+ ..... ..... +---+ +---+ 1530 |QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end 1531 +---+ +---+ ..... ..... +---+ +---+ reservation 1533 Figure 12: Reservation aggregation 1535 The deaggregator acts as the QNR for the aggregate reservation. 1536 Session binding information carried in the RESERVE message enables 1537 the deaggregator to associate the end-to-end and aggregate 1538 reservations with one another (using the BOUND_SESSION_ID). 1540 The key difference between this example and the one shown in Section 1541 4.1 is that the flow identifier for the aggregate is expected to be 1542 different to that for the end-to-end reservation. The aggregate 1543 reservation can be updated independently of the per-flow end-to-end 1544 reservations. 1546 4.6. Message Binding 1548 Section 4.5 sketches the interaction of an aggregated end-to-end flow 1549 and an aggregate. For this scenario, and probably others, it is 1550 useful to have a method for synchronizing signaling message exchanges 1551 of different sessions. This can be used to speed up signaling, 1552 because some message exchanges can be started simultaneously and can 1553 be processed in parallel until further processing of a message from 1554 one particular session depends on another message from a different 1555 session. For instance, in Figure 11 there is a case where inclusion 1556 of a new reservation requires to increase the capacity of the 1557 encompassing aggregate first. So the RESERVE (bound message) for the 1558 individual flow arriving at the deaggregator should wait until the 1559 RESERVE' (binding message) for the aggregate arrived successfully 1560 (otherwise the individual flow could not be included into the 1561 existing aggregate and cannot be admitted). Another alternative 1562 would be to increase the aggregate first and then to reserve 1563 resources for a set of aggregated individual flows. In this case the 1564 binding and synchronization between the (RESERVE and RESERVE') 1565 messages is not needed. 1567 A message binding may be used (depending an the aggregators policy) 1568 as follows: a QNE (aggregator QNI' in Figure 14) generates randomly a 1569 128-bit MSG_ID (same rules apply as for generating a SESSION_ID) and 1570 includes it as BOUND_MSG_ID object into the bound signaling message 1571 (RESERVE (1) in Figure 14) that should wait for the arrival of a 1572 related binding signaling message (RESERVE' (3) in Figure 14) that 1573 carries the associated MSG_ID object. The BOUND_SESSION_ID should 1574 also be set accordingly. Only one MSG_ID or BOUND_MSG_ID object per 1575 message is allowed. If the dependency relation between the two 1576 messages is bidirectional then the Message_Binding_Type flag is SET 1577 (value is 1). Otherwise, the Message_Binding_Type flag is UNSET. In 1578 most cases an RII object must be included in order to get a 1579 corresponding RESPONSE back. 1581 The receiving QNE enqueues (probably after some pre-processing) this 1582 message for the corresponding session. It also starts a MsgIDWait 1583 timer in order to discard the message in case the related 1584 "triggering" message (RESERVE' in Figure 15) does not arrive. The 1585 timeout period for this time SHOULD be set to the default 1586 retransmission timeout period (QOSNSLP_REQUEST_RETRY). In case a 1587 retransmitted RESERVE message arrives before the timeout it will 1588 simply override the waiting message (i.e. the latter is discarded and 1589 the new message is now waiting with the MsgIDWait timer being reset). 1590 At the same time, the "triggering" message including a MSG_ID object, 1591 carrying the same value as the BOUND_MSG_ID object is sent by the 1592 same initiating QNE (QNI' in Figure 13). The intermediate QNE' sees 1593 the MSG_ID object, but can determine that it is not the endpoint for 1594 the session (QNR') and therefore simply forwards the message after 1595 normal processing. The receiving QNE (QNR') as endpoint for the 1596 aggregate session (i.e., deaggregator) interprets the MSG_ID object 1597 and looks for a corresponding waiting message with a BOUND_MSG_ID of 1598 the same value whose waiting condition is satisfied now. Depending 1599 on successful processing of the RESERVE' (3), processing of the 1600 waiting RESERVE will be resumed and the MsgIDWait timer will be 1601 stopped as soon as the related RESERVE' arrived. 1603 QNI QNE QNE/QNI' QNE' QNR'/QNE QNR 1604 aggregator deaggregator 1605 | | | | | | 1606 | RESERVE | | | | | 1607 +--------->| | | | | 1608 | | RESERVE | | | | 1609 | +--------->| | | | 1610 | | | RESERVE | | | 1611 | | | (1) | | | 1612 | | +-------------------->| | 1613 | | | RESERVE' | | | 1614 | | | (2) | | | 1615 | | +=========>| RESERVE' | | 1616 | | | | (3) | | 1617 | | | +=========>| RESERVE | 1618 | | | | | (4) | 1619 | | | | +--------->| 1620 | | | | RESPONSE'| | 1621 | | | RESPONSE'|<=========+ | 1622 | | |<=========+ | | 1623 | | | | | RESPONSE | 1624 | | | | RESPONSE |<---------+ 1625 | | |<--------------------+ | 1626 | | RESPONSE | | | | 1627 | |<---------+ | | | 1628 | RESPONSE | | | | | 1629 |<---------+ | | | | 1630 | | | | | | 1631 | | | | | | 1633 (1): RESERVE: SESSION_ID=F, BOUND_MSG_ID=x, BOUND_SESSION_ID=A 1634 (2)+(3): RESERVE': SESSION_ID=A, MSG_ID=x 1635 (4): RESERVE: SESSION_ID=F (MSG_ID object was removed) 1637 Figure 13: Example for using message binding 1639 Several further cases have to be considered in this context: 1641 o "Triggering message" (3) arrives before waiting (bound) message 1642 (1): In this case the processing of the triggering message depends 1643 on the value of the Message_Binding_Type flag. If 1644 Message_Binding_Type is UNSET (value is 0) then the triggering 1645 message can be processed normally, but the MSG_ID and the result 1646 (success or failure) should be saved for the waiting message. 1647 Thus the RESPONSE' can be sent by the QNR' immediately. If the 1648 waiting message (1) finally arrives at the QNR', it can be 1649 detected that the waiting condition was already satisfied, because 1650 the triggering message already arrived earlier. If 1651 Message_Binding_Type is SET (value is 1) then the triggering 1652 message interprets the MSG_ID object and looks for the 1653 corresponding waiting message with a BOUND_MSG_ID of the same 1654 value, which in this case has not yet arrived. It then starts a 1655 MsgIDWait timer in order to discard the message in case the 1656 related message (RESERVE (1) in Figure 14) does not arrive. 1657 Depending on successful processing of the RESERVE (1), processing 1658 of the waiting RESERVE' will be resumed, the MsgIDWait timer will 1659 be stopped as soon as the related RESERVE arrived and the 1660 RESPONSE' can be sent by the QNR' towards the QNI'. 1661 o The "triggering message" (3) does not arrive at all: this may be 1662 the case due to message loss (which will cause a retransmission by 1663 the QNI' if the RII object is included) or due to a reservation 1664 failure at an intermediate node (QNE' in the example). The 1665 MsgIDWait timeout will then simply discard the waiting message at 1666 QNR'. In this case the QNR' MAY send a RESPONSE message towards 1667 the QNI informing that the synchronisation of the two messages has 1668 failed. 1669 o Retransmissions should use the same MSG_ID, because usually only 1670 one message of the two related messages is retransmitted. As 1671 mentioned above: retransmissions will only occur if the RII object 1672 is set in the RESERVE. If a retransmitted message with a MSG_ID 1673 arrives while a bound message with the same MSG_ID is still 1674 waiting, the retransmitted message will replace the bound message. 1676 For a receiving node there are conceptually two lists indexed by 1677 message IDs. One list contains the IDs and results of triggering 1678 messages (those carrying a MSG_ID object), the other list contains 1679 the IDs and message contents of the bound waiting messages (those who 1680 carried a BOUND_MSG_ID). The former list is used when a triggering 1681 message arrives before the bound message. The latter list is used 1682 when a bound message arrives before a triggering message. 1684 4.7. Reduced State or Stateless Interior Nodes 1686 This example uses a different QoS model within a domain, in 1687 conjunction with GIST and NSLP functionality which allows the 1688 interior nodes to avoid storing GIST and QoS NSLP state. As a result 1689 the interior nodes only store the QSPEC-related reservation state, or 1690 even no state at all. This allows the QoS model to use a form of 1691 "reduced-state" operation, where reservation states with a coarser 1692 granularity (e.g., per-class) are used, or a "stateless" operation 1693 where no QoS NSLP state is needed (or created). This is usefull e.g. 1694 for measurement-based admission control schemes. 1696 The key difference between this example and the use of different QoS 1697 models in Section 4.5 is that the transport characteristics for the 1698 reservation, i.e., GIST can be used in a different way for the edge- 1699 to-edge and hop-by-hop sessions. The reduced state reservation can 1700 be updated independently of the per-flow end-to-end reservations. 1702 4.7.1. Sender-initiated Reservation 1704 The QNI initiates a RESERVE message (see Fig. 14). At the QNEs on 1705 the edges of the stateless or reduced-state region the processing is 1706 different and the nodes support two QoS models. At the ingress the 1707 original RESERVE message is forwarded but ignored by the stateless or 1708 reduced-state nodes. This is accomplished by marking this message, 1709 i.e., modifying the QoS NSLP default NSLP-ID value to another NSLP-ID 1710 predefined value (see Section 4.6). The marking must be accomplished 1711 by the ingress by modifying the QoS_NSLP default NSLP-ID value to a 1712 NSLP-ID predefined value. The egress must reassign the QoS NSLP 1713 default NSLP-ID value to the original end-to-end RESERVE message. An 1714 example of such operation is given in [I-D.ietf-nsis-rmd]. 1716 The egress node is the next QoS NSLP hop for the end-to-end RESERVE 1717 message. Reliable GIST transfer mode can be used between the ingress 1718 and egress without requiring GIST state in the interior. At the 1719 egress node the RESERVE message is then forwarded normally. 1721 At the ingress a second RESERVE' message is also built (Fig. 14). 1722 This makes use of a QoS model suitable for a reduced state or 1723 stateless form of operation (such as the RMD per hop reservation). 1724 Since the original RESERVE and the RESERVE' messages are addressed 1725 identically, the RESERVE' message also arrives at the same egress QNE 1726 that was also traversed by the RESERVE message. Message binding is 1727 used to synchronize the messages. 1729 When processed by interior (stateless) nodes the QoS NSLP processing 1730 exercises its options to not keep state wherever possible, so that no 1731 per flow QoS NSLP state is stored. Some state, e.g., per class, for 1732 the QSPEC related data may be held at these interior nodes. The QoS 1733 NSLP also requests that GIST use different transport characteristics 1734 (e.g., sending of messages in unreliable GIST transfer mode). It 1735 also requests the local GIST processing not to retain messaging 1736 association state or reverse message routing state. 1738 Nodes, such as those in the interior of the stateless or reduced- 1739 state domain, that do not retain reservation state cannot send back 1740 RESPONSE messages (and so cannot use the refresh reduction 1741 extension). 1743 At the egress node the RESERVE' message is interpreted in conjunction 1744 with the reservation state from the end-to-end RESERVE message (using 1745 information carried in the message to correlate the signaling flows). 1747 The RESERVE message is only forwarded further if the processing of 1748 the RESERVE' message was successful at all nodes in the local domain, 1749 otherwise the end-to-end reservation is regarded as having failed to 1750 be installed. Note that the egress should use a timer, with a 1751 preconfigured value, that can be used to synchronise the arrival of 1752 both messages, i.e., the end-to-end RESERVE message and the local 1753 RESERVE' message. 1755 QNE QNE QNE QNE 1756 ingress interior interior egress 1757 GIST stateful GIST stateless GIST stateless GIST stateful 1758 | A B | 1759 RESERVE | | | | 1760 -------->| RESERVE | | | 1761 +--------------------------------------------->| 1762 | RESERVE' | | | 1763 +-------------->| | | 1764 | | RESERVE' | | 1765 | +-------------->| | 1766 | | | RESERVE' | 1767 | | +------------->| 1768 | | | RESPONSE' | 1769 |<---------------------------------------------+ 1770 | | | | RESERVE 1771 | | | +--------> 1772 | | | | RESPONSE 1773 | | | |<-------- 1774 | | | RESPONSE | 1775 |<---------------------------------------------+ 1776 RESPONSE| | | | 1777 <--------| | | | 1779 Figure 14: Sender-initiated reservation with Reduced State Interior 1780 Nodes 1782 Resource management errors in the example above are reflected in the 1783 QSPEC and QoS Model processing. For example, if the RESERVE' fails 1784 at QNE A, it can no send an error message back to the ingress QNE. 1785 Thus, the RESERVE' is forwarded along the intended path, but the 1786 QSPEC includes information for subsequent QNEs telling them an error 1787 happened upstream. It is up to the QoS model to determine what to 1788 do. Eventually, the RESERVE' will reach the egress QNE, and again, 1789 the QoS model then determines the response. 1791 4.7.2. Receiver-initiated Reservation 1793 Since NSLP neighbor relationships are not maintained in the reduced- 1794 state region, only sender-initiated signaling can be supported within 1795 the reduced state region. If a receiver-initiated reservation over a 1796 stateless or reduced state domain is required this can be implemented 1797 as shown in Figure 15. 1799 QNE QNE QNE 1800 ingress interior egress 1801 GIST stateful GIST stateless GIST stateful 1802 | | | 1803 QUERY | | | 1804 -------->| QUERY | | 1805 +------------------------------>| 1806 | | | QUERY 1807 | | +--------> 1808 | | | RESERVE 1809 | | |<-------- 1810 | | RESERVE | 1811 |<------------------------------+ 1812 | RESERVE' | RESERVE' | 1813 |-------------->|-------------->| 1814 | | RESPONSE' | 1815 |<------------------------------+ 1816 RESERVE | | | 1817 <--------| | | 1819 Figure 15: Receiver-initiated reservation with Reduced State Interior 1820 Nodes 1822 The RESERVE message that is received by the egress QNE of the 1823 stateless domain is sent transparently to the ingress QNE (known as 1824 the source of the QUERY message). When the RESERVE message reaches 1825 the ingress, the ingress QNE needs to send a sender- initiated 1826 RESERVE' over the stateless domain. The ingress QNE needs to wait 1827 for a RESPONSE'. If the RESPONSE' notifies that the reservation was 1828 accomplished successfully then the ingress QNE sends a RESERVE 1829 message further upstream. 1831 4.8. Proxy Mode 1833 Besides the sender- and receiver-initiated reservations, the QoS NSLP 1834 includes a functionality we refer to as Proxy Mode. Here a QNE is 1835 set by administrator assignment to work as a proxy QNE (P-QNE) for a 1836 certain region, e.g., for an administrative domain. A node 1837 initiating the signaling may set the PROXY scope flag to indicate 1838 that the signaling is meant to be confined within the area controlled 1839 by the proxy, e.g., the local access network. 1841 The Proxy Mode has two uses. First it allows to confine the QoS NSLP 1842 signaling to a pre-defined section of the path. Secondly, it allows 1843 a node to make reservations for an incoming data flow. 1845 For outgoing data flows and sender-initiated reservations, the end 1846 host is the QNI, and sends a RESERVE with the PROXY scope flag set. 1847 The P-QNE is the QNR, it will receive the RESERVE, notice the PROXY 1848 scope flag is set and reply with a RESPONSE (if requested). This 1849 operation is the same as illustrated in Figure 7. The receiver- 1850 oriented reservation for outgoing flows works the same way as in 1851 Figure 8, the P-QNE is the QNI. 1853 For incoming data flows, the end host is the QNI, and it sends a 1854 RESERVE towards the data sender with the PROXY scope flag set. Here 1855 the end host sets the MRI so that it indicates the end host as the 1856 receiver of the data, and sets the D-flag. 1858 GIST is able to send messages towards the data sender if there is 1859 existing message routing state or it is able to use the Upstream Q- 1860 mode Encapsulation. In some cases GIST will be unable to determine 1861 the appropriate next hop for the message, and so will indicate a 1862 failure to deliver it (by sending an error message). This may occur, 1863 for example, if GIST attempts to determine an upstream next hop and 1864 there are multiple possible inbound routes that could be used. 1866 Bi-directional reservations, as discussed in Section 4.4. The P-QNE 1867 will be the QNR or QNI for reservations. 1869 If the PROXY scope flag is set in an incoming QoS NSLP message, the 1870 QNE must set the same flag in all QoS NSLP messages it sends that are 1871 related to this session. 1873 5. QoS NSLP Functional Specification 1875 5.1. QoS NSLP Message and Object Formats 1877 A QoS NSLP message consists of a common header, followed by a body 1878 consisting of a variable number of variable-length, typed "objects". 1879 The common header and other objects are encapsulated together in a 1880 GIST NSLP-Data object. The following subsections define the formats 1881 of the common header and each of the QoS NSLP message types. In the 1882 message formats, the common header is denoted as COMMON_HEADER. 1884 For each QoS NSLP message type, there is a set of rules for the 1885 permissible choice of object types. These rules are specified using 1886 the Augmented Backus-Naur Form (ABNF) specified in RFC 5234 1887 [RFC5234]. The ABNF implies an order for the objects in a message. 1888 However, in many (but not all) cases, object order makes no logical 1889 difference. An implementation SHOULD create messages with the 1890 objects in the order shown here, but MUST accept the objects in any 1891 order. 1893 5.1.1. Common Header 1895 All GIST NSLP-Data objects for the QoS NSLP MUST contain this common 1896 header as the first 32 bits of the object (this is not the same as 1897 the GIST Common Header). 1899 0 1 2 3 1900 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 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | Message Type | Message Flags | Generic Flags | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 The fields in the common header are as follows: 1907 Msg Type: 8 bits 1909 1 = RESERVE 1911 2 = QUERY 1913 3 = RESPONSE 1915 4 = NOTIFY 1917 Message-specific flags: 8 bits 1919 These flags are defined as part of the specfication of individual 1920 messages, and, thus, are different with each message type. 1922 Generic flags: 16 bits 1924 Generic flags have the same meaning for all message types. There 1925 exist currently four generic flags, the (next hop) Scoping flag (S), 1926 the Proxy scope flag (P), the Acknowledgement Requested flag (A), and 1927 the Break flag (B). 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Reserved |B|A|P|S| 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 SCOPING (S) - when set, indicates that the message is scoped and 1934 should not travel down the entire path but only as far as the next 1935 QNE (scope="next hop"). By default, this flag is not set (default 1936 scope="whole path"). 1938 PROXY (P) - when set, indicates that the message is scoped, and 1939 should not travel down the entire path but only as far as the P-QNE. 1940 By default, this flag is not set. 1942 ACK-REQ (A) - when set, indicates that the message should be 1943 acknowledged by the receiving peer. The flag is only used between 1944 stateful peers, and only used with RESERVE and QUERY messages. 1945 Currently, the flag is only used with refresh messages. By default 1946 the flag is not set. 1948 BREAK (B) - when set, indicates that there are routers along the path 1949 where QoS cannot be provided. 1951 The set of appropriate flags depends on the particular message being 1952 processed. Any bit not defined as a flag for a particular message 1953 MUST be set to zero on sending and MUST be ignored on receiving. 1955 The ACK-REQ flag is useful when a QNE wants to make sure the messages 1956 received by the downstream QNE are truly processed by the QoS NSLP, 1957 not just delivered by GIST. This is useful for faster dead peer 1958 diagnostics on the NSLP layer. This liveliness test can only be used 1959 with refresh RESERVE messages. The ACK-REQ-flag must not be set for 1960 RESERVE messages that already include an RII object, since a 1961 confirmation has already been requested from the QNR. Reliable 1962 transmission of messages between two QoS NSLP peer should be handled 1963 by GIST, not the NSLP by itself. 1965 5.1.2. Message Formats 1967 5.1.2.1. RESERVE 1969 The format of a RESERVE message is as follows: 1971 RESERVE = COMMON_HEADER 1972 RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ] 1973 [ SESSION_ID_LIST [ RSN_LIST ] ] 1974 [ MSG_ID / BOUND_MSG_ID ] [ INFO_SPEC ] 1975 [ [ PACKET_CLASSIFIER ] QSPEC ] 1977 The RSN is the only mandatory object and MUST always be present in 1978 all cases. A QSPEC MUST be included in the initial RESERVE sent 1979 towards the QNR. A PACKET_CLASSIFIER MAY be provided. If the 1980 PACKET_CLASSIFIER is not provided, then the full set of information 1981 provided in the GIST MRI for the session should be used for packet 1982 classification purposes. 1984 Subsequent RESERVE messages meant as reduced refreshes, where no 1985 QSPEC is provided, MUST NOT include a PACKET_CLASSIFIER either. 1987 There are no requirements on transmission order, although the above 1988 order is recommended. 1990 Two message-specific flags are defined for use in the common header 1991 with the RESERVE message. These are: 1993 +-+-+-+-+-+-+-+-+ 1994 |Reserved |T|R| 1995 +-+-+-+-+-+-+-+-+ 1997 TEAR (T) - when set, indicates that reservation state and QoS NSLP 1998 operation state should be torn down. The former is indicated to the 1999 RMF. Depending on the QoS model, the tear message may include a 2000 QSPEC to further specify state removal, e.g., for an aggregation, the 2001 QSPEC may specify the amount of resources removed from the aggregate. 2003 REPLACE (R) - when set the flag has two uses. First, it indicates 2004 that a RESERVE with different MRI (but same SID) replaces an existing 2005 one, so the old one MAY be torn down immediately. This is the 2006 default situation. This flag may be unset to indicate a desire from 2007 an upstream node to keep an existing reservation on an old branch in 2008 place. Second, this flag is also used to indicate whether the 2009 reserved resources on the old branch should be torn down or not when 2010 a data path change happens. In this case, the MRI is the same and 2011 only the route path changes. 2013 If the REFRESH_PERIOD is not present, a default value of 30 seconds 2014 is assumed. 2016 If the session of this message is bound to another session, then the 2017 RESERVE message SHOULD include the SESSION_ID of that other session 2018 in a BOUND_SESSION_ID object. In the situation of aggregated 2019 tunnels, the aggregated session MAY not include the SESSION_ID of its 2020 bound sessions in BOUND_SESSION_ID(s). 2022 The negotiation of whether to perform sender or receiver-initiated 2023 signaling is done outside the QoS NSLP. Yet, in theory, it is 2024 possible that a "reservation collision" may occur if the sender 2025 believes that a sender-initiated reservation should be performed for 2026 a flow, whilst the other end believes that it should be starting a 2027 receiver- initiated reservation. If different session identifiers 2028 are used then this error condition is transparent to the QoS NSLP 2029 though it may result in an error from the RMF, otherwise the removal 2030 of the duplicate reservation is left to the QNIs/QNRs for the two 2031 sessions. 2033 If a reservation is already installed and a RESERVE message is 2034 received with the same session identifier from the other direction 2035 (i.e., going upstream where the reservation was installed by a 2036 downstream RESERVE message, or vice versa) then an error indicating 2037 "RESERVE received from wrong direction" MUST be sent in a RESPONSE 2038 message to the signaling message source for this second RESERVE. 2040 A refresh right along the path can be forced by requesting a RESPONSE 2041 from the far end (i.e., by including an RII object in the RESERVE 2042 message). Without this, a refresh RESERVE would not trigger RESERVE 2043 messages to be sent further along the path, as each hop has its own 2044 refresh timer. 2046 A QNE may ask for confirmation of tear operation by including an RII 2047 object. QoS NSLP retransmissions SHOULD be disabled. A QNE sending 2048 a tearing RESERVE with an RII included MAY ask GIST to use reliable 2049 transport. When the QNE sends out a tearing RESERVE, it MUST NOT 2050 send refresh messages anymore. 2052 If the routing path changed due to mobility and the mobile node's IP 2053 address changed, and it sent a Mobile IP binding update, the 2054 resulting refresh is a new RESERVE. This RESERVE includes a new MRI 2055 and will be propagated end-to-end; there is no need to force end-to- 2056 end forwarding by including an RII. 2058 Note: It is possible for a host to use this mechanism to constantly 2059 force the QNEs on the path to send refreshing RESERVE messages. It 2060 may, therefore, be appropriate for QNEs to perform rate limiting on 2061 the refresh messages that they send. 2063 5.1.2.2. QUERY 2065 The format of a QUERY message is as follows: 2066 QUERY = COMMON_HEADER 2067 [ RII ][ *BOUND_SESSION_ID ] 2068 [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC 2070 QUERY messages MUST always include a QSPEC. QUERY messages MAY 2071 include a PACKET_CLASSIFIER when the message is used to trigger a 2072 receiver-initiated reservation. If a PACKET_CLASSIFIER is not 2073 included then the full GIST MRI should be used for packet 2074 classification purposes in the subsequent RESERVE. A QUERY message 2075 MAY contain a second QSPEC object. 2077 A QUERY message for requesting information about network resources 2078 MUST contain an RII object to match an incoming RESPONSE to the 2079 QUERY. 2081 The QSPEC object describes what is being queried for and may contain 2082 objects that gather information along the data path. There are no 2083 requirements on transmission order, although the above order is 2084 recommended. 2086 One message-specific flags are defined for use in the common header 2087 with the QUERY message. This is: 2089 +-+-+-+-+-+-+-+-+ 2090 |Reserved |R| 2091 +-+-+-+-+-+-+-+-+ 2093 RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger 2094 for the recipient to make a resource reservation by sending a 2095 RESERVE. 2097 If the session of this message is bound to another session, then the 2098 RESERVE message SHOULD include the SESSION_ID of that other session 2099 in a BOUND_SESSION_ID object. In the situation of aggregated 2100 tunnels, the aggregated session MAY not include the SESSION_ID of its 2101 bound sessions in BOUND_SESSION_ID(s). 2103 5.1.2.3. RESPONSE 2105 The format of a RESPONSE message is as follows: 2107 RESPONSE = COMMON_HEADER 2108 [ RII / RSN ] INFO_SPEC [SESSION_ID_LIST [ RSN_LIST ] ] 2109 [ QSPEC ] 2111 A RESPONSE message MUST contain an INFO_SPEC object which indicates 2112 the success of a reservation installation or an error condition. 2113 Depending on the value of the INFO_SPEC, the RESPONSE MAY also 2114 contain a QSPEC object. The value of an RII or an RSN object was 2115 provided by some previous QNE. There are no requirement on 2116 transmission order, although the above order is recommended. 2118 No message-specific flags are defined for use in the common header 2119 with the RESPONSE message. 2121 5.1.2.4. NOTIFY 2123 The format of a NOTIFY message is as follows: 2125 NOTIFY = COMMON_HEADER 2126 INFO_SPEC [ QSPEC ] 2128 A NOTIFY message MUST contain an INFO_SPEC object indicating the 2129 reason for the notification. Depending on the INFO_SPEC value, it 2130 MAY contain a QSPEC object providing additional information. 2132 No message-specific flags are defined for use with the NOTIFY 2133 message. 2135 5.1.3. Object Formats 2137 The QoS NSLP uses a Type-Length-Value (TLV) object format similar to 2138 that used by GIST. Every object consists of one or more 32-bit words 2139 with a one-word header. For convenience the standard object header 2140 is shown here: 2142 0 1 2 3 2143 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 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 |A|B|r|r| Type |r|r|r|r| Length | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 The value for the Type field comes from the shared NSLP object type 2149 space, the various objects are presented in subsequent sections. The 2150 Length field is given in units of 32 bit words and measures the 2151 length of the Value component of the TLV object (i.e., it does not 2152 include the standard header). 2154 The bits marked 'A' and 'B' are flags used to signal the desired 2155 treatment for objects whose treatment has not been defined in the 2156 protocol specification (i.e., whose Type field is unknown at the 2157 receiver). The following four categories of object have been 2158 identified, and are described here. 2160 AB=00 ("Mandatory"): If the object is not understood, the entire 2161 message containing it MUST be rejected, and an error message sent 2162 back. 2164 AB=01 ("Ignore"): If the object is not understood, it MUST be deleted 2165 and the rest of the message processed as usual. 2167 AB=10 ("Forward"): If the object is not understood, it MUST be 2168 retained unchanged in any message forwarded as a result of message 2169 processing, but not stored locally. 2171 AB=11 ("Refresh"): If the object is not understood, it should be 2172 incorporated into the locally stored QoS NSLP signaling application 2173 operational state for this flow/session, forwarded in any resulting 2174 message, and also used in any refresh or repair message which is 2175 generated locally. The contents of this object does not need to be 2176 interpreted, and should only be stored as bytes on the QNE. 2178 The remaining bits marked 'r' are reserved. The extensibility flags 2179 AB are similar to those used in the GIST specification. All objects 2180 defined in this specification MUST be understood by all QNEs, thus, 2181 they MUST have the AB-bits set to "00". A QoS NSLP implementation 2182 must recognize objects of the following types: RII, RSN, 2183 REFRESH_PERIOD, BOUND_SESSION_ID, INFO_SPEC, and QSPEC. 2185 The object header is followed by the Value field, which varies for 2186 different objects. The format of the Value field for currently 2187 defined objects is specified below. 2189 The object diagrams here use '//' to indicate a variable sized field. 2191 5.1.3.1. Request Identification Information (RII) 2193 Type: 0x01 2195 Length: Fixed - 1 32-bit word 2197 Value: An identifier which MUST be (probabilistically) unique within 2198 the context of a SESSION_ID, and SHOULD be different every time a 2199 RESPONSE is desired. Used by a QNE to match back a RESPONSE to a 2200 request in a RESERVE or QUERY message. 2202 0 1 2 3 2203 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 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | Response Identification Information (RII) | 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 5.1.3.2. Reservation Sequence Number (RSN) 2210 Type: 0x02 2212 Length: Fixed - 2 32-bit words 2214 Value: An incrementing sequence number that indicates the order in 2215 which state modifying actions are performed by a QNE, and an epoch 2216 identifier to allow the identification of peer restarts. The RSN has 2217 local significance only, i.e., between a QNE and its downstream 2218 stateful peers. The RSN is not reset when the downstream peer 2219 changes. 2221 0 1 2 3 2222 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 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | Reservation Sequence Number (RSN) | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 | Epoch Identifier | 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 5.1.3.3. Refresh Period (REFRESH_PERIOD) 2231 Type: 0x03 2233 Length: Fixed - 1 32-bit word 2235 Value: The refresh timeout period R used to generate this message; in 2236 milliseconds. 2238 0 1 2 3 2239 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 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Refresh Period (R) | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 5.1.3.4. Bound Session ID (BOUND_SESSION_ID) 2246 Type: 0x04 2248 Length: Fixed - 5 32-bit words 2250 Value: contains an 8-bit Binding_Code that indicates the nature of 2251 binding. The rest specifies the SESSION_ID (as specified in GIST 2252 [I-D.ietf-nsis-ntlp]) of the session that MUST be bound to the 2253 session associated with the message carrying this object. 2255 0 1 2 3 2256 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 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | RESERVED | Binding Code | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | | 2261 + + 2262 | | 2263 + Session ID + 2264 | | 2265 + + 2266 | | 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 Currently defined Binding Codes are: 2271 o 0x01 - Tunnel and end-to-end sessions 2273 o 0x02 - Bi-directional sessions 2275 o 0x03 - Aggregate sessions 2276 o 0x04 - Dependent sessions (binding session is alive only if the 2277 other session is also alive) 2279 o 0x05 - Indicated session caused pre-emption 2281 More binding codes maybe defined based on the above four atomic 2282 binding actions. Note a message may include more than one 2283 BOUND_SESSION_ID object. This may be needed in case one needs to 2284 define more specifically the reason for binding, or if the session 2285 must on depend on more than one other session (with possibly 2286 different reasons). Note that a session with e.g., SID_A (the 2287 binding session) can express its unidirectional dependency relation 2288 to another session with e.g., SID_B (the bound session) by including 2289 a BOUND_SESSION_ID object containing SID_B in its messages. 2291 5.1.3.5. Packet Classifier (PACKET_CLASSIFIER) 2293 Type: 0x05 2295 Length: Variable 2297 Value: Contains a variable length MRM-specific data 2299 0 1 2 3 2300 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 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 // Method-specific classifier data (variable) // 2303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 At this stage, the QoS NSLP only uses the path-coupled routing MRM. 2306 The method-specific classifier data is two bytes long and consists of 2307 a set of flags: 2309 0 1 2 3 2310 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 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2312 |X|Y|P|T|F|S|A|B| Reserved | 2313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 The flags are: 2317 X - Source Address and Prefix 2319 Y - Destination Address and Prefix 2321 P - Protocol 2323 T - DiffServ Code Point 2324 F - Flow Label 2326 S - SPI 2328 A - Source Port 2330 B - Destination Port 2332 The flags indicate which fields from the MRI MUST be used by the 2333 packet classifier. This allows a subset of the information in the 2334 MRI to be used for identifying the set of packets which are part of 2335 the reservation. Flags MUST only be set if the data is present in 2336 the MRI (i.e., where there is a corresponding flag in the GIST MRI, 2337 the flag can only be set if the corresponding GIST MRI flag is set). 2338 It should be noted that some flags in the PACKET_CLASSIFIER (X and Y) 2339 relate to data that is always present in the MRI, but are optional to 2340 use for QoS NSLP packet classification. The appropriate set of flags 2341 set may depend, to some extent, on the QoS model being used. 2343 As mentioned earlier in this section, the QoS NSLP is currently only 2344 defined for use with the Path-Coupled Message Routing Mechanism (MRM) 2345 in GIST. Future work may extend the QoS NSLP to additional routing 2346 mechanisms. Such MRMs must include sufficient information in the MRI 2347 to allow the subset of packets for which QoS is to be provided to be 2348 identified. When QoS NSLP is extended to support a new MRM, 2349 appropriate method-specific classifier data for the PACKET_CLASSIFIER 2350 object MUST be defined. 2352 5.1.3.6. Information Object (INFO_SPEC) and Error Codes 2354 Type: 0x06 2356 Length: Variable 2358 Value: Contains a 16-bit error code, a 4-bit error class, a 4-bit 2359 error source identifier type, and an 8-bit error source identifier 2360 length (in 32-bit words), an error source identifier and optionally 2361 variable length error-specific information. 2363 0 1 2 3 2364 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 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 | Error Code |E-Class|ESI Typ| ESI-Length | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 // Error Source Identifier // 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 // Optional error-specific information // 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 Class Field: 2374 The four E-Class bits of the object indicate the error severity 2375 class. The currently defined severity classes are: 2377 o 0x01 - Informational 2379 o 0x02 - Success 2381 o 0x03 - Protocol Error 2383 o 0x04 - Transient Failure 2385 o 0x05 - Permanent Failure 2387 o 0x06 - QoS Model Error 2389 Error field: 2391 Within each error severity class a number of Error Code values are 2392 defined. 2394 o Informational: 2396 * 0x01 - Unknown BOUND_SESSION_ID: the message refers to an unknown 2397 SESSION_ID in its BOUND_SESSION_ID object. 2399 * 0x02 - Route Change: possible route change occurred on downstream 2400 path. 2402 * 0x03 - Reduced refreshes not supported, full QSPEC required. 2404 * 0x04 - Congestion situation: Possible congestion situation occurred 2405 on downstream path. 2407 * 0x05 - Unknown SESSION ID in SESSION_ID_LIST 2409 * 0x06 - Mismatching RSN in RSN LIST 2411 o Success: 2413 * 0x01 - Reservation successful 2415 * 0x02 - Tear down successful 2417 * 0x03 - Acknowledgement 2419 * 0x04 - Refresh successful 2420 o Protocol Error: 2422 * 0x01 - Illegal message type: the type given in the Message Type 2423 field of the common header is unknown. 2425 * 0x02 - Wrong message length: the length given for the message does 2426 not match the length of the message data. 2428 * 0x03 - Bad flags value: an undefined flag or combination of flags 2429 was set in the generic flags 2431 * 0x04 - Bad flags value: an undefined flag or combination of flags 2432 was set in the message-specific flags 2434 * 0x05 - Mandatory object missing: an object required in a message of 2435 this type was missing. 2437 * 0x06 - Illegal object present: an object was present which must not 2438 be used in a message of this type. 2440 * 0x07 - Unknown object present: an object of an unknown type was 2441 present in the message. 2443 * 0x08 - Wrong object length: the length given for the object did not 2444 match the length of the object data present. 2446 * 0x09 - RESERVE received from wrong direction. 2448 * 0x0a - Unknown object field value: a field in an object had an 2449 unknown value. 2451 * 0x0b - Duplicate object present. 2453 * 0x0c - Malformed QSPEC. 2455 * 0x0d - Unknown MRI. 2457 * 0x0e - Erroneous value in the TLV object's value field. 2459 * 0x0f - Incompatible QSPEC 2461 o Transient Failure: 2463 * 0x01 - No GIST reverse-path forwarding state 2465 * 0x02 - No path state for RESERVE, when doing a receiver- oriented 2466 reservation 2467 * 0x03 - RII conflict 2469 * 0x04 - Full QSPEC required 2471 * 0x05 - Mismatch synchronization between end-to-end RESERVE and 2472 intra-domain RESERVE 2474 * 0x06 - Reservation preempted 2476 * 0x07 - Reservation failure 2478 * 0x08 - Path truncated - Next peer dead 2480 o Permanent Failure: 2482 * 0x01 - Internal or system error 2484 * 0x02 - Authorization failure 2486 o QoS Model Error: 2488 This error class can be used by QoS Models to add error codes 2489 specific to the QoS Model being used. All these errors and events 2490 are created outside the QoS NSLP itself. The error codes in this 2491 class are defined in QoS model specifications. Note that this error 2492 class may also include codes that are not purely errors, but rather 2493 some non-fatal information. 2495 Error Source Identifier 2497 The Error Source Identifier is for diagnostic purposes and its 2498 inclusion is OPTIONAL. It is suggested that implementations use this 2499 for the IP address, host name or other identifier of the QNE 2500 generating the INFO_SPEC to aid diagnostic activities. A QNE SHOULD 2501 NOT be used in any other purpose other than error logging or 2502 presenting to the user as part of any diagnostic information. A QNE 2503 SHOULD NOT attempt to send a message to that address. 2505 If no Error Source Identifier is included, the Error Source 2506 Identifier Type field must be zero. 2508 Currently three Error Source Identifiers have been defined: IPv4, 2509 IPv6 and FQDN. 2511 Error Source Identifier: IPv4 2513 Error Source Identifier Type: 0x01 2514 0 1 2 3 2515 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 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | 32-bit IPv4 address | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 Error Source Identifier: IPv6 2522 Error Source Identifier Type: 0x02 2524 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 2525 1 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | | 2529 + + 2530 | | 2531 + 128-bit IPv6 address + 2532 | | 2533 + + 2534 | | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 Error Source Identifier: FQDN name in UTF-8 2539 Error Source Identifier Type: 0x03 2541 0 1 2 3 2542 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 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 // FQDN Name // 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 If the length of the FQDN name is not a multiple of 32-bits, the 2548 field is padded with zero octets to the next 32-bit boundary. 2550 If a QNE encounters protocol errors, it MAY include additional 2551 information, mainly for diagnostic purposes. Additional information 2552 MAY be included if the type of an object is erroneous, or a field has 2553 an erroneous value. 2555 If the type of an object is erroneous, the following optional error- 2556 specific information may be included at the end of the INFO_SPEC. 2558 Object Type Info: 2560 0 1 2 3 2561 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 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 | Object Type | Reserved | 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 This object provides information about the type of object which 2567 caused the error. 2569 If a field in an object had an incorrect value, the following 2570 optional error-specific information may be added at the end of the 2571 INFO_SPEC. 2573 Object Value Info: 2575 0 1 2 3 2576 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 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | Rsvd | Real Object Length | Offset | 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 // Object // 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 Real Object Length: Since the length in the original TLV header may 2584 be inaccurate, this field provides the actual length of the object 2585 (including the TLV Header) included in the error message. 2587 Offset: The byte in the object at which the QNE found the error. 2588 When this field is set to "0", the complete object is included. 2590 Object: The invalid TLV object (including the TLV Header). 2592 This object carries information about a TLV object which was found to 2593 be invalid in the original message. An error message may contain 2594 more than one Object Value Info object. 2596 5.1.3.7. SESSION ID List (SESSION_ID_LIST) 2598 Type: 0x07 2600 Length: Variable 2602 Value: A list of 128-bit SESSION IDs used in summary refresh and 2603 summary tear messages. All SESSION IDs are concatenated together. 2605 0 1 2 3 2606 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 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 | | 2609 + + 2610 | | 2611 + Session ID 1 + 2612 | | 2613 + + 2614 | | 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 : : 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 | | 2619 + + 2620 | | 2621 + Session ID n + 2622 | | 2623 + + 2624 | | 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 5.1.3.8. Reservation Sequence Number (RSN) List (RSN_LIST) 2629 Type: 0x08 2631 Length: Variable 2633 Value: A list of 32-bit Reservation Sequence Number (RSN) values. 2634 All RSN are concatenated together. 2636 0 1 2 3 2637 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 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 | Epoch Identifier | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | Reservation Sequence Number 1 (RSN1) | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 : : 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | Reservation Sequence Number n (RSNn) | 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 5.1.3.9. Message ID (MSG_ID) 2650 Type: 0x09 2652 Length: Fixed - 5 32-bit words 2653 Value: contains an 1-bit Message_Binding_Type (D) that indicates the 2654 dependency relation of a message binding. The rest specifies a 128 2655 bit randomly generated value that "uniquely" identifies this 2656 particular message. 2658 0 1 2 3 2659 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 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | RESERVED |D| 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2663 | | 2664 + + 2665 | | 2666 + Message ID + 2667 | | 2668 + + 2669 | | 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 The Message Binding Codes are: 2674 * 0 - Unidirectional binding dependency 2676 * 1 - Bi-directional binding dependency 2678 5.1.3.10. Bound Message ID (BOUND_MSG_ID) 2680 Type: 0x0A 2682 Length: Fixed - 5 32-bit words 2684 Value: contains an 1-bit Message_Binding_Type (D) that indicates the 2685 dependency relation of a message binding. The rest specifies a 128 2686 bit randomly generated value that refers to a Message ID in another 2687 message. 2689 0 1 2 3 2690 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 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | RESERVED |D| 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 | | 2695 + + 2696 | | 2697 + Bound Message ID + 2698 | | 2699 + + 2700 | | 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 The Message Binding Codes are: 2705 * 0 - Unidirectional binding dependency 2707 * 1 - Bi-directional binding dependency 2709 5.1.3.11. QoS Specification (QSPEC) 2711 Type: 0x0B 2713 Length: Variable 2715 Value: Variable length QSPEC (QoS specification) information, which 2716 is QoS Model dependent. 2718 The contents and encoding rules for this object are specified in 2719 other documents. See [I-D.ietf-nsis-qspec]. 2721 0 1 2 3 2722 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 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | | 2725 // QSPEC Data // 2726 | | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 5.2. General Processing Rules 2731 This section provides the general processing rules used by QoS-NSLP. 2732 The triggers communicated between RM/QOSM and QoS-NSLP 2733 functionalities are given in Appenices A.1, A.2 and A.3. 2735 5.2.1. State Manipulation 2737 The processing of a message and its component objects involves 2738 manipulating the QoS NSLP and reservation state of a QNE. 2740 For each flow, a QNE stores (RMF-related) reservation state which 2741 depends on the QoS model / QSPEC used and QoS NSLP operation state 2742 which includes non-persistent state (e.g., the API parameters while a 2743 QNE is processing a message) and persistent state which is kept as 2744 long as the session is active. 2746 The persistent QoS NSLP state is conceptually organized in a table 2747 with the following structure. The primary key (index) for the table 2748 is the SESSION_ID: 2750 SESSION_ID 2752 A 128-bit identifier. 2754 The state information for a given key includes: 2756 Flow ID 2758 Based on GIST MRI. Several entries are possible in case of mobility 2759 events. 2761 SII-Handle for each upstream and downstream peer 2763 The SII-Handle is a local identifier generated by GIST and passed 2764 over the API. It is a handle that allows to refer to a particular 2765 GIST next hop. See SII-Handle in [I-D.ietf-nsis-ntlp] for more 2766 information. 2768 RSN from the upstream peer 2770 The RSN is a 32 bit counter. 2772 The latest local RSN 2774 A 32 bit counter. 2776 List of RII for outstanding responses with processing information. 2778 The RII is a 32 bit number. 2780 State lifetime 2782 The state lifetime indicates how long the state that is being 2783 signaled for remains valid. 2785 List of bound sessions 2787 A list of BOUND_SESSION_ID 128-bit identifiers for each session bound 2788 to this state. 2790 Scope of the signaling 2792 If the Proxy scope is used, a flag is needed to identify all 2793 signaling of this session as being scoped. 2795 Adding the state requirements of all these items gives an upper bound 2796 on the state to be kept by a QNE. The need to keep state depends on 2797 the desired functionality at the NSLP layer. 2799 5.2.2. Message Forwarding 2801 QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP 2802 does not have the concept of a message being sent directly to the end 2803 of the path. Instead, messages are received by a QNE, which may then 2804 send another message (which may be identical to the received message, 2805 or contain some subset of objects from it) to continue in the same 2806 direction (i.e., towards QNI or QNR) as the message received. 2808 The decision on whether to generate a message to forward may be 2809 affected by the value of the SCOPING or PROXY flags, or by the 2810 presence of an RII object. 2812 5.2.3. Standard Message Processing Rules 2814 If a mandatory object is missing from a message then the receiving 2815 QNE MUST NOT propagate the message any further. It MUST construct a 2816 RESPONSE message indicating the error condition and send it back to 2817 the peer QNE that sent the message. 2819 If a message contains an object of an unrecognised type, then the 2820 behavior depends on the AB extensibility flags. 2822 If the Proxy scope flag was set in an incoming QoS NSLP message, the 2823 QNE must set the same flag in all QoS NSLP messages it sends that are 2824 related to this session. 2826 5.2.4. Retransmissions 2828 Retransmissions may happen end-to-end, e.g., between QNI and QNR 2829 (using an RII object), or peer-to-peer, between two adjacent QNEs. 2830 When a QNE transmits a RESERVE with an RII object set, it waits for a 2831 RESPONSE from the responding QNE. QoS NSLP messages for which a 2832 response is requested by including an RII object, but fail to elicit 2833 a response are retransmitted. Similarly, a QNE may include the ACK- 2834 REQ-flag to request confirmation of a refresh message reception from 2835 its immediate peer. The retransmitted message should be exactly the 2836 same as the original message, e.g., the RSN is not modified with each 2837 retransmission. 2839 The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY wait 2840 period. Retransmissions MUST be made with exponentially increasing 2841 wait intervals (doubling the wait each time). QoS NSLP messages 2842 SHOULD be retransmitted until either a RESPONSE (which might be an 2843 error) has been obtained, or until QOSNSLP_RETRY_MAX seconds after 2844 the initial transmission. In the latter case, a failure SHOULD be 2845 indicated to the signaling application. The default values for the 2846 above-mentioned timers are: 2848 QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial 2849 retransmit of the message 2851 QOSNSLP_RETRY_MAX: 30 seconds Give up retrying to send the message 2853 Retransmissions SHOULD be disabled for tear messages. 2855 5.2.5. Rerouting 2857 5.2.5.1. Last Node Behavior 2859 As discussed in Section 3.2.12 some care needs to be taken to handle 2860 cases where the last node on the path may change. 2862 A node that is the last node on the path, but not the data receiver 2863 (or an explicitly configured proxy for it), MUST continue to attempt 2864 to send messages downstream to probe for path changes. This must be 2865 done in order to handle the "Path Extension" case described in 2866 Section 3.2.12.1. 2868 A node on the path, that was not previously the last node, MUST take 2869 over as the last node on the signaling path if GIST path change 2870 detection identifies that there are no further downstream nodes on 2871 the path. This must be done in order to handle the "Path Truncation" 2872 case described in Section 3.2.12.1. 2874 5.2.5.2. Avoiding Mistaken Teardown 2876 In order to handle the spurious route change problem described in 2877 Section 3.2.12.2, the RSN must be used in a particular way when 2878 maintaining the reservation after a route change is believed to have 2879 occurred. 2881 We assume that the current RSN (RSN[current]) is initially RSN0. 2883 When a route change is believed to have occurred, the QNE SHOULD send 2884 a RESERVE message, including the full QSPEC. This must contain an 2885 RSN which is RSN[current] = RSN0 + 2. It SHOULD include an RII, to 2886 request a response from the QNR. An SII-Handle MUST NOT be specified 2887 when passing this message over the API to GIST, so that it is 2888 correctly routed to the new peer QNE. 2890 When the QNE receives the RESPONSE message that relates to the 2891 RESERVE message sent down the new path, it SHOULD send a RESERVE 2892 message with the TEAR flag sent down the old path. To do so, it MUST 2893 request GIST to use its explicit routing mechanism and the QoS NSLP 2894 MUST supply an SII-Handle relating to the old peer QNE. When sending 2895 this RESERVE message it MUST contain an RSN which is RSN[current] - 2896 1. (RSN[current] remains unchanged). 2898 If the RESPONSE received after sending the RESERVE down the new path 2899 contains the code "Refresh successful" in the INFO_SPEC, then the QNE 2900 MAY elect not to send the tearing RESERVE, since this indicates that 2901 the path is unchanged. 2903 5.2.5.3. Upstream Route Change Notification 2905 GIST may notify the QoS NSLP that a possible upstream route change 2906 has occurred over the GIST API. On receiving such a notification, 2907 the QoS NSLP SHOULD send a NOTIFY message with Informational code 2908 0x02 for signaling sessions associated with the identified MRI. If 2909 this is sent, it MUST be sent to the old peer using the GIST explicit 2910 routing mechanism through the use of the SII-Handle. 2912 On receiving such a NOTIFY message, the QoS NSLP SHOULD use the 2913 InvalidateRoutingState API call to inform GIST that routing state may 2914 be out of date. The QoS NSLP SHOULD send a NOTIFY message upstream. 2915 The NOTIFY message should be propagated back to the QNI or QNR. 2917 5.2.5.4. Route Change Oscillation 2919 In some circumstances a route change may occur, but the path then 2920 falls back to the original route. 2922 After a route change the routers on the old path will continue to 2923 refresh the reservation until soft state times out, or an explicit 2924 TEAR is received. 2926 After detecting an upstream route change a QNE SHOULD consider the 2927 new upstream peer as current and not fall back to the old upstream 2928 peer unless: 2930 - it stops receiving refreshes from the old upstream peer for at 2931 least the soft state timeout period and then starts receiving 2932 messages from the old upstream peer again 2934 - or, it stops receiving refreshes from the new upstream peer for at 2935 least the soft state timeout period. 2937 GIST routing state keeps track of the latest upstream peer it has 2938 seen, and so may spuriously indicate route changes occur when the old 2939 upstream peer refreshes its routing state until the state at that 2940 node is explicitly torn down or times out. 2942 5.3. Object Processing 2944 This section presents processing rules for individual QoS NSLP 2945 objects. 2947 5.3.1. Reservation Sequence Number (RSN) 2949 A QNE's own RSN is a sequence number which applies to a particular 2950 signaling session (i.e., with a particular SESSION_ID). It MUST be 2951 incremented for each new RESERVE message where the reservation for 2952 the session changes. The RSN is manipulated using the serial number 2953 arithmetic rules from [RFC1982], which also defines wrapping rules 2954 and the meaning of 'equals', 'less than' and 'greater than' for 2955 comparing sequence numbers in a circular sequence space. 2957 The RSN starts at zero. It is stored as part of the per-session 2958 state and it carries on incrementing (i.e., it is not reset to zero) 2959 when a downstream peer change occurs. (Note that section 5.2.5.2 2960 provides some particular rules for use when a downstream peer 2961 changes.) 2963 The RSN object also contains an Epoch Identifier, which provides a 2964 method for determining when a peer has restarted (e.g., due to node 2965 reboot or software restart). The exact method for providing this 2966 value is implementation defined. Options include storing a serial 2967 number which is incremented on each restart, picking a random value 2968 on each restart or using the restart time. 2970 On receiving a RESERVE message a QNE examines the Epoch Identifier to 2971 determine if the peer sending the message has restarted. If the 2972 Epoch Identifier is different to that stored for the reservation then 2973 the RESERVE message MUST be treated as an updated reservation (even 2974 if the RSN is less than the current stored value), and the stored RSN 2975 and Epoch Identifier MUST be updated to the new values. 2977 When receiving a RESERVE message a QNE uses the RSN given in the 2978 message to determine whether the state being requested is different 2979 to that already stored. If the RSN is equal to that stored for the 2980 current reservation the current state MUST be refreshed. If the RSN 2981 is greater than the current stored value, the current reservation 2982 MUST be modified appropriately as specified in the QSPEC (provided 2983 that admission control and policy control succeed), and the stored 2984 RSN value updated to that for the new reservation. If the RSN is 2985 greater than the current stored value and the RESERVE was a reduced 2986 refresh, the QNE SHOULD send upstream a transient error message "Full 2987 QSPEC required". If the RSN is less than the current value, then it 2988 indicates an out-of-order message and the RESERVE message MUST be 2989 discarded. 2991 If the QNE does not store per-session state (and so does not keep any 2992 previous RSN values) then it MAY ignore the value of the RSN. It 2993 MUST also copy the same RSN into the RESERVE message (if any) it 2994 sends as a consequence of receiving this one. 2996 5.3.2. Request Identification Information (RII) 2998 A QNE sending QUERY or RESERVE messages may require a response to be 2999 sent. It does so by including a Request Identification Information 3000 (RII) object. When creating an RII object the QNE MUST select the 3001 value for the RII such that it is probabilistically unique within the 3002 given session. A RII object is typically set by the QNI. 3004 A number of choices are available when implementing this. 3005 Possibilities might include using a random value, or a node 3006 identifier together with a counter. If the value collides with one 3007 selected by another QNE for a different QUERY then RESPONSE messages 3008 may be incorrectly terminated, and may not be passed back to the node 3009 that requested them. 3011 The node that created the RII object MUST remember the value used in 3012 the RII to match back any RESPONSE it will receive. The node SHOULD 3013 use a timer to identify situations where it has taken too long to 3014 receive the expected RESPONSE. If the timer expires without 3015 receiving a RESPONSE it MAY perform a retransmission as discussed in 3016 Section 5.2.4. In this case this QNE MUST NOT generate any RESPONSE 3017 or NOTIFY message to notify this error. 3019 If an intermediate QNE wants to receive a response for an outgoing 3020 message, but the message already included an RII when it arrived, the 3021 QNE MUST NOT add a new RII object nor replace the old RII object, but 3022 MUST simply remember this RII to match a later RESPONSE message. 3024 When it receives the RESPONSE, it forwards the RESPONSE upstream 3025 towards the RII originating node. Note that only the node that 3026 originally created the RII can set up a retransmission timer. Thus, 3027 if an intermediate QNE decides to use the RII already contained in 3028 the message, it MUST NOT set up a retransmission timer, but rely on 3029 the retransmission timer set up by the QNE that inserted the RII. 3031 When receiving a message containing an RII object the node MUST send 3032 a RESPONSE if 3034 o The SCOPING flag is set ('next hop' scope), 3036 o The PROXY scope flag is set and the QNE is the P-QNE, or 3038 o This QNE is the last one on the path for the given session. 3040 and the QNE keeps per-session state for the given session. 3042 In the rare event that the QNE wants to request a response for a 3043 message that already included an RII, and this RII value conflicts 3044 with an existing RII value on the QNE, the node should interrupt the 3045 processing the message, and send an error message upstream to 3046 indicate an RII collision, and request a retry with a new RII value. 3048 5.3.3. BOUND_SESSION_ID 3050 As shown in the examples in Section 4, the QoS NSLP can relate 3051 multiple sessions together. It does this by including the SESSION_ID 3052 from one session in a BOUND_SESSION_ID object in messages in another 3053 session. 3055 When receiving a message with a BOUND_SESSION_ID object, a QNE MUST 3056 copy the BOUND_SESSION_ID object into all messages it sends for the 3057 same session. A QNE that stores per-session state MUST store the 3058 value of the BOUND_SESSION_ID. 3060 The BOUND_SESSION_ID is only indicative in nature. However, a QNE 3061 implementation may use BOUND_SESSION_ID information to optimize 3062 resource allocation, e.g., for bidirectional reservations. When 3063 receiving a tear down message (e.g., a RESERVE message with tear down 3064 semantic) for an aggregate reservation, it may use this information 3065 to initiate a tear down for end-to-end sessions bound to the 3066 aggregate. A QoS NSLP implementation MUST be ready to process more 3067 than one BOUND_SESSION_ID object within a single message. 3069 5.3.4. REFRESH_PERIOD 3071 Refresh timer management values are carried by the REFRESH_PERIOD 3072 object which has local significance only. At the expiration of a 3073 "refresh timeout" period, each QNE independently examines its state 3074 and sends a refreshing RESERVE message to the next QNE peer where it 3075 is absorbed. This peer-to-peer refreshing (as opposed to the QNI 3076 initiating a refresh which travels all the way to the QNR) allows 3077 QNEs to choose refresh intervals as appropriate for their 3078 environment. For example, it is conceivable that refreshing 3079 intervals in the backbone, where reservations are relatively stable, 3080 are much larger than in an access network. The "refresh timeout" is 3081 calculated within the QNE and is not part of the protocol; however, 3082 it must be chosen to be compatible with the reservation lifetime as 3083 expressed by the REFRESH_PERIOD, and an assessment of the reliability 3084 of message delivery. 3086 The details of timer management and timer changes (slew handling and 3087 so on) are identical to the ones specified in Section 3.7 of RFC 2205 3088 [RFC2205]. 3090 There are two time parameters relevant to each QoS NSLP state in a 3091 node: the refresh period R between generation of successive refreshes 3092 for the state by the neighbor node, and the local state's lifetime L. 3093 Each RESERVE message may contain a REFRESH_PERIOD object specifying 3094 the R value that was used to generate this (refresh) message. This R 3095 value is then used to determine the value for L when the state is 3096 received and stored. The values for R and L may vary from peer to 3097 peer. 3099 5.3.5. INFO_SPEC 3101 The INFO_SPEC object is carried by the RESPONSE and NOTIFY messages 3102 and it is used to report a successful, an unsuccessful, or an error 3103 situation. In case of an error situation the error messages SHOULD 3104 be generated even if no RII object is included in the RESERVE or in 3105 the QUERY messages. Note that when the TEAR flag is set in the 3106 RESERVE message an error situation SHOULD NOT trigger the generation 3107 of a RESPONSE message. 3109 Six classes of INFO_SPEC objects are identified and specified in 3110 Section 5.1.3.6. The message processing rules for each class are 3111 defined below. 3113 A RESPONSE message MUST carry INFO_SPEC objects towards the QNI. The 3114 RESPONSE message MUST be forwarded unconditionally up to the QNI. 3115 The actions that SHOULD be undertaken by the QNI that receives the 3116 INFO_SPEC object are specified by the local policy of the QoS model 3117 supported by this QNE. The default action is that the QNI that 3118 receives the INFO_SPEC object SHOULD not trigger any other QoS NSLP 3119 procedure. 3121 The Informational INFO_SPEC class MUST be generated by a by a 3122 stateful QoS NSLP QNE when an Informational error class is caught. 3123 The Informational INFO-SPEC object MUST be carried by a RESPONSE or a 3124 NOTIFY message. 3126 In case of an unidirectional reservation, the Success INFO_SPEC class 3127 MUST be generated by a stateful QoS NSLP QNR when a RESERVE message 3128 is received and the reservation state installation or refresh 3129 succeeded. In case of a bi-directional reservation the INFO-SPEC 3130 object SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE 3131 message is received and the reservation state installation or refresh 3132 succeeded. The Success INFO-SPEC object MUST be carried by a 3133 RESPONSE or a NOTIFY message. 3135 In case of an unidirectional reservation, the Protocol Error 3136 INFO_SPEC class MUST be generated by a stateful QoS NSLP QNE when a 3137 RESERVE or QUERY message is received by the QNE and a protocol error 3138 is caught. In case of a bi-directional reservation, the Protocol 3139 Error INFO_SPEC class SHOULD be generated by a stateful QoS NSLP QNE 3140 when a RESERVE or QUERY message is received by the QNE and a protocol 3141 error is caught. A RESPONSE message MUST carry this object, which 3142 MUST be forwarded unconditionally towards the upstream QNE that 3143 generated the RESERVE or QUERY message that triggered the generation 3144 of this INFO_SPEC object. The default action for a stateless QoS 3145 NSLP QNE that detects such an error is that none of the QoS NSLP 3146 objects SHOULD be processed and the RESERVE or QUERY message SHOULD 3147 be forwarded downstream. 3149 In case of an unidirectional reservation, the Transient Failure 3150 INFO_SPEC class MUST be generated by a stateful QoS NSLP QNE when a 3151 RESERVE or QUERY message is received by the QNE and one Transient 3152 failure error code is caught, or when an event happens that causes a 3153 transient error. In case of a bi-directional reservation, the 3154 Transient Failure INFO_SPEC class SHOULD be generated by a stateful 3155 QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE 3156 and one Transient failure error code is caught. 3158 A RESPONSE message MUST carry this object, which MUST be forwarded 3159 unconditionally towards the upstream QNE that generated the RESERVE 3160 or QUERY message that triggered the generation of this INFO_SPEC 3161 object. The transient RMF-related error MAY also be carried by a 3162 NOTIFY message. The default action is that the QNE that receives 3163 this INFO_SPEC object SHOULD re-trigger the retransmission of the 3164 RESERVE or QUERY message that triggered the generation of the 3165 INFO_SPEC object. The default action for a stateless QoS NSLP QNE 3166 that detects such an error is that none of the QoS NSLP objects 3167 SHOULD be processed and the RESERVE or QUERY message SHOULD be 3168 forwarded downstream. 3170 In case of an unidirectional reservation, the Permanent Failure 3171 INFO_SPEC class MUST be generated by a stateful QoS NSLP QNE when a 3172 RESERVE or QUERY message is received by a QNE and an internal or 3173 system error occured, or authorization failed. In case of a bi- 3174 directional reservation, the Permanent Failure INFO_SPEC class SHOULD 3175 be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY 3176 message is received by a QNE and an internal or system error occured, 3177 or authorization failed. A RESPONSE message MUST carry this object, 3178 which MUST be forwarded unconditionally towards the upstream QNE that 3179 generated the RESERVE or QUERY message that triggered this protocol 3180 error. The permanent RMF-related, the internal or system errors MAY 3181 also be carried by a NOTIFY message. The default action for a 3182 stateless QoS NSLP QNE that detects such an error is that none of the 3183 QoS NSLP objects SHOULD be processed and the RESERVE or QUERY message 3184 SHOULD be forwarded downstream. 3186 The QoS-specific error class may be used when errors outside the QoS 3187 NSLP itself occur that are related to the particular QoS Model being 3188 used. The processing rules of these errors are not specified in this 3189 document. 3191 5.3.6. SESSION_ID_LIST 3193 A SESSION_ID_LIST is carried in RESERVE messages. It is used in two 3194 cases, to refresh or two tear down the indicated sessions. A 3195 SESSION_ID_LIST carries information about sessions that should be 3196 refreshed or torn down, in addition to the main (primary) session 3197 indicated in the RESERVE. 3199 If the primary SESSION_ID is not understood, the SESSION_ID_LIST 3200 object MUST NOT be processed. 3202 When a stateful QNE goes through the SESSION_ID_LIST, if it finds one 3203 or more unknown SESSION ID values, it SHOULD construct an 3204 informational RESPONSE message back to the upstream stateful QNE with 3205 error code for unknown SESSION ID in SESSION_ID_LIST, and include all 3206 uknown SESSION IDs in a SESSION_ID_LIST. 3208 If the RESERVE is a tear, for each session in the SESSION_ID_LIST, 3209 the stateful QNE MUST inform the RMF that the reservation is no 3210 longer required. RSN values MUST also be interpreted in order to 3211 distinguish whether the tear down is valid, or whether it is refering 3212 to an old state, and, thus, should be silently discarded. 3214 If the RESERVE is a refresh, the stateful QNE MUST also process the 3215 RSN_LIST object as detailed in the next section. 3217 If the RESERVE is a tear, for each session in the SESSION_ID_LIST, 3218 the QNE MUST inform the RMF that the reservation is no longer 3219 required. RSN values MUST be interpreted. 3221 Note that a stateless QNE can not support summary or single reduced 3222 refreshes, and always needs full single refreshes. 3224 5.3.7. RSN_LIST 3226 An RSN_LIST MUST be carried in RESERVE messages when a QNE wants to 3227 perform a refresh or tear-down of several sessions with a single NSLP 3228 message. The RSN_LIST object MUST be populated with RSN values of 3229 the same sessions and in the same order as indicated in the 3230 SESSION_ID_LIST. Thus, entries in both objects at position X refer 3231 to the same session. 3233 If the primary session and RSN reference in the RESERVE were not 3234 understood, the stateful QNE MUST NOT process the RSN_LIST. Instead 3235 an error RESPONSE SHOULD be sent back to the upstream stateful QNE. 3237 On receiving an RSN_LIST object, the stateful QNE should check 3238 whether the number of items in the SESSION_ID_LIST and RSN_LIST 3239 objects match. If there is a mismatch, the stateful QNE SHOULD send 3240 back a protocol error indicating a bad value in the object. 3242 While matching the RSN_LIST values to the SESSION_ID_LIST values, if 3243 one or more RSN values in the RSN_LIST are not in synch with the 3244 local values, the stateful QNE SHOULD construct an informational 3245 RESPONSE message with an error code for RSN mismatch in RSN_LIST. 3246 The stateful QNE MUST include the erroneous SESSION ID and RSN values 3247 in SESSION_ID_LIST and RSN_LIST objects in the RESPONSE. 3249 If no errors were found in processing the RSN_LIST, the stateful QNE 3250 refreshes the reservation states of all sessions, both the primary 3251 single session indicated in the refresh, and all sessions in the 3252 SESSION_ID_LIST. 3254 For each successfully processed session in the RESERVE, the stateful 3255 QNE performs a refresh of the reservation state. Thus, even if some 3256 sessions were not in synch, the remaining sessions in the 3257 SESSION_ID_LIST and RSN_LIST are refreshed. 3259 5.3.8. QSPEC 3261 The contents of the QSPEC depends on the QoS model being used. A 3262 template for QSPEC objects can be found in [I-D.ietf-nsis-qspec]. 3264 Upon reception, the complete QSPEC is passed to the Resource 3265 Management Function (RMF), along with other information from the 3266 message necessary for the RMF processing. A QNE may also receive an 3267 INFO_SPEC that includes a partial or full QSPEC. This will also be 3268 passed to the RMF. 3270 5.4. Message Processing Rules 3272 This section provides rules for message processing. Not all possible 3273 error situations are considered. A general rule for dealing with 3274 erroneous messages is that a node should evaluate the situation 3275 before deciding how to react. There are two ways to react to 3276 erroneous messages: 3278 a) Silently drop the message, or 3280 b) Drop the message, and reply with an error code to the sender. 3282 The default behavior, in order to protect the QNE from a possible DoS 3283 attack, is to silently drop the message. However, if the QNE is able 3284 to authenticate the sender, e.g., through GIST, the QNE may send a 3285 proper error message back to the neighbor QNE in order to let it know 3286 that there is an inconsistency in the states of adjacent QNEs. 3288 5.4.1. RESERVE Messages 3290 The RESERVE message is used to manipulate QoS reservation state in 3291 QNEs. A RESERVE message may create, refresh, modify or remove such 3292 state. A QNE sending a RESERVE MAY require a response to be sent by 3293 including a Request Identification Information (RII) object, see 3294 Section 5.3.2. 3296 RESERVE messages MUST only be sent towards the QNR. A QNE that 3297 receives a RESERVE message checks the message format. In case of 3298 malformed messages, the QNE MAY send a RESPONSE message with the 3299 appropriate INFO_SPEC. 3301 Before performing any state changing actions a QNE MUST determine 3302 whether the request is authorized. The way to do this check depends 3303 on the authorization model being used. 3305 When the RESERVE is authorized, a QNE checks the COMMON_HEADER flags. 3306 If the TEAR flag is set, the message is a tearing RESERVE which 3307 indicates complete QoS NSLP state removal (as opposed to a 3308 reservation of zero resources). On receiving such a RESERVE message 3309 the QNE MUST inform the RMF that the reservation is no longer 3310 required. The RSN value MUST be processed. After this, there are 3311 two modes of operation: 3313 1. If the tearing RESERVE did not include an RII, i.e., the QNI did 3314 not want a confirmation, the QNE SHOULD remove the QoS NSLP state. 3315 It MAY signal to GIST (over the API) that reverse path state for this 3316 reservation is no longer required. Any errors in processing the 3317 tearing RESERVE SHOULD NOT be sent back towards the QNI since the 3318 upstream QNEs will already have removed their session states, thus, 3319 they are unable to do anything to the error. 3321 2. If an RII was included, the stateful QNE SHOULD still keep the 3322 NSLP operational state until a RESPONSE for the tear going towards 3323 the QNI is received. This operational state SHOULD be kept for one 3324 refresh interval, after which the NSLP operational state for the 3325 session is removed. Depending on the QoS model, the tear message MAY 3326 include a QSPEC to further specify state removal. If the QoS model 3327 requires a QSPEC, and none is provided, the QNE SHOULD reply with an 3328 error message, and SHOULD NOT remove the reservation. 3330 If the tearing RESERVE includes a QSPEC, but none is required by the 3331 QoS model, the QNE MAY silently discard the QSPEC and proceed as if 3332 it did not exist in the message. In general, a QoS NSLP 3333 implementation should carefully consider, when an error message 3334 should be sent, and when not. If the tearing RESERVE did not include 3335 an RII, then the upstream QNE has removed the RMF and NSLP states, 3336 and will not be able to do anything to the error. If an RII was 3337 included, the upstream QNE may still have the NSLP operational state, 3338 but no RMF state. 3340 If a QNE receives a tearing RESERVE for a session it still has the 3341 operational state, but the RMF state was removed, the QNE SHOULD 3342 accept the message and forward it downstream as if all is well. 3344 If the tearing RESERVE includes a SESSION_ID_LIST, the stateful QNE 3345 MUST process the object as described earlier in this document, and 3346 for each identified session, indicate to the RMF that the reservation 3347 is no longer required. 3349 If a QNE receives a refreshing RESERVE for a session it still has the 3350 operational state, but the RMF state was removed, the QNE MUST 3351 silently drop the message and not forward it downstream. 3353 As discussed in Section 5.2.5.2, to avoid incorrect removal of state 3354 after a rerouting event, a node receiving a RESERVE message with the 3355 TEAR flag set which does not come from the current peer QNE, 3356 identified by its SII, MUST be ignored and MUST NOT be forwarded. 3358 If the QNE has reservations which are bound and dependent to this 3359 session (they contain the SESSION_ID of this session in their 3360 BOUND_SESSION_ID object and use Binding Code: 0x04), it MUST send a 3361 NOTIFY message for each of the reservations with an appropriate 3362 INFO_SPEC. If the QNE has reservations which are bound, but which 3363 they are not dependent to this session (the Binding Code in the 3364 BOUND_SESSION_ID object has one of the values: 0x01, 0x02, 0x03), it 3365 MAY send a NOTIFY message for each of the reservations with an 3366 appropriate INFO_SPEC. The QNE MAY elect to send RESERVE messages 3367 with the TEAR flag set for these reservations. 3369 The default behavior of a QNE that receives a RESERVE with a 3370 SESSION_ID for which it already has state installed but with a 3371 different flow ID is to replace the existing reservation (and tear 3372 down the reservation on the old branch if the RESERVE is received 3373 with a different SII). 3375 In some cases, this may not be the desired behavior. In that case, 3376 the QNI or a QNE MAY set the REPLACE flag in the common header to 3377 zero to indicate that the new session does not replace the existing 3378 one. 3380 A QNE that receives a RESERVE with the REPLACE flag set to zero but 3381 with the same SII, will indicate REPLACE=0 to the RMF (where it will 3382 be used for the resource handling). Furthermore, if the QNE 3383 maintains a QoS NSLP state then it will also add the new flow ID in 3384 the QoS NSLP state. If the SII is different, this means that the QNE 3385 is a merge point. In that case, in addition to the operations 3386 specified above, the value REPLACE=0 is also indicating that a 3387 tearing RESERVE SHOULD NOT be sent on the old branch. 3389 When a QNE receives a RESERVE message with an unknown SESSION_ID and 3390 this message contains no QSPEC because it was meant as a refresh then 3391 the node MUST send a RESPONSE message with an INFO_SPEC that 3392 indicates a missing QSPEC to the upstream peer ("Full QSPEC 3393 required"). The upstream peer SHOULD send a complete RESERVE (i.e., 3394 one containing a QSPEC) on the new path (new SII). 3396 At a QNE, resource handling is performed by the RMF. For sessions 3397 with the REPLACE flag set to zero, we assume that the QoS model 3398 includes directions to deal with resource sharing. This may include, 3399 adding the reservations, or taking the maximum of the two or more 3400 complex mathematical operations. 3402 This resource handling mechanism in the QoS Model is also applicable 3403 to sessions with different SESSION_ID but related through the 3404 BOUND_SESSION_ID object. Session replacement is not an issue here, 3405 but the QoS Model may specify whether to let the sessions that are 3406 bound together share resources on common links or not. 3408 Finally, it is possible that a RESERVE is received with no QSPEC at 3409 all. This is the case of a reduced refresh. In this case, rather 3410 than sending a refreshing RESERVE with the full QSPEC, only the 3411 SESSION_ID and the RSN are sent to refresh the reservation. Note 3412 that this mechanism just reduces the message size (and probably eases 3413 processing). One RESERVE per session is still needed. Such a 3414 reduced refresh may further include a SESSION_ID_LIST and RSN_LIST, 3415 which indicate further sessions to be refreshed along the primary 3416 session. The processing of these objects were described earlier in 3417 this document. 3419 If the REPLACE flag is set, the QNE SHOULD update the reservation 3420 state according to the QSPEC contained in the message (if the QSPEC 3421 is missing the QNE SHOULD indicate this error by replying with a 3422 RESPONSE containing the corresponding INFO_SPEC "Full QSPEC 3423 required"). It MUST update the lifetime of the reservation. If the 3424 REPLACE flag is not set, a QNE SHOULD NOT remove the old reservation 3425 state if the SII which is passed by GIST over the API is different 3426 than the SII that was stored for this reservation. The QNE MAY elect 3427 to keep sending refreshing RESERVE messages. 3429 If a stateful QoS NSLP QNE receives a RESERVE message with the BREAK 3430 flag set then the BREAK flag of new generated messages (e.g., RESERVE 3431 or RESPONSE) MUST be set. When a stateful QoS NSLP QNE receives a 3432 RESERVE message with the BREAK flag not set then the IP-TTL and 3433 Original-TTL values in GIST RecvMessage primitive MUST be monitored. 3434 If they differ, it is RECOMMENDED to set the BREAK flag in new 3435 generated messages (e.g., RESERVE or RESPONSE). In situations where 3436 a QNE or a domain is able to provide QoS using other means, see 3437 Section 3.3.5, then the BREAK flag SHOULD NOT be set. 3439 If the RESERVE message included an RII, and any of the following are 3440 true, the QNE MUST send a RESPONSE message: 3442 o If the QNE is configured, for a particular session, to be a QNR, 3444 o the SCOPING flag is set, 3446 o the Proxy scope flag is set and the QNE is a P-QNE, or 3448 o the QNE is the last QNE on the path to the destination. 3450 When a QNE receives a RESERVE message, its processing may involve 3451 sending out another RESERVE message. 3453 If a QNE has received a RESPONSE mandating the use of full refreshes 3454 from its downstream peer for a session, the QNE MUST continue to use 3455 full refresh messages. 3457 If the session of this message is bound to another session, then the 3458 RESERVE message SHOULD include the SESSION_ID of that other session 3459 in a BOUND_SESSION_ID object. In the situation of aggregated 3460 tunnels, the aggregated session MAY not include the SESSION_ID of its 3461 bound sessions in BOUND_SESSION_ID(s). 3463 In case of receiver-initiated reservations, the RESERVE message must 3464 follow the same path that has been followed by the QUERY message. 3465 Therefore, GIST is informed, over the QoS NSLP/GIST API, to pass the 3466 message upstream, i.e., by setting GIST "D" flag, see GIST 3467 [I-D.ietf-nsis-ntlp]. 3469 The QNE MUST create a new RESERVE and send it to its next peer, when: 3471 - A new resource set up was done, 3473 - A new resource set up was not done, but the QOSM still defines that 3474 a RESERVE must be propagated, 3476 - The RESERVE is a refresh and includes new MRI, or 3478 - If the RESERVE-INIT flag is included in an arrived QUERY. 3480 If the QNE sent out a refresh RESERVE with the ACK-REQ-flag set, and 3481 did not receive a RESPONSE from its immediate stateful peer within 3482 the retransmission period of QOSNSLP_RETRY_MAX, the QNE SHOULD send a 3483 NOTIFY to its immediate upstream sateful peer and indicate "Path 3484 truncated - Next peer dead" in the INFO_SPEC. The ACK-REQ-flag 3485 SHOULD NOT be added to a RESERVE that already include an RII object, 3486 since a confirmation from the QNR has already been requested. 3488 Finally, if a received RESERVE requested acknowledgement through the 3489 ACK-REQ-flag in the COMMON HEADER flags and the processing of the 3490 message was successul, the stateful QNE SHOULD send back a RESPONSE 3491 with an INFO_SPEC carrying the acknowledgement success code. The QNE 3492 MAY include the ACK-REQ-flag in the next refresh message it will send 3493 for the session. The use of the ACK-REQ-flag for diagnostics 3494 purposes is a policy issue, i.e., using an acknowledged refresh 3495 message as a hint to further probe the end-to-end path can be used 3496 simply as a hint to check that the end-to-end path is still intact. 3498 5.4.2. QUERY Messages 3500 A QUERY message is used to request information about the data path 3501 without making a reservation. This functionality can be used to 3502 'probe' the network for path characteristics or for support of 3503 certain QoS models, or for initiating a receiver-initiated 3504 reservation. 3506 A QNE sending a QUERY indicates a request for a response by including 3507 a Request Identification Information (RII) object, see Section 5.3.2. 3508 A request to initiate a receiver-initiated reservation is done 3509 through the RESERVE-INIT flag, see Section 5.1.2.2. 3511 When a QNE receives a QUERY message the QSPEC is passed to the RMF 3512 for processing. The RMF may return a modified QSPEC that is used in 3513 any QUERY or RESPONSE message sent out as a result of the QUERY 3514 processing. 3516 When processing a QUERY message, a QNE checks whether the RESERVE- 3517 INIT flag is set. If the flag is set, the QUERY is used to install 3518 reverse path state. In this case, if the QNE is not the QNI, it 3519 creates a new QUERY message to send downstream. If the QUERY 3520 contained a QSPEC, it MUST be passed to the RMF where it may be 3521 modified by the QoS Model specific QUERY processing. If the QNE is 3522 the QNI, the QNE creates a RESERVE message, which contains a QSPEC 3523 received from the RMF and which may be based on the received QSPEC. 3524 If this node was not expecting to perform a receiver-initiated 3525 reservation then an error MUST be sent back along the path. 3527 If an RII object is present, and if the QNE is the QNR, the SCOPING 3528 flag is set or the PROXY scope flag is set and the QNE is a P-QNE, 3529 the QNE MUST generate a RESPONSE message and pass it back along the 3530 reverse of the path used by the QUERY. 3532 In other cases, the QNE MUST generate a QUERY message which is then 3533 forwarded further along the path using the same MRI, Session ID and 3534 Direction as provided when the QUERY was received over the GIST API. 3536 The QSPEC to be used is that provided by the RMF as described 3537 previously. When generating a QUERY to send out to pass the query 3538 further along the path, the QNE MUST copy the RII object (if present) 3539 unchanged into the new QUERY message. A QNE that is also interested 3540 in the response to the query keeps track of the RII to identify the 3541 RESPONSE when it passes through it. 3543 Note that QUERY messages with the RESERVE-INIT flag set MUST be 3544 answered by the QNR. This feature may be used, e.g., following 3545 handovers, to set up new path state in GIST, and request the other 3546 party to send a RESERVE back on this new GIST path. 3548 If a stateful QoS NSLP QNE receives a QUERY message with the RESERVE- 3549 INIT flag and BREAK flag set then the BREAK flag of new generated 3550 messages (e.g., QUERY, RESERVE or RESPONSE) MUST be set. When a 3551 stateful QoS NSLP QNE receives a QUERY message with the RESERVE- INIT 3552 flag set and BREAK flag not set then the IP-TTL and Original-TTL 3553 values in GIST RecvMessage primitive MUST be monitored. If they 3554 differ, it is RECOMMENDED to set the BREAK flag in new generated 3555 messages (e.g., QUERY, RESERVE or RESPONSE). In situations where a 3556 QNE or a domain is able to provide QoS using other means, see Section 3557 3.3.5, then the BREAK flag SHOULD NOT be set. 3559 Finally, if a received QUERY requested acknowledgement through the 3560 ACK-REQ-flag in the COMMON HEADER flags and the processing of the 3561 message was successul, the stateful QNE SHOULD send back a RESPONSE 3562 with an INFO_SPEC carrying the acknowledgement success code. 3564 5.4.3. RESPONSE Messages 3566 The RESPONSE message is used to provide information about the result 3567 of a previous QoS NSLP message, e.g., confirmation of a reservation 3568 or information resulting from a QUERY. The RESPONSE message does not 3569 cause any state to be installed, but may cause state(s) to be 3570 modified, e.g., if the RESPONSE contains information about an error. 3572 A RESPONSE message MUST be sent when the QNR processes a RESERVE or 3573 QUERY message containing an RII object or if the QNE receives a 3574 scoped RESERVE or a scoped QUERY. In this case, the RESPONSE message 3575 MUST contain the RII object copied from the RESERVE or the QUERY. 3576 Also, if there is an error in processing a received RESERVE, a 3577 RESPONSE is sent indicating the nature of the error. In this case, 3578 the RII and RSN, if available, MUST be included in the RESPONSE. 3580 On receipt of a RESPONSE message containing an RII object, the 3581 stateful QoS NSLP QNE MUST attempt to match it to the outstanding 3582 response requests for that signaling session. If the match succeeds, 3583 then the RESPONSE MUST NOT be forwarded further along the path if it 3584 contains an INFO_SPEC class informational or success. If the QNE did 3585 not insert this RII itself, if must forward the RESPONSE to the next 3586 peer. Thus, for RESPONSES indicating success, forwarding should only 3587 stop if the QNE inserted the RII by itself, If the RESPONSE carries 3588 an INFO_SPEC indicating an error, forwarding SHOULD continue upstream 3589 towards the QNI by using RSNs as described in the next paragraph. 3591 On receipt of a RESPONSE message containing an RSN object, a stateful 3592 QoS NSLP QNE MUST compare the RSN to that of the appropriate 3593 signaling session. If the match succeeds then the INFO_SPEC MUST be 3594 processed. If the INFO_SPEC object is used to notify errors then the 3595 node MUST use the stored upstream peer RSN value, associated with the 3596 same session, and forward the RESPONSE message further along the path 3597 towards the QNI. 3599 If the INFO_SPEC is not used to notify error situations, see above, 3600 then if the RESPONSE message carries an RSN, the message MUST NOT be 3601 forwarded further along the path. 3603 If there is no match for RSN, the message SHOULD be silently dropped. 3605 On receipt of a RESPONSE message containing neither an RII nor an RSN 3606 object, the RESPONSE MUST NOT be forwarded further along the path. 3608 In the typical case RESPONSE messages do not change the states 3609 installed in intermediate QNEs. However, depending on the QoS model, 3610 there may be situations where states are affected, e.g., 3612 - if the RESPONSE includes an INFO_SPEC describing an error situation 3613 resulting in reservations to be removed, or 3615 - the QoS model allows a QSPEC to define [min,max] limits on the 3616 resources requested, and downstream QNEs gave less resources than 3617 their upstream nodes, which means that the upstream nodes may release 3618 a part of the resource reservation. 3620 If a stateful QoS NSLP QNE receives a RESPONSE message with the BREAK 3621 flag set then the BREAK flag of new generated message (e.g., 3622 RESPONSE) MUST be set. 3624 5.4.4. NOTIFY Messages 3626 NOTIFY messages are used to convey information to a QNE 3627 asynchronously. NOTIFY messages do not cause any state to be 3628 installed. The decision to remove state depends on the QoS model. 3629 The exact operation depends on the QoS model. A NOTIFY message does 3630 not directly cause other messages to be sent. NOTIFY messages are 3631 sent asynchronously, rather than in response to other messages. They 3632 may be sent in either direction (upstream or downstream). 3634 A special case of synchronous NOTIFY is when the upstream QNE asked 3635 to use reduced refresh by setting the appropriate flag in the 3636 RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY 3637 and a proper INFO_SPEC code whether the QNE agrees to use reduced 3638 refresh between the upstream QNE. 3640 The Transient error code 0x07 "Reservation preempted" is sent to the 3641 QNI whose resources were preempted. The NOTIFY message carries 3642 information to the QNI that one QNE no longer has a reservation for 3643 the session. It is up to the QNI to decide what to do based on the 3644 QoS Model being used. The QNI would normally tear down the preempted 3645 reservation by sending a RESERVE with the TEAR flag set using the SII 3646 of the preempted reservation. However, the QNI can follow other 3647 procedures as specified in its QoS Model. More discussion on 3648 preemption can be found in the QSPEC Template [I-D.ietf-nsis-qspec] 3649 and the individual QoS Model specifications. 3651 6. IANA Considerations 3653 This section provides guidance to the Internet Assigned Numbers 3654 Authority (IANA) regarding registration of values related to the QoS 3655 NSLP, in accordance with BCP 26 RFC 2434 [RFC2434]. 3657 The QoS NSLP requires IANA to create a number of new registries: 3659 - QoS NSLP Message Types 3661 - QoS NSLP Binding Codes 3663 - QoS NSLP Error Classes and Error Codes 3665 It also requires registration of new values in a number of 3666 registries: 3668 - NSLP Object Types - GIST NSLP-ID - Router Alert Option Values (IPv4 3669 and IPv6) 3671 6.1. QoS NSLP Message Type 3673 The QoS NSLP Message Type is an 8 bit value. This specification 3674 defines four QoS NSLP message types, which form the initial contents 3675 of this registry: RESERVE (0x01), QUERY (0x02), RESPONSE (0x03) and 3676 NOTIFY (0x04). 3678 The value 0 is reserved. Values 1-239 are to be allocated by 3679 Standards Action. Values 240 to 255 are for Experimental/Private 3680 Use. 3682 When a new message type is defined, any message flags used with it 3683 must also be defined. 3685 6.2. NSLP Message Objects 3687 [Delete this part if already done by another NSLP: 3689 A new registry is to be created for NSLP Message Objects. This is a 3690 12-bit field (giving values from 0 to 4095). This registry is shared 3691 between a number of NSLPs. Allocation policies are as follows: 3693 0-1023: Standards Action 3695 1024-1999: Specification Required 3697 2000-2047: Private/Experimental Use 3699 2048-4095: Reserved 3701 When a new object is defined, the extensbility bits (A/B) must also 3702 be defined.] 3704 This document defines eleven new NSLP objects. These are described 3705 in Section 5.1.3: RII (0x01), RSN (0x02), REFRESH_PERIOD (0x03), 3706 BOUND_SESSION_ID (0x04), PACKET_CLASSIFIER (0x05), INFO_SPEC (0x06), 3707 SESSION ID LIST (0x07), RSN LIST (0x08), MSG_ID (0x09), BOUND_MSG_ID 3708 (0x0A), and QSPEC (0x0B). 3710 Values are to be assigned from the Standards Action required section 3711 of the NSLP Object Type registry. 3713 6.3. QoS NSLP Binding Codes 3715 A new registry is to be created for the 8-bit Binding Codes used in 3716 the BOUND_SESSION_ID object. The initial values for this registry 3717 are listed in Section 5.1.3.4. 3719 Value 0 is reserved. Values 1 to 127 are to be assigned based on a 3720 policy of Specification Required. Values 128 to 159 are for 3721 Exerimental/Private Use. Other values are Reserved. 3723 6.4. QoS NSLP Error Classes and Error Codes 3725 In addition Error Classes and Error Codes for the INFO_SPEC object 3726 are defined. These are described in Section 5.1.3.6. 3728 The Error Class is 4-bits in length. The initial values are: 3730 0: Reserved 3732 1: Informational 3734 2: Success 3736 3: Protocol Error 3737 4: Transient Failure 3739 5: Permanent Failure 3741 6: QoS Model Error 3743 7-15: Reserved 3745 The Error Code is 16 bits in length. Each Error Codes are assigned 3746 within a particular Error Class. This requires the creation of a 3747 registry for Error Codes in each Error Class. The error code 0 in 3748 each class is Reserved. 3750 Policies for the error code registries are as follows: 3752 0-8191: Standards Action 3754 8192-12287: Specification Required 3756 12288-16383: Experimental/Private Use 3758 16384-65536: Reserved 3760 The initial assignments for the Error Code registries are given in 3761 section 5.1.3.6. 3763 6.5. QoS NSLP Error Source Identifiers 3765 Section 5.1.3.4 defines Error Source Identifiers, the type of which 3766 is identified by a 4 bit value. The value 0 is reserved, all other 3767 values are assigned on a basis of Specification Required, except for 3768 14 and 15 which are for Experimental/Private Use. 3770 Initial assignments are given in section 5.1.3.4. 3772 6.6. NSLP IDs and Router Alert Option Values 3774 This specification defines an NSLP for use with GIST. Furthermore it 3775 specifies that a number of NSLP-ID values are used for the support of 3776 bypassing intermediary nodes. Consequently, new identifiers must be 3777 assigned for them from the GIST NSLP identifier registry. The QoS 3778 NSLP requires that 32 NSLP-ID values be assigned, corresponding to 3779 QoS NSLP Aggregation Levels 0 to 31. 3781 The GIST specification also requires that NSLP-IDs be associated with 3782 specific Router Alert Option (RAO) values (although multiple NSLP-IDs 3783 may be associated with the same value). For the purposes of the QoS 3784 NSLP, each of its NSLP-ID values should be associated with a 3785 different RAO value. This requires that a block of 32 new IPv4 RAO 3786 values and a block of 32 new IPv6 RAO values be assigned, 3787 corresponding to QoS NSLP Aggregation Levels 0 to 31. 3789 7. Security Considerations 3791 The security requirement for the QoS NSLP is to protect the signaling 3792 exchange for establishing QoS reservations against identified 3793 security threats. For the signaling problem as a whole, these 3794 threats have been outlined in NSIS threats [RFC4081]; the NSIS 3795 framework [RFC4080] assigns a subset of the responsibility to GIST 3796 and the remaining threats need to be addressed by NSLPs. The main 3797 issues to be handled can be summarized as: 3799 Authorization: 3801 The QoS NSLP must assure that the network is protected against theft- 3802 of-service by offering mechanisms to authorize the QoS reservation 3803 requester. A user requesting a QoS reservation might want proper 3804 resource accounting and protection against spoofing and other 3805 security vulnerabilities which lead to denial of service and 3806 financial loss. In many cases authorization is based on the 3807 authenticated identity. The authorization solution must provide 3808 guarantees that replay attacks are either not possible or limited to 3809 a certain extent. Authorization can also be based on traits which 3810 enables the user to remain anonymous. Support for user identity 3811 confidentiality can be accomplished. 3813 Message Protection: 3815 Signaling message content should be protected against modification, 3816 replay, injection and eavesdropping while in transit. Authorization 3817 information, such as authorization tokens, need protection. This 3818 type of protection at the NSLP layer is necessary to protect messages 3819 between NSLP nodes. 3821 Rate Limitation: 3823 QNEs should perform rate limiting on the refresh messages that they 3824 send. An attacker could send erroneous messages on purpose, forcing 3825 the QNE to constantly reply with an error message. Authentication 3826 mechanisms would help in figuring out if error situations should be 3827 reported to the sender, or silently ignored. If the sender is 3828 authenticated, the QNE should reply promptly. 3830 Prevention of Denial of Service Attacks: 3832 GIST and QoS NSLP nodes have finite resources (state storage, 3833 processing power, bandwidth). The protocol mechanisms s in this 3834 document try to minimize exhaustion attacks against these resources 3835 when performing authentication and authorization for QoS resources. 3837 To some extent the QoS NSLP relies on the security mechanisms 3838 provided by GIST which by itself relies on existing authentication 3839 and key exchange protocols. Some signaling messages cannot be 3840 protected by GIST and hence should be used with care by the QoS NSLP. 3841 An API must ensure that the QoS NSLP implementation is aware of the 3842 underlying security mechanisms and must be able to indicate which 3843 degree of security is provided between two GIST peers. If a level of 3844 security protection for QoS NSLP messages is required which goes 3845 beyond the security offered by GIST or underlying security 3846 mechanisms, additional security mechanisms described in this document 3847 must be used. The different usage environments and the different 3848 scenarios where NSIS is used make it very difficult to make general 3849 statements without reducing its flexibility. 3851 7.1. Trust Relationship Model 3853 This specification is based on a model which requires trust between 3854 neighboring NSLP nodes to establish a chain-of-trust along the QoS 3855 signaling path. The model is simple to deploy, was used in previous 3856 QoS authorization environments (such as RSVP) and seems to provide 3857 sufficiently strong security properties. We refer to this model as 3858 the New Jersey Turnpike. 3860 On the New Jersey Turnpike, motorists pick up a ticket at a toll 3861 booth when entering the highway. At the highway exit the ticket is 3862 presented and payment is made at the toll booth for the distance 3863 driven. For QoS signaling in the Internet this procedure is roughly 3864 similar. In most cases the data sender is charged for transmitted 3865 data traffic where charging is provided only between neighboring 3866 entities. 3868 +------------------+ +------------------+ +------------------+ 3869 | Network | | Network | | Network | 3870 | X | | Y | | Z | 3871 | | | | | | 3872 | -----------> -----------> | 3873 | | | | | | 3874 | | | | | | 3875 +--------^---------+ +------------------+ +-------+----------+ 3876 | . 3877 | . 3878 | v 3879 +--+---+ Data Data +--+---+ 3880 | Node | ==============================> | Node | 3881 | A | Sender Receiver | B | 3882 +------+ +------+ 3884 Legend: 3886 ----> Peering relationship which allows neighboring 3887 networks/entities to charge each other for the 3888 QoS reservation and data traffic 3890 ====> Data flow 3892 .... Communication to the end host 3894 Figure 42: New Jersey Turnpike Model 3896 The model shown in Figure 42 uses peer-to-peer relationships between 3897 different administrative domains as a basis for accounting and 3898 charging. As mentioned above, based on the peering relationship a 3899 chain-of-trust is established. There are several issues which come 3900 to mind when considering this type of model: 3902 o The model allows authorization on a request basis or on a per- 3903 session basis. Authorization mechanisms are elaborated in Section 3904 4.9. The duration for which the QoS authorization is valid needs to 3905 be controlled. Combining the interval with the soft-state interval 3906 is possible. Notifications from the networks also seem to be viable 3907 approach. 3909 o The price for a QoS reservation needs to be determined somehow and 3910 communicated to the charged entity and to the network where the 3911 charged entity is attached. Protocols providing Advice of Charge 3912 functionality are out of scope. 3914 o This architecture is simple enough to allow a scalable solution 3915 (ignoring reverse charging, multicast issues and price distribution). 3917 Charging the data sender as performed in the model simplifies 3918 security handling by demanding only peer-to-peer security protection. 3919 Node A would perform authentication and key establishment. The 3920 established security association (together with the session key) 3921 would allow the user to protect QoS signaling messages. The identity 3922 used during the authentication and key establishment phase would be 3923 used by Network X (see Figure 42) to perform the so-called policy- 3924 based admission control procedure. In our context this user 3925 identifier would be used to establish the necessary infrastructure to 3926 provide authorization and charging. Signaling messages later 3927 exchanged between the different networks are then also subject to 3928 authentication and authorization. The authenticated entity thereby 3929 is, however, the neighboring network and not the end host. 3931 The New Jersey Turnpike model is attractive because of its 3932 simplicity. S. Schenker et. al. [shenker] discuss various accounting 3933 implications and introduced the edge pricing model. The edge pricing 3934 model shows similarity to the model described in this section with 3935 the exception that mobility and the security implications itself are 3936 not addressed. 3938 7.2. Authorization Model Examples 3940 Various authorization models can be used in conjunction with the QoS 3941 NSLP. 3943 7.2.1. Authorization for the Two Party Approach 3945 The two party approach (Figure 43) is conceptually the simplest 3946 authorization model. 3948 +-------------+ QoS request +--------------+ 3949 | Entity |----------------->| Entity | 3950 | requesting | | authorizing | 3951 | resource |granted / rejected| resource | 3952 | |<-----------------| request | 3953 +-------------+ +--------------+ 3954 ^ ^ 3955 +...........................+ 3956 compensation 3958 Figure 43: Two party approach 3960 In this example the authorization decision only involves the two 3961 entities, or makes use of previous authorization using an out-of-band 3962 mechanism to avoid the need for active participation of an external 3963 entity during the NSIS protocol execution. 3965 This type of model may be applicable, e.g., between two neighboring 3966 networks (inter-domain signaling) where a long-term contract (or 3967 other out-of-band mechanisms) exists to manage charging and provides 3968 sufficient information to authorize individual requests. 3970 7.2.2. Token-based Three Party Approach 3972 An alternative approach makes use of tokens, such as those described 3973 in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the 3974 Open Settlement Protocol [osp]. Authorization tokens are used to 3975 associate two different signaling protocols runs (e.g., SIP and NSIS) 3976 and their authorization decision with each other. The latter is a 3977 form of assertion or trait. As an example, with the authorization 3978 token mechanism, some form of authorization is provided by the SIP 3979 proxy, which acts as the resource authorizing entity in Figure 44. 3980 If the request is authorized, then the SIP signaling returns an 3981 authorization token which can be included in the QoS signaling 3982 protocol messages to refer to the previous authorization decision. 3983 The tokens themselves may take a number of different forms, some of 3984 which may require the entity performing the QoS reservation to query 3985 external state. 3987 Authorization 3988 Token Request +--------------+ 3989 +-------------->| Entity C | financial settlement 3990 | | authorizing | <..................+ 3991 | | resource | . 3992 | +------+ request | . 3993 | | +--------------+ . 3994 | | . 3995 | |Authorization . 3996 | |Token . 3997 | | . 3998 | | . 3999 | | . 4000 | | QoS request . 4001 +-------------+ + Authz. Token +--------------+ . 4002 | Entity |----------------->| Entity B | . 4003 | requesting | | performing | . 4004 | resource |granted / rejected| QoS | <..+ 4005 | A |<-----------------| reservation | 4006 +-------------+ +--------------+ 4008 Figure 44: Token based three party approach 4010 For the digital money type of systems (e.g., OSP tokens), the token 4011 represents a limited amount of credit. So, new tokens must be sent 4012 with later refresh messages once the credit is exhausted. 4014 7.2.3. Generic Three Party Approach 4016 Another method is for the node performing the QoS reservation to 4017 delegate the authorization decision to a third party, as illustrated 4018 in Figure 45. The authorization decision may be performed on a per- 4019 request basis, periodically, or on a per-session basis. 4021 +--------------+ 4022 | Entity C | 4023 | authorizing | 4024 | resource | 4025 | request | 4026 +-----------+--+ 4027 ^ | 4028 QoS | | QoS 4029 authz| |authz 4030 req.| | res. 4031 QoS | v 4032 +-------------+ request +--+-----------+ 4033 | Entity |----------------->| Entity B | 4034 | requesting | | performing | 4035 | resource |granted / rejected| QoS | 4036 | A |<-----------------| reservation | 4037 +-------------+ +--------------+ 4039 Figure 45: Three party approach 4041 7.3. Computing the Authorization Decision 4043 Whenever an authorization decision has to be made then there is the 4044 question which information serves as an input to the authorizing 4045 entity. The following information items have been mentioned in the 4046 past for computing the authorization decision (in addition to the 4047 authenticated identity): 4049 Price 4051 QoS objects 4053 Policy rules 4055 Policy rules include attributes like time of day, subscription to 4056 certain services, membership, etc. into consideration when computing 4057 an authorization decision. 4059 The policies used to make the authorization are outside the scope of 4060 this document and implementation/deployment specific. 4062 8. Acknowledgments 4064 The authors would like to thank Eleanor Hepworth, Ruediger Geib, 4065 Roland Bless, Nemeth Krisztian, Markus Ott, Mayi Zoumaro-Djayoon, 4066 Martijn Swanink, and Ruud Klaver for their useful comments. Roland, 4067 especially, has done deep reviews of the document, making sure the 4068 protocol is well defined. Bob Braden provided helpful comments and 4069 guidance which were gratefully received. 4071 9. Contributors 4073 This draft combines work from three individual drafts. The following 4074 authors from these drafts also contributed to this document: Robert 4075 Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia 4076 Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and 4077 Maarten Buechli (Dante) and Eric Waegeman (Alcatel). In addition, 4078 Roland Bless has contributed considerable amounts of text all along 4079 the writing of this specification. 4081 Sven Van den Bosch was the first editor of the draft. Since version 4082 06 of the draft, Jukka Manner has taken the editorship. Yacine El 4083 Mghazli (Alcatel) contributed text on AAA. Charles Shen and Henning 4084 Schulzrinne suggested the use of the reason field in the 4085 BOUND_SESSION_ID. 4087 10. References 4089 10.1. Normative References 4091 [I-D.ietf-nsis-ntlp] 4092 Schulzrinne, H. and R. Hancock, "GIST: General Internet 4093 Signalling Transport", draft-ietf-nsis-ntlp-15 (work in 4094 progress), February 2008. 4096 [I-D.ietf-nsis-qspec] 4097 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 4098 QSPEC Template", draft-ietf-nsis-qspec-18 (work in 4099 progress), October 2007. 4101 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 4102 August 1996. 4104 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4105 Requirement Levels", BCP 14, RFC 2119, March 1997. 4107 10.2. Informative References 4109 [I-D.ietf-nsis-applicability-mobility-signaling] 4110 Lee, S., "Applicability Statement of NSIS Protocols in 4111 Mobile Environments", 4112 draft-ietf-nsis-applicability-mobility-signaling-08 (work 4113 in progress), November 2007. 4115 [I-D.ietf-nsis-rmd] 4116 Bader, A., "RMD-QOSM - The Resource Management in Diffserv 4117 QOS Model", draft-ietf-nsis-rmd-12 (work in progress), 4118 November 2007. 4120 [I-D.manner-nsis-nslp-auth] 4121 Manner, J., "Authorization for NSIS Signaling Layer 4122 Protocols", draft-manner-nsis-nslp-auth-03 (work in 4123 progress), March 2007. 4125 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 4126 Services in the Internet Architecture: an Overview", 4127 RFC 1633, June 1994. 4129 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 4130 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 4131 Functional Specification", RFC 2205, September 1997. 4133 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 4134 Services", RFC 2210, September 1997. 4136 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4137 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 4138 October 1998. 4140 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 4141 and S. Molendini, "RSVP Refresh Overhead Reduction 4142 Extensions", RFC 2961, April 2001. 4144 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 4145 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 4146 RFC 3175, September 2001. 4148 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 4149 "Session Authorization Policy Element", RFC 3520, 4150 April 2003. 4152 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 4153 Session Set-up with Media Authorization", RFC 3521, 4154 April 2003. 4156 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 4157 RFC 3726, April 2004. 4159 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 4160 Bosch, "Next Steps in Signaling (NSIS): Framework", 4161 RFC 4080, June 2005. 4163 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 4164 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 4166 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 4167 Specifications: ABNF", STD 68, RFC 5234, January 2008. 4169 [lrsvp] Manner, J. and K. Raatikainen, "Localized QoS Management 4170 for Multimedia Applications in Wireless Access Networks. 4171 IASTED, IMSA, August, 2004, pp. 193-200.". 4173 [opwa95] Breslau, L., "Two Issues in Reservation Establishment, 4174 Proc. ACM SIGCOMM '95 , Cambridge , MA , August 1995.". 4176 [osp] ETSI, ""Telecommunications and Internet protocol 4177 harmonization over networks (tiphon); open settlement 4178 protocol (osp) for inter- domain pricing, authorization, 4179 and usage exchange", Technical Specification 101 321, 4180 version 2.1.0.". 4182 [qos-auth] 4183 Tschofenig, H., "QoS NSLP Authorization Issues. Work in 4184 Progress.". 4186 [shenker] Shenker, S. and et al., ""Pricing in computer networks: 4187 Reshaping the research agenda", Proc. of TPRC 1995, 4188 1995.". 4190 Appendix A. Abstract NSLP-RMF API 4192 This appendix is purely informational and provides an abstract API 4193 between the QoS NSLP and the RMF. It should not be taken as a strict 4194 rule of implementors, but rather help clarify the interface between 4195 the NSLP and RMF. 4197 A.1. Triggers from QOS-NSLP towards RMF 4199 The QoS-NSLP triggers the RMF/QOSM functionality by using the 4200 sendrmf() primitive: 4202 int sendrmf(sid, nslp_req_type, qspec, authorization_info, 4203 NSLP_objects, filter, features_in, GIST_API_triggers, 4204 incoming_interface, outgoing_interface) 4206 o sid: SESSION_ID - The NSIS session identifier 4207 o nslp_req_type: indicates type of request: 4208 * RESERVE 4209 * QUERY 4210 * RESPONSE 4211 * NOTIFY 4212 o qspec: the QSPEC object, if present 4213 o authorization_info: the AUTHO_SESSION object, if present 4214 o NSLP_objects: data structure that contains a list with received 4215 QoS-NSLP objects. This list can be used by e.g., Local 4216 application, Management, Policy control: 4217 * RII 4218 * RSN 4219 * BOUND_SESSION_ID list 4220 * REFRESH_PERIOD 4221 * SESSION_ID_LIST 4222 * RSN_LIST 4223 * INFO_SPEC 4224 * MSG_ID 4225 * BOUND_MSG_ID 4226 o filter: the information for packet filtering, based on the MRI and 4227 the PACKET_CLASSIFIER object. 4228 o features_in: it represents the flags included in the common header 4229 of the received QOS-NSLP message, but also additional 4230 o triggers: 4231 * BREAK 4232 * REQUEST REDUCED REFRESHES 4233 * RESERVE-INIT 4234 * TEAR 4235 * REPLACE 4236 * ACK-REQ 4237 * PROXY 4238 * SCOPING 4239 * synchronization_required: this attribute is set (see e.g., 4240 Section 4.6 and 4.7.1) when the QoS-NSLP functionality 4241 supported by a QNE Egress receives a non tearing RESERVE 4242 message that includes a MSG_ID or a BOUND_MSG_ID object and the 4243 BINDING_CODE value of the BOUND_SESSION_ID object is equal to 4244 one of the following values: 4245 + Tunnel and end-to-end sessions 4246 + Aggregate sessions 4247 * GIST_API_triggers: it represents the attributes that are 4248 provided by GIST to QoS-NSLP via the GIST API: 4250 + NSLPID 4251 + Routing-State-Check 4252 + SII-Handle 4253 + Transfer-Attributes 4254 + GIST-Hop-Count 4255 + IP-TTL 4256 + IP-Distance 4257 o incoming_interface: the ID of the incoming interface. Used only 4258 when the QNE reserves resources on incoming interface. Default is 4259 0 (no reservations on incoming interface) 4260 o outgoing_interface: the ID of the outgoing interface. Used only 4261 when the QNE reserves resources on outgoing interface. Default is 4262 0 (no reservations on outgoing interface) 4264 A.2. Triggers from RMF/QOSM towards QOS-NSLP 4266 The RMF triggers the QoS-NSLP functionality using the "recvrmf()" and 4267 "config()" primitives to perform either all or a subset of the 4268 features listed below. 4270 The recvrmf() primitive represents either a response to a request 4271 that has been sent via the API by the QoS-NSLP or an asynchronous 4272 notification. Note that when the RMF/QOSM receives a request via the 4273 API from the QoS-NSLP function, then one or more than one "recvrmf()" 4274 response primitives can be sent via the API towards QoS-NSLP. In 4275 this way the QOS-NSLP can generate one, or more than one, QoS-NSLP 4276 messages that can be for example, used in the situation that the 4277 arrival of one end-to-end RESERVE triggers the generation of two (or 4278 more) RESERVE messages, an end-to-end RESERVE message and one (or 4279 more) intra-domain (local) RESERVE message. 4281 The config() primitive is used to configure certain features, such as 4282 QNE type, statefullness, bypassing support. 4284 Note that the selection of the subset of triggers is controlled by 4285 the QoS Model. 4287 int recvrmf(sid, nslp_resp_type, qspec, authorization_info, status, 4288 NSLP_objects, filter, features_out, GIST_API_triggers 4289 incoming_interface, outgoing_interface) 4291 o sid: SESSION_ID - The NSIS session identifier 4292 o nslp_resp_type: indicates type of response: 4293 * RESERVE 4294 * QUERY 4295 * RESPONSE 4296 * NOTIFY 4297 o qspec: the QSPEC object, if present 4298 o authorization_info: the AUTHO_SESSION object, if present 4299 o status: boolean that notifies the status of the reservation and 4300 can be used by QOS-NSLP to include in the INFO_SPEC object: 4301 * RESERVATION_SUCCESSFUL 4302 * TEAR_DOWN_SUCCESSFUL 4303 * NO RESOURCES 4304 * RESERVATION_FAILURE 4305 * RESERVATION_PREEMPTED: reservation was pre-empted 4306 * AUTHORIZATION_FAILED: authorizing the request failed 4307 * MALFORMED_QSPEC: request failed due to malformed qspec 4308 * SYNCHRONISATION_FAILED: Mismatch synchronization between an 4309 end-to-end RESERVE and an intra-domain RESERVE (see Section 4.6 4310 and 4.7.1) 4311 * CONGESTION_SITUATION: Possible congestion situation occurred on 4312 downstream path 4313 * QOS Model Error 4314 o NSLP_objects: data structure that contains a list with QoS-NSLP 4315 objects that can be used by QoS-NSLP, when the QNE is a QNI, QNR, 4316 QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress: 4317 * RII 4318 * RSN 4319 * BOUND_SESSION_ID list 4320 * REFRESH_PERIOD 4321 * SESSION_ID_LIST 4322 * RSN_LIST 4323 * MSG_ID 4324 * BOUND_MSG_ID 4325 o filter: it represents the MRM related PACKET CLASSIFIER 4326 o features_out: it represents among others the flags that can be 4327 used by the QOS-NSLP for new generated QoS-NSLP messages: 4328 * BREAK 4329 * REQUEST REDUCED REFRESHES 4330 * RESERVE-INIT 4331 * TEAR 4332 * REPLACE 4333 * ACK-REQ 4334 * PROXY 4335 * SCOPING 4336 * BYPASSING: when the outgoing message should be bypassed then it 4337 includes the required bypassing level. Otherwise it is empty. 4338 It can be set only by QNI_Ingress, QNR_Ingress, QNI_Egress, 4339 QNR_Egress. It can be unset only by QNI_Ingress, QNR_Ingress, 4340 QNI_Egress, QNR_Egress. 4341 * BINDING () when BINDING is required then it includes a 4342 BOUND_SESSION_ID list. Otherwise it is empty. It can only be 4343 requested by the following QNE types: QNI, QNR, QNI_Ingress, 4344 QNR_Ingress, QNI_Egress, QNR_Egress. 4345 * NEW_SID - it requests to generate a new session with a new 4346 SESSION_ID. If the QoS-NSLP generates a new SESSION_ID then 4347 the QoS-NSLP has to return the value of this new SESSION_ID to 4348 the RMF/QOSM. It can be requested by a QNI, QNR, QNI_Ingress, 4349 QNI_Egress, QNR_Ingress, QNR_Egress. 4350 * NEW_RSN - it requests to generate a new RSN. If the QoS-NSLP 4351 generates a new RSN then the QoS-NSLP has to return the value 4352 of this new RSN to the RMF/QOSM. 4353 * NEW_RII - it requests to generate a new RII. If the QoS-NSLP 4354 generates a new RII then the QoS-NSLP has to return the value 4355 of this new RII to the RMF/QOSM. 4356 o GIST_API_triggers: it represents the attributes that are provided 4357 to GIST via QoS-NSLP via the GIST API 4358 * NSLPID 4359 * SII-Handle 4360 * Transfer-Attributes 4361 * GIST-Hop-Count 4362 * IP-TTL 4363 * ROUTING-STATE-CHECK (if set it requires from GIST to create a 4364 routing state) 4365 o incoming_interface: the ID of the incoming interface. Used only 4366 when the QNE reserves resources on incoming interface. Default is 4367 0 (no reservations on incoming interface) 4368 o outgoing_interface: the ID of the outgoing interface. Used only 4369 when the QNE reserves resources on outgoing interface. Default is 4370 0 (no reservations on outgoing interface) 4372 A.3. Configuration interface 4374 The config() function is meant for configuring per-session settings, 4375 from the RMF towards the NSLP. 4377 int config(sid, qne_type, state_type, bypassing_type) 4379 o sid: SESSION_ID - The NSIS session identifier 4380 o qne_type: it defines the type of a QNE 4381 * QNI 4382 * QNI_Ingress: the QNE is a QNI and an Ingress QNE 4383 * QNE: the QNE is not a QNI or QNR 4384 * QNE_Interior: the QNE is an Interior QNE, but it is not a QNI 4385 or QNR 4386 * QNI_Egress: the QNE is a QNI and an Egress QNE 4387 * QNR 4388 * QNR_Ingress: the QNE is a QNR and an Ingress QNE 4389 * QNR_Egress: the QNE is a QNR and an Egress QNE 4391 o state_type: it defines if the QNE keeps QoS-NSLP operational 4392 states 4393 * STATEFULL 4394 * STATELESS 4395 o bypassing_type: it defines if a QNE bypasses end-to-end messages 4396 or not 4398 Appendix B. Glossary 4400 AAA: Authentication, Authorization and Accounting 4402 EAP: Extensible Authentication Protocol 4404 MRI: Message Routing Information (see [I-D.ietf-nsis-ntlp]) 4406 NAT: Network Address Translator 4408 NSLP: NSIS Signaling Layer Protocol (see [RFC4080]) 4410 NTLP: NSIS Transport Layer Protocol (see [RFC4080]) 4412 OPWA: One Pass With Advertising 4414 OSP: Open Settlement Protocol 4416 PIN: Policy Ignorant Node 4418 QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2) 4420 QNI: the first node in the sequence of QNEs that issues a reservation 4421 request for a session (see Section 2) 4423 QNR: the last node in the sequence of QNEs that receives a 4424 reservation request for a session (see Section 2) 4426 QSPEC: Quality of Service Specification 4428 RII: Request Identification Information 4430 RMD: Resource Management for DiffServ 4432 RMF: Resource Management Function 4434 RSN: Reservation Sequence Number 4436 RSVP: Resource Reservation Protocol (see [RFC2205]) 4437 SII: Source Identification Information 4439 SIP: Session Initiation Protocol 4441 SLA: Service Level Agreement 4443 Authors' Addresses 4445 Jukka Manner 4446 Helsinki University of Technology (TKK) 4447 P.O. Box 3000 4448 Espoo FIN-02015 TKK 4449 Finland 4451 Phone: +358 9 451 2481 4452 Email: jukka.manner@tkk.fi 4454 Georgios Karagiannis 4455 University of Twente/Ericsson 4456 P.O. Box 217 4457 Enschede 7500 AE 4458 The Netherlands 4460 Email: karagian@cs.utwente.nl 4462 Andrew McDonald 4463 Siemens/Roke Manor Research 4464 Roke Manor Research Ltd. 4465 Romsey, Hants S051 0ZN 4466 UK 4468 Email: andrew.mcdonals@roke.co.uk 4470 Full Copyright Statement 4472 Copyright (C) The IETF Trust (2008). 4474 This document is subject to the rights, licenses and restrictions 4475 contained in BCP 78, and except as set forth therein, the authors 4476 retain all their rights. 4478 This document and the information contained herein are provided on an 4479 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4480 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4481 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4482 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4483 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4484 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4486 Intellectual Property 4488 The IETF takes no position regarding the validity or scope of any 4489 Intellectual Property Rights or other rights that might be claimed to 4490 pertain to the implementation or use of the technology described in 4491 this document or the extent to which any license under such rights 4492 might or might not be available; nor does it represent that it has 4493 made any independent effort to identify any such rights. Information 4494 on the procedures with respect to rights in RFC documents can be 4495 found in BCP 78 and BCP 79. 4497 Copies of IPR disclosures made to the IETF Secretariat and any 4498 assurances of licenses to be made available, or the result of an 4499 attempt made to obtain a general license or permission for the use of 4500 such proprietary rights by implementers or users of this 4501 specification can be obtained from the IETF on-line IPR repository at 4502 http://www.ietf.org/ipr. 4504 The IETF invites any interested party to bring to its attention any 4505 copyrights, patents or patent applications, or other proprietary 4506 rights that may cover technology that may be required to implement 4507 this standard. Please address the information to the IETF at 4508 ietf-ipr@ietf.org. 4510 Acknowledgment 4512 Funding for the RFC Editor function is provided by the IETF 4513 Administrative Support Activity (IASA).