idnits 2.17.1 draft-ietf-nsis-qos-nslp-15.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 4447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4471. 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 'MUST not' in this paragraph: The node that created the RII object MUST remember the value used in the RII to match back any RESPONSE it will receive. The node SHOULD use a timer to identify situations where it has taken too long to receive the expected RESPONSE. If the timer expires without receiving a RESPONSE it MAY perform a retransmission as discussed in Section 5.2.4. In this case this QNE MUST not generate any RESPONSE or NOTIFY message to notify this error. == 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. == 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 'MUST not' in this paragraph: If a stateful QoS NSLP QNE receives a RESERVE message with the BREAK flag set then the BREAK flag of new generated messages (e.g., RESERVE or RESPONSE) MUST be set. When a stateful QoS NSLP QNE receives a RESERVE message with the BREAK flag not set then the IP-TTL and Original-TTL values in GIST RecvMessage primitive MUST be monitored. If they differ then the BREAK flag of new generated messages (e.g., RESERVE or RESPONSE) SHOULD be set. In situations where a QNE or a domain is able to provide QoS using other means, see Section 3.3.5, then the BREAK flag MUST not be set. == 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 'MUST not' in this paragraph: If a stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT flag and BREAK flag set then the BREAK flag of new generated messages (e.g., QUERY, RESERVE or RESPONSE) MUST be set. When a stateful QoS NSLP QNE receives a QUERY message with the the RESERVE-INIT flag set and BREAK flag not set then then the IP-TTL and Original-TTL values in GIST RecvMessage primitive MUST be monitored. If they differ then the BREAK flag of new generated messages (e.g., QUERY, RESERVE or RESPONSE) SHOULD be set. In situations where a QNE or a domain is able to provide QoS using other means, see Section 3.3.5, then the BREAK flag MUST not be set. -- 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 (July 25, 2007) is 6119 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-14 ** 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-17 ** 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-07 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-rmd-10 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manner 3 Internet-Draft University of Helsinki 4 Intended status: Standards Track G. Karagiannis 5 Expires: January 26, 2008 University of Twente/Ericsson 6 A. McDonald 7 Siemens/Roke Manor Research 8 July 25, 2007 10 NSLP for Quality-of-Service Signaling 11 draft-ietf-nsis-qos-nslp-15.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 January 26, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . 81 130 7.1. Trust Relationship Model . . . . . . . . . . . . . . . . . 82 131 7.2. Authorization Model Examples . . . . . . . . . . . . . . . 84 132 7.2.1. Authorization for the Two Party Approach . . . . . . . 84 133 7.2.2. Token-based Three Party Approach . . . . . . . . . . . 85 134 7.2.3. Generic Three Party Approach . . . . . . . . . . . . . 86 135 7.3. Computing the Authorization Decision . . . . . . . . . . . 87 136 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87 137 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 88 138 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88 139 10.1. Normative References . . . . . . . . . . . . . . . . . . . 88 140 10.2. Informative References . . . . . . . . . . . . . . . . . . 88 141 Appendix A. 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. 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. All QNEs on the path, including the QNI and 221 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 336 management (e.g. initiating a tunnel to handle an aggregate, or 337 interworking with some other reservation protocol - such as RSVP) and 338 the policy control module (e.g., for explicit teardown triggered by 339 AAA). In this sense, the model does not distinguish between hosts 340 and routers. 342 Incoming messages are captured during input packet processing and 343 handled by GIST. Only messages related to QoS are passed to the QoS 344 NSLP. GIST may also generate triggers to the QoS NSLP (e.g., 345 indications that a route change has occurred). The QoS request is 346 handled by the RMF, which coordinates the activities required to 347 grant and configure the resource. It also handles policy-specific 348 aspects of QoS signaling. 350 The grant processing involves two local decision modules, 'policy 351 control' and 'admission control'. Policy control determines whether 352 the user is authorized to make the reservation. Admission control 353 determines whether the network of the node has sufficient available 354 resources to supply the requested QoS. If both checks succeed, 355 parameters are set in the packet classifier and in the link layer 356 interface (e.g., in the packet scheduler) to obtain the desired QoS. 357 Error notifications are passed back to the request originator. The 358 resource management function may also manipulate the forwarding 359 tables at this stage, to select (or at least pin) a route; this must 360 be done before interface-dependent actions are carried out (including 361 sending outgoing messages over any new route), and is in any case 362 invisible to the operation of the protocol. 364 Policy control is expected to make use of the authentication 365 infrastructure or the authentication protocols external to the node 366 itself. Some discussion can be found in a separate document on 367 authorization issues [qos-auth]. More generally, the processing of 368 policy and resource management functions may be outsourced to an 369 external node leaving only 'stubs' co-located with the NSLP node; 370 this is not visible to the protocol operation. A more detailed 371 discussion of authentication and authorization can be found in 372 Section 3.1.3. 374 Admission control, packet scheduling, and any part of policy control 375 beyond simple authorization have to be implemented using specific 376 definitions for types and levels of QoS. A key assumption is made 377 that the QoS NSLP is independent of the QoS parameters (e.g., IntServ 378 service elements). These are captured in a QoS Model and interpreted 379 only by the resource management and associated functions, and are 380 opaque to the QoS NSLP itself. QoS Models are discussed further in 381 Section 3.1.2. 383 The final stage of processing for a resource request is to indicate 384 to the QoS NSLP protocol processing that the required resources have 385 been configured. The QoS NSLP may generate an acknowledgment message 386 in one direction, and may forward the resource request in the other. 387 Message routing is carried out by the GIST module. Note that while 388 Figure 2 shows a unidirectional data flow, the signaling messages can 389 pass in both directions through the node, depending on the particular 390 message and orientation of the reservation. 392 3.1.1. Protocol Messages 394 The QoS NSLP uses four message types: 396 RESERVE: The RESERVE message is the only message that manipulates QoS 397 NSLP reservation state. It is used to create, refresh, modify and 398 remove such state. The result of a RESERVE message is the same 399 whether a message is received once or many times. 401 QUERY: A QUERY message is used to request information about the data 402 path without making a reservation. This functionality can be used to 403 reservations or for support of certain QoS models. The information 404 obtained from a QUERY may be used in the admission control process of 405 a QNE (e.g., in case of measurement-based admission control). Note 406 that a QUERY does not change existing reservation state. 408 RESPONSE: The RESPONSE message is used to provide information about 409 the result of a previous QoS NSLP message. This includes explicit 410 confirmation of the state manipulation signaled in the RESERVE 411 message, the response to a QUERY message or an error code if the QNE 412 or QNR is unable to provide the requested information or if the 413 response is negative. The RESPONSE message does not cause any 414 reservation state to be installed or modified. 416 NOTIFY: NOTIFY messages are used to convey information to a QNE. 417 They differ from RESPONSE messages in that they are sent 418 asynchronously and need not refer to any particular state or 419 previously received message. The information conveyed by a NOTIFY 420 message is typically related to error conditions. Examples would be 421 notification to an upstream peer about state being torn down or to 422 indicate when a reservation has been preempted. 424 QoS NSLP messages are sent peer-to-peer. This means that a QNE 425 considers its adjacent upstream or downstream peer to be the source 426 of the each message. 428 Each protocol message has a common header which indicates the message 429 type and contains various flag bits. Message formats are defined in 430 Section 5.1.2. Message processing rules are defined in Section 5.4. 432 QoS NSLP messages contain three types of objects: 434 1. Control Information: Control information objects carry general 435 information for the QoS NSLP processing, such as sequence numbers or 436 whether a response is required. 438 2. QoS specifications (QSPECs): QSPEC objects describe the actual 439 resources that are required and depend on the QoS model being used. 440 Besides any resource description they may also contain other control 441 information used by the RMF's processing. 443 3. Policy objects: Policy objects contain data used to authorize the 444 reservation of resources. 446 Object formats are defined in Section 5.1.3. Object processing rules 447 are defined in Section 5.3. 449 3.1.2. QoS Models and QoS Specifications 451 The QoS NSLP provides flexibility over the exact patterns of 452 signaling messages that are exchanged. The decoupling of QoS NSLP 453 and QSPEC allows the QoS NSLP to be ignorant about the ways in which 454 traffic, resources, etc. are described, and it can treat the QSPEC as 455 an opaque object. Various QoS models can be designed, and these do 456 not affect the specification of the QoS NSLP protocol. Only the RMF 457 specific to a given QoS model will need to interpret the QSPEC. The 458 Resource Management Function (RMF) reserves resources for each flow. 460 An ongoing effort attempts to specify a QSPEC template 461 [I-D.ietf-nsis-qspec]. The QSPEC template contains object formats 462 for generally useful elements of the QoS description, which is 463 designed to ensure interoperability when using the basic set of 464 objects. 466 The QSPEC fulfills a similar purpose to the TSpec, RSpec and AdSpec 467 objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC 468 2210 [RFC2210]. At each QNE, the content of the QSPEC is interpreted 469 by the Resource Management Function and the Policy Control Function 470 for the purposes of traffic and policy control (including admission 471 control and configuration of the packet classifier and scheduler). 473 The QoS NSLP does not mandate any particular behavior for the RMF, 474 instead providing interoperability at the signaling protocol level 475 whilst leaving the validation of RMF behavior to contracts external 476 to the protocol itself. The RMF may make use of various elements 477 from the QoS NSLP message, not only the QSPEC object. 479 Still, this specification assumes that resource sharing is possible 480 between flows with the same SESSION_ID that originate from the same 481 QNI or between flows with a different SESSION_ID that are related 482 through the BOUND_SESSION_ID object. For flows with the same 483 SESSION_ID, resource sharing is only applicable when the existing 484 reservation is not just replaced (which is indicated by the REPLACE 485 flag in the common header). We assume that the QoS model supports 486 resource sharing between flows. A QoS Model may elect to implement a 487 more general behavior of supporting relative operations on existing 488 reservations, such as ADDING or SUBTRACTING a certain amount of 489 resources from the current reservation. A QoS Model may also elect 490 to allow resource sharing more generally, e.g., between all flows 491 with the same DSCP. 493 The QSPEC carries a collection of objects that can describe QoS 494 specifications in a number of different ways. A generic template is 495 defined in [I-D.ietf-nsis-qspec]. A QSPEC describing the resources 496 requested will usually contain objects which need to be understood by 497 all implementations, and it can also be enhanced with additional 498 objects specific to a QoS model to provide a more exact definition to 499 the RMF, which may be better able to use its specific resource 500 management mechanisms (which may, e.g., be link specific) as a 501 result. 503 A QoS Model defines the behavior of the RMF, including inputs and 504 outputs, and how QSPEC information is used to describe resources 505 available, resources required, traffic descriptions, and control 506 information required by the RMF. A QoS Model also describes the 507 minimum set of parameters QNEs should use in the QSPEC when signaling 508 about this QoS Model. 510 QoS Models may be local (private to one network), implementation/ 511 vendor specific, or global (implementable by different networks and 512 vendors). All QSPECs should follow the design of the QSPEC template 513 [I-D.ietf-nsis-qspec]. 515 The definition of a QoS model may also have implications on how local 516 behavior should be implemented in the areas where the QoS NSLP gives 517 freedom to implementers. For example, it may be useful to identify 518 recommended behavior for how a RESERVE message that is forwarded 519 relates to that received, or when additional signaling sessions 520 should be started based on existing sessions, such as required for 521 aggregate reservations. In some cases, suggestions may be made on 522 whether state that may optionally be retained should be held in 523 particular scenarios. A QoS model may specify reservation 524 preemption, e.g., an incoming resource request may cause removal of 525 an earlier established reservation. 527 3.1.3. Policy Control 529 Getting access to network resources, e.g., network access in general 530 or access to QoS, typically involves some kind of policy control. 531 One example of this is authorization of the resource requester. 532 Policy control for QoS NSLP resource reservation signaling is 533 conceptually organized as illustrated below in Figure 3. 535 +-------------+ 536 | Policy | 537 | Decision | 538 | Point (PDP) | 539 +------+------+ 540 | 541 /-\-----+-----/\ 542 //// \\\\ 543 || || 544 | Policy transport | 545 || || 546 \\\\ //// 547 \-------+------/ 548 | 549 +-------------+ QoS signaling +------+------+ 550 | Entity |<==============>| QNE = Policy|<=========> 551 | requesting | Data Flow | Enforcement | 552 | resource |----------------|-Point (PEP)-|----------> 553 +-------------+ +-------------+ 555 Figure 3: Policy control with the QoS NSLP signaling 557 From the QoS NSLP point of view, the policy control model is 558 essentially a two-party model between neighboring QNEs. The actual 559 policy decision may depend on the involvement of a third entity (the 560 policy decision point, PDP), but this happens outside of the QoS NSLP 561 protocol by means of existing policy infrastructure (COPS, Diameter, 562 etc). The policy control model for the entire end-to-end chain of 563 QNEs is therefore one of transitivity, where each of the QNEs 564 exchanges policy information with its QoS NSLP policy peer. 566 The authorization of a resource request often depends on the identity 567 of the entity making the request. Authentication may be required. 568 The GIST channel security mechanisms provide one way of 569 authenticating the QoS NSLP peer which sent the request, and so may 570 be used in making the authorization decision. 572 Additional information might also be provided in order to assist in 573 making the authorization decision. This might include alternative 574 methods of authenticating the request. 576 The QoS NSLP does not contain objects to carry authorization 577 information. A separate work [nslp-auth] defines this functionality 578 for the QoS NSLP and the NATFW NSLP. 580 It is generally assumed that policy enforcement is likely to 581 concentrate on border nodes between administrative domains. This may 582 mean that nodes within the domain are "Policy Ignorant Nodes" that 583 perform no per-request authentication or authorization, relying on 584 the border nodes to perform the enforcement. In such cases, the 585 policy management between ingress and egress edge of a domain relies 586 on the internal chain of trust between the nodes in the domain. If 587 this is not acceptable, a separate signaling session can be set up 588 between the ingress and egress edge nodes in order to exchange policy 589 information. 591 3.2. Design Background 593 This section presents some of the key functionality behind the 594 specification of the QoS NSLP. 596 3.2.1. Soft States 598 The NSIS protocol suite takes a soft-state approach to state 599 management. This means that reservation state in QNEs must be 600 periodically refreshed. The frequency with which state installation 601 is refreshed is expressed in the REFRESH_PERIOD object. This object 602 contains a value in milliseconds indicating how long the state that 603 is signaled for remains valid. Maintaining the reservation beyond 604 this lifetime can be done by sending a RESERVE message periodically. 606 3.2.2. Sender and Receiver Initiation 608 The QoS NSLP supports both sender-initiated and receiver-initiated 609 reservations. For a sender-initiated reservation, RESERVE messages 610 travel in the same direction as the data flow that is being signaled 611 for (the QNI is at the side of the source of the data flow). For a 612 receiver-initiated reservation, RESERVE messages travel in the 613 opposite direction (the QNI is at the side of the receiver of the 614 data flow). 616 Note: these definitions follow the definitions in Section 3.3.1. of 617 RFC 4080 [RFC4080]. The main issue is, which node is in charge of 618 requesting and maintaining the resource reservation. In a receiver- 619 initiated reservation, even though the sender sends the initial 620 QUERY, the receiver is still in charge of making the actual resource 621 request, and maintaining the reservation. 623 3.2.3. Protection Against Message Re-ordering and Duplication 625 RESERVE messages affect the installed reservation state. Unlike 626 NOTIFY, QUERY and RESPONSE messages, the order in which RESERVE 627 messages are received influences the eventual reservation state that 628 will be stored at a QNE, that is, the most recent RESERVE message 629 replaces the current reservation. Therefore, in order to protect 630 against RESERVE message re-ordering or duplication, the QoS NSLP uses 631 a Reservation Sequence Number (RSN). The RSN has local significance 632 only, i.e., between a QNE and its downstream peers. 634 3.2.4. Explicit Confirmations 636 A QNE may require a confirmation that the end-to-end reservation is 637 in place, or a reply to a query along the path. For such requests, 638 it must be able to keep track of which request each response refers 639 to. This is supported by including a Request Identification 640 Information (RII) object in a QoS NSLP message. 642 3.2.5. Reduced Refreshes 644 For scalability, the QoS NSLP supports an abbreviated form of refresh 645 RESERVE message. In this case, the refresh RESERVE references the 646 reservation using the RSN and the SESSION_ID, and does not include 647 the full reservation specification (including QSPEC). By default 648 state refresh should be performed with reduced refreshes in order to 649 save bytes during transmission. Stateless QNEs will require full 650 refresh since they do not store the whole reservation information. 652 If the stateful QNE does not support reduced refreshes, or there is a 653 mismatch between the local and received RSN, the stateful QNE must 654 reply with an RESPONSE carrying an INFO_SPEC indicating the error. 655 Furthermore, the QNE must stop sending reduced refreshes to this peer 656 if the error indicates lacking support for this feature. 658 3.2.6. Summary Refreshes and Summary Tear 660 For limiting the number of individual messages, the QoS NSLP supports 661 a summary refresh and summary tear messages. When sending a 662 refreshing RESERVE for a certain (primary) session, a QNE may include 663 a SESSION_ID_LIST object where the QNE indicates (secondary) sessions 664 that are also refreshed. An RSN_LIST object must also be added. The 665 SESSION IDs and RSNs are stacked in the objects such that the index 666 in both stacks refer to the same reservation state, i.e., the 667 SESSION_ID and RSN at index i in both objects refers to the same 668 session. If the receiving stateful QNE notices unknown SESSION IDs 669 or a mismatch with RSNs for a session, it will reply back to the 670 upstream stateful QNE with an error. 672 In order to tear down several sessions at once, a QNE may include 673 SESSION_ID_LIST and RSN_LIST objects in a tearing reserve. The 674 downstream stateful QNE must then also tear the other sessions 675 indicated. The downstream stateful QNE must silently ignore any 676 unknown SESSION IDs. 678 GIST provides a SII_HANDLE for every downstream session. The 679 SII_HANDLE identifies a peer, and should be the same for all sessions 680 whose downstream peer is the same. The QoS NSLP uses this 681 information to decide whether summary refresh messages can be sent, 682 or when a summary tear is possible. 684 3.2.7. Message Scoping 686 A QNE may use local policy when deciding whether to propagate a 687 message or not. For example, the local policy can define/configure 688 that a QNE is, for a particular session, a QNI and/or a QNR. The QoS 689 NSLP also includes an explicit mechanism to restrict message 690 propagation by means of a scoping mechanism. 692 For a RESERVE or a QUERY message, two scoping flags limit the part of 693 the path on which state is installed on the downstream nodes that can 694 respond. When the SCOPING flag is set to zero, it indicates that the 695 scope is "whole path" (default). When set to one, the scope is 696 "single hop". When the PROXY scope flag is set, the path is 697 terminated at a pre-defined Proxy QNE (P-QNE). This is similar to 698 the Localized RSVP [lrsvp]. 700 The propagation of a RESPONSE message is limited by the RII object, 701 which ensures that it is not forwarded back along the path further 702 than the node that requested the RESPONSE. 704 3.2.8. Session Binding 706 Session binding is defined as the enforcement of a relation between 707 different QoS NSLP sessions (i.e., signaling flows with different 708 SESSION_ID (SID) as defined in GIST [I-D.ietf-nsis-ntlp]). 710 Session binding indicates a unidirectional dependency relation 711 between two or more sessions by including a BOUND_SESSION_ID object. 712 A session with SID_A (the binding session) can express its 713 unidirectional dependency relation to another session with SID_B (the 714 bound session) by including a BOUND_SESSION_ID object containing 715 SID_B in its messages. 717 The concept of session binding is used to indicate the unidirectional 718 dependency relation between the end-to-end session and the aggregate 719 session in case of aggregate reservations. In case of bidirectional 720 reservations, it is used to express the unidirectional dependency 721 relation between the sessions used for forward and reverse 722 reservation. Typically, the dependency relation indicated by session 723 binding is purely informative in nature and does not automatically 724 trigger any implicit action in a QNE. A QNE may use the dependency 725 relation information for local resource optimization or to explicitly 726 tear down reservations that are no longer useful. However, by using 727 an explicit binding code, see Section 5.1.3.4, it is possible to 728 formalise this dependency relation, meaning that if the bound session 729 (e.g., session with SID_B) is terminated also the binding session 730 (e.g., the session with SID_A) must be terminated. 732 A message may include more than one BOUND_SESSION_ID object. This 733 may happen, e.g., in certain aggregation and bi-directional 734 reservation scenarios, where an end-to-end session has an 735 unidirectional dependency relation with an aggregate session and at 736 the same time it has an unidirectional dependency relation with 737 another session used for the reverse path. 739 3.2.9. Message Binding 741 QoS NSLP supports binding of messages in order to allow for 742 expressing dependencies between different messages. The message 743 binding can indicate either a unidirectional or bidirectional 744 dependency relation between two messages by including in one of the 745 message the MSG_ID object ("binding message") and in the other 746 message ("bound message") the BOUND_MSG_ID object. The 747 unidirectional dependency means that only RESERVE messages are bound 748 to each other whereas a bidirectional dependency means that there is 749 also a dependency for the related RESPONSE messages. The message 750 binding can be used to speed up signaling by starting two signaling 751 exchanges simultaneously that are synchronized later by using message 752 IDs. This can be used as an optimization technique for example in 753 scenarios where aggregate reservations are used. Section 4.6 754 provides more details. 756 3.2.10. Layering 758 The QoS NSLP supports layered reservations. Layered reservations may 759 occur when certain parts of the network (domains) implement one or 760 more local QoS models, or when they locally apply specific transport 761 characteristics (e.g., GIST unreliable transfer mode instead of 762 reliable transfer mode). They may also occur when several per-flow 763 reservations are locally combined into an aggregate reservation. 765 3.2.10.1. Local QoS Models 767 A domain may have local policies regarding QoS model implementation, 768 i.e., it may map incoming traffic to its own locally defined QoS 769 models. The QSPEC allows this functionality, and the operation is 770 transparent to the QoS NSLP. The use of local QoS models within a 771 domain is performed in the RMF. 773 3.2.10.2. Local Control Plane Properties 775 The way signaling messages are handled is mainly determined by the 776 parameters that are sent over GIST-NSLP API and by the domain 777 internal configuration. A domain may have a policy to implement 778 local transport behavior. It may, for instance, elect to use an 779 unreliable transport locally in the domain while still keeping end- 780 to-end reliability intact. 782 The QoS NSLP supports this situation by allowing two sessions to be 783 set up for the same reservation. The local session has the desired 784 local transport properties and is interpreted in internal QNEs. This 785 solution poses two requirements: the end-to-end session must be able 786 to bypass intermediate nodes and the egress QNE needs to bind both 787 sessions together. Bypassing intermediate nodes is achieved with 788 GIST. The local session and the end-to-end session are bound at the 789 egress QNE by means of the BOUND_SESSION_ID object. 791 3.2.10.3. Aggregate Reservations 793 In some cases it is desirable to create reservations for an 794 aggregate, rather than on a per-flow basis, in order to reduce the 795 amount of reservation state needed, as well as, the processing load 796 for signaling messages. Note that the QoS NSLP does not specify how 797 reservations need to be combined in an aggregate or how end-to-end 798 properties need to be computed but only provides signaling support 799 for it. 801 The essential difference with the layering approaches described in 802 Section 3.2.10.1 and Section 3.2.10.2 is that the aggregate 803 reservation needs a MRI that describes all traffic carried in the 804 aggregate (e.g., a DSCP in case of IntServ over DiffServ). The need 805 for a different MRI mandates the use of two different sessions, 806 similar to Section 3.2.10.3 and to the RSVP aggregation solution in 807 RFC 3175 [RFC3175]. 809 Edge QNEs of the aggregation domain that want to maintain some end- 810 to-end properties may establish a peering relation by sending the 811 end-to-end message transparently over the domain (using the 812 intermediate node bypass capability described above). Updating the 813 end-to-end properties in this message may require some knowledge of 814 the aggregated session (e.g., for updating delay values). For this 815 purpose, the end-to-end session contains a BOUND_SESSION_ID carrying 816 the SESSION_ID of the aggregate session. 818 3.2.11. Support for Request Priorities 820 This specification acknowledges the fact that in some situations, 821 some messages or some reservations may be more important than others 822 and therefore foresees mechanisms to give these messages or 823 reservations priority. 825 Priority of certain signaling messages over others may be required in 826 mobile scenarios when a message loss during call set-up is less 827 harmful than during handover. This situation only occurs when GIST 828 or QoS NSLP processing is the congested part or scarce resource. 830 Priority of certain reservations over others may be required when QoS 831 resources are oversubscribed. In that case, existing reservations 832 may be preempted in order to make room for new higher-priority 833 reservations. A typical approach to deal with priority and 834 preemption is through the specification of a setup priority and 835 holding priority for each reservation. The resource management 836 function at each QNE then keeps track of the resource consumption at 837 each priority level. Reservations are established when resources, at 838 their setup priority level, are still available. They may cause 839 preemption of reservations with a lower holding priority than their 840 setup priority. 842 Support of reservation priority is a QSPEC parameter and therefore 843 outside the scope of this specification. The GIST specification 844 provides a mechanism to support a number of levels of message 845 priority that can be requested over the NSLP-GIST API. 847 3.2.12. Rerouting 849 The QoS NSLP needs to adapt to route changes in the data path. This 850 assumes the capability to detect rerouting events, create a QoS 851 reservation on the new path and optionally tear down reservations on 852 the old path. 854 From an NSLP perspective, rerouting detection can be performed in two 855 ways. It can either come through NetworkNotification from GIST, or 856 from information seen at the NSLP. In the latter case, the QoS NSLP 857 node is able to detect changes in its QoS NSLP peers by keeping track 858 of a Source Identification Information (SII) handle that provides 859 information similar in nature to the RSVP_HOP object described in RFC 860 2205 [RFC2205]. When a RESERVE message with an existing SESSION_ID 861 and a different SII is received, the QNE knows its upstream or 862 downstream peer has changed, for sender-oriented and receiver- 863 oriented reservations, respectively. 865 Reservation on the new path happens when a RESERVE message arrives at 866 the QNE beyond the point where the old and new paths diverge. If the 867 QoS NSLP suspects that a reroute has occurred, then a full RESERVE 868 message (including the QSPEC) would be sent. A refreshing RESERVE 869 (with no QSPEC) will be identified as an error by a QNE on the new 870 path which does not have the reservation installed (i.e. it was not 871 on the old path) or which previously had a different previous-hop 872 QNE. It will send back an error message which results in a full 873 RESERVE message being sent. Rapid recovery at the NSLP layer 874 therefore requires short refresh periods. Detection before the next 875 RESERVE message arrives is only possible at the IP layer or through 876 monitoring of GIST peering relations (e.g., by TTL counting the 877 number of GIST hops between NSLP peers or the observing changes in 878 the outgoing interface towards GIST peer). These mechanisms can 879 provide implementation specific optimizations, and are outside the 880 scope of this specification. 882 When the QoS NSLP is aware of the route change, it needs to set up 883 the reservation on the new path. This is done by sending a new 884 RESERVE message. If the next QNE is, in fact, unchanged then this 885 will be used to refresh/update the existing reservation. Otherwise 886 it will lead to the reservation being installed on the new path. 888 Note that the operation for a receiver-initiated reservation session 889 differs a bit from the above description. If the routing changes in 890 the middle of the session, the QNE that notices that its downstream 891 path changed, the divergence point, must send a QUERY with the R-flag 892 downstream. It will be processed as above, and at some point hits a 893 QNE for which the path downstream towards the QNI remains (the 894 convergence point). This node must then send a full RESERVE upstream 895 to set up the reservation state along the new path. It should not 896 send the QUERY further downstream, since this would have no real use. 897 Similarly, when the QNE that sent the QUERY receives the RESERVE, it 898 should not send the RESERVE further upstream. 900 After the reservation on the new path is set up, the branching node 901 may want to tear down the reservation on the old path (sooner than 902 would result from normal soft-state time-out). This functionality is 903 supported by keeping track of the old SII-Handle provided over the 904 GIST API. This handle can be used by the QoS NSLP to route messages 905 explicitly to the next node. 907 If the old path is downstream, the QNE can send a tearing RESERVE 908 using the old SII-Handle. If the old path is upstream, the QNE can 909 send a NOTIFY with the code for "Route Change". This is forwarded 910 upstream until it hits a QNE that can issue a tearing RESERVE 911 downstream. A separate document discusses in detail the effect of 912 mobility on the QoS NSLP signaling 913 [I-D.ietf-nsis-applicability-mobility-signaling]. 915 A QNI or a branch node may wish to keep the reservation on the old 916 branch. This could for instance be the case when a mobile node has 917 experienced a mobility event and wishes to keep reservation to its 918 old attachment point in case it moves back there. For this purpose, 919 a REPLACE flag is provided in the QoS NSLP common header, which, when 920 not set, indicates that the reservation on the old branch should be 921 kept. 923 Note that keeping old reservations affects the resources available to 924 other nodes. Thus, the operator of the access network must make the 925 final decision on whether this behavior is allowed. Also, the QNEs 926 in the access network may add this flag even if the mobile node has 927 not used the flag initially. 929 The design of the QoS NSLP allows reservations to be installed at a 930 subset of the nodes along a path. In particular, usage scenarios 931 include cases where the data flow endpoints do not support the QoS 932 NSLP. 934 3.2.12.1. Last Node Behavior 936 In the case where the data flow receiver does not support the QoS 937 NSLP, some particular considerations must be given to node discovery 938 and rerouting at the end of the signaling path. 940 There are three cases for the last node on the signaling path: 1) 941 Last node is the data receiver 2) Last node is a configured proxy for 942 the data receiver 3) Last node is not the data receiver and is not 943 explicitly configured to act as a signaling proxy on behalf of the 944 data receiver. 946 Cases (1) and (2) can be handled by the QoS NSLP itself during the 947 initial path setup, since the QNE knows that it should terminate the 948 signaling. Case (3) requires some assistance from GIST which 949 provides messages across the API to indicate that no further QoS NSLP 950 supporting GIST nodes are present downstream, and downstream route 951 change probing needs to continue once the reservation is installed to 952 detect any changes in this situation. 954 Two particular scenarios need to be considered in this third case. 955 In the first, referred to as "Path Extension", rerouting occurs such 956 that an additional QNE is inserted into the signaling path between 957 the old last node and the data receiver, as shown in Figure 4. 959 /-------\ Initial route 960 / v 961 /-\ 962 /--|B|--\ +-+ 963 / \-/ \ |x| = QoS NSLP aware 964 +-+ /-\ +-+ 965 ----|A| |D| 966 +-+ \-/ /-\ 967 \ +-+ / |x| = QoS NSLP unaware 968 \--|C|--/ \-/ 969 +-+ 970 \ ^ 971 \-------/ Updated route 973 Figure 4: Path Extension 975 When rerouting occurs, the data path changes from A-B-D to A-C-D. 976 Initially the signaling path ends at A. Despite initially being the 977 last node, node A needs to continue to attempt to send messages 978 downstream to probe for path changes, unless it has been explicitly 979 configured as a signaling proxy for the data flow receiver. This is 980 required so that the signaling path change is detected, and C will 981 become the new last QNE. 983 In a second case, referred to as "Path Truncation", rerouting occurs 984 such that the QNE that was the last node on the signaling path is no 985 longer on the data path. This is shown in Figure 5. 987 /-------\ Initial route 988 / v 989 +-+ 990 /--|B|--\ +-+ 991 / +-+ \ |x| = QoS NSLP aware 992 +-+ /-\ +-+ 993 ----|A| |D| 994 +-+ \-/ /-\ 995 \ /-\ / |x| = QoS NSLP unaware 996 \--|C|--/ \-/ 997 \-/ 998 \ ^ 999 \-------/ Updated route 1001 Figure 5: Path Truncation 1003 When rerouting occurs, the data path again changes from A-B-D to A-C- 1004 D. The signaling path initially ends at B, but this node is not on 1005 the new path. In this case, the normal GIST path change detection 1006 procedures at A will detect the path change and notify the QoS NSLP. 1007 GIST will also notify the signaling application that no downstream 1008 GIST nodes supporting the QoS NSLP are present. Node A will take 1009 over as the last node on the signaling path. 1011 3.2.12.2. Handling Spurious Route Change Notifications 1013 The QoS NSLP is notified by GIST (with the NetworkNotification 1014 primitive) when GIST believes that a rerouting event may have 1015 occurred. In some cases, events that are detected as possible route 1016 changes will turn out not to be. The QoS NSLP will not always be 1017 able to detect this, even after receiving messages from the 'new' 1018 peer. 1020 As part of the RecvMessage API primitive, GIST provides an SII-Handle 1021 which can be used by the NSLP to direct a signaling message to a 1022 particular peer. The current SII-Handle will change if the signaling 1023 peer changes. However, it is not guaranteed to remain the same after 1024 a rerouting event where the peer does not change. Therefore, the QoS 1025 NSLP mechanism for reservation maintenance after a route change 1026 includes robustness mechanisms to avoid accidentally tearing down a 1027 reservation in situations where the peer QNE has remained the same 1028 after a 'route change' notification from GIST. 1030 A simple example that illustrates the problem is shown in Figure 6 1031 below. 1033 (1) +-+ 1034 /-----\ |x| = QoS NSLP aware 1035 +-+ /-\ (3) +-+ +-+ 1036 ----|A| |B|-----|C|---- 1037 +-+ \-/ +-+ /-\ 1038 \-----/ |x| = QoS NSLP unaware 1039 (2) \-/ 1041 Figure 6: Spurious reroute alerting 1043 In this example the initial route A-B-C uses links (1) and (3). 1044 After link (1) fails, the path is rerouted using links (2) and (3). 1045 The set of QNEs along the path is unchanged (it is A-C in both cases, 1046 since B does not support the QoS NSLP). 1048 When the outgoing interface at A has changes, GIST may signal across 1049 its API to the NSLP with a NetworkNotification. The QoS NSLP at A 1050 will then attempt to repair the path by installing the reservation on 1051 the path (2),(3). In this case, however, the old and new paths are 1052 the same. 1054 To install the new reservation A will send a RESERVE message, which 1055 GIST will transport to C (discovering the new next peer as 1056 appropriate). The RESERVE also requests a RESPONSE from the QNR. 1057 When this RESERVE message is received through the RecvMessage API 1058 call from GIST at the QoS NSLP at C, the SII-Handle will be unchanged 1059 from its previous communications from A. 1061 A RESPONSE message will be sent by the QNR, and be forwarded from C 1062 to A. This confirms that the reservation was installed on the new 1063 path. The SII-Handle passed with the RecvMessage call from GIST to 1064 the QoS NSLP will be different to that seen previously, since the 1065 interface being used on A has changed. 1067 At this point A can attempt to tear down the reservation on the old 1068 path. The RESERVE message with the TEAR flag set is sent down the 1069 old path by using the GIST explicit routing mechanism and specifying 1070 the SII-Handle relating to the 'old' peer QNE. 1072 If RSNs were being incremented for each of these RESERVE and RESERVE- 1073 with-TEAR messages the reservation would be torn down at C and any 1074 QNEs further along the path. To avoid this the RSN is used in a 1075 special way. The RESERVE down the new path is sent with the new 1076 current RSN set to the old RSN plus 2. The RESERVE-with-TEAR down 1077 the old path is sent with an RSN set to the new current RSN minus 1. 1078 This is the peer from which it was receiving RESERVE messages. 1080 3.2.13. Pre-emption 1082 The QoS NSLP provides building blocks to implement pre-emption. This 1083 specification does not define how pre-emption should work, but only 1084 provides signaling mechanisms that can be used by QoS Models. For 1085 example, an INFO_SPEC object can be added to messages to indicate 1086 that the signaled session was pre-empted. A BOUND_SESSION_ID object 1087 can carry the Session ID of the flow that caused the pre-emption to 1088 happen for the signaled session. How these are used by QoS Models is 1089 out of scope of the QoS NSLP specification. 1091 3.3. GIST Interactions 1093 The QoS NSLP uses GIST for delivery of all its messages. Messages 1094 are passed from the NSLP to GIST via an API (defined in Appendix B of 1095 [I-D.ietf-nsis-ntlp]), which also specifies additional information, 1096 including an identifier for the signaling application (e.g., 'QoS 1097 NSLP'), session identifier, MRI, and an indication of the intended 1098 direction - towards data sender or receiver. On reception, GIST 1099 provides the same information to the QoS NSLP. In addition to the 1100 NSLP message data itself, other meta-data (e.g. session identifier 1101 and MRI) can be transferred across this interface. 1103 The QoS NSLP keeps message and reservation state per session. A 1104 session is identified by a Session Identifier (SESSION_ID). The 1105 SESSION_ID is the primary index for stored NSLP state and needs to be 1106 constant and unique (with a sufficiently high probability) along a 1107 path through the network. The QoS NSLP picks a value for Session-ID. 1109 This value is subsequently used by GIST and the QoS NSLP to refer to 1110 this session. 1112 Currently, the QoS NSLP specification considers mainly the path- 1113 coupled MRM. However, extensions may specify how other types of MRMs 1114 may be applied in combination with the QoS NSLP. 1116 When GIST passes the QoS NSLP data to the NSLP for processing, it 1117 must also indicate the value of the 'D' (Direction) flag for that 1118 message in the MRI. 1120 The QoS NSLP does not provide any method of interacting with 1121 firewalls or Network Address Translators (NATs). It assumes that a 1122 basic NAT traversal service is provided by GIST. 1124 3.3.1. Support for Bypassing Intermediate Nodes 1126 The QoS NSLP may want to restrict the handling of its messages to 1127 specific nodes. This functionality is needed to support layering 1128 (explained in Section 3.2.10), when only the edge QNEs of a domain 1129 process the message. This requires a mechanism at GIST level (which 1130 can be invoked by the QoS NSLP) to bypass intermediate nodes between 1131 the edges of the domain. 1133 The intermediate nodes are bypassed using multiple levels of the 1134 router alert option. In that case, internal routers are configured 1135 to handle only certain levels of router alerts. This is accomplished 1136 by marking the signaling messages, i.e., modifying the QoS NSLP 1137 default NSLP-ID value to another NSLP-ID predefined value. The 1138 marking is accomplished by the ingress edge by modifying the QoS NSLP 1139 default NSLP-ID value to a NSLP-ID predefined value, see Section 6.6. 1140 The egress stops this marking process by reassigning the QoS NSLP 1141 default NSLP-ID value to the original RESERVE message. The exact 1142 operation of modifying the NSLP-ID must be specified in the relevant 1143 QoS model specification. 1145 3.3.2. Support for Peer Change Identification 1147 There are several circumstances where it is necessary for a QNE to 1148 identify the adjacent QNE peer, which is the source of a signaling 1149 application message; e.g., it may be to apply the policy that "state 1150 can only be modified by messages from the node that created it" or it 1151 might be that keeping track of peer identity is used as a (fallback) 1152 mechanism for rerouting detection at the NSLP layer. 1154 This functionality is implemented in GIST service interface with SII- 1155 handle. As shown in the above example, we assume the SII- handling 1156 will support both own SII and peer SII. 1158 Keeping track of the SII of a certain reservation also provides a 1159 means for the QoS NSLP to detect route changes. When a QNE receives 1160 a RESERVE referring to existing state but with a different SII, it 1161 knows that its upstream peer has changed. It can then use the old 1162 SII to initiate a teardown along the old section of the path. This 1163 functionality is supported in GIST service interface when the peer's 1164 SII which is stored on message reception is passed to GIST upon 1165 message transmission. 1167 3.3.3. Support for Stateless Operation 1169 Stateless or reduced state QoS NSLP operation makes the most sense 1170 when some nodes are able to operate in a stateless way at GIST level 1171 as well. Such nodes should not worry about keeping reverse state, 1172 message fragmentation and reassembly (at GIST), congestion control or 1173 security associations. A stateless or reduced state QNE will be able 1174 to inform the underlying GIST of this situation. GIST service 1175 interface supports this functionality with the Retain-State attribute 1176 in the MessageReceived primitive. 1178 3.3.4. Priority of Signaling Messages 1180 The QoS NSLP will generate messages with a range of performance 1181 requirements for GIST. These requirements may result from a 1182 prioritization at the QoS NSLP (Section 3.2.11) or from the 1183 responsiveness expected by certain applications supported by the QoS 1184 NSLP. GIST service interface supports this with the 'priority' 1185 transfer attribute. 1187 3.3.5. Knowledge of Intermediate QoS NSLP Unaware Nodes 1189 In some cases it is useful to know that there are routers along the 1190 path where QoS cannot be provided. The GIST service interface 1191 supports this by keeping track of IP-TTL and Original-TTL in the 1192 RecvMessage primitive. A difference between the two indicates the 1193 number of QoS NSLP unaware nodes. In this case the QNE that detects 1194 this difference should set the "B" (BREAK) flag. If a QNE generates 1195 a QUERY, RESERVE or RESPONSE message, after receiving a QUERY or 1196 RESERVE message with a "Break" flag set, it can set the "B" (BREAK) 1197 flag in these messages. There are however, situations where the 1198 egress QNE in a local domain may have some other means to provide QoS 1199 [I-D.ietf-nsis-qspec]. For example, in an RMD-QOSM 1200 [I-D.ietf-nsis-rmd] (or RMD-QOSM like) aware local domain that uses 1201 either NTLP stateless nodes or NSIS unaware nodes the end to end 1202 RESERVE or QUERY message bypasses these NTLP stateless or NSIS 1203 unaware nodes. However, the reservation within the local domain can 1204 be signaled by the RMD-QOSM (or RMD-QOSM like QOSM). In such 1205 situations, the "B" (BREAK) flag in the end to end RESERVE or QUERY 1206 message should not be set by the edges of the local domain. 1208 4. Examples of QoS NSLP Operation 1210 The QoS NSLP can be used in a number of ways. The examples given 1211 here give an indication of some of the basic processing. However, 1212 they are not exhaustive and do not attempt to cover the details of 1213 the protocol processing. 1215 4.1. Sender-initiated Reservation 1217 QNI QNE QNE QNR 1218 | | | | 1219 | RESERVE | | | 1220 +--------->| | | 1221 | | RESERVE | | 1222 | +--------->| | 1223 | | | RESERVE | 1224 | | +--------->| 1225 | | | | 1226 | | | RESPONSE | 1227 | | |<---------+ 1228 | | RESPONSE | | 1229 | |<---------+ | 1230 | RESPONSE | | | 1231 |<---------+ | | 1232 | | | | 1233 | | | | 1235 Figure 7: Basic Sender Initiated Reservation 1237 To make a new reservation, the QNI constructs a RESERVE message 1238 containing a QSPEC object, from its chosen QoS model, which describes 1239 the required QoS parameters. 1241 The RESERVE message is passed to GIST which transports it to the next 1242 QNE. There it is delivered to the QoS NSLP processing which examines 1243 the message. Policy control and admission control decisions are 1244 made. The exact processing also takes into account the QoS model 1245 being used. The node performs appropriate actions (e.g., installing 1246 reservation) based on the QSPEC object in the message. 1248 The QoS NSLP then generates a new RESERVE message (usually based on 1249 the one received). This is passed to GIST, which forwards it to the 1250 next QNE. 1252 The same processing is performed at further QNEs along the path, up 1253 to the QNR. The determination that a node is the QNR may be made 1254 directly (e.g., that node is the destination for the data flow), or 1255 using GIST functionality to determine that there are no more QNEs 1256 between this node and the data flow destination. 1258 Any node may include a request for a RESPONSE in its RESERVE 1259 messages. It does so by including a Request Identification 1260 Information (RII) object in the RESERVE message. If the message 1261 already includes an RII, an interested QNE must not add a new RII 1262 object nor replace the old RII object. Instead it needs to remember 1263 the RII value so that it can match a RESPONSE message belonging to 1264 the RESERVE. When it receives the RESPONSE, it forwards the RESPONSE 1265 upstream towards the RII originating node. 1267 In this example, the RESPONSE message is forwarded peer-to-peer along 1268 the reverse of the path that the RESERVE message took (using GIST 1269 path state), and so is seen by all the QNEs on this segment of the 1270 path. It is only forwarded as far as the node which requested the 1271 RESPONSE originally. 1273 The reservation can subsequently be refreshed by sending further 1274 RESERVE messages containing the complete reservation information, as 1275 for the initial reservation. The reservation can also be modified in 1276 the same way, by changing the QSPEC data to indicate a different set 1277 of resources to reserve. 1279 The overhead required to perform refreshes can be reduced, in a 1280 similar way to that proposed for RSVP in RFC 2961 [RFC2961]. Once a 1281 RESPONSE message has been received indicating the successful 1282 installation of a reservation, subsequent refreshing RESERVE messages 1283 can simply refer to the existing reservation, rather than including 1284 the complete reservation specification. 1286 4.2. Sending a Query 1288 QUERY messages can be used to gather information from QNEs along the 1289 path. For example, they can be used to find out what resources are 1290 available before a reservation is made. 1292 In order to perform a query along a path, the QNE constructs a QUERY 1293 message. This message includes a QSPEC containing the actual query 1294 to be performed at QNEs along the path. It also contains an RII 1295 object used to match the response back to the query, and an indicator 1296 of the query scope (next node, whole path, proxy). The QUERY message 1297 is passed to GIST to forward it along the path. 1299 A QNE receiving a QUERY message should inspect it and create a new 1300 message, based on that received with the query objects modified as 1301 required. For example, the query may request information on whether 1302 a flow can be admitted, and so a node processing the query might 1303 record the available bandwidth. The new message is then passed to 1304 GIST for further forwarding (unless it knows it is the QNR, or is the 1305 limit for the scope in the QUERY). 1307 At the QNR, a RESPONSE message must be generated if the QUERY message 1308 includes a Request Identification Information (RII) object. Various 1309 objects from the received QUERY message have to be copied into the 1310 RESPONSE message. It is then passed to GIST to be forwarded peer-to- 1311 peer back along the path. 1313 Each QNE receiving the RESPONSE message should inspect the RII object 1314 to see if it 'belongs' to it (i.e., it was the one that originally 1315 created it). If it does not then it simply passes the message back 1316 to GIST to be forwarded upstream. 1318 If there was an error in processing a RESERVE, instead of an RII, the 1319 RESPONSE may carry an RSN. Thus, a QNE must also be prepared to look 1320 for an RSN object if no RII was present, and act based on the error 1321 code set in the INFO_SPEC of the RESPONSE. 1323 4.3. Basic Receiver-initiated Reservation 1325 As described in the NSIS framework [RFC4080] in some signaling 1326 applications, a node at one end of the data flow takes responsibility 1327 for requesting special treatment - such as a resource reservation - 1328 from the network. Both ends then agree whether sender or receiver- 1329 initiated reservation is to be done. In case of a receiver initiated 1330 reservation, both ends agree whether a "One Pass With Advertising" 1331 (OPWA) [opwa95] model is being used. This negotiation can be 1332 accomplished using mechanisms that are outside the scope of NSIS. 1334 To make a receiver-initiated reservation, the QNR constructs a QUERY 1335 message, which may contain a QSPEC object from its chosen QoS model 1336 (see Figure 8). The QUERY must have the RESERVE-INIT flag set. This 1337 QUERY message does not need to trigger a RESPONSE message and 1338 therefore, the QNI must not include the RII object (Section 5.4.2) in 1339 the QUERY message. The QUERY message may be used to gather 1340 information along the path, which is carried by the QSPEC object. An 1341 example of such information is the "One Pass With Advertising" (OPWA) 1342 [opwa95]. This QUERY message causes GIST reverse-path state to be 1343 installed. 1345 QNR QNE QNE QNI 1346 sender receiver 1347 | | | | 1348 | QUERY | | | 1349 +--------->| | | 1350 | | QUERY | | 1351 | +--------->| | 1352 | | | QUERY | 1353 | | +--------->| 1354 | | | | 1355 | | | RESERVE | 1356 | | |<---------+ 1357 | | RESERVE | | 1358 | |<---------+ | 1359 | RESERVE | | | 1360 |<---------+ | | 1361 | | | | 1362 | RESPONSE | | | 1363 +--------->| | | 1364 | | RESPONSE | | 1365 | +--------->| | 1366 | | | RESPONSE | 1367 | | +--------->| 1368 | | | | 1370 Figure 8: Basic Receiver Initiated Reservation 1372 The QUERY message is transported by GIST to the next downstream QoS 1373 NSLP node. There it is delivered to the QoS NSLP processing which 1374 examines the message. The exact processing also takes into account 1375 the QoS model being used and may include gathering information on 1376 path characteristics that may be used to predict the end-to-end QoS. 1378 The QNE generates a new QUERY message (usually based on the one 1379 received). This is passed to GIST, which forwards it to the next 1380 QNE. The same processing is performed at further QNEs along the 1381 path, up to the flow receiver. The receiver detects that this QUERY 1382 message carries the RESERVE-INIT flag and by using the information 1383 contained in the received QUERY message, such as the QSPEC, 1384 constructs a RESERVE message. 1386 The RESERVE is forwarded peer-to-peer along the reverse of the path 1387 that the QUERY message took (using GIST reverse path state). Similar 1388 to the sender-initiated approach, any node may include an RII in its 1389 RESERVE messages. The RESPONSE is sent back to confirm the resources 1390 are set up. The reservation can subsequently be refreshed with 1391 RESERVE messages in the upstream direction. 1393 4.4. Bidirectional Reservations 1395 The term "bidirectional reservation" refers to two different cases 1396 that are supported by this specification: 1398 o Binding two sender-initiated reservations together, e.g., one 1399 sender-initiated reservation from QNE A to QNE B and another one from 1400 QNE B to QNE A. 1402 o Binding a sender-initiated and a receiver-initiated reservation 1403 together, e.g., a sender-initiated reservation from QNE A towards QNE 1404 B, and a receiver-initiated reservation from QNE A towards QNE B for 1405 the data flow in the opposite direction (from QNE B to QNE A). This 1406 case is particularly useful when one end of the communication has all 1407 required information to set up both sessions. 1409 Both ends have to agree on which bi-directional reservation type they 1410 need to use. This negotiation/agreement can be accomplished using 1411 mechanisms that are outside the scope of NSIS. 1413 The scenario with two sender-initiated reservations is shown in 1414 Figure 9. Note that RESERVE messages for both directions may visit 1415 different QNEs along the path because of asymmetric routing. Both 1416 directions of the flows are bound by inserting the BOUND_SESSION_ID 1417 object at the QNI and QNR. RESPONSE messages are optional and not 1418 shown in the picture for simplicity. 1420 A QNE QNE B 1421 | | FLOW-1 | | 1422 |===============================>| 1423 |RESERVE-1 | | | 1424 QNI+--------->|RESERVE-1 | | 1425 | +-------------------->|QNR 1426 | | | | 1427 | | FLOW-2 | | 1428 |<===============================| 1429 | | |RESERVE-2 | 1430 | RESERVE-2 |<---------+QNI 1431 QNR|<--------------------+ | 1432 | | | | 1434 Figure 9: Bi-directional reservation for sender+sender scenario 1436 The scenario with a sender-initiated and a receiver-initiated 1437 reservation is shown in Figure 10. In this case, QNI B sends out two 1438 RESERVE messages, one for the sender-initiated and one for the 1439 receiver-initiated reservation. Note that the sequence of the two 1440 RESERVE messages may be interleaved. 1442 A QNE QNE B 1443 | | FLOW-1 | | 1444 |===============================>| 1445 | QUERY-1 | | | 1446 QNI+--------->| QUERY-1 | | 1447 | +-------------------->|QNR 1448 | | | | 1449 | |RESERVE-1 | | 1450 |RESERVE-1 +<--------------------|QNR 1451 QNI+<---------| | | 1452 | | | | 1453 | | FLOW-2 | | 1454 |<===============================| 1455 | | |RESERVE-2 | 1456 |RESERVE-2 | |<---------+QNI 1457 QNR|<--------------------+ | 1458 | | | | 1460 Figure 10: Bi-directional reservation for sender+receiver scenario 1462 4.5. Aggregate Reservations 1464 In order to reduce signaling and per-flow state in the network, the 1465 reservations for a number of flows may be aggregated. 1467 QNI QNE QNE/QNI' QNE' QNR'/QNE QNR 1468 aggregator deaggregator 1469 | | | | | | 1470 | RESERVE | | | | | 1471 +--------->| | | | | 1472 | | RESERVE | | | | 1473 | +--------->| | | | 1474 | | | RESERVE | | | 1475 | | +-------------------->| | 1476 | | | RESERVE' | | | 1477 | | +=========>| RESERVE' | | 1478 | | | +=========>| RESERVE | 1479 | | | | +--------->| 1480 | | | | RESPONSE'| | 1481 | | | RESPONSE'|<=========+ | 1482 | | |<=========+ | | 1483 | | | | | RESPONSE | 1484 | | | | RESPONSE |<---------+ 1485 | | |<--------------------+ | 1486 | | RESPONSE | | | | 1487 | |<---------+ | | | 1488 | RESPONSE | | | | | 1489 |<---------+ | | | | 1490 | | | | | | 1491 | | | | | | 1493 Figure 11: Sender Initiated Reservation with Aggregation 1495 An end-to-end per-flow reservation is initiated with the messages 1496 shown in Figure 11 as "RESERVE". 1498 At the aggregator a reservation for the aggregated flow is initiated 1499 (shown in Figure 11 as "RESERVE'"). This may use the same QoS model 1500 as the end-to-end reservation but has an MRI identifying the 1501 aggregated flow (e.g., tunnel) instead of for the individual flows. 1503 This document does not specify how the QSPEC of the aggregate session 1504 can be derived from the QSPECs of the end-to-end sessions. 1506 The messages used for the signaling of the individual reservation 1507 need to be marked such that the intermediate routers will not inspect 1508 them. In the QoS NSLP the following marking possibility is applied, 1509 see also RFC3175. 1511 All routers use essentially the same algorithm for which messages 1512 they process, i.e. all messages at aggregation level 0. However, 1513 messages have their aggregation level incremented on entry to an 1514 aggregation region and decremented on exit. In this technique the 1515 interior routers are not required to do any rewriting of the RAO 1516 values. However, the aggregating/deaggregating routers must be 1517 configured with which of their interfaces lie at which aggregation 1518 level, and also requires consistent message rewriting at these 1519 boundaries. 1521 In particular, the Aggregator performs the marking by modifying the 1522 QoS NSLP default NSLP-ID value to a NSLP-ID predefined value, see 1523 Section 6.6. A RAO value is then uniquely derivable from each 1524 predefined NSLP-ID. However, the RAO does not have to have a one-to- 1525 one relation to a specific NSLP-ID. 1527 Aggregator Deaggregator 1529 +---+ +---+ +---+ +---+ 1530 |QNI|-----|QNE|-----|QNE|-----|QNR| aggregate 1531 +---+ +---+ +---+ +---+ reservation 1533 +---+ +---+ ..... ..... +---+ +---+ 1534 |QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end 1535 +---+ +---+ ..... ..... +---+ +---+ reservation 1537 Figure 12: Reservation aggregation 1539 The deaggregator acts as the QNR for the aggregate reservation. 1540 Session binding information carried in the RESERVE message enables 1541 the deaggregator to associate the end-to-end and aggregate 1542 reservations with one another (using the BOUND_SESSION_ID). 1544 The key difference between this example and the one shown in Section 1545 4.5 is that the flow identifier for the aggregate is expected to be 1546 different to that for the end-to-end reservation. The aggregate 1547 reservation can be updated independently of the per-flow end-to-end 1548 reservations. 1550 4.6. Message Binding 1552 Section 4.5 sketches the interaction of an aggregated end-to-end flow 1553 and an aggregate. For this scenario, and probably others, it is 1554 useful to have a method for synchronizing signaling message exchanges 1555 of different sessions. This can be used to speed up signaling, 1556 because some message exchanges can be started simultaneously and can 1557 be processed in parallel until further processing of a message from 1558 one particular session depends on another message from a different 1559 session. For instance, in Figure 11 there is a case where inclusion 1560 of a new reservation requires to increase the capacity of the 1561 encompassing aggregate first. So the RESERVE (bound message) for the 1562 individual flow arriving at the deaggregator should wait until the 1563 RESERVE' (binding message) for the aggregate arrived successfully 1564 (otherwise the individual flow could not be included into the 1565 existing aggregate and cannot be admitted). Another alternative 1566 would be to increase the aggregate first and then to reserve 1567 resources for a set of aggregated individual flows. In this case the 1568 binding and synchronization between the (RESERVE and RESERVE') 1569 messages is not needed. 1571 A message binding may be used (depending an the aggregators policy) 1572 as follows: a QNE (aggregator QNI' in Figure 14) generates randomly a 1573 128-bit MSG_ID (same rules apply as for generating a SESSION_ID) and 1574 includes it as BOUND_MSG_ID object into the bound signaling message 1575 (RESERVE (1) in Figure 14) that should wait for the arrival of a 1576 related binding signaling message (RESERVE' (3) in Figure 14) that 1577 carries the associated MSG_ID object. The BOUND_SESSION_ID should 1578 also be set accordingly. Only one MSG_ID or BOUND_MSG_ID object per 1579 message is allowed. If the dependency relation between the two 1580 messages is bidirectional then the Message_Binding_Type flag is SET 1581 (value is 1). Otherwise, the Message_Binding_Type flag is UNSET. In 1582 most cases an RII object must be included in order to get a 1583 corresponding RESPONSE back. 1585 The receiving QNE enqueues (probably after some pre-processing) this 1586 message for the corresponding session. It also starts a MsgIDWait 1587 timer in order to discard the message in case the related 1588 "triggering" message (RESERVE' in Figure 15) does not arrive. The 1589 timeout period for this time SHOULD be set to the default 1590 retransmission timeout period (QOSNSLP_REQUEST_RETRY). In case a 1591 retransmitted RESERVE message arrives before the timeout it will 1592 simply override the waiting message (i.e. the latter is discarded and 1593 the new message is now waiting with the MsgIDWait timer being reset). 1594 At the same time, the "triggering" message including a MSG_ID object, 1595 carrying the same value as the BOUND_MSG_ID object is sent by the 1596 same initiating QNE (QNI' in Figure 13). The intermediate QNE' sees 1597 the MSG_ID object, but can determine that it is not the endpoint for 1598 the session (QNR') and therefore simply forwards the message after 1599 normal processing. The receiving QNE (QNR') as endpoint for the 1600 aggregate session (i.e., deaggregator) interprets the MSG_ID object 1601 and looks for a corresponding waiting message with a BOUND_MSG_ID of 1602 the same value whose waiting condition is satisfied now. Depending 1603 on successful processing of the RESERVE' (3), processing of the 1604 waiting RESERVE will be resumed and the MsgIDWait timer will be 1605 stopped as soon as the related RESERVE' arrived. 1607 QNI QNE QNE/QNI' QNE' QNR'/QNE QNR 1608 aggregator deaggregator 1609 | | | | | | 1610 | RESERVE | | | | | 1611 +--------->| | | | | 1612 | | RESERVE | | | | 1613 | +--------->| | | | 1614 | | | RESERVE | | | 1615 | | | (1) | | | 1616 | | +-------------------->| | 1617 | | | RESERVE' | | | 1618 | | | (2) | | | 1619 | | +=========>| RESERVE' | | 1620 | | | | (3) | | 1621 | | | +=========>| RESERVE | 1622 | | | | | (4) | 1623 | | | | +--------->| 1624 | | | | RESPONSE'| | 1625 | | | RESPONSE'|<=========+ | 1626 | | |<=========+ | | 1627 | | | | | RESPONSE | 1628 | | | | RESPONSE |<---------+ 1629 | | |<--------------------+ | 1630 | | RESPONSE | | | | 1631 | |<---------+ | | | 1632 | RESPONSE | | | | | 1633 |<---------+ | | | | 1634 | | | | | | 1635 | | | | | | 1637 (1): RESERVE: SESSION_ID=F, BOUND_MSG_ID=x, BOUND_SESSION_ID=A 1638 (2)+(3): RESERVE': SESSION_ID=A, MSG_ID=x 1639 (4): RESERVE: SESSION_ID=F (MSG_ID object was removed) 1641 Figure 13: Example for using message binding 1643 Several further cases have to be considered in this context: 1645 o "Triggering message" (3) arrives before waiting (bound) message 1646 (1): In this case the processing of the triggering message depends 1647 on the value of the Message_Binding_Type flag. If 1648 Message_Binding_Type is UNSET (value is 0) then the triggering 1649 message can be processed normally, but the MSG_ID and the result 1650 (success or failure) should be saved for the waiting message. 1651 Thus the RESPONSE' can be sent by the QNR' immediately. If the 1652 waiting message (1) finally arrives at the QNR', it can be 1653 detected that the waiting condition was already satisfied, because 1654 the triggering message already arrived earlier. If 1655 Message_Binding_Type is SET (value is 1) then the triggering 1656 message interprets the MSG_ID object and looks for the 1657 corresponding waiting message with a BOUND_MSG_ID of the same 1658 value, which in this case has not yet arrived. It then starts a 1659 MsgIDWait timer in order to discard the message in case the 1660 related message (RESERVE (1) in Figure 14) does not arrive. 1661 Depending on successful processing of the RESERVE (1), processing 1662 of the waiting RESERVE' will be resumed, the MsgIDWait timer will 1663 be stopped as soon as the related RESERVE arrived and the 1664 RESPONSE' can be sent by the QNR' towards the QNI'. 1665 o The "triggering message" (3) does not arrive at all: this may be 1666 the case due to message loss (which will cause a retransmission by 1667 the QNI' if the RII object is included) or due to a reservation 1668 failure at an intermediate node (QNE' in the example). The 1669 MsgIDWait timeout will then simply discard the waiting message at 1670 QNR'. In this case the QNR' MAY send a RESPONSE message towards 1671 the QNI informing that the synchronisation of the two messages has 1672 failed. 1673 o Retransmissions should use the same MSG_ID, because usually only 1674 one message of the two related messages is retransmitted. As 1675 mentioned above: retransmissions will only occur if the RII object 1676 is set in the RESERVE. If a retransmitted message with a MSG_ID 1677 arrives while a bound message with the same MSG_ID is still 1678 waiting, the retransmitted message will replace the bound message. 1680 For a receiving node there are conceptually two lists indexed by 1681 message IDs. One list contains the IDs and results of triggering 1682 messages (those carrying a MSG_ID object), the other list contains 1683 the IDs and message contents of the bound waiting messages (those who 1684 carried a BOUND_MSG_ID). The former list is used when a triggering 1685 message arrives before the bound message. The latter list is used 1686 when a bound message arrives before a triggering message. 1688 4.7. Reduced State or Stateless Interior Nodes 1690 This example uses a different QoS model within a domain, in 1691 conjunction with GIST and NSLP functionality which allows the 1692 interior nodes to avoid storing GIST and QoS NSLP state. As a result 1693 the interior nodes only store the QSPEC-related reservation state, or 1694 even no state at all. This allows the QoS model to use a form of 1695 "reduced-state" operation, where reservation states with a coarser 1696 granularity (e.g., per-class) are used, or a "stateless" operation 1697 where no QoS NSLP state is needed (or created). 1699 The key difference between this example and the use of different QoS 1700 models in Section 4.5 is that the transport characteristics for the 1701 reservation, i.e., GIST can be used in a different way for the edge- 1702 to-edge and hop-by-hop sessions. The reduced state reservation can 1703 be updated independently of the per-flow end-to-end reservations. 1705 4.7.1. Sender-initiated Reservation 1707 The QNI initiates a RESERVE message (see Fig. 14). At the QNEs on 1708 the edges of the stateless or reduced-state region the processing is 1709 different and the nodes support two QoS models. At the ingress the 1710 original RESERVE message is forwarded but ignored by the stateless or 1711 reduced-state nodes. This is accomplished by marking this message, 1712 i.e., modifying the QoS NSLP default NSLP-ID value to another NSLP-ID 1713 predefined value (see Section 4.6). The marking must be accomplished 1714 by the ingress by modifying the QoS_NSLP default NSLP-ID value to a 1715 NSLP-ID predefined value. The egress must reassign the QoS NSLP 1716 default NSLP-ID value to the original end-to-end RESERVE message. An 1717 example of such operation is given in [I-D.ietf-nsis-rmd]. 1719 The egress node is the next QoS NSLP hop for the end-to-end RESERVE 1720 message. Reliable GIST transfer mode can be used between the ingress 1721 and egress without requiring GIST state in the interior. At the 1722 egress node the RESERVE message is then forwarded normally. 1724 At the ingress a second RESERVE' message is also built (Fig. 14). 1725 This makes use of a QoS model suitable for a reduced state or 1726 stateless form of operation (such as the RMD per hop reservation). 1727 Since the original RESERVE and the RESERVE' messages are addressed 1728 identically, the RESERVE' message also arrives at the same egress QNE 1729 that was also traversed by the RESERVE message. Message binding is 1730 used to synchronize the messages. 1732 When processed by interior (stateless) nodes the QoS NSLP processing 1733 exercises its options to not keep state wherever possible, so that no 1734 per flow QoS NSLP state is stored. Some state, e.g., per class, for 1735 the QSPEC related data may be held at these interior nodes. The QoS 1736 NSLP also requests that GIST use different transport characteristics 1737 (e.g., sending of messages in unreliable GIST transfer mode). It 1738 also requests the local GIST processing not to retain messaging 1739 association state or reverse message routing state. 1741 Nodes, such as those in the interior of the stateless or reduced- 1742 state domain, that do not retain reservation state cannot send back 1743 RESPONSE messages (and so cannot use the refresh reduction 1744 extension). 1746 At the egress node the RESERVE' message is interpreted in conjunction 1747 with the reservation state from the end-to-end RESERVE message (using 1748 information carried in the message to correlate the signaling flows). 1749 The RESERVE message is only forwarded further if the processing of 1750 the RESERVE' message was successful at all nodes in the local domain, 1751 otherwise the end-to-end reservation is regarded as having failed to 1752 be installed. Note that the egress should use a timer, with a 1753 preconfigured value, that can be used to synchronise the arrival of 1754 both messages, i.e., the end-to-end RESERVE message and the local 1755 RESERVE' message. 1757 QNE QNE QNE QNE 1758 ingress interior interior egress 1759 GIST stateful GIST stateless GIST stateless GIST stateful 1760 | | | | 1761 RESERVE | | | | 1762 -------->| RESERVE | | | 1763 +--------------------------------------------->| 1764 | RESERVE' | | | 1765 +-------------->| | | 1766 | | RESERVE' | | 1767 | +-------------->| | 1768 | | | RESERVE' | 1769 | | +------------->| 1770 | | | RESPONSE' | 1771 |<---------------------------------------------+ 1772 | | | | RESERVE 1773 | | | +--------> 1774 | | | | RESPONSE 1775 | | | |<-------- 1776 | | | RESPONSE | 1777 |<---------------------------------------------+ 1778 RESPONSE| | | | 1779 <--------| | | | 1781 Figure 14: Sender-initiated reservation with Reduced State Interior 1782 Nodes 1784 4.7.2. Receiver-initiated Reservation 1786 Since NSLP neighbor relationships are not maintained in the reduced- 1787 state region, only sender-initiated signaling can be supported within 1788 the reduced state region. If a receiver-initiated reservation over a 1789 stateless or reduced state domain is required this can be implemented 1790 as shown in Figure 15. 1792 QNE QNE QNE 1793 ingress interior egress 1794 GIST stateful GIST stateless GIST stateful 1795 | | | 1796 QUERY | | | 1797 -------->| QUERY | | 1798 +------------------------------>| 1799 | | | QUERY 1800 | | +--------> 1801 | | | RESERVE 1802 | | |<-------- 1803 | | RESERVE | 1804 |<------------------------------+ 1805 | RESERVE' | RESERVE' | 1806 |-------------->|-------------->| 1807 | | RESPONSE' | 1808 |<------------------------------+ 1809 RESERVE | | | 1810 <--------| | | 1812 Figure 15: Receiver-initiated reservation with Reduced State Interior 1813 Nodes 1815 The RESERVE message that is received by the egress QNE of the 1816 stateless domain is sent transparently to the ingress QNE (known as 1817 the source of the QUERY message). When the RESERVE message reaches 1818 the ingress, the ingress QNE needs to send a sender- initiated 1819 RESERVE' over the stateless domain. The ingress QNE needs to wait 1820 for a RESPONSE'. If the RESPONSE' notifies that the reservation was 1821 accomplished successfully then the ingress QNE sends a RESERVE 1822 message further upstream. 1824 4.8. Proxy Mode 1826 Besides the sender- and receiver-initiated reservations, the QoS NSLP 1827 includes a functionality we refer to as Proxy Mode. Here a QNE is 1828 set by administrator assignment to work as a proxy QNE (P-QNE) for a 1829 certain region, e.g., for an administrative domain. A node 1830 initiating the signaling may set the PROXY scope flag to indicate 1831 that the signaling is meant to be confined within the area controlled 1832 by the proxy, e.g., the local access network. 1834 The Proxy Mode has two uses. First it allows to confine the QoS NSLP 1835 signaling to a pre-defined section of the path. Secondly, it allows 1836 a node to make reservations for an incoming data flow. 1838 For outgoing data flows and sender-initiated reservations, the end 1839 host is the QNI, and sends a RESERVE with the PROXY scope flag set. 1841 The P-QNE is the QNR, it will receive the RESERVE, notice the PROXY 1842 scope flag is set and reply with a RESPONSE (if requested). This 1843 operation is the same as illustrated in Figure 7. The receiver- 1844 oriented reservation for outgoing flows works the same way as in 1845 Figure 8, the P-QNE is the QNI. 1847 For incoming data flows, the end host is the QNI, and it sends a 1848 RESERVE towards the data sender with the PROXY scope flag set. Here 1849 the end host sets the MRI so that it indicates the end host as the 1850 receiver of the data, and sets the D-flag. 1852 GIST is able to send messages towards the data sender if there is 1853 existing message routing state or it is able to use the Upstream Q- 1854 mode Encapsulation. In some cases GIST will be unable to determine 1855 the appropriate next hop for the message, and so will indicate a 1856 failure to deliver it (by sending an error message). This may occur, 1857 for example, if GIST attempts to determine an upstream next hop and 1858 there are multiple possible inbound routes that could be used. 1860 Bi-directional reservations, as discussed in Section 4.4. The P-QNE 1861 will be the QNR or QNI for reservations. 1863 If the PROXY scope flag is set in an incoming QoS NSLP message, the 1864 QNE must set the same flag in all QoS NSLP messages it sends that are 1865 related to this session. 1867 5. QoS NSLP Functional Specification 1869 5.1. QoS NSLP Message and Object Formats 1871 A QoS NSLP message consists of a common header, followed by a body 1872 consisting of a variable number of variable-length, typed "objects". 1873 The common header and other objects are encapsulated together in a 1874 GIST NSLP-Data object. The following subsections define the formats 1875 of the common header and each of the QoS NSLP message types. In the 1876 message formats, the common header is denoted as COMMON_HEADER. 1878 For each QoS NSLP message type, there is a set of rules for the 1879 permissible choice of object types. These rules are specified using 1880 the Augmented Backus-Naur Form (ABNF) specified in RFC 4234 1881 [RFC4234]. The ABNF implies an order for the objects in a message. 1882 However, in many (but not all) cases, object order makes no logical 1883 difference. An implementation SHOULD create messages with the 1884 objects in the order shown here, but MUST accept the objects in any 1885 order. 1887 5.1.1. Common Header 1889 All GIST NSLP-Data objects for the QoS NSLP MUST contain this common 1890 header as the first 32 bits of the object (this is not the same as 1891 the GIST Common Header). 1893 0 1 2 3 1894 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 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | Message Type | Message Flags | Generic Flags | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 The fields in the common header are as follows: 1901 Msg Type: 8 bits 1903 1 = RESERVE 1905 2 = QUERY 1907 3 = RESPONSE 1909 4 = NOTIFY 1911 Message-specific flags: 8 bits 1913 These flags are defined as part of the specfication of individual 1914 messages, and, thus, are different with each message type. 1916 Generic flags: 16 bits 1918 Generic flags have the same meaning for all message types. There 1919 exist currently three generic flags, the (next hop) Scoping flag (S), 1920 the Proxy scope flag (P) and the Acknowledgement Requested (A). 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Reserved |B|A|P|S| 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 SCOPING (S) - when set, indicates that the message is scoped and 1927 should not travel down the entire path but only as far as the next 1928 QNE (scope="next hop"). By default, this flag is not set (default 1929 scope="whole path"). 1931 PROXY (P) - when set, indicates that the message is scoped, and 1932 should not travel down the entire path but only as far as the P-QNE. 1933 By default, this flag is not set. 1935 ACK-REQ (A) - when set, indicates that the message should be 1936 acknowledged by the receiving peer. The flag is only used between 1937 stateful peers, and only used with RESERVE and QUERY messages. 1938 Currently, the flag is only used with refresh messages. By default 1939 the flag is not set. 1941 BREAK (B) - when set, indicates that there are routers along the path 1942 where QoS cannot be provided. 1944 The set of appropriate flags depends on the particular message being 1945 processed. Any bit not defined as a flag for a particular message 1946 MUST be set to zero on sending and MUST be ignored on receiving. 1948 The ACK-REQ flag is useful when a QNE wants to make sure the messages 1949 received by the downstream QNE are truly processed by the QoS NSLP, 1950 not just delivered by GIST. This is useful for faster dead peer 1951 diagnostics on the NSLP layer. This liveliness test can only be used 1952 with refresh RESERVE messages. The ACK-REQ-flag must not be set for 1953 RESERVE messages that already include an RII object, since a 1954 confirmation has already been requested from the QNR. Reliable 1955 transmission of messages between two QoS NSLP peer should be handled 1956 by GIST, not the NSLP by itself. 1958 5.1.2. Message Formats 1960 5.1.2.1. RESERVE 1962 The format of a RESERVE message is as follows: 1964 RESERVE = COMMON_HEADER 1965 RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ] 1966 [ SESSION_ID_LIST [ RSN_LIST ] ] 1967 [ MSG_ID / BOUND_MSG_ID ] [ INFO_SPEC ] 1968 [ [ PACKET_CLASSIFIER ] QSPEC ] 1970 The RSN is the only mandatory object and MUST always be present in 1971 all cases. A QSPEC MUST be included in the initial RESERVE sent 1972 towards the QNR. A PACKET_CLASSIFIER MAY be provided. If the 1973 PACKET_CLASSIFIER is not provided, then the full set of information 1974 provided in the GIST MRI for the session should be used for packet 1975 classification purposes. 1977 Subsequent RESERVE messages meant as reduced refreshes, where no 1978 QSPEC is provided, MUST NOT include a PACKET_CLASSIFIER either. 1980 There are no requirements on transmission order, although the above 1981 order is recommended. 1983 Two message-specific flags are defined for use in the common header 1984 with the RESERVE message. These are: 1986 +-+-+-+-+-+-+-+-+ 1987 |Reserved |T|R| 1988 +-+-+-+-+-+-+-+-+ 1990 TEAR (T) - when set, indicates that reservation state and QoS NSLP 1991 operation state should be torn down. The former is indicated to the 1992 RMF. Depending on the QoS model, the tear message may include a 1993 QSPEC to further specify state removal, e.g., for an aggregation, the 1994 QSPEC may specify the amount of resources removed from the aggregate. 1996 REPLACE (R) - when set the flag has two uses. First, it indicates 1997 that a RESERVE with different MRI (but same SID) replaces an existing 1998 one, so the old one MAY be torn down immediately. This is the 1999 default situation. This flag may be unset to indicate a desire from 2000 an upstream node to keep an existing reservation on an old branch in 2001 place. Second, this flag is also used to indicate whether the 2002 reserved resources on the old branch should be torn down or not when 2003 a data path change happens. In this case, the MRI is the same and 2004 only the route path changes. 2006 If the REFRESH_PERIOD is not present, a default value of 30 seconds 2007 is assumed. 2009 If the session of this message is bound to another session, then the 2010 RESERVE message SHOULD include the SESSION_ID of that other session 2011 in a BOUND_SESSION_ID object. In the situation of aggregated 2012 tunnels, the aggregated session MAY not include the SESSION_ID of its 2013 bound sessions in BOUND_SESSION_ID(s). 2015 The negotiation of whether to perform sender or receiver-initiated 2016 signaling is done outside the QoS NSLP. Yet, in theory, it is 2017 possible that a "reservation collision" may occur if the sender 2018 believes that a sender-initiated reservation should be performed for 2019 a flow, whilst the other end believes that it should be starting a 2020 receiver- initiated reservation. If different session identifiers 2021 are used then this error condition is transparent to the QoS NSLP 2022 though it may result in an error from the RMF, otherwise the removal 2023 of the duplicate reservation is left to the QNIs/QNRs for the two 2024 sessions. 2026 If a reservation is already installed and a RESERVE message is 2027 received with the same session identifier from the other direction 2028 (i.e., going upstream where the reservation was installed by a 2029 downstream RESERVE message, or vice versa) then an error indicating 2030 "RESERVE received from wrong direction" MUST be sent in a RESPONSE 2031 message to the signaling message source for this second RESERVE. 2033 A refresh right along the path can be forced by requesting a RESPONSE 2034 from the far end (i.e., by including an RII object in the RESERVE 2035 message). Without this, a refresh RESERVE would not trigger RESERVE 2036 messages to be sent further along the path, as each hop has its own 2037 refresh timer. 2039 A QNE may ask for confirmation of tear operation by including an RII 2040 object. Retransmissions SHOULD be disabled. A QNE sending a tearing 2041 RESERVE with an RII included MAY ask GIST to use reliable transport. 2042 When the QNE sends out a tearing RESERVE, it MUST NOT send refresh 2043 messages anymore. 2045 If the routing path changed due to mobility and the mobile node's IP 2046 address changed, and it sent a Mobile IP binding update, the 2047 resulting refresh is a new RESERVE. This RESERVE includes a new MRI 2048 and will be propagated end-to-end; there is no need to force end-to- 2049 end forwarding by including an RII. 2051 Note: It is possible for a host to use this mechanism to constantly 2052 force the QNEs on the path to send refreshing RESERVE messages. It 2053 may, therefore, be appropriate for QNEs to perform rate limiting on 2054 the refresh messages that they send. 2056 5.1.2.2. QUERY 2058 The format of a QUERY message is as follows: 2059 QUERY = COMMON_HEADER 2060 [ RII ][ *BOUND_SESSION_ID ] 2061 [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC 2063 QUERY messages MUST always include a QSPEC. QUERY messages MAY 2064 include a PACKET_CLASSIFIER when the message is used to trigger a 2065 receiver-initiated reservation. If a PACKET_CLASSIFIER is not 2066 included then the full GIST MRI should be used for packet 2067 classification purposes in the subsequent RESERVE. A QUERY message 2068 MAY contain a second QSPEC object. 2070 A QUERY message for requesting information about network resources 2071 MUST contain an RII object to match an incoming RESPONSE to the 2072 QUERY. 2074 The QSPEC object describes what is being queried for and may contain 2075 objects that gather information along the data path. There are no 2076 requirements on transmission order, although the above order is 2077 recommended. 2079 One message-specific flags are defined for use in the common header 2080 with the QUERY message. This is: 2082 +-+-+-+-+-+-+-+-+ 2083 |Reserved |R| 2084 +-+-+-+-+-+-+-+-+ 2086 RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger 2087 for the recipient to make a resource reservation by sending a 2088 RESERVE. 2090 If the session of this message is bound to another session, then the 2091 RESERVE message SHOULD include the SESSION_ID of that other session 2092 in a BOUND_SESSION_ID object. In the situation of aggregated 2093 tunnels, the aggregated session MAY not include the SESSION_ID of its 2094 bound sessions in BOUND_SESSION_ID(s). 2096 5.1.2.3. RESPONSE 2098 The format of a RESPONSE message is as follows: 2100 RESPONSE = COMMON_HEADER 2101 [ RII / RSN ] INFO_SPEC [SESSION_ID_LIST [ RSN_LIST ] ] 2102 [ QSPEC ] 2104 A RESPONSE message MUST contain an INFO_SPEC object which indicates 2105 the success of a reservation installation or an error condition. 2106 Depending on the value of the INFO_SPEC, the RESPONSE MAY also 2107 contain a QSPEC object. The value of an RII or an RSN object was 2108 provided by some previous QNE. There are no requirement on 2109 transmission order, although the above order is recommended. 2111 No message-specific flags are defined for use in the common header 2112 with the RESPONSE message. 2114 5.1.2.4. NOTIFY 2116 The format of a NOTIFY message is as follows: 2118 NOTIFY = COMMON_HEADER 2119 INFO_SPEC [ QSPEC ] 2121 A NOTIFY message MUST contain an INFO_SPEC object indicating the 2122 reason for the notification. Depending on the INFO_SPEC value, it 2123 MAY contain a QSPEC object providing additional information. 2125 No message-specific flags are defined for use with the NOTIFY 2126 message. 2128 5.1.3. Object Formats 2130 The QoS NSLP uses a Type-Length-Value (TLV) object format similar to 2131 that used by GIST. Every object consists of one or more 32-bit words 2132 with a one-word header. For convenience the standard object header 2133 is shown here: 2135 0 1 2 3 2136 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 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 |A|B|r|r| Type |r|r|r|r| Length | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 The value for the Type field comes from the shared NSLP object type 2142 space, the various objects are presented in subsequent sections. The 2143 Length field is given in units of 32 bit words and measures the 2144 length of the Value component of the TLV object (i.e., it does not 2145 include the standard header). 2147 The bits marked 'A' and 'B' are flags used to signal the desired 2148 treatment for objects whose treatment has not been defined in the 2149 protocol specification (i.e., whose Type field is unknown at the 2150 receiver). The following four categories of object have been 2151 identified, and are described here. 2153 AB=00 ("Mandatory"): If the object is not understood, the entire 2154 message containing it MUST be rejected, and an error message sent 2155 back. 2157 AB=01 ("Ignore"): If the object is not understood, it MUST be deleted 2158 and the rest of the message processed as usual. 2160 AB=10 ("Forward"): If the object is not understood, it MUST be 2161 retained unchanged in any message forwarded as a result of message 2162 processing, but not stored locally. 2164 AB=11 ("Refresh"): If the object is not understood, it should be 2165 incorporated into the locally stored QoS NSLP signaling application 2166 operational state for this flow/session, forwarded in any resulting 2167 message, and also used in any refresh or repair message which is 2168 generated locally. The contents of this object does not need to be 2169 interpreted, and should only be stored as bytes on the QNE. 2171 The remaining bits marked 'r' are reserved. The extensibility flags 2172 AB are similar to those used in the GIST specification. All objects 2173 defined in this specification MUST be understood by all QNEs, thus, 2174 they MUST have the AB-bits set to "00". A QoS NSLP implementation 2175 must recognize objects of the following types: RII, RSN, 2176 REFRESH_PERIOD, BOUND_SESSION_ID, INFO_SPEC, and QSPEC. 2178 The object header is followed by the Value field, which varies for 2179 different objects. The format of the Value field for currently 2180 defined objects is specified below. 2182 The object diagrams here use '//' to indicate a variable sized field. 2184 5.1.3.1. Request Identification Information (RII) 2186 Type: 0x01 2188 Length: Fixed - 1 32-bit word 2190 Value: An identifier which MUST be (probabilistically) unique within 2191 the context of a SESSION_ID, and SHOULD be different every time a 2192 RESPONSE is desired. Used by a QNE to match back a RESPONSE to a 2193 request in a RESERVE or QUERY message. 2195 0 1 2 3 2196 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 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | Response Identification Information (RII) | 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 5.1.3.2. Reservation Sequence Number (RSN) 2203 Type: 0x02 2205 Length: Fixed - 2 32-bit words 2207 Value: An incrementing sequence number that indicates the order in 2208 which state modifying actions are performed by a QNE, and an epoch 2209 identifier to allow the identification of peer restarts. The RSN has 2210 local significance only, i.e., between a QNE and its downstream 2211 stateful peers. The RSN is not reset when the downstream peer 2212 changes. 2214 0 1 2 3 2215 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 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | Reservation Sequence Number (RSN) | 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 | Epoch Identifier | 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 5.1.3.3. Refresh Period (REFRESH_PERIOD) 2224 Type: 0x03 2226 Length: Fixed - 1 32-bit word 2228 Value: The refresh timeout period R used to generate this message; in 2229 milliseconds. 2231 0 1 2 3 2232 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 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | Refresh Period (R) | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 5.1.3.4. Bound Session ID (BOUND_SESSION_ID) 2239 Type: 0x04 2241 Length: Fixed - 5 32-bit words 2243 Value: contains an 8-bit Binding_Code that indicates the nature of 2244 binding. The rest specifies the SESSION_ID (as specified in GIST 2245 [I-D.ietf-nsis-ntlp]) of the session that MUST be bound to the 2246 session associated with the message carrying this object. 2248 0 1 2 3 2249 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 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 | RESERVED | Binding Code | 2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2253 | | 2254 + + 2255 | | 2256 + Session ID + 2257 | | 2258 + + 2259 | | 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 Currently defined Binding Codes are: 2264 o 0x01 - Tunnel and end-to-end sessions 2266 o 0x02 - Bi-directional sessions 2268 o 0x03 - Aggregate sessions 2269 o 0x04 - Dependent sessions (binding session is alive only if the 2270 other session is also alive) 2272 o 0x05 - Indicated session caused pre-emption 2274 More binding codes maybe defined based on the above four atomic 2275 binding actions. Note a message may include more than one 2276 BOUND_SESSION_ID object. This may be needed in case one needs to 2277 define more specifically the reason for binding, or if the session 2278 must on depend on more than one other session (with possibly 2279 different reasons). Note that a session with e.g., SID_A (the 2280 binding session) can express its unidirectional dependency relation 2281 to another session with e.g., SID_B (the bound session) by including 2282 a BOUND_SESSION_ID object containing SID_B in its messages. 2284 5.1.3.5. Packet Classifier (PACKET_CLASSIFIER) 2286 Type: 0x05 2288 Length: Variable 2290 Value: Contains a variable length MRM-specific data 2292 0 1 2 3 2293 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 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 // Method-specific classifier data (variable) // 2296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 At this stage, the QoS NSLP only uses the path-coupled routing MRM. 2299 The method-specific classifier data is two bytes long and consists of 2300 a set of flags: 2302 0 1 2 3 2303 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 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 |X|Y|P|T|F|S|A|B| Reserved | 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 The flags are: 2310 X - Source Address and Prefix 2312 Y - Destination Address and Prefix 2314 P - Protocol 2316 T - DiffServ Code Point 2317 F - Flow Label 2319 S - SPI 2321 A - Source Port 2323 B - Destination Port 2325 The flags indicate which fields from the MRI MUST be used by the 2326 packet classifier. This allows a subset of the information in the 2327 MRI to be used for identifying the set of packets which are part of 2328 the reservation. Flags MUST only be set if the data is present in 2329 the MRI (i.e., where there is a corresponding flag in the GIST MRI, 2330 the flag can only be set if the corresponding GIST MRI flag is set). 2331 It should be noted that some flags in the PACKET_CLASSIFIER (X and Y) 2332 relate to data that is always present in the MRI, but are optional to 2333 use for QoS NSLP packet classification. The appropriate set of flags 2334 set may depend, to some extent, on the QoS model being used. 2336 As mentioned earlier in this section, the QoS NSLP is currently only 2337 defined for use with the Path-Coupled Message Routing Mechanism (MRM) 2338 in GIST. Future work may extend the QoS NSLP to additional routing 2339 mechanisms. Such MRMs must include sufficient information in the MRI 2340 to allow the subset of packets for which QoS is to be provided to be 2341 identified. When QoS NSLP is extended to support a new MRM, 2342 appropriate method-specific classifier data for the PACKET_CLASSIFIER 2343 object MUST be defined. 2345 5.1.3.6. Information Object (INFO_SPEC) and Error Codes 2347 Type: 0x06 2349 Length: Variable 2351 Value: Contains a 16-bit error code, a 4-bit error class, a 4-bit 2352 error source identifier type, and an 8-bit error source identifier 2353 length (in 32-bit words), an error source identifier and optionally 2354 variable length error-specific information. 2356 0 1 2 3 2357 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 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 | Error Code |E-Class|ESI Typ| ESI-Length | 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 // Error Source Identifier // 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 // Optional error-specific information // 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 Class Field: 2367 The four E-Class bits of the object indicate the error severity 2368 class. The currently defined severity classes are: 2370 o 0x01 - Informational 2372 o 0x02 - Success 2374 o 0x03 - Protocol Error 2376 o 0x04 - Transient Failure 2378 o 0x05 - Permanent Failure 2380 o 0x06 - QoS Model Error 2382 Error field: 2384 Within each error severity class a number of error values are 2385 defined. 2387 o Informational: 2389 * 0x01 - Unknown BOUND_SESSION_ID: the message refers to an unknown 2390 SESSION_ID in its BOUND_SESSION_ID object. 2392 * 0x02 - Route Change: possible route change occurred on downstream 2393 path. 2395 * 0x03 - Reduced refreshes not supported, full QSPEC required. 2397 * 0x04 - Congestion situation: Possible congestion situation occurred 2398 on downstream path. 2400 * 0x05 - Unknown SESSION ID in SESSION_ID_LIST 2402 * 0x06 - Mismatching RSN in RSN LIST 2404 o Success: 2406 * 0x01 - Reservation successful 2408 * 0x02 - Tear down successful 2410 * 0x03 - Acknowledgement 2412 * 0x04 - Refresh successful 2413 o Protocol Error: 2415 * 0x01 - Illegal message type: the type given in the Message Type 2416 field of the common header is unknown. 2418 * 0x02 - Wrong message length: the length given for the message does 2419 not match the length of the message data. 2421 * 0x03 - Bad flags value: an undefined flag or combination of flags 2422 was set in the generic flags 2424 * 0x04 - Bad flags value: an undefined flag or combination of flags 2425 was set in the message-specific flags 2427 * 0x05 - Mandatory object missing: an object required in a message of 2428 this type was missing. 2430 * 0x06 - Illegal object present: an object was present which must not 2431 be used in a message of this type. 2433 * 0x07 - Unknown object present: an object of an unknown type was 2434 present in the message. 2436 * 0x08 - Wrong object length: the length given for the object did not 2437 match the length of the object data present. 2439 * 0x09 - RESERVE received from wrong direction. 2441 * 0x0a - Unknown object field value: a field in an object had an 2442 unknown value. 2444 * 0x0b - Duplicate object present. 2446 * 0x0c - Malformed QSPEC. 2448 * 0x0d - Unknown MRI. 2450 * 0x0e - Erroneous value in the TLV object's value field. 2452 * 0x0f - Incompatible QSPEC 2454 o Transient Failure: 2456 * 0x01 - No GIST reverse-path forwarding state 2458 * 0x02 - No path state for RESERVE, when doing a receiver- oriented 2459 reservation 2460 * 0x03 - RII conflict 2462 * 0x04 - Full QSPEC required 2464 * 0x05 - Mismatch synchronization between end-to-end RESERVE and 2465 intra-domain RESERVE 2467 * 0x06 - Reservation preempted 2469 * 0x07 - Reservation failure 2471 * 0x08 - Path truncated - Next peer dead 2473 o Permanent Failure: 2475 * 0x01 - Internal or system error 2477 * 0x02 - Authorization failure 2479 o QoS Model Error: 2481 This error class can be used by QoS Models to add error codes 2482 specific to the QoS Model being used. All these errors and events 2483 are created outside the QoS NSLP itself. The error codes in this 2484 class are defined in QoS model specifications. Note that this error 2485 class may also include codes that are not purely errors, but rather 2486 some non-fatal information. 2488 Error Source Identifier 2490 The Error Source Identifier is for diagnostic purposes and its 2491 inclusion is OPTIONAL. It is suggested that implementations use this 2492 for the IP address, host name or other identifier of the QNE 2493 generating the INFO_SPEC to aid diagnostic activities. A QNE SHOULD 2494 NOT be used in any other purpose other than error logging or 2495 presenting to the user as part of any diagnostic information. A QNE 2496 SHOULD NOT attempt to send a message to that address. 2498 If no Error Source Identifier is included, the Error Source 2499 Identifier Type field must be zero. 2501 Currently three Error Source Identifiers have been defined: IPv4, 2502 IPv6 and FQDN. 2504 Error Source Identifier: IPv4 2506 Error Source Identifier Type: 0x01 2507 0 1 2 3 2508 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 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | 32-bit IPv4 address | 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 Error Source Identifier: IPv6 2515 Error Source Identifier Type: 0x02 2517 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 2518 1 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | | 2522 + + 2523 | | 2524 + 128-bit IPv6 address + 2525 | | 2526 + + 2527 | | 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 Error Source Identifier: FQDN name in UTF-8 2532 Error Source Identifier Type: 0x03 2534 0 1 2 3 2535 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 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 // FQDN Name // 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2540 If the length of the FQDN name is not a multiple of 32-bits, the 2541 field is padded with zero octets to the next 32-bit boundary. 2543 If a QNE encounters protocol errors, it MAY include additional 2544 information, mainly for diagnostic purposes. Additional information 2545 MAY be included if the type of an object is erroneous, or a field has 2546 an erroneous value. 2548 If the type of an object is erroneous, the following optional error- 2549 specific information may be included at the end of the INFO_SPEC. 2551 Object Type Info: 2553 0 1 2 3 2554 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 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | Object Type | Reserved | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 This object provides information about the type of object which 2560 caused the error. 2562 If a field in an object had an incorrect value, the following 2563 optional error-specific information may be added at the end of the 2564 INFO_SPEC. 2566 Object Value Info: 2568 0 1 2 3 2569 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 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 | Rsvd | Real Object Length | Offset | 2572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 // Object // 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 Real Object Length: Since the length in the original TLV header may 2577 be inaccurate, this field provides the actual length of the object 2578 (including the TLV Header) included in the error message. 2580 Offset: The byte in the object at which the QNE found the error. 2581 When this byte is set to "0", the complete object is included. 2583 Object: The invalid TLV object (including the TLV Header). 2585 This object carries information about a TLV object which was found to 2586 be invalid in the original message. An error message may contain 2587 more than one Object Value Info object. 2589 5.1.3.7. SESSION ID List (SESSION_ID_LIST) 2591 Type: 0x07 2593 Length: Variable 2595 Value: A list of 128-bit SESSION IDs used in summary refresh and 2596 summary tear messages. All SESSION IDs are concatenated together. 2598 0 1 2 3 2599 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 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | | 2602 + + 2603 | | 2604 + Session ID 1 + 2605 | | 2606 + + 2607 | | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 : : 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | | 2612 + + 2613 | | 2614 + Session ID n + 2615 | | 2616 + + 2617 | | 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 5.1.3.8. Reservation Sequence Number (RSN) List (RSN_LIST) 2622 Type: 0x08 2624 Length: Variable 2626 Value: A list of 32-bit Reservation Sequence Number (RSN) values. 2627 All RSN are concatenated together. 2629 0 1 2 3 2630 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 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 | Epoch Identifier | 2633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 | Reservation Sequence Number 1 (RSN1) | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 : : 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 | Reservation Sequence Number n (RSNn) | 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 5.1.3.9. Message ID (MSG_ID) 2643 Type: 0x09 2645 Length: Fixed - 5 32-bit words 2646 Value: contains an 1-bit Message_Binding_Type (D) that indicates the 2647 dependency relation of a message binding. The rest specifies a 128 2648 bit randomly generated value that "uniquely" identifies this 2649 particular message. 2651 0 1 2 3 2652 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 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 | RESERVED |D| 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 | | 2657 + + 2658 | | 2659 + Message ID + 2660 | | 2661 + + 2662 | | 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 The Message Binding Codes are: 2667 * 0 - Unidirectional binding dependency 2669 * 1 - Bi-directional binding dependency 2671 5.1.3.10. Bound Message ID (BOUND_MSG_ID) 2673 Type: 0x0A 2675 Length: Fixed - 5 32-bit words 2677 Value: contains an 1-bit Message_Binding_Type (D) that indicates the 2678 dependency relation of a message binding. The rest specifies a 128 2679 bit randomly generated value that refers to a Message ID in another 2680 message. 2682 0 1 2 3 2683 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 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | RESERVED |D| 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 | | 2688 + + 2689 | | 2690 + Bound Message ID + 2691 | | 2692 + + 2693 | | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 The Message Binding Codes are: 2698 * 0 - Unidirectional binding dependency 2700 * 1 - Bi-directional binding dependency 2702 5.1.3.11. QoS Specification (QSPEC) 2704 Type: 0x0B 2706 Length: Variable 2708 Value: Variable length QSPEC (QoS specification) information, which 2709 is QoS Model dependent. 2711 The contents and encoding rules for this object are specified in 2712 other documents. See [I-D.ietf-nsis-qspec]. 2714 0 1 2 3 2715 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 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 | | 2718 // QSPEC Data // 2719 | | 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 5.2. General Processing Rules 2724 This section provides the general processing rules used by QoS-NSLP. 2725 The triggers communicated between RM/QOSM and QoS-NSLP 2726 functionalities are given in Appenices A.1, A.2 and A.3. 2728 5.2.1. State Manipulation 2730 The processing of a message and its component objects involves 2731 manipulating the QoS NSLP and reservation state of a QNE. 2733 For each flow, a QNE stores (RMF-related) reservation state which 2734 depends on the QoS model / QSPEC used and QoS NSLP operation state 2735 which includes non-persistent state (e.g., the API parameters while a 2736 QNE is processing a message) and persistent state which is kept as 2737 long as the session is active. 2739 The persistent QoS NSLP state is conceptually organized in a table 2740 with the following structure. The primary key (index) for the table 2741 is the SESSION_ID: 2743 SESSION_ID 2745 A 128-bit identifier. 2747 The state information for a given key includes: 2749 Flow ID 2751 Based on GIST MRI. Several entries are possible in case of mobility 2752 events. 2754 SII-Handle for each upstream and downstream peer 2756 The SII-Handle is a local identifier generated by GIST and passed 2757 over the API. It is a handle that allows to refer to a particular 2758 GIST next hop. See SII-Handle in [I-D.ietf-nsis-ntlp] for more 2759 information. 2761 RSN from the upstream peer 2763 The RSN is a 32 bit counter. 2765 The latest local RSN 2767 A 32 bit counter. 2769 List of RII for outstanding responses with processing information. 2771 The RII is a 32 bit number. 2773 State lifetime 2775 The state lifetime indicates how long the state that is being 2776 signaled for remains valid. 2778 List of bound sessions 2780 A list of BOUND_SESSION_ID 128-bit identifiers for each session bound 2781 to this state. 2783 Scope of the signaling 2785 If the Proxy scope is used, a flag is needed to identify all 2786 signaling of this session as being scoped. 2788 Adding the state requirements of all these items gives an upper bound 2789 on the state to be kept by a QNE. The need to keep state depends on 2790 the desired functionality at the NSLP layer. 2792 5.2.2. Message Forwarding 2794 QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP 2795 does not have the concept of a message being sent directly to the end 2796 of the path. Instead, messages are received by a QNE, which may then 2797 send another message (which may be identical to the received message, 2798 or contain some subset of objects from it) to continue in the same 2799 direction (i.e., towards QNI or QNR) as the message received. 2801 The decision on whether to generate a message to forward may be 2802 affected by the value of the SCOPING or PROXY flags, or by the 2803 presence of an RII object. 2805 5.2.3. Standard Message Processing Rules 2807 If a mandatory object is missing from a message then the receiving 2808 QNE MUST NOT propagate the message any further. It MUST construct a 2809 RESPONSE message indicating the error condition and send it back to 2810 the peer QNE that sent the message. 2812 If a message contains an object of an unrecognised type, then the 2813 behavior depends on the AB extensibility flags. 2815 If the Proxy scope flag was set in an incoming QoS NSLP message, the 2816 QNE must set the same flag in all QoS NSLP messages it sends that are 2817 related to this session. 2819 5.2.4. Retransmissions 2821 Retransmissions may happen end-to-end, e.g., between QNI and QNR 2822 (using an RII object), or peer-to-peer, between two adjacent QNEs. 2823 When a QNE transmits a RESERVE with an RII object set, it waits for a 2824 RESPONSE from the responding QNE. QoS NSLP messages for which a 2825 response is requested by including an RII object, but fail to elicit 2826 a response are retransmitted. Similarly, a QNE may include the ACK- 2827 REQ-flag to request confirmation of a refresh message reception from 2828 its immediate peer. The retransmitted message should be exactly the 2829 same as the original message, e.g., the RSN is not modified with each 2830 retransmission. 2832 The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY wait 2833 period. Retransmissions MUST be made with exponentially increasing 2834 wait intervals (doubling the wait each time). QoS NSLP messages 2835 SHOULD be retransmitted until either a RESPONSE (which might be an 2836 error) has been obtained, or until QOSNSLP_RETRY_MAX seconds after 2837 the initial transmission. In the latter case, a failure SHOULD be 2838 indicated to the signaling application. The default values for the 2839 above-mentioned timers are: 2841 QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial 2842 retransmit of the message 2844 QOSNSLP_RETRY_MAX: 30 seconds Give up retrying to send the message 2846 Retransmissions SHOULD be disabled for tear messages. 2848 5.2.5. Rerouting 2850 5.2.5.1. Last Node Behavior 2852 As discussed in Section 3.2.12 some care needs to be taken to handle 2853 cases where the last node on the path may change. 2855 A node that is the last node on the path, but not the data receiver 2856 (or an explicitly configured proxy for it), MUST continue to attempt 2857 to send messages downstream to probe for path changes. This must be 2858 done in order to handle the "Path Extension" case described in 2859 Section 3.2.12.1. 2861 A node on the path, that was not previously the last node, MUST take 2862 over as the last node on the signaling path if GIST path change 2863 detection identifies that there are no further downstream nodes on 2864 the path. This must be done in order to handle the "Path Truncation" 2865 case described in Section 3.2.12.1. 2867 5.2.5.2. Avoiding Mistaken Teardown 2869 In order to handle the spurious route change problem described in 2870 Section 3.2.12.2, the RSN must be used in a particular way when 2871 maintaining the reservation after a route change is believed to have 2872 occurred. 2874 We assume that the current RSN (RSN[current]) is initially RSN0. 2876 When a route change is believed to have occurred, the QNE SHOULD send 2877 a RESERVE message, including the full QSPEC. This must contain an 2878 RSN which is RSN[current] = RSN0 + 2. It SHOULD include an RII, to 2879 request a response from the QNR. An SII-Handle MUST NOT be specified 2880 when passing this message over the API to GIST, so that it is 2881 correctly routed to the new peer QNE. 2883 When the QNE receives the RESPONSE message that relates to the 2884 RESERVE message sent down the new path, it SHOULD send a RESERVE 2885 message with the TEAR flag sent down the old path. To do so, it MUST 2886 request GIST to use its explicit routing mechanism and the QoS NSLP 2887 MUST supply an SII-Handle relating to the old peer QNE. When sending 2888 this RESERVE message it MUST contain an RSN which is RSN[current] - 2889 1. (RSN[current] remains unchanged). 2891 If the RESPONSE received after sending the RESERVE down the new path 2892 contains the code "Refresh successful" in the INFO_SPEC, then the QNE 2893 MAY elect not to send the tearing RESERVE, since this indicates that 2894 the path is unchanged. 2896 5.2.5.3. Upstream Route Change Notification 2898 GIST may notify the QoS NSLP that a possible upstream route change 2899 has occurred over the GIST API. On receiving such a notification, 2900 the QoS NSLP SHOULD send a NOTIFY message with Informational code 2901 0x02 for signaling sessions associated with the identified MRI. If 2902 this is sent, it MUST be sent to the old peer using the GIST explicit 2903 routing mechanism through the use of the SII-Handle. 2905 On receiving such a NOTIFY message, the QoS NSLP SHOULD use the 2906 InvalidateRoutingState API call to inform GIST that routing state may 2907 be out of date. The QoS NSLP SHOULD send a NOTIFY message upstream. 2908 The NOTIFY message should be propagated back to the QNI or QNR. 2910 5.2.5.4. Route Change Oscillation 2912 In some circumstances a route change may occur, but the path then 2913 falls back to the original route. 2915 After a route change the routers on the old path will continue to 2916 refresh the reservation until soft state times out, or an explicit 2917 TEAR is received. 2919 After detecting an upstream route change a QNE SHOULD consider the 2920 new upstream peer as current and not fall back to the old upstream 2921 peer unless: 2923 - it stops receiving refreshes from the old upstream peer for at 2924 least the soft state timeout period and then starts receiving 2925 messages from the old upstream peer again 2927 - or, it stops receiving refreshes from the new upstream peer for at 2928 least the soft state timeout period. 2930 GIST routing state keeps track of the latest upstream peer it has 2931 seen, and so may spuriously indicate route changes occur when the old 2932 upstream peer refreshes its routing state until the state at that 2933 node is explicitly torn down or times out. 2935 5.3. Object Processing 2937 This section presents processing rules for individual QoS NSLP 2938 objects. 2940 5.3.1. Reservation Sequence Number (RSN) 2942 A QNE's own RSN is a sequence number which applies to a particular 2943 signaling session (i.e., with a particular SESSION_ID). It MUST be 2944 incremented for each new RESERVE message where the reservation for 2945 the session changes. The RSN is manipulated using the serial number 2946 arithmetic rules from [RFC1982], which also defines wrapping rules 2947 and the meaning of 'equals', 'less than' and 'greater than' for 2948 comparing sequence numbers in a circular sequence space. 2950 The RSN starts at zero. It is stored as part of the per-session 2951 state and it carries on incrementing (i.e., it is not reset to zero) 2952 when a downstream peer change occurs. (Note that section 5.2.5.2 2953 provides some particular rules for use when a downstream peer 2954 changes.) 2956 The RSN object also contains an Epoch Identifier, which provides a 2957 method for determining when a peer has restarted (e.g., due to node 2958 reboot or software restart). The exact method for providing this 2959 value is implementation defined. Options include storing a serial 2960 number which is incremented on each restart, picking a random value 2961 on each restart or using the restart time. 2963 On receiving a RESERVE message a QNE examines the Epoch Identifier to 2964 determine if the peer sending the message has restarted. If the 2965 Epoch Identifier is different to that stored for the reservation then 2966 the RESERVE message MUST be treated as an updated reservation (even 2967 if the RSN is less than the current stored value), and the stored RSN 2968 and Epoch Identifier MUST be updated to the new values. 2970 When receiving a RESERVE message a QNE uses the RSN given in the 2971 message to determine whether the state being requested is different 2972 to that already stored. If the RSN is equal to that stored for the 2973 current reservation the current state MUST be refreshed. If the RSN 2974 is greater than the current stored value, the current reservation 2975 MUST be modified appropriately as specified in the QSPEC (provided 2976 that admission control and policy control succeed), and the stored 2977 RSN value updated to that for the new reservation. If the RSN is 2978 greater than the current stored value and the RESERVE was a reduced 2979 refresh, the QNE SHOULD send upstream a transient error message "Full 2980 QSPEC required". If the RSN is less than the current value, then it 2981 indicates an out-of-order message and the RESERVE message MUST be 2982 discarded. 2984 If the QNE does not store per-session state (and so does not keep any 2985 previous RSN values) then it MAY ignore the value of the RSN. It 2986 MUST also copy the same RSN into the RESERVE message (if any) it 2987 sends as a consequence of receiving this one. 2989 5.3.2. Request Identification Information (RII) 2991 A QNE sending QUERY or RESERVE messages may require a response to be 2992 sent. It does so by including a Request Identification Information 2993 (RII) object. When creating an RII object the QNE MUST select the 2994 value for the RII such that it is probabilistically unique within the 2995 given session. A RII object is typically set by the QNI. 2997 A number of choices are available when implementing this. 2998 Possibilities might include using a random value, or a node 2999 identifier together with a counter. If the value collides with one 3000 selected by another QNE for a different QUERY then RESPONSE messages 3001 may be incorrectly terminated, and may not be passed back to the node 3002 that requested them. 3004 The node that created the RII object MUST remember the value used in 3005 the RII to match back any RESPONSE it will receive. The node SHOULD 3006 use a timer to identify situations where it has taken too long to 3007 receive the expected RESPONSE. If the timer expires without 3008 receiving a RESPONSE it MAY perform a retransmission as discussed in 3009 Section 5.2.4. In this case this QNE MUST not generate any RESPONSE 3010 or NOTIFY message to notify this error. 3012 If an intermediate QNE wants to receive a response for an outgoing 3013 message, but the message already included an RII when it arrived, the 3014 QNE MUST NOT add a new RII object nor replace the old RII object, but 3015 MUST simply remember this RII to match a later RESPONSE message. 3017 When it receives the RESPONSE, it forwards the RESPONSE upstream 3018 towards the RII originating node. Note that only the node that 3019 originally created the RII can set up a retransmission timer. Thus, 3020 if an intermediate QNE decides to use the RII already contained in 3021 the message, it MUST NOT set up a retransmission timer, but rely on 3022 the retransmission timer set up by the QNE that inserted the RII. 3024 When receiving a message containing an RII object the node MUST send 3025 a RESPONSE if 3027 o The SCOPING flag is set ('next hop' scope), 3029 o The PROXY scope flag is set and the QNE is the P-QNE, or 3031 o This QNE is the last one on the path for the given session. 3033 and the QNE keeps per-session state for the given session. 3035 In the rare event that the QNE wants to request a response for a 3036 message that already included an RII, and this RII value conflicts 3037 with an existing RII value on the QNE, the node should interrupt the 3038 processing the message, and send an error message upstream to 3039 indicate an RII collision, and request a retry with a new RII value. 3041 5.3.3. BOUND_SESSION_ID 3043 As shown in the examples in Section 4, the QoS NSLP can relate 3044 multiple sessions together. It does this by including the SESSION_ID 3045 from one session in a BOUND_SESSION_ID object in messages in another 3046 session. 3048 When receiving a message with a BOUND_SESSION_ID object, a QNE MUST 3049 copy the BOUND_SESSION_ID object into all messages it sends for the 3050 same session. A QNE that stores per-session state MUST store the 3051 value of the BOUND_SESSION_ID. 3053 The BOUND_SESSION_ID is only indicative in nature. However, a QNE 3054 implementation may use BOUND_SESSION_ID information to optimize 3055 resource allocation, e.g., for bidirectional reservations. When 3056 receiving a tear down message (e.g., a RESERVE message with tear down 3057 semantic) for an aggregate reservation, it may use this information 3058 to initiate a tear down for end-to-end sessions bound to the 3059 aggregate. A QoS NSLP implementation MUST be ready to process more 3060 than one BOUND_SESSION_ID object within a single message. 3062 5.3.4. REFRESH_PERIOD 3064 Refresh timer management values are carried by the REFRESH_PERIOD 3065 object which has local significance only. At the expiration of a 3066 "refresh timeout" period, each QNE independently examines its state 3067 and sends a refreshing RESERVE message to the next QNE peer where it 3068 is absorbed. This peer-to-peer refreshing (as opposed to the QNI 3069 initiating a refresh which travels all the way to the QNR) allows 3070 QNEs to choose refresh intervals as appropriate for their 3071 environment. For example, it is conceivable that refreshing 3072 intervals in the backbone, where reservations are relatively stable, 3073 are much larger than in an access network. The "refresh timeout" is 3074 calculated within the QNE and is not part of the protocol; however, 3075 it must be chosen to be compatible with the reservation lifetime as 3076 expressed by the REFRESH_PERIOD, and an assessment of the reliability 3077 of message delivery. 3079 The details of timer management and timer changes (slew handling and 3080 so on) are identical to the ones specified in Section 3.7 of RFC 2205 3081 [RFC2205]. 3083 There are two time parameters relevant to each QoS NSLP state in a 3084 node: the refresh period R between generation of successive refreshes 3085 for the state by the neighbor node, and the local state's lifetime L. 3086 Each RESERVE message may contain a REFRESH_PERIOD object specifying 3087 the R value that was used to generate this (refresh) message. This R 3088 value is then used to determine the value for L when the state is 3089 received and stored. The values for R and L may vary from peer to 3090 peer. 3092 5.3.5. INFO_SPEC 3094 The INFO_SPEC object is carried by the RESPONSE and NOTIFY messages 3095 and it is used to report a successful, an unsuccessful, or an error 3096 situation. In case of an error situation the error messages SHOULD 3097 be generated even if no RII object is included in the RESERVE or in 3098 the QUERY messages. Note that when the TEAR flag is set in the 3099 RESERVE message an error situation SHOULD NOT trigger the generation 3100 of a RESPONSE message. 3102 Six classes of INFO_SPEC objects are identified and specified in 3103 Section 5.1.3.6. The message processing rules for each class are 3104 defined below. 3106 A RESPONSE message MUST carry INFO_SPEC objects towards the QNI. The 3107 RESPONSE message MUST be forwarded unconditionally up to the QNI. 3108 The actions that SHOULD be undertaken by the QNI that receives the 3109 INFO_SPEC object are specified by the local policy of the QoS model 3110 supported by this QNE. The default action is that the QNI that 3111 receives the INFO_SPEC object SHOULD not trigger any other QoS NSLP 3112 procedure. 3114 The Informational INFO_SPEC class MUST be generated by a by a 3115 stateful QoS NSLP QNE when an Informational error class is caught. 3116 The Informational INFO-SPEC object MUST be carried by a RESPONSE or a 3117 NOTIFY message. 3119 In case of an unidirectional reservation, the Success INFO_SPEC class 3120 MUST be generated by a stateful QoS NSLP QNR when a RESERVE message 3121 is received and the reservation state installation or refresh 3122 succeeded. In case of a bi-directional reservation the INFO-SPEC 3123 object SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE 3124 message is received and the reservation state installation or refresh 3125 succeeded. The Success INFO-SPEC object MUST be carried by a 3126 RESPONSE or a NOTIFY message. 3128 In case of an unidirectional reservation, the Protocol Error 3129 INFO_SPEC class MUST be generated by a stateful QoS NSLP QNE when a 3130 RESERVE or QUERY message is received by the QNE and a protocol error 3131 is caught. In case of a bi-directional reservation, the Protocol 3132 Error INFO_SPEC class SHOULD be generated by a stateful QoS NSLP QNE 3133 when a RESERVE or QUERY message is received by the QNE and a protocol 3134 error is caught. A RESPONSE message MUST carry this object, which 3135 MUST be forwarded unconditionally towards the upstream QNE that 3136 generated the RESERVE or QUERY message that triggered the generation 3137 of this INFO_SPEC object. The default action for a stateless QoS 3138 NSLP QNE that detects such an error is that none of the QoS NSLP 3139 objects SHOULD be processed and the RESERVE or QUERY message SHOULD 3140 be forwarded downstream. 3142 In case of an unidirectional reservation, the Transient Failure 3143 INFO_SPEC class MUST be generated by a stateful QoS NSLP QNE when a 3144 RESERVE or QUERY message is received by the QNE and one Transient 3145 failure error code is caught, or when an event happens that causes a 3146 transient error. In case of a bi-directional reservation, the 3147 Transient Failure INFO_SPEC class SHOULD be generated by a stateful 3148 QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE 3149 and one Transient failure error code is caught. 3151 A RESPONSE message MUST carry this object, which MUST be forwarded 3152 unconditionally towards the upstream QNE that generated the RESERVE 3153 or QUERY message that triggered the generation of this INFO_SPEC 3154 object. The transient RMF-related error MAY also be carried by a 3155 NOTIFY message. The default action is that the QNE that receives 3156 this INFO_SPEC object SHOULD re-trigger the retransmission of the 3157 RESERVE or QUERY message that triggered the generation of the 3158 INFO_SPEC object. The default action for a stateless QoS NSLP QNE 3159 that detects such an error is that none of the QoS NSLP objects 3160 SHOULD be processed and the RESERVE or QUERY message SHOULD be 3161 forwarded downstream. 3163 In case of an unidirectional reservation, the Permanent Failure 3164 INFO_SPEC class MUST be generated by a stateful QoS NSLP QNE when a 3165 RESERVE or QUERY message is received by a QNE and an internal or 3166 system error occured, or authorization failed. In case of a bi- 3167 directional reservation, the Permanent Failure INFO_SPEC class SHOULD 3168 be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY 3169 message is received by a QNE and an internal or system error occured, 3170 or authorization failed. A RESPONSE message MUST carry this object, 3171 which MUST be forwarded unconditionally towards the upstream QNE that 3172 generated the RESERVE or QUERY message that triggered this protocol 3173 error. The permanent RMF-related, the internal or system errors MAY 3174 also be carried by a NOTIFY message. The default action for a 3175 stateless QoS NSLP QNE that detects such an error is that none of the 3176 QoS NSLP objects SHOULD be processed and the RESERVE or QUERY message 3177 SHOULD be forwarded downstream. 3179 The QoS-specific error class may be used when errors outside the QoS 3180 NSLP itself occur that are related to the particular QoS Model being 3181 used. The processing rules of these errors are not specified in this 3182 document. 3184 5.3.6. SESSION_ID_LIST 3186 A SESSION_ID_LIST is carried in RESERVE messages. It is used in two 3187 cases, to refresh or two tear down the indicated sessions. A 3188 SESSION_ID_LIST carries information about sessions that should be 3189 refreshed or torn down, in addition to the main (primary) session 3190 indicated in the RESERVE. 3192 If the primary SESSION_ID is not understood, the SESSION_ID_LIST 3193 object MUST NOT be processed. 3195 When a stateful QNE goes through the SESSION_ID_LIST, if it finds one 3196 or more unknown SESSION ID values, it SHOULD construct an 3197 informational RESPONSE message back to the upstream stateful QNE with 3198 error code for unknown SESSION ID in SESSION_ID_LIST, and include all 3199 uknown SESSION IDs in a SESSION_ID_LIST. 3201 If the RESERVE is a tear, for each session in the SESSION_ID_LIST, 3202 the stateful QNE MUST inform the RMF that the reservation is no 3203 longer required. RSN values MUST also be interpreted in order to 3204 distinguish whether the tear down is valid, or whether it is refering 3205 to an old state, and, thus, should be silently discarded. 3207 If the RESERVE is a refresh, the stateful QNE MUST also process the 3208 RSN_LIST object as detailed in the next section. 3210 If the RESERVE is a tear, for each session in the SESSION_ID_LIST, 3211 the QNE MUST inform the RMF that the reservation is no longer 3212 required. RSN values MUST be interpreted. 3214 Note that a stateless QNE can not support summary or single reduced 3215 refreshes, and always needs full single refreshes. 3217 5.3.7. RSN_LIST 3219 An RSN_LIST MUST be carried in RESERVE messages when a QNE wants to 3220 perform a refresh or tear-down of several sessions with a single NSLP 3221 message. The RSN_LIST object MUST be populated with RSN values of 3222 the same sessions and in the same order as indicated in the 3223 SESSION_ID_LIST. Thus, entries on both objects at locationg i refer 3224 to the same session. 3226 If the primary session and RSN reference in the RESERVE were not 3227 understood, the stateful QNE MUST NOT process the RSN_LIST. Instead 3228 an error RESPONSE SHOULD be sent back to the upstream stateful QNE. 3230 On receiving an RSN_LIST object, the stateful QNE should check 3231 whether the number of items in the SESSION_ID_LIST and RSN_LIST 3232 objects match. If there is a mismatch, the stateful QNE SHOULD send 3233 back a protocol error indicating a bad value in the object. 3235 While matching the RSN_LIST values to the SESSION_ID_LIST values, if 3236 one or more RSN values in the RSN_LIST are not in synch with the 3237 local values, the stateful QNE SHOULD construct an informational 3238 RESPONSE message with an error code for RSN mismatch in RSN_LIST. 3239 The stateful QNE MUST include the erroneous SESSION ID and RSN values 3240 in SESSION_ID_LIST and RSN_LIST objects in the RESPONSE. 3242 If no errors were found in processing the RSN_LIST, the stateful QNE 3243 refreshes the reservation states of all sessions, both the primary 3244 single session indicated in the refresh, and all sessions in the 3245 SESSION_ID_LIST. 3247 For each successfully processed session in the RESERVE, the stateful 3248 QNE performs a refresh of the reservation state. Thus, even if some 3249 sessions were not in synch, the remaining sessions in the 3250 SESSION_ID_LIST and RSN_LIST are refreshed. 3252 5.3.8. QSPEC 3254 The contents of the QSPEC depends on the QoS model being used. A 3255 template for QSPEC objects can be found in [I-D.ietf-nsis-qspec]. 3257 Upon reception, the complete QSPEC is passed to the Resource 3258 Management Function (RMF), along with other information from the 3259 message necessary for the RMF processing. A QNE may also receive an 3260 INFO_SPEC that includes a partial or full QSPEC. This will also be 3261 passed to the RMF. 3263 5.4. Message Processing Rules 3265 This section provides rules for message processing. Not all possible 3266 error situations are considered. A general rule for dealing with 3267 erroneous messages is that a node should evaluate the situation 3268 before deciding how to react. There are two ways to react to 3269 erroneous messages: 3271 a) Silently drop the message, or 3273 b) Drop the message, and reply with an error code to the sender. 3275 The default behavior, in order to protect the QNE from a possible DoS 3276 attack, is to silently drop the message. However, if the QNE is able 3277 to authenticate the sender, e.g., through GIST, the QNE may send a 3278 proper error message back to the neighbor QNE in order to let it know 3279 that there is an inconsistency in the states of adjacent QNEs. 3281 5.4.1. RESERVE Messages 3283 The RESERVE message is used to manipulate QoS reservation state in 3284 QNEs. A RESERVE message may create, refresh, modify or remove such 3285 state. A QNE sending a RESERVE MAY require a response to be sent by 3286 including a Request Identification Information (RII) object, see 3287 Section 5.3.2. 3289 RESERVE messages MUST only be sent towards the QNR. A QNE that 3290 receives a RESERVE message checks the message format. In case of 3291 malformed messages, the QNE MAY send a RESPONSE message with the 3292 appropriate INFO_SPEC. 3294 Before performing any state changing actions a QNE MUST determine 3295 whether the request is authorized. The way to do this check depends 3296 on the authorization model being used. 3298 When the RESERVE is authorized, a QNE checks the COMMON_HEADER flags. 3299 If the TEAR flag is set, the message is a tearing RESERVE which 3300 indicates complete QoS NSLP state removal (as opposed to a 3301 reservation of zero resources). On receiving such a RESERVE message 3302 the QNE MUST inform the RMF that the reservation is no longer 3303 required. The RSN value MUST be processed. After this, there are 3304 two modes of operation: 3306 1. If the tearing RESERVE did not include an RII, i.e., the QNI did 3307 not want a confirmation, the QNE SHOULD remove the QoS NSLP state. 3308 It MAY signal to GIST (over the API) that reverse path state for this 3309 reservation is no longer required. Any errors in processing the 3310 tearing RESERVE SHOULD NOT be sent back towards the QNI since the 3311 upstream QNEs will already have removed their session states, thus, 3312 they are unable to do anything to the error. 3314 2. If an RII was included, the stateful QNE SHOULD still keep the 3315 NSLP operational state until a RESPONSE for the tear going towards 3316 the QNI is received. This operational state SHOULD be kept for one 3317 refresh interval, after which the NSLP operational state for the 3318 session is removed. Depending on the QoS model, the tear message MAY 3319 include a QSPEC to further specify state removal. If the QoS model 3320 requires a QSPEC, and none is provided, the QNE SHOULD reply with an 3321 error message, and SHOULD NOT remove the reservation. 3323 If the tearing RESERVE includes a QSPEC, but none is required by the 3324 QoS model, the QNE MAY silently discard the QSPEC and proceed as if 3325 it did not exist in the message. In general, a QoS NSLP 3326 implementation should carefully consider, when an error message 3327 should be sent, and when not. If the tearing RESERVE did not include 3328 an RII, then the upstream QNE has removed the RMF and NSLP states, 3329 and will not be able to do anything to the error. If an RII was 3330 included, the upstream QNE may still have the NSLP operational state, 3331 but no RMF state. 3333 If a QNE receives a tearing RESERVE for a session it still has the 3334 operational state, but the RMF state was removed, the QNE SHOULD 3335 accept the message and forward it downstream as if all is well. 3337 If the tearing RESERVE includes a SESSION_ID_LIST, the stateful QNE 3338 MUST process the object as described earlier in this document, and 3339 for each identified session, indicate to the RMF that the reservation 3340 is no longer required. 3342 If a QNE receives a refreshing RESERVE for a session it still has the 3343 operational state, but the RMF state was removed, the QNE MUST 3344 silently drop the message and not forward it downstream. 3346 As discussed in Section 5.2.5.2, to avoid incorrect removal of state 3347 after a rerouting event, a node receiving a RESERVE message with the 3348 TEAR flag set which does not come from the current peer QNE, 3349 identified by its SII, MUST be ignored and MUST NOT be forwarded. 3351 If the QNE has reservations which are bound and dependent to this 3352 session (they contain the SESSION_ID of this session in their 3353 BOUND_SESSION_ID object and use Binding Code: 0x04), it MUST send a 3354 NOTIFY message for each of the reservations with an appropriate 3355 INFO_SPEC. If the QNE has reservations which are bound, but which 3356 they are not dependent to this session (the Binding Code in the 3357 BOUND_SESSION_ID object has one of the values: 0x01, 0x02, 0x03), it 3358 MAY send a NOTIFY message for each of the reservations with an 3359 appropriate INFO_SPEC. The QNE MAY elect to send RESERVE messages 3360 with the TEAR flag set for these reservations. 3362 The default behavior of a QNE that receives a RESERVE with a 3363 SESSION_ID for which it already has state installed but with a 3364 different flow ID is to replace the existing reservation (and tear 3365 down the reservation on the old branch if the RESERVE is received 3366 with a different SII). 3368 In some cases, this may not be the desired behavior. In that case, 3369 the QNI or a QNE MAY set the REPLACE flag in the common header to 3370 zero to indicate that the new session does not replace the existing 3371 one. 3373 A QNE that receives a RESERVE with the REPLACE flag set to zero but 3374 with the same SII, will indicate REPLACE=0 to the RMF (where it will 3375 be used for the resource handling). Furthermore, if the QNE 3376 maintains a QoS NSLP state then it will also add the new flow ID in 3377 the QoS NSLP state. If the SII is different, this means that the QNE 3378 is a merge point. In that case, in addition to the operations 3379 specified above, the value REPLACE=0 is also indicating that a 3380 tearing RESERVE SHOULD NOT be sent on the old branch. 3382 When a QNE receives a RESERVE message with an unknown SESSION_ID and 3383 this message contains no QSPEC because it was meant as a refresh then 3384 the node MUST send a RESPONSE message with an INFO_SPEC that 3385 indicates a missing QSPEC to the upstream peer ("Full QSPEC 3386 required"). The upstream peer SHOULD send a complete RESERVE (i.e., 3387 one containing a QSPEC) on the new path (new SII). 3389 At a QNE, resource handling is performed by the RMF. For sessions 3390 with the REPLACE flag set to zero, we assume that the QoS model 3391 includes directions to deal with resource sharing. This may include, 3392 adding the reservations, or taking the maximum of the two or more 3393 complex mathematical operations. 3395 This resource handling mechanism in the QoS Model is also applicable 3396 to sessions with different SESSION_ID but related through the 3397 BOUND_SESSION_ID object. Session replacement is not an issue here, 3398 but the QoS Model may specify whether to let the sessions that are 3399 bound together share resources on common links or not. 3401 Finally, it is possible that a RESERVE is received with no QSPEC at 3402 all. This is the case of a reduced refresh. In this case, rather 3403 than sending a refreshing RESERVE with the full QSPEC, only the 3404 SESSION_ID and the RSN are sent to refresh the reservation. Note 3405 that this mechanism just reduces the message size (and probably eases 3406 processing). One RESERVE per session is still needed. Such a 3407 reduced refresh may further include a SESSION_ID_LIST and RSN_LIST, 3408 which indicate further sessions to be refreshed along the primary 3409 session. The processing of these objects were described earlier in 3410 this document. 3412 If the REPLACE flag is set, the QNE SHOULD update the reservation 3413 state according to the QSPEC contained in the message (if the QSPEC 3414 is missing the QNE SHOULD indicate this error by replying with a 3415 RESPONSE containing the corresponding INFO_SPEC "Full QSPEC 3416 required"). It MUST update the lifetime of the reservation. If the 3417 REPLACE flag is not set, a QNE SHOULD NOT remove the old reservation 3418 state if the SII which is passed by GIST over the API is different 3419 than the SII that was stored for this reservation. The QNE MAY elect 3420 to keep sending refreshing RESERVE messages. 3422 If a stateful QoS NSLP QNE receives a RESERVE message with the BREAK 3423 flag set then the BREAK flag of new generated messages (e.g., RESERVE 3424 or RESPONSE) MUST be set. When a stateful QoS NSLP QNE receives a 3425 RESERVE message with the BREAK flag not set then the IP-TTL and 3426 Original-TTL values in GIST RecvMessage primitive MUST be monitored. 3427 If they differ then the BREAK flag of new generated messages (e.g., 3428 RESERVE or RESPONSE) SHOULD be set. In situations where a QNE or a 3429 domain is able to provide QoS using other means, see Section 3.3.5, 3430 then the BREAK flag MUST not be set. 3432 If the RESERVE message included an RII, and any of the following are 3433 true, the QNE MUST send a RESPONSE message: 3435 o If the QNE is configured, for a particular session, to be a QNR, 3437 o The SCOPING flag is set, 3439 o The Proxy scope flag is set and the QNE is a P-QNE, or 3441 o The QNE is the last QNE on the path to the destination. 3443 When a QNE receives a RESERVE message, its processing may involve 3444 sending out another RESERVE message. 3446 If a QNE has received a RESPONSE mandating the use of full refreshes 3447 from its downstream peer for a session, the QNE MUST continue to use 3448 full refresh messages. 3450 If the session of this message is bound to another session, then the 3451 RESERVE message SHOULD include the SESSION_ID of that other session 3452 in a BOUND_SESSION_ID object. In the situation of aggregated 3453 tunnels, the aggregated session MAY not include the SESSION_ID of its 3454 bound sessions in BOUND_SESSION_ID(s). 3456 In case of receiver-initiated reservations, the RESERVE message must 3457 follow the same path that has been followed by the QUERY message. 3458 Therefore, GIST is informed, over the QoS NSLP/GIST API, to pass the 3459 message upstream, i.e., by setting GIST "D" flag, see GIST 3460 [I-D.ietf-nsis-ntlp]. 3462 The QNE MUST create a new RESERVE and send it to its next peer, when: 3464 - A new resource set up was done, 3466 - A new resource set up was not done, but the QOSM still defines that 3467 a RESERVE must be propagated, 3469 - The RESERVE is a refresh and includes new MRI, or 3471 - If the RESERVE-INIT flag is included in an arrived QUERY. 3473 If the QNE sent out a refresh RESERVE with the ACK-REQ-flag set, and 3474 did not receive a RESPONSE from its immediate stateful peer within 3475 the retransmission period of QOSNSLP_RETRY_MAX, the QNE SHOULD send a 3476 NOTIFY to its immediate upstream sateful peer and indicate "Path 3477 truncated - Next peer dead" in the INFO_SPEC. The ACK-REQ-flag 3478 SHOULD NOT be added to a RESERVE that already include an RII object, 3479 since a confirmation from the QNR has already been requested. 3481 Finally, if a received RESERVE requested acknowledgement through the 3482 ACK-REQ-flag in the COMMON HEADER flags and the processing of the 3483 message was successul, the stateful QNE SHOULD send back a RESPONSE 3484 with an INFO_SPEC carrying the acknowledgement success code. The QNE 3485 MAY include the ACK-REQ-flag in the next refresh message it will send 3486 for the session. The use of the ACK-REQ-flag for diagnostics 3487 purposes is a policy issue, i.e., using an acknowledged refresh 3488 message as a hint to further probe the end-to-end path can be used 3489 simply as a hint to check that the end-to-end path is still intact. 3491 5.4.2. QUERY Messages 3493 A QUERY message is used to request information about the data path 3494 without making a reservation. This functionality can be used to 3495 'probe' the network for path characteristics or for support of 3496 certain QoS models, or for initiating a receiver-initiated 3497 reservation. 3499 A QNE sending a QUERY indicates a request for a response by including 3500 a Request Identification Information (RII) object, see Section 5.3.2. 3501 A request to initiate a receiver-initiated reservation is done 3502 through the RESERVE-INIT flag, see Section 5.1.2.2. 3504 When a QNE receives a QUERY message the QSPEC is passed to the RMF 3505 for processing. The RMF may return a modified QSPEC that is used in 3506 any QUERY or RESPONSE message sent out as a result of the QUERY 3507 processing. 3509 When processing a QUERY message, a QNE checks whether the RESERVE- 3510 INIT flag is set. If the flag is set, the QUERY is used to install 3511 reverse path state. In this case, if the QNE is not the QNI, it 3512 creates a new QUERY message to send downstream. If the QUERY 3513 contained a QSPEC, it MUST be passed to the RMF where it may be 3514 modified by the QoS Model specific QUERY processing. If the QNE is 3515 the QNI, the QNE creates a RESERVE message, which contains a QSPEC 3516 received from the RMF and which may be based on the received QSPEC. 3517 If this node was not expecting to perform a receiver-initiated 3518 reservation then an error MUST be sent back along the path. 3520 If an RII object is present, and if the QNE is the QNR, the SCOPING 3521 flag is set or the PROXY scope flag is set and the QNE is a P-QNE, 3522 the QNE MUST generate a RESPONSE message and pass it back along the 3523 reverse of the path used by the QUERY. 3525 In other cases, the QNE MUST generate a QUERY message which is then 3526 forwarded further along the path using the same MRI, Session ID and 3527 Direction as provided when the QUERY was received over the GIST API. 3529 The QSPEC to be used is that provided by the RMF as described 3530 previously. When generating a QUERY to send out to pass the query 3531 further along the path, the QNE MUST copy the RII object (if present) 3532 unchanged into the new QUERY message. A QNE that is also interested 3533 in the response to the query keeps track of the RII to identify the 3534 RESPONSE when it passes through it. 3536 Note that QUERY messages with the RESERVE-INIT flag set MUST be 3537 answered by the QNI. This feature may be used, e.g., following 3538 handovers, to set up new path state in GIST, and request the other 3539 party to send a RESERVE back on this new GIST path. 3541 If a stateful QoS NSLP QNE receives a QUERY message with the RESERVE- 3542 INIT flag and BREAK flag set then the BREAK flag of new generated 3543 messages (e.g., QUERY, RESERVE or RESPONSE) MUST be set. When a 3544 stateful QoS NSLP QNE receives a QUERY message with the the RESERVE- 3545 INIT flag set and BREAK flag not set then then the IP-TTL and 3546 Original-TTL values in GIST RecvMessage primitive MUST be monitored. 3547 If they differ then the BREAK flag of new generated messages (e.g., 3548 QUERY, RESERVE or RESPONSE) SHOULD be set. In situations where a QNE 3549 or a domain is able to provide QoS using other means, see Section 3550 3.3.5, then the BREAK flag MUST not be set. 3552 Finally, if a received QUERY requested acknowledgement through the 3553 ACK-REQ-flag in the COMMON HEADER flags and the processing of the 3554 message was successul, the stateful QNE SHOULD send back a RESPONSE 3555 with an INFO_SPEC carrying the acknowledgement success code. 3557 5.4.3. RESPONSE Messages 3559 The RESPONSE message is used to provide information about the result 3560 of a previous QoS NSLP message, e.g., confirmation of a reservation 3561 or information resulting from a QUERY. The RESPONSE message does not 3562 cause any state to be installed, but may cause state(s) to be 3563 modified, e.g., if the RESPONSE contains information about an error. 3565 A RESPONSE message MUST be sent when the QNR processes a RESERVE or 3566 QUERY message containing an RII object or if the QNE receives a 3567 scoped RESERVE or a scoped QUERY. In this case, the RESPONSE message 3568 MUST contain the RII object copied from the RESERVE or the QUERY. 3569 Also, if there is an error in processing a received RESERVE, a 3570 RESPONSE is sent indicating the nature of the error. In this case, 3571 the RII and RSN, if available, MUST be included in the RESPONSE. 3573 On receipt of a RESPONSE message containing an RII object, the 3574 stateful QoS NSLP QNE MUST attempt to match it to the outstanding 3575 response requests for that signaling session. If the match succeeds, 3576 then the RESPONSE MUST NOT be forwarded further along the path if it 3577 contains an INFO_SPEC class informational or success. If the QNE did 3578 not insert this RII itself, if must forward the RESPONSE to the next 3579 peer. Thus, for RESPONSES indicating success, forwarding should only 3580 stop if the QNE inserted the RII by itself, If the RESPONSE carries 3581 an INFO_SPEC indicating an error, forwarding SHOULD continue upstream 3582 towards the QNI by using RSNs as described in the next paragraph. 3584 On receipt of a RESPONSE message containing an RSN object, a stateful 3585 QoS NSLP QNE MUST compare the RSN to that of the appropriate 3586 signaling session. If the match succeeds then the INFO_SPEC MUST be 3587 processed. If the INFO_SPEC object is used to notify errors then the 3588 node MUST use the stored upstream peer RSN value, associated with the 3589 same session, and forward the RESPONSE message further along the path 3590 towards the QNI. 3592 If the INFO_SPEC is not used to notify error situations, see above, 3593 then if the RESPONSE message carries an RSN, the message MUST NOT be 3594 forwarded further along the path. 3596 If there is no match for RSN, the message SHOULD be silently dropped. 3598 On receipt of a RESPONSE message containing neither an RII nor an RSN 3599 object, the RESPONSE MUST NOT be forwarded further along the path. 3601 In the typical case RESPONSE messages do not change the states 3602 installed in intermediate QNEs. However, depending on the QoS model, 3603 there may be situations where states are affected, e.g., 3605 - if the RESPONSE includes an INFO_SPEC describing an error situation 3606 resulting in reservations to be removed, or 3608 - the QoS model allows a QSPEC to define [min,max] limits on the 3609 resources requested, and downstream QNEs gave less resources than 3610 their upstream nodes, which means that the upstream nodes may release 3611 a part of the resource reservation. 3613 If a stateful QoS NSLP QNE receives a RESPONSE message with the BREAK 3614 flag set then the BREAK flag of new generated message (e.g., 3615 RESPONSE) MUST be set. 3617 5.4.4. NOTIFY Messages 3619 NOTIFY messages are used to convey information to a QNE 3620 asynchronously. NOTIFY messages do not cause any state to be 3621 installed. The decision to remove state depends on the QoS model. 3622 The exact operation depends on the QoS model. A NOTIFY message does 3623 not directly cause other messages to be sent. NOTIFY messages are 3624 sent asynchronously, rather than in response to other messages. They 3625 may be sent in either direction (upstream or downstream). 3627 A special case of synchronous NOTIFY is when the upstream QNE asked 3628 to use reduced refresh by setting the appropriate flag in the 3629 RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY 3630 and a proper INFO_SPEC code whether the QNE agrees to use reduced 3631 refresh between the upstream QNE. 3633 The Transient error code 0x07 "Reservation preempted" is sent to the 3634 QNI whose resources were preempted. The NOTIFY message carries 3635 information to the QNI that one QNE no longer has a reservation for 3636 the session. It is up to the QNI to decide what to do based on the 3637 QoS Model being used. The QNI would normally tear down the preempted 3638 reservation by sending a RESERVE with the TEAR flag set using the SII 3639 of the preempted reservation. However, the QNI can follow other 3640 procedures as specified in its QoS Model. More discussion on 3641 preemption can be found in the QSPEC Template [I-D.ietf-nsis-qspec] 3642 and the individual QoS Model specifications. 3644 6. IANA Considerations 3646 This section provides guidance to the Internet Assigned Numbers 3647 Authority (IANA) regarding registration of values related to the QoS 3648 NSLP, in accordance with BCP 26 RFC 2434 [RFC2434]. 3650 The QoS NSLP requires IANA to create a number of new registries: - 3651 QoS NSLP Message Types - QoS NSLP Binding Codes - QoS NSLP Error 3652 Classes and Error Codes 3654 It also requires registration of new values in a number of 3655 registries: 3657 - NSLP Object Types - GIST NSLP-ID - Router Alert Option Values (IPv4 3658 and IPv6) 3660 6.1. QoS NSLP Message Type 3662 The QoS NSLP Message Type is an 8 bit value. This specification 3663 defines four QoS NSLP message types, which form the initial contents 3664 of this registry: RESERVE (0x01), QUERY (0x02), RESPONSE (0x03) and 3665 NOTIFY (0x04). 3667 The value 0 is reserved. Values 1-239 are to be allocated by 3668 Standards Action. Values 240 to 255 are for Experimental/Private 3669 Use. 3671 When a new message type is defined, any message flags used with it 3672 must also be defined. 3674 6.2. NSLP Message Objects 3676 [Delete this part if already done by another NSLP: 3678 A new registry is to be created for NSLP Message Objects. This is a 3679 12-bit field (giving values from 0 to 4095). This registry is shared 3680 between a number of NSLPs. Allocation policies are as follows: 3681 0-1023: Standards Action 1024-1999: Specification Required 2000-2047: 3683 Private/Experimental Use 2048-4095: Reserved 3685 When a new object is defined, the extensbility bits (A/B) must also 3686 be defined.] 3688 This document defines eleven new NSLP objects. These are described 3689 in Section 5.1.3: RII (0x01), RSN (0x02), REFRESH_PERIOD (0x03), 3690 BOUND_SESSION_ID (0x04), PACKET_CLASSIFIER (0x05), INFO_SPEC (0x06), 3691 SESSION ID LIST (0x07), RSN LIST (0x08), MSG_ID (0x09), BOUND_MSG_ID 3692 (0x0A), and QSPEC (0x0B). 3694 Values are to be assigned from the Standards Action required section 3695 of the NSLP Object Type registry. 3697 6.3. QoS NSLP Binding Codes 3699 A new registry is to be created for the 8-bit Binding Codes used in 3700 the BOUND_SESSION_ID object. The initial values for this registry 3701 are listed in Section 5.1.3.4. 3703 Value 0 is reserved. Values 1 to 127 are to be assigned based on a 3704 policy of Specification Required. Values 128 to 159 are for 3705 Exerimental/Private Use. Other values are Reserved. 3707 6.4. QoS NSLP Error Classes and Error Codes 3709 In addition Error Classes and Error Codes for the INFO_SPEC object 3710 are defined. These are described in Section 5.1.3.6. 3712 The Error Class is 4-bits in length. The initial values are: 0: 3713 Reserved 1: Informational 2: Success 3: Protocol Error 4: Transient 3714 Failure 5: Permanent Failure 6: QoS Model Error 7-15: Reserved 3716 The Error Code is 16 bits in length. Each Error Codes are assigned 3717 within a particular Error Class. This requires the creation of a 3718 registry for Error Codes in each Error Class. The error code 0 in 3719 each class is Reserved. 3721 Policies for the error code registries are as follows: 0-8191: 3722 Standards Action 8192-12287: Specification Required 12288-16383: 3723 Experimental/Private Use 16384-65536: Reserved 3725 The initial assignments for the Error Code registries are given in 3726 section 5.1.3.6. 3728 6.5. QoS NSLP Error Source Identifiers 3730 Section 5.1.3.4 defines Error Source Identifiers, the type of which 3731 is identified by a 4 bit value. The value 0 is reserved, all other 3732 values are assigned on a basis of Specification Required, except for 3733 14 and 15 which are for Experimental/Private Use. 3735 Initial assignments are given in section 5.1.3.4. 3737 6.6. NSLP IDs and Router Alert Option Values 3739 This specification defines an NSLP for use with GIST. Furthermore it 3740 specifies that a number of NSLP-ID values are used for the support of 3741 bypassing intermediary nodes. Consequently, new identifiers must be 3742 assigned for them from the GIST NSLP identifier registry. The QoS 3743 NSLP requires that 32 NSLP-ID values be assigned, corresponding to 3744 QoS NSLP Aggregation Levels 0 to 31. 3746 The GIST specification also requires that NSLP-IDs be associated with 3747 specific Router Alert Option (RAO) values (although multiple NSLP-IDs 3748 may be associated with the same value). For the purposes of the QoS 3749 NSLP, each of its NSLP-ID values should be associated with a 3750 different RAO value. This requires that a block of 32 new IPv4 RAO 3751 values and a block of 32 new IPv6 RAO values be assigned, 3752 corresponding to QoS NSLP Aggregation Levels 0 to 31. 3754 7. Security Considerations 3756 The security requirement for the QoS NSLP is to protect the signaling 3757 exchange for establishing QoS reservations against identified 3758 security threats. For the signaling problem as a whole, these 3759 threats have been outlined in NSIS threats [RFC4081]; the NSIS 3760 framework [RFC4080] assigns a subset of the responsibility to GIST 3761 and the remaining threats need to be addressed by NSLPs. The main 3762 issues to be handled can be summarized as: 3764 Authorization: 3766 The QoS NSLP must assure that the network is protected against theft- 3767 of-service by offering mechanisms to authorize the QoS reservation 3768 requester. A user requesting a QoS reservation might want proper 3769 resource accounting and protection against spoofing and other 3770 security vulnerabilities which lead to denial of service and 3771 financial loss. In many cases authorization is based on the 3772 authenticated identity. The authorization solution must provide 3773 guarantees that replay attacks are either not possible or limited to 3774 a certain extent. Authorization can also be based on traits which 3775 enables the user to remain anonymous. Support for user identity 3776 confidentiality can be accomplished. 3778 Message Protection: 3780 Signaling message content should be protected against modification, 3781 replay, injection and eavesdropping while in transit. Authorization 3782 information, such as authorization tokens, need protection. This 3783 type of protection at the NSLP layer is necessary to protect messages 3784 between NSLP nodes. 3786 Rate Limitation: 3788 QNEs should perform rate limiting on the refresh messages that they 3789 send. An attacker could send erroneous messages on purpose, forcing 3790 the QNE to constantly reply with an error message. Authentication 3791 mechanisms would help in figuring out if error situations should be 3792 reported to the sender, or silently ignored. If the sender is 3793 authenticated, the QNE should reply promptly. 3795 Prevention of Denial of Service Attacks: 3797 GIST and QoS NSLP nodes have finite resources (state storage, 3798 processing power, bandwidth). The protocol mechanisms s in this 3799 document try to minimize exhaustion attacks against these resources 3800 when performing authentication and authorization for QoS resources. 3802 To some extent the QoS NSLP relies on the security mechanisms 3803 provided by GIST which by itself relies on existing authentication 3804 and key exchange protocols. Some signaling messages cannot be 3805 protected by GIST and hence should be used with care by the QoS NSLP. 3806 An API must ensure that the QoS NSLP implementation is aware of the 3807 underlying security mechanisms and must be able to indicate which 3808 degree of security is provided between two GIST peers. If a level of 3809 security protection for QoS NSLP messages is required which goes 3810 beyond the security offered by GIST or underlying security 3811 mechanisms, additional security mechanisms described in this document 3812 must be used. The different usage environments and the different 3813 scenarios where NSIS is used make it very difficult to make general 3814 statements without reducing its flexibility. 3816 7.1. Trust Relationship Model 3818 This specification is based on a model which requires trust between 3819 neighboring NSLP nodes to establish a chain-of-trust along the QoS 3820 signaling path. The model is simple to deploy, was used in previous 3821 QoS authorization environments (such as RSVP) and seems to provide 3822 sufficiently strong security properties. We refer to this model as 3823 the New Jersey Turnpike. 3825 On the New Jersey Turnpike, motorists pick up a ticket at a toll 3826 booth when entering the highway. At the highway exit the ticket is 3827 presented and payment is made at the toll booth for the distance 3828 driven. For QoS signaling in the Internet this procedure is roughly 3829 similar. In most cases the data sender is charged for transmitted 3830 data traffic where charging is provided only between neighboring 3831 entities. 3833 +------------------+ +------------------+ +------------------+ 3834 | Network | | Network | | Network | 3835 | X | | Y | | Z | 3836 | | | | | | 3837 | -----------> -----------> | 3838 | | | | | | 3839 | | | | | | 3840 +--------^---------+ +------------------+ +-------+----------+ 3841 | . 3842 | . 3843 | v 3844 +--+---+ Data Data +--+---+ 3845 | Node | ==============================> | Node | 3846 | A | Sender Receiver | B | 3847 +------+ +------+ 3849 Legend: 3851 ----> Peering relationship which allows neighboring 3852 networks/entities to charge each other for the 3853 QoS reservation and data traffic 3855 ====> Data flow 3857 .... Communication to the end host 3859 Figure 42: New Jersey Turnpike Model 3861 The model shown in Figure 42 uses peer-to-peer relationships between 3862 different administrative domains as a basis for accounting and 3863 charging. As mentioned above, based on the peering relationship a 3864 chain-of-trust is established. There are several issues which come 3865 to mind when considering this type of model: 3867 o The model allows authorization on a request basis or on a per- 3868 session basis. Authorization mechanisms are elaborated in Section 3869 4.9. The duration for which the QoS authorization is valid needs to 3870 be controlled. Combining the interval with the soft-state interval 3871 is possible. Notifications from the networks also seem to be viable 3872 approach. 3874 o The price for a QoS reservation needs to be determined somehow and 3875 communicated to the charged entity and to the network where the 3876 charged entity is attached. Protocols providing Advice of Charge 3877 functionality are out of scope. 3879 o This architecture is simple enough to allow a scalable solution 3880 (ignoring reverse charging, multicast issues and price distribution). 3882 Charging the data sender as performed in the model simplifies 3883 security handling by demanding only peer-to-peer security protection. 3884 Node A would perform authentication and key establishment. The 3885 established security association (together with the session key) 3886 would allow the user to protect QoS signaling messages. The identity 3887 used during the authentication and key establishment phase would be 3888 used by Network X (see Figure 42) to perform the so-called policy- 3889 based admission control procedure. In our context this user 3890 identifier would be used to establish the necessary infrastructure to 3891 provide authorization and charging. Signaling messages later 3892 exchanged between the different networks are then also subject to 3893 authentication and authorization. The authenticated entity thereby 3894 is, however, the neighboring network and not the end host. 3896 The New Jersey Turnpike model is attractive because of its 3897 simplicity. S. Schenker et. al. [shenker] discuss various accounting 3898 implications and introduced the edge pricing model. The edge pricing 3899 model shows similarity to the model described in this section with 3900 the exception that mobility and the security implications itself are 3901 not addressed. 3903 7.2. Authorization Model Examples 3905 Various authorization models can be used in conjunction with the QoS 3906 NSLP. 3908 7.2.1. Authorization for the Two Party Approach 3910 The two party approach (Figure 43) is conceptually the simplest 3911 authorization model. 3913 +-------------+ QoS request +--------------+ 3914 | Entity |----------------->| Entity | 3915 | requesting | | authorizing | 3916 | resource |granted / rejected| resource | 3917 | |<-----------------| request | 3918 +-------------+ +--------------+ 3919 ^ ^ 3920 +...........................+ 3921 compensation 3923 Figure 43: Two party approach 3925 In this example the authorization decision only involves the two 3926 entities, or makes use of previous authorization using an out-of-band 3927 mechanism to avoid the need for active participation of an external 3928 entity during the NSIS protocol execution. 3930 This type of model may be applicable, e.g., between two neighboring 3931 networks (inter-domain signaling) where a long-term contract (or 3932 other out-of-band mechanisms) exists to manage charging and provides 3933 sufficient information to authorize individual requests. 3935 7.2.2. Token-based Three Party Approach 3937 An alternative approach makes use of tokens, such as those described 3938 in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the 3939 Open Settlement Protocol [osp]. Authorization tokens are used to 3940 associate two different signaling protocols runs (e.g., SIP and NSIS) 3941 and their authorization decision with each other. The latter is a 3942 form of assertion or trait. As an example, with the authorization 3943 token mechanism, some form of authorization is provided by the SIP 3944 proxy, which acts as the resource authorizing entity in Figure 44. 3945 If the request is authorized, then the SIP signaling returns an 3946 authorization token which can be included in the QoS signaling 3947 protocol messages to refer to the previous authorization decision. 3948 The tokens themselves may take a number of different forms, some of 3949 which may require the entity performing the QoS reservation to query 3950 external state. 3952 Authorization 3953 Token Request +--------------+ 3954 +-------------->| Entity C | financial settlement 3955 | | authorizing | <..................+ 3956 | | resource | . 3957 | +------+ request | . 3958 | | +--------------+ . 3959 | | . 3960 | |Authorization . 3961 | |Token . 3962 | | . 3963 | | . 3964 | | . 3965 | | QoS request . 3966 +-------------+ + Authz. Token +--------------+ . 3967 | Entity |----------------->| Entity B | . 3968 | requesting | | performing | . 3969 | resource |granted / rejected| QoS | <..+ 3970 | A |<-----------------| reservation | 3971 +-------------+ +--------------+ 3973 Figure 44: Token based three party approach 3975 For the digital money type of systems (e.g., OSP tokens), the token 3976 represents a limited amount of credit. So, new tokens must be sent 3977 with later refresh messages once the credit is exhausted. 3979 7.2.3. Generic Three Party Approach 3981 Another method is for the node performing the QoS reservation to 3982 delegate the authorization decision to a third party, as illustrated 3983 in Figure 45. The authorization decision may be performed on a per- 3984 request basis, periodically, or on a per-session basis. 3986 +--------------+ 3987 | Entity C | 3988 | authorizing | 3989 | resource | 3990 | request | 3991 +-----------+--+ 3992 ^ | 3993 QoS | | QoS 3994 authz| |authz 3995 req.| | res. 3996 QoS | v 3997 +-------------+ request +--+-----------+ 3998 | Entity |----------------->| Entity B | 3999 | requesting | | performing | 4000 | resource |granted / rejected| QoS | 4001 | A |<-----------------| reservation | 4002 +-------------+ +--------------+ 4004 Figure 45: Three party approach 4006 7.3. Computing the Authorization Decision 4008 Whenever an authorization decision has to be made then there is the 4009 question which information serves as an input to the authorizing 4010 entity. The following information items have been mentioned in the 4011 past for computing the authorization decision (in addition to the 4012 authenticated identity): 4014 Price 4016 QoS objects 4018 Policy rules 4020 Policy rules include attributes like time of day, subscription to 4021 certain services, membership, etc. into consideration when computing 4022 an authorization decision. 4024 The policies used to make the authorization are outside the scope of 4025 this document and implementation/deployment specific. 4027 8. Acknowledgments 4029 The authors would like to thank Eleanor Hepworth, Ruediger Geib, 4030 Roland Bless, Nemeth Krisztian, Markus Ott, Mayi Zoumaro-Djayoon, 4031 Martijn Swanink, and Ruud Klaver for their useful comments. Roland, 4032 especially, has done deep reviews of the document, making sure the 4033 protocol is well defined. Bob Braden provided helpful comments and 4034 guidance which were gratefully received. 4036 9. Contributors 4038 This draft combines work from three individual drafts. The following 4039 authors from these drafts also contributed to this document: Robert 4040 Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia 4041 Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and 4042 Maarten Buechli (Dante) and Eric Waegeman (Alcatel). In addition, 4043 Roland Bless has contributed considerable amounts of text all along 4044 the writing of this specification. 4046 Sven Van den Bosch was the first editor of the draft. Since version 4047 06 of the draft, Jukka Manner has taken the editorship. Yacine El 4048 Mghazli (Alcatel) contributed text on AAA. Charles Shen and Henning 4049 Schulzrinne suggested the use of the reason field in the 4050 BOUND_SESSION_ID. 4052 10. References 4054 10.1. Normative References 4056 [I-D.ietf-nsis-ntlp] 4057 Schulzrinne, H. and R. Hancock, "GIST: General Internet 4058 Signalling Transport", draft-ietf-nsis-ntlp-14 (work in 4059 progress), July 2007. 4061 [I-D.ietf-nsis-qspec] 4062 Ash, J., "QoS NSLP QSPEC Template", 4063 draft-ietf-nsis-qspec-17 (work in progress), July 2007. 4065 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 4066 August 1996. 4068 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4069 Requirement Levels", BCP 14, RFC 2119, March 1997. 4071 10.2. Informative References 4073 [I-D.ietf-nsis-applicability-mobility-signaling] 4074 Lee, S., "Applicability Statement of NSIS Protocols in 4075 Mobile Environments", 4076 draft-ietf-nsis-applicability-mobility-signaling-07 (work 4077 in progress), July 2007. 4079 [I-D.ietf-nsis-rmd] 4080 Bader, A., "RMD-QOSM - The Resource Management in Diffserv 4081 QOS Model", draft-ietf-nsis-rmd-10 (work in progress), 4082 June 2007. 4084 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 4085 Services in the Internet Architecture: an Overview", 4086 RFC 1633, June 1994. 4088 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 4089 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 4090 Functional Specification", RFC 2205, September 1997. 4092 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 4093 Services", RFC 2210, September 1997. 4095 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4096 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 4097 October 1998. 4099 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 4100 and S. Molendini, "RSVP Refresh Overhead Reduction 4101 Extensions", RFC 2961, April 2001. 4103 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 4104 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 4105 RFC 3175, September 2001. 4107 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 4108 "Session Authorization Policy Element", RFC 3520, 4109 April 2003. 4111 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 4112 Session Set-up with Media Authorization", RFC 3521, 4113 April 2003. 4115 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 4116 RFC 3726, April 2004. 4118 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 4119 Bosch, "Next Steps in Signaling (NSIS): Framework", 4120 RFC 4080, June 2005. 4122 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 4123 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 4125 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 4126 Specifications: ABNF", RFC 4234, October 2005. 4128 [lrsvp] Manner, J. and K. Raatikainen, "Localized QoS Management 4129 for Multimedia Applications in Wireless Access Networks. 4130 IASTED, IMSA, August, 2004, pp. 193-200.". 4132 [nslp-auth] 4133 Manne, J., Stiemerling, M., and H. Tschofenig, 4134 "Authorization for NSIS Signaling Layer Protocols, Work in 4135 Progress.". 4137 [opwa95] Breslau, L., "Two Issues in Reservation Establishment, 4138 Proc. ACM SIGCOMM '95 , Cambridge , MA , August 1995.". 4140 [osp] ETSI, ""Telecommunications and Internet protocol 4141 harmonization over networks (tiphon); open settlement 4142 protocol (osp) for inter- domain pricing, authorization, 4143 and usage exchange", Technical Specification 101 321, 4144 version 2.1.0.". 4146 [qos-auth] 4147 Tschofenig, H., "QoS NSLP Authorization Issues. Work in 4148 Progress.". 4150 [shenker] Shenker, S. and et al., ""Pricing in computer networks: 4151 Reshaping the research agenda", Proc. of TPRC 1995, 4152 1995.". 4154 Appendix A. Appendix A. Abstract NSLP-RMF API 4156 This appendix provides an abstract API between the QoS NSLP and the 4157 RMF. It should not be taken as a strict rule of implementors, but 4158 rather help clarify the interface between the NSLP and RMF. 4160 A.1. Triggers from QOS-NSLP towards RMF 4162 The QoS-NSLP triggers the RMF/QOSM functionality by using the 4163 sendrmf() primitive: 4165 int sendrmf(sid, nslp_req_type, qspec, authorization_info, 4166 NSLP_objects, filter, features_in, GIST_API_triggers, 4167 incoming_interface, outgoing_interface) 4169 o sid: SESSION_ID - The NSIS session identifier 4170 o nslp_req_type: indicates type of request: 4171 * RESERVE 4172 * QUERY 4173 * RESPONSE 4174 * NOTIFY 4175 o qspec: the QSPEC object, if present 4176 o authorization_info: the AUTHO_SESSION object, if present 4177 o NSLP_objects: data structure that contains a list with received 4178 QoS-NSLP objects. This list can be used by e.g., Local 4179 application, Management, Policy control: 4180 * RII 4181 * RSN 4182 * BOUND_SESSION_ID list 4183 * REFRESH_PERIOD 4184 * SESSION_ID_LIST 4185 * RSN_LIST 4186 * INFO_SPEC 4187 * MSG_ID 4188 * BOUND_MSG_ID 4189 o filter: the information for packet filtering, based on the MRI and 4190 the PACKET_CLASSIFIER object. 4191 o features_in: it represents the flags included in the common header 4192 of the received QOS-NSLP message, but also additional 4193 o triggers: 4194 * BREAK 4195 * REQUEST REDUCED REFRESHES 4196 * RESERVE-INIT 4197 * TEAR 4198 * REPLACE 4199 * ACK-REQ 4200 * PROXY 4201 * SCOPING 4202 * synchronization_required: this attribute is set (see e.g., 4203 Section 4.6 and 4.7.1) when the QoS-NSLP functionality 4204 supported by a QNE Egress receives a non tearing RESERVE 4205 message that includes a MSG_ID or a BOUND_MSG_ID object and the 4206 BINDING_CODE value of the BOUND_SESSION_ID object is equal to 4207 one of the following values: 4208 + Tunnel and end-to-end sessions 4209 + Aggregate sessions 4210 * GIST_API_triggers: it represents the attributes that are 4211 provided by GIST to QoS-NSLP via the GIST API: 4212 + NSLPID 4213 + Routing-State-Check 4214 + SII-Handle 4215 + Transfer-Attributes 4216 + GIST-Hop-Count 4217 + IP-TTL 4218 + IP-Distance 4220 o incoming_interface: the ID of the incoming interface. Used only 4221 when the QNE reserves resources on incoming interface. Default is 4222 0 (no reservations on incoming interface) 4223 o outgoing_interface: the ID of the outgoing interface. Used only 4224 when the QNE reserves resources on outgoing interface. Default is 4225 0 (no reservations on outgoing interface) 4227 A.2. Triggers from RMF/QOSM towards QOS-NSLP 4229 The RMF triggers the QoS-NSLP functionality using the "recvrmf()" and 4230 "config()" primitives to perform either all or a subset of the 4231 features listed below. 4233 The recvrmf() primitive represents either a response to a request 4234 that has been sent via the API by the QoS-NSLP or an asynchronous 4235 notification. Note that when the RMF/QOSM receives a request via the 4236 API from the QoS-NSLP function, then one or more than one "recvrmf()" 4237 response primitives can be sent via the API towards QoS-NSLP. In 4238 this way the QOS-NSLP can generate one, or more than one, QoS-NSLP 4239 messages that can be for example, used in the situation that the 4240 arrival of one end-to-end RESERVE triggers the generation of two (or 4241 more) RESERVE messages, an end-to-end RESERVE message and one (or 4242 more) intra-domain (local) RESERVE message. 4244 The config() primitive is used to configure certain features, such as 4245 QNE type, statefullness, bypassing support. 4247 Note that the selection of the subset of triggers is controlled by 4248 the QoS Model. 4250 int recvrmf(sid, nslp_resp_type, qspec, authorization_info, status, 4251 NSLP_objects, filter, features_out, GIST_API_triggers 4252 incoming_interface, outgoing_interface) 4254 o sid: SESSION_ID - The NSIS session identifier 4255 o nslp_resp_type: indicates type of response: 4256 * RESERVE 4257 * QUERY 4258 * RESPONSE 4259 * NOTIFY 4260 o qspec: the QSPEC object, if present 4261 o authorization_info: the AUTHO_SESSION object, if present 4262 o status: boolean that notifies the status of the reservation and 4263 can be used by QOS-NSLP to include in the INFO_SPEC object: 4264 * RESERVATION_SUCCESSFUL 4265 * TEAR_DOWN_SUCCESSFUL 4266 * NO RESOURCES 4267 * RESERVATION_FAILURE 4268 * RESERVATION_PREEMPTED: reservation was pre-empted 4269 * AUTHORIZATION_FAILED: authorizing the request failed 4270 * MALFORMED_QSPEC: request failed due to malformed qspec 4271 * SYNCHRONISATION_FAILED: Mismatch synchronization between an 4272 end-to-end RESERVE and an intra-domain RESERVE (see Section 4.6 4273 and 4.7.1) 4274 * CONGESTION_SITUATION: Possible congestion situation occurred on 4275 downstream path 4276 * QOS Model Error 4277 o NSLP_objects: data structure that contains a list with QoS-NSLP 4278 objects that can be used by QoS-NSLP, when the QNE is a QNI, QNR, 4279 QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress: 4280 * RII 4281 * RSN 4282 * BOUND_SESSION_ID list 4283 * REFRESH_PERIOD 4284 * SESSION_ID_LIST 4285 * RSN_LIST 4286 * MSG_ID 4287 * BOUND_MSG_ID 4288 o filter: it represents the MRM related PACKET CLASSIFIER 4289 o features_out: it represents among others the flags that can be 4290 used by the QOS-NSLP for new generated QoS-NSLP messages: 4291 * BREAK 4292 * REQUEST REDUCED REFRESHES 4293 * RESERVE-INIT 4294 * TEAR 4295 * REPLACE 4296 * ACK-REQ 4297 * PROXY 4298 * SCOPING 4299 * BYPASSING: when the outgoing message should be bypassed then it 4300 includes the required bypassing level. Otherwise it is empty. 4301 It can be set only by QNI_Ingress, QNR_Ingress, QNI_Egress, 4302 QNR_Egress. It can be unset only by QNI_Ingress, QNR_Ingress, 4303 QNI_Egress, QNR_Egress. 4304 * BINDING () when BINDING is required then it includes a 4305 BOUND_SESSION_ID list. Otherwise it is empty. It can only be 4306 requested by the following QNE types: QNI, QNR, QNI_Ingress, 4307 QNR_Ingress, QNI_Egress, QNR_Egress. 4308 * NEW_SID - it requests to generate a new session with a new 4309 SESSION_ID. If the QoS-NSLP generates a new SESSION_ID then 4310 the QoS-NSLP has to return the value of this new SESSION_ID to 4311 the RMF/QOSM. It can be requested by a QNI, QNR, QNI_Ingress, 4312 QNI_Egress, QNR_Ingress, QNR_Egress. 4314 * NEW_RSN - it requests to generate a new RSN. If the QoS-NSLP 4315 generates a new RSN then the QoS-NSLP has to return the value 4316 of this new RSN to the RMF/QOSM. 4317 * NEW_RII - it requests to generate a new RII. If the QoS-NSLP 4318 generates a new RII then the QoS-NSLP has to return the value 4319 of this new RII to the RMF/QOSM. 4320 o GIST_API_triggers: it represents the attributes that are provided 4321 to GIST via QoS-NSLP via the GIST API 4322 * NSLPID 4323 * SII-Handle 4324 * Transfer-Attributes 4325 * GIST-Hop-Count 4326 * IP-TTL 4327 * ROUTING-STATE-CHECK (if set it requires from GIST to create a 4328 routing state) 4329 o incoming_interface: the ID of the incoming interface. Used only 4330 when the QNE reserves resources on incoming interface. Default is 4331 0 (no reservations on incoming interface) 4332 o outgoing_interface: the ID of the outgoing interface. Used only 4333 when the QNE reserves resources on outgoing interface. Default is 4334 0 (no reservations on outgoing interface) 4336 A.3. Configuration interface 4338 The config() function is meant for configuring per-session settings, 4339 from the RMF towards the NSLP. 4341 int config(sid, qne_type, state_type, bypassing_type) 4343 o sid: SESSION_ID - The NSIS session identifier 4344 o qne_type: it defines the type of a QNE 4345 * QNI 4346 * QNI_Ingress: the QNE is a QNI and an Ingress QNE 4347 * QNE: the QNE is not a QNI or QNR 4348 * QNE_Interior: the QNE is an Interior QNE, but it is not a QNI 4349 or QNR 4350 * QNI_Egress: the QNE is a QNI and an Egress QNE 4351 * QNR 4352 * QNR_Ingress: the QNE is a QNR and an Ingress QNE 4353 * QNR_Egress: the QNE is a QNR and an Egress QNE 4354 o state_type: it defines if the QNE keeps QoS-NSLP operational 4355 states 4356 * STATEFULL 4357 * STATELESS 4358 o bypassing_type: it defines if a QNE bypasses end-to-end messages 4359 or not 4361 Appendix B. Appendix B. Glossary 4363 AAA: Authentication, Authorization and Accounting 4365 EAP: Extensible Authentication Protocol 4367 MRI: Message Routing Information (see [I-D.ietf-nsis-ntlp]) 4369 NAT: Network Address Translator 4371 NSLP: NSIS Signaling Layer Protocol (see [RFC4080]) 4373 NTLP: NSIS Transport Layer Protocol (see [RFC4080]) 4375 OPWA: One Pass With Advertising 4377 OSP: Open Settlement Protocol 4379 PIN: Policy Ignorant Node 4381 QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2) 4383 QNI: the first node in the sequence of QNEs that issues a reservation 4384 request for a session (see Section 2) 4386 QNR: the last node in the sequence of QNEs that receives a 4387 reservation request for a session (see Section 2) 4389 QSPEC: Quality of Service Specification 4391 RII: Request Identification Information 4393 RMD: Resource Management for DiffServ 4395 RMF: Resource Management Function 4397 RSN: Reservation Sequence Number 4399 RSVP: Resource Reservation Protocol (see [RFC2205]) 4401 SII: Source Identification Information 4403 SIP: Session Initiation Protocol 4405 SLA: Service Level Agreement 4407 Authors' Addresses 4409 Jukka Manner 4410 University of Helsinki 4411 P.O. Box 68 4412 University of Helsinki FIN-00014 University of Helsinki 4413 Finland 4415 Email: jmanner@cs.helsinki.fi 4417 Georgios Karagiannis 4418 University of Twente/Ericsson 4419 P.O. Box 217 4420 Enschede 7500 AE 4421 The Netherlands 4423 Email: karagian@cs.utwente.nl 4425 Andrew McDonald 4426 Siemens/Roke Manor Research 4427 Roke Manor Research Ltd. 4428 Romsey, Hants S051 0ZN 4429 UK 4431 Email: andrew.mcdonals@roke.co.uk 4433 Full Copyright Statement 4435 Copyright (C) The IETF Trust (2007). 4437 This document is subject to the rights, licenses and restrictions 4438 contained in BCP 78, and except as set forth therein, the authors 4439 retain all their rights. 4441 This document and the information contained herein are provided on an 4442 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4443 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4444 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4445 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4446 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4449 Intellectual Property 4451 The IETF takes no position regarding the validity or scope of any 4452 Intellectual Property Rights or other rights that might be claimed to 4453 pertain to the implementation or use of the technology described in 4454 this document or the extent to which any license under such rights 4455 might or might not be available; nor does it represent that it has 4456 made any independent effort to identify any such rights. Information 4457 on the procedures with respect to rights in RFC documents can be 4458 found in BCP 78 and BCP 79. 4460 Copies of IPR disclosures made to the IETF Secretariat and any 4461 assurances of licenses to be made available, or the result of an 4462 attempt made to obtain a general license or permission for the use of 4463 such proprietary rights by implementers or users of this 4464 specification can be obtained from the IETF on-line IPR repository at 4465 http://www.ietf.org/ipr. 4467 The IETF invites any interested party to bring to its attention any 4468 copyrights, patents or patent applications, or other proprietary 4469 rights that may cover technology that may be required to implement 4470 this standard. Please address the information to the IETF at 4471 ietf-ipr@ietf.org. 4473 Acknowledgment 4475 Funding for the RFC Editor function is provided by the IETF 4476 Administrative Support Activity (IASA).