idnits 2.17.1 draft-ietf-nsis-qos-nslp-05.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3299. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 3039 has weird spacing: '...d usage excha...' -- 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 (October 25, 2004) is 7124 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) == Unused Reference: 'RFC2119' is defined on line 2971, but no explicit reference was found in the text == Unused Reference: 'RFC3583' is defined on line 3075, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-01) exists of draft-bader-nsis-rmd-diffserv-qsm-00 == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-06 == Outdated reference: A later version (-06) exists of draft-ietf-nsis-threats-05 == Outdated reference: A later version (-14) exists of draft-kappler-nsis-qosmodel-controlledload-00 == Outdated reference: A later version (-04) exists of draft-manner-lrsvp-03 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Next Steps in Signalling S. Van den Bosch 3 Internet-Draft Alcatel 4 Expires: April 25, 2005 G. Karagiannis 5 University of Twente/Ericsson 6 A. McDonald 7 Siemens/Roke Manor Research 8 October 25, 2004 10 NSLP for Quality-of-Service signalling 11 draft-ietf-nsis-qos-nslp-05.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 25, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This draft describes an NSIS Signalling Layer Protocol (NSLP) for 47 signalling QoS reservations in the Internet. It is in accordance 48 with the framework and requirements developed in NSIS. 50 Together with GIMPS, it provides functionality similar to RSVP and 51 extends it. The QoS-NSLP is independent of the underlying QoS 52 specification or architecture and provides support for different 53 reservation models. It is simplified by the elimination of support 54 for multicast flows. 56 This draft explains the overall protocol approach, design decisions 57 made and provides examples. It specifies object and message formats 58 and processing rules. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1 Scope and background . . . . . . . . . . . . . . . . . . . 5 64 1.2 Model of operation . . . . . . . . . . . . . . . . . . . . 6 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 10 67 3.1 Overall approach . . . . . . . . . . . . . . . . . . . . . 10 68 3.1.1 GIMPS Interactions . . . . . . . . . . . . . . . . . . 10 69 3.1.2 Protocol messages . . . . . . . . . . . . . . . . . . 10 70 3.1.3 QoS Signalling Models and QoS specifications . . . . . 11 71 3.1.4 Authentication and authorization . . . . . . . . . . . 12 72 3.2 Design decisions . . . . . . . . . . . . . . . . . . . . . 15 73 3.2.1 Soft-state . . . . . . . . . . . . . . . . . . . . . . 15 74 3.2.2 Sender-receiver initiation . . . . . . . . . . . . . . 15 75 3.2.3 Message sequencing . . . . . . . . . . . . . . . . . . 15 76 3.2.4 Explicit state installation confirmation and 77 responses . . . . . . . . . . . . . . . . . . . . . . 16 78 3.2.5 Summary refreshes . . . . . . . . . . . . . . . . . . 16 79 3.2.6 Message scoping . . . . . . . . . . . . . . . . . . . 16 80 3.2.7 Session binding . . . . . . . . . . . . . . . . . . . 17 81 3.2.8 Layering . . . . . . . . . . . . . . . . . . . . . . . 17 82 3.2.9 Priority . . . . . . . . . . . . . . . . . . . . . . . 19 83 3.2.10 Rerouting (SII) . . . . . . . . . . . . . . . . . . 19 84 4. Examples of QoS NSLP Operation . . . . . . . . . . . . . . . 21 85 4.1 Basic sender-initiated reservation . . . . . . . . . . . . 21 86 4.2 Sending a Query . . . . . . . . . . . . . . . . . . . . . 22 87 4.3 Basic receiver-initiated reservation . . . . . . . . . . . 23 88 4.4 Bidirectional Reservations . . . . . . . . . . . . . . . . 25 89 4.5 Use of Local QoS Models . . . . . . . . . . . . . . . . . 26 90 4.6 Aggregate Reservations . . . . . . . . . . . . . . . . . . 27 91 4.7 Reduced State or Stateless Interior Nodes . . . . . . . . 29 92 4.8 Re-routing scenario . . . . . . . . . . . . . . . . . . . 32 93 4.9 Authorization Model Examples . . . . . . . . . . . . . . . 33 94 4.9.1 Authorization for the two party approach . . . . . . . 33 95 4.9.2 Token based three party approach . . . . . . . . . . . 33 96 4.9.3 Generic three party approach . . . . . . . . . . . . . 34 97 5. QoS NSLP Functional specification . . . . . . . . . . . . . 36 98 5.1 QoS NSLP Message and Object Formats . . . . . . . . . . . 36 99 5.1.1 Common header . . . . . . . . . . . . . . . . . . . . 36 100 5.1.2 Message formats . . . . . . . . . . . . . . . . . . . 37 101 5.1.3 Object Formats . . . . . . . . . . . . . . . . . . . . 39 102 5.2 General Processing Rules . . . . . . . . . . . . . . . . . 43 103 5.2.1 State Manipulation . . . . . . . . . . . . . . . . . . 44 104 5.2.2 Message Forwarding . . . . . . . . . . . . . . . . . . 45 105 5.2.3 Standard Message Processing Rules . . . . . . . . . . 45 106 5.3 Object Processing . . . . . . . . . . . . . . . . . . . . 45 107 5.3.1 Reservation Sequence Number (RSN) . . . . . . . . . . 45 108 5.3.2 Request Identification Information (RII) . . . . . . . 46 109 5.3.3 BOUND_SESSION_ID . . . . . . . . . . . . . . . . . . . 47 110 5.3.4 REFRESH_PERIOD . . . . . . . . . . . . . . . . . . . . 47 111 5.3.5 ERROR_SPEC . . . . . . . . . . . . . . . . . . . . . . 49 112 5.3.6 QSPEC . . . . . . . . . . . . . . . . . . . . . . . . 49 113 5.4 Message Processing Rules . . . . . . . . . . . . . . . . . 50 114 5.4.1 RESERVE Messages . . . . . . . . . . . . . . . . . . . 50 115 5.4.2 QUERY Messages . . . . . . . . . . . . . . . . . . . . 52 116 5.4.3 RESPONSE Messages . . . . . . . . . . . . . . . . . . 53 117 5.4.4 NOTIFY Messages . . . . . . . . . . . . . . . . . . . 54 118 6. IANA considerations . . . . . . . . . . . . . . . . . . . . 55 119 7. QoS use of GIMPS service interface . . . . . . . . . . . . . 56 120 7.1 Example sender-initiated reservation . . . . . . . . . . . 56 121 7.2 Session identification . . . . . . . . . . . . . . . . . . 57 122 7.3 Support for bypassing intermediate nodes . . . . . . . . . 57 123 7.4 Support for peer change identification . . . . . . . . . . 58 124 7.5 Support for stateless operation . . . . . . . . . . . . . 58 125 7.6 Last node detection . . . . . . . . . . . . . . . . . . . 58 126 7.7 Re-routing detection . . . . . . . . . . . . . . . . . . . 59 127 7.8 Priority of signalling messages . . . . . . . . . . . . . 59 128 7.9 Knowledge of intermediate QoS NSLP unaware nodes . . . . . 59 129 7.10 NSLP Data Size . . . . . . . . . . . . . . . . . . . . . 60 130 7.11 Notification of GIMPS 'D' flag value . . . . . . . . . . 60 131 7.12 NAT Traversal . . . . . . . . . . . . . . . . . . . . . 60 132 8. Assumptions on the QSM . . . . . . . . . . . . . . . . . . . 61 133 8.1 Resource sharing . . . . . . . . . . . . . . . . . . . . . 61 134 8.2 Reserve/commit support . . . . . . . . . . . . . . . . . . 61 135 9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 62 136 9.1 Peering agreements on interdomain links . . . . . . . . . 62 137 9.2 Protocol Operating Environment Assumptions . . . . . . . . 62 138 10. Security Considerations . . . . . . . . . . . . . . . . . . 64 139 10.1 Introduction and Threat Overview . . . . . . . . . . . . 64 140 10.2 Trust Model . . . . . . . . . . . . . . . . . . . . . . 65 141 10.3 Computing the authorization decision . . . . . . . . . . 67 142 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 68 143 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 144 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 71 145 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 146 14.1 Normative References . . . . . . . . . . . . . . . . . . . 72 147 14.2 Informative References . . . . . . . . . . . . . . . . . . 72 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 74 149 A. POLICY_DATA Class . . . . . . . . . . . . . . . . . . . . . 76 150 A.1 Base Format . . . . . . . . . . . . . . . . . . . . . . . 76 151 A.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . 76 152 A.3 Policy Elements . . . . . . . . . . . . . . . . . . . . . 77 153 A.3.1 Authorization token Policy Element . . . . . . . . . . 77 154 A.3.2 OSP Token Policy Element . . . . . . . . . . . . . . . 79 155 A.3.3 User Identity Policy element . . . . . . . . . . . . . 79 156 Intellectual Property and Copyright Statements . . . . . . . 80 158 1. Introduction 160 1.1 Scope and background 162 This document defines a Quality of Service (QoS) NSIS Signalling 163 Layer Protocol (NSLP), henceforth referred to as the "QoS-NSLP". 164 This protocol establishes and maintains state at nodes along the path 165 of a data flow for the purpose of providing some forwarding resources 166 for that flow. It is intended to satisfy the QoS-related 167 requirements of RFC 3726 [RFC3726]. This QoS-NSLP is part of a 168 larger suite of signalling protocols, whose structure is outlined in 169 the NSIS framework [I-D.ietf-nsis-fw]; this defines a common NSIS 170 Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out many 171 aspects of signalling message delivery. A specification of the NTLP, 172 GIMPS [I-D.ietf-nsis-ntlp] is done in another document. 174 The design of QoS-NSLP is conceptually similar to RSVP, RFC 2205 175 [RFC2205], and uses soft-state peer-to-peer refresh messages as the 176 primary state management mechanism (i.e. state installation/refresh 177 is performed between pairs of adjacent NSLP nodes, rather than in an 178 end-to-end fashion along the complete signalling path). Although 179 there is no backwards compatibility at the level of protocol 180 messages, interworking with RSVP at a signalling application gateway 181 would be possible in some circumstances. QoS-NSLP extends the set of 182 reservation mechanisms to meet the requirements of RFC 3726 183 [RFC3726], in particular support of sender or receiver-initiated 184 reservations, as well as a type of bi-directional reservation and 185 support of reservations between arbitrary nodes, e.g. edge-to-edge, 186 end-to-access, etc. On the other hand, there is no support for IP 187 multicast. 189 QoS-NSLP does not mandate any specific 'QoS Signalling Model' (QSM), 190 i.e. a particular QoS provisioning method or QoS architecture; this 191 is similar to (but stronger than) the decoupling between RSVP and the 192 IntServ architecture, RFC 1633 [RFC1633]. It should be able to carry 193 information for various QSMs; the specification of Integrated 194 Services for use with RSVP given in RFC 2210 [RFC2210] could form the 195 basis of one QSM. 197 This document is structured as follows. The overall approach to 198 protocol design is outlined in Section 3.1. The operation and use of 199 QoS NSLP is then clarified by means of a number of examples in 200 Section 4. These sections should be read by readers interested in 201 the protocol capabilities. The functional specification Section 5 202 contains more detailed object and message formats and processing 203 rules and should be the basis for implementers. The subsequent 204 sections describe extensibility (IANA), requirements on GIMPS API and 205 security considerations. 207 1.2 Model of operation 209 This section presents a logical model for the operation of the 210 QoS-NSLP and associated provisioning mechanisms within a single node. 211 The model is shown in Figure 1. 213 +---------------+ 214 | Local | 215 |Applications or| 216 |Management (e.g| 217 |for aggregates)| 218 +---------------+ 219 ^ 220 ^ 221 V 222 V 223 +-------------+ +------------+----------+ +---------+ 224 |Common NSLP | |QSM-specific| Resource | | Policy | 225 | Processing +<<>>>| NSLP |Mgmt. Fct.|<<>| Control | 226 | | | Processing | | | | 227 +-------------+ +------------+----------+ +---------+ 228 . ^ | * ^ 229 | V . * ^ 230 +----------+ * ^ 231 | GIMPS | * ^ 232 |Processing| * V 233 +----------+ * V 234 | | * V 235 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 236 . . * V 237 | | * ............................. 238 . . * . Traffic Control . 239 | | * . +---------+. 240 . . * . |Admission|. 241 | | * . | Control |. 242 +----------+ +------------+ . +---------+. 243 <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> 244 | Packet | | Interface | .+----------+ +---------+. 245 ===>|Processing|====| Selection |===.| Packet |====| Packet |.==> 246 | | |(Forwarding)| .|Classifier| Scheduler|. 247 +----------+ +------------+ .+----------+ +---------+. 248 ............................. 249 <.-.-> = signalling flow 250 =====> = data flow (sender --> receiver) 251 <<<>>> = control and configuration operations 252 ****** = routing table manipulation 253 Figure 1: QoS-NSLP in a Node 255 This diagram shows an example implementation scenario where QoS 256 conditioning is performed on the output interface. However, this 257 does not limit the possible implementations. For example, in some 258 cases traffic conditioning may be performed on the incoming 259 interface, or it may be split over the input and output interfaces. 261 From the perspective of a single node, the request for QoS may result 262 from a local application request, or from processing an incoming QoS- 263 NSLP message. 264 o The 'local application case' includes not only user applications 265 (e.g. multimedia applications) but also network management (e.g. 266 initiating a tunnel to handle an aggregate, or interworking with 267 some other reservation protocol - such as RSVP) and the policy 268 control module (e.g. for explicit teardown triggered by AAA). In 269 this sense, the model does not distinguish between hosts and 270 routers. 271 o The 'incoming message' case requires NSIS messages to be captured 272 during input packet processing and handled by GIMPS. Only 273 messages related to QoS are passed to the QoS-NSLP. GIMPS may 274 also generate triggers to the QoS-NSLP (e.g. indications that a 275 route change has occurred). 277 The QoS request is handled by a local 'resource management' function, 278 which coordinates the activities required to grant and configure the 279 resource. It also handles QoS Signalling Policy-specific message 280 aspects. 281 o The grant processing involves two local decision modules, 'policy 282 control' and 'admission control'. Policy control determines 283 whether the user has administrative permission to make the 284 reservation. Admission control determines whether the node has 285 sufficient available resources to supply the requested QoS. 286 o If both checks succeed, parameters are set in the packet 287 classifier and in the link layer interface (e.g., in the packet 288 scheduler) to obtain the desired QoS. Error notifications are 289 passed back to the request originator. The resource management 290 function may also manipulate the forwarding tables at this stage, 291 to select (or at least pin) a route; this must be done before 292 interface-dependent actions are carried out (including forwarding 293 outgoing messages over any new route), and is in any case 294 invisible to the operation of the protocol. 296 Policy control is expected to make use of a AAA service external to 297 the node itself. Some discussion can be found in a separate document 298 on AAA issues [I-D.tschofenig-nsis-aaa-issues] and one on 299 auhorization issues [I-D.tschofenig-nsis-qos-authz-issues]. More 300 generally, the processing of policy and resource management functions 301 may be outsourced to an external node leaving only 'stubs' co-located 302 with the NSLP; this is not visible to the protocol operation, 303 although it may have some influence on the detailed design of 304 protocol messages to allow the stub to be minimally complex. A more 305 detailed discussion on authentication and authorization can be found 306 in Section 3.1.4. The definition of the POLICY_DATA class is given 307 in Appendix A. 309 The group of user plane functions, which implement QoS for a flow 310 (admission control, packet classification, and scheduling) is 311 sometimes known as 'traffic control'. 313 Admission control, packet scheduling, and any part of policy control 314 beyond simple authentication have to be implemented using specific 315 definitions for types and levels of QoS; Our assumption is that the 316 QoS-NSLP is independent of the QoS parameters (e.g. IntServ service 317 elements). These are captured in a QoS Signalling Policy and 318 interpreted only by the resource management and associated functions, 319 and are opaque to the QoS-NSLP itself. QoS Signalling Policy is 320 discussed further in Section 3.1.3. 322 The final stage of processing for a resource request is to indicate 323 to the QoS-NSLP protocol processing that the required resources have 324 been configured. The QoS-NSLP may generate an acknowledgement 325 message in one direction, and may propagate the resource request 326 forwards in the other. Message routing is (by default) carried out 327 by GIMPS module. Note that while Figure 1 shows a unidirectional 328 data flow, the signalling messages can pass in both directions 329 through the node, depending on the particular message and orientation 330 of the reservation. 332 2. Terminology 334 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 335 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 336 document are to be interpreted as described in RFC 2119. 338 The terminology defined by GIMPS [I-D.ietf-nsis-ntlp] applies to this 339 draft. 341 In addition, the following terms are used: 342 QNE: an NSIS Entity (NE), which supports the QoS-NSLP. 343 QNI: the first node in the sequence of QNEs that issues a reservation 344 request for a session. 345 QNR: the last node in the sequence of QNEs that receives a 346 reservation request for a session. 347 Source or message source: The one of two adjacent NSLP peers that is 348 sending a signalling message (maybe the upstream or the downstream 349 peer). NB: this is not necessarily the QNI. 350 QoS NSLP operation state: state used/kept by QoS NSLP processing to 351 handle messaging aspects. 352 QoS reservation state: state used/kept by Resource Management 353 Function to describe reserved resources for a session. 355 QoS NSLP nodes 356 IP address (QoS unware NSIS nodes are IP address 357 = Flow not shown) = Flow 358 Source | | | Destination 359 Address | | | Address 360 V V V 361 +--------+ Data +------+ +------+ +------+ +--------+ 362 | Flow |-------|------|------|------|-------|------|---->| Flow | 363 | Sender | Flow | | | | | | |Receiver| 364 +--------+ | QNI | | QNE | | QNR | +--------+ 365 | | | | | | 366 +------+ +------+ +------+ 367 =====================> 368 <===================== 369 Signalling 370 Flow 372 3. Protocol Overview 374 3.1 Overall approach 376 3.1.1 GIMPS Interactions 378 The QoS NSLP uses GIMPS for delivery of all its messages. Messages 379 are normally passed from the NSLP to the GIMPS via an API, which also 380 specifies additional information, including an identifier for the 381 signalling application (e.g. 'QoS-NSLP'), the flow/session 382 identifier, and an indication of the intended direction - towards 383 data sender or receiver. On reception, GIMPS provides the same 384 information to the QoS-NSLP. In addition to the NSLP message data 385 itself, other meta-data (e.g. session identifier, flow routing 386 information) can be transferred across this interface. 388 The QoS NSLP does not provide any method of interacting with 389 firewalls or Network Address Translators (NATs). It assumes that a 390 basic NAT traversal service is provided by the GIMPS. 392 3.1.2 Protocol messages 394 The QoS NSLP uses four message types: 395 RESERVE: The RESERVE message is the only message that manipulates 396 QoS NSLP reservation state. It is used to create, refresh, modify 397 and remove such state. The RESERVE message is idempotent; the 398 resultant effect is the same whether a message is received once or 399 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 403 to 'probe' the network for path characteristics, for 404 receiver-initiated reservations or for support of certain QoS 405 models. The information obtained from a QUERY may be used in the 406 admission control process of a QNE (e.g. in case of 407 measurement-based admission control). Note that a QUERY does not 408 change existing reservation state. It does not cause QoS NSLP 409 state to be installed in nodes other than the one that generated 410 the QUERY. 412 RESPONSE: The RESPONSE message is used to provide information about 413 the result of a previous QoS-NSLP message. This includes explicit 414 confirmation of the state manipulation signaled in the RESERVE 415 message, the response to a QUERY message or an error code if the 416 QNE or QNR is unable to provide the requested information or if 417 the response is negative. The RESPONSE message is impotent, it 418 does not cause any reservation state to be installed or modified. 420 NOTIFY: NOTIFY messages are used to convey information to a QNE. 421 They differ from RESPONSE messages in that they are sent 422 asynchronously and need not refer to any particular state or 423 previously received message. The information conveyed by a NOTIFY 424 message is typically related to error conditions. Examples would 425 be notification to an upstream peer about state being torn down or 426 to indicate when a reservation has been pre-empted. 428 QoS-NSLP messages are sent peer-to-peer. This means that a QNE 429 considers its adjacent upstream or downstream peer to be the source 430 of the each message. 432 Each protocol message has a common header which indicates the message 433 type and contains flags. Message formats are defined in Section 434 5.1.2. Message processing rules are defined in Section 5.4. 436 QoS NSLP messages contain three types of objects: 437 Control Information: Control information objects carry general 438 information for the QoS NSLP processing, such as sequence numbers 439 or whether a response is required. This may include some 440 mechanisms that are useful for many QSMs (Common Control 441 Information) and some that are for a particular QSM only (QSM 442 specific Control Information). QSM specific Control Information 443 is specified together with a QSM. This specification only defines 444 Common Control Information. Currently, Common Control Information 445 is defined for session identification, message sequencing, 446 response request, message scoping and session lifetime. 448 QoS specifications (QSPECs): QSPEC objects describe the actual 449 resources that are required and are specific to the QSM being 450 used. Besides any resource description they may also contain QSM 451 specific control information used by the QSM's processing. 453 Policy objects: Policy objects contain data used to authorise the 454 reservation of resources. 456 Object formats are defined in Section 5.1.3. Object processing rules 457 are defined in Section 5.3. 459 3.1.3 QoS Signalling Models and QoS specifications 461 A QoS Signalling Model (QSM) is a mechanism which allows QNEs to 462 signal for QoS reservations in the Internet using QoS NSLP. It does 463 not define new QoS provisioning methods or architectures, which we 464 collectively denote as a "QoS model", but rather enables signalling 465 for existing ones. Integrated Services [RFC1633], Differentiated 466 Services [RFC2475] and RMD [I-D.westberg-rmd-framework] are all 467 examples of QoS architectures for which a QSM can be specified. 469 There is no restriction on the number of QSMs that can be defined. 470 QSMs may be local (private to one network), implementation/vendor 471 specific, or global (implementable by different networks and 472 vendors). The authors are currently aware of three efforts related 473 to QSM specification: IntServ Controlled Load 474 [I-D.kappler-nsis-qosmodel-controlledload], based on ITU 475 [I-D.ash-nsis-nslp-qos-sig-proof-of-concept] and Resource Management 476 for DiffServ (RMD) 477 [I-D.bader-rmd-qos-model][I-D.bader-nsis-rmd-diffserv-qsm]. 479 The specification of a QSM includes a description of its QoS 480 parameter information, as well as how that information should be 481 treated or interpreted in the network. In that sense, the QSM goes 482 beyond the QoS NSLP protocol level in that it could also describe the 483 role of QNEs in this QoS Model and a certain QSPEC. Specification of 484 a certain QSPEC may include specifying generic and optional 485 parameters (including how generic parameters not used in this QSM are 486 mapped onto parameters defined therein) and QSM-specific message 487 formats or state management. 489 The information needed to signal for a QSM is carried in QoS NSLP 490 inside a QoS specification (QSPEC) object. The QSPEC is opaque to 491 the QoS NSLP and similar in purpose to the TSpec, RSpec and AdSpec 492 specified in RFC 2205 [RFC2205] and RFC 2210 [RFC2210]. At each QNE, 493 its content is interpreted by the Resource Management Function and 494 the Policy Control Function for the purposes of policy control and 495 traffic control (including admission control and configuration of the 496 packet classifier and scheduler). 498 An ongoing effort attempts to specify a QSPEC template. The QSPEC 499 template contains object formats for generally useful elements of the 500 QoS description, which is expected to enhance interoperability. The 501 QSPEC template defines a QSM ID, QSM-specific Control Information and 502 a QoS Description. A QSM specifies which generic parameters may be 503 carried in the QSPEC, or restricts the values these parameters can 504 take. A QSM may also define additional QSM-specific parameters. 506 3.1.4 Authentication and authorization 508 The QoS signalling protocol needs to exchange information which is 509 subsequently used as input to the AAA infrastructure. The response 510 from the AAA infrastructure must also be returned and processed by 511 the respective entities. 513 +-------------+ 514 | Entity | 515 | authorizing | 516 | resource | 517 | request | 518 +-----+-------+ 519 | 520 | 521 /-\----+-----/\ 522 //// \\\\ 523 || || 524 | AAA Cloud | 525 || || 526 \\\\ //// 527 \-------+-----/ 528 | 529 +-------------+ QoS signalling +---+--+ 530 | Entity |<=================>| |<=========> 531 | requesting | Data Flow | QNE | 532 | resource |-------------------|------|----------> 533 +-------------+ +------+ 535 QoS NSLP requests allow particular user(s) to obtain preferential 536 access to network resources. To prevent abuse, some form of an 537 access control (also known as policy based admission control) will 538 generally be required on users who make reservations. Typically, 539 such authorization is expected to make use of an AAA service external 540 to the node itself. In any case, cryptographic user identification 541 and selective admission will generally be needed when a reservation 542 is requested. 544 The QoS NSLP request is handled by a local 'resource management' 545 function, which coordinates the activities required to grant and 546 configure the resource. The grant processing involves two local 547 decision modules, 'policy control' and 'admission control'. Policy 548 control determines whether the user is sufficiently authorized to 549 make the reservation. Admission control determines whether the node 550 has sufficient available resources to offer the requested QoS. 552 3.1.4.1 Policy Ignorant Nodes 554 It is generally assumed that policy enforcement is likely to 555 concentrate on border nodes between administrative domains. Figure 4 556 below illustrates a simple administrative domain with: 557 o two boundary nodes (A, C), which represent QNEs authorized by AAA 558 entities. 559 o A core node (B) represents an Policy Ignorant QNE (PIN) with 560 capabilities limited to default admission control handling. 562 Authorizing Entity 1 Authorizing Entity 2 563 | | 564 | | 565 +---+ +---+ +---+ 566 | A +---------+ B +---------+ C | 567 +---+ +---+ +---+ 568 QNE1 PIN QNE2 570 Figure 4: Administrative Domain scenario 572 Here, policy objects transmitted across the domain traverse an 573 intermediate PIN node (B) that is allowed to process QoS NSLP message 574 but does not handle policy information. 576 3.1.4.2 Policy Data 578 The input to policy control is referred to as "Policy data", which 579 QoS NSLP carries in the POLICY_DATA object. Policy data may include 580 credentials identifying entities and traits depending on the 581 authorization model in use (2-party, 3-party, token-based 3-party). 582 There are no requirements for all nodes to process this object. 583 Policy data itself is opaque to the QoS NSLP, which simply passes it 584 to policy control when required. The policy data is independent from 585 the QSM in use. 587 Policy control depends on successful user authentication and 588 authorization of a QoS NSLP reservation request. The authorization 589 decision might be valid for a certain amount of time or even for the 590 entire lifetime of the session. It is a decision of the involved 591 party to trigger a re-authorization procedure. This feature is 592 supported by the Policy Refresh Timer (PRT) option of the Policy 593 object. 595 Policy objects are carried by QoS NSLP messages and contain policy 596 information. All policy-capable nodes (at any location in the 597 network) can generate, modify, or remove policy objects, even when 598 senders or receivers do not provide, and may not even be aware of 599 policy data objects. 601 The exchange of Policy objects between policy-capable QNEs along the 602 data path, supports the generation of consistent end-to-end policies. 604 Furthermore, such policies can be successfully deployed across 605 multiple administrative domains when border nodes manipulate and 606 translate Policy objects according to established sets of bilateral 607 agreements. 609 3.2 Design decisions 611 QoS NSLP was designed according to the principles and supports the 612 functionality outlined below. 614 3.2.1 Soft-state 616 The NSIS protocol suite takes a soft-state approach to state 617 management. This means that reservation state in QNEs must be 618 periodically refreshed. The frequency with which state installation 619 is refreshed is expressed in the REFRESH_PERIOD object. This object 620 contains a value in milliseconds indicating how long the state that 621 is signalled for remains valid. Maintaining the reservation beyond 622 this lifetime can be done by sending a ("refreshing") RESERVE 623 message. 625 3.2.2 Sender-receiver initiation 627 QoS NSLP supports both sender-initiated and receiver-initiated 628 reservations. For a sender-initiated reservation, RESERVE messages 629 travel in the same direction as the dataflow that is being signalled 630 for (the QNI is at the side of the source of the dataflow). For a 631 receiver-initiated reservation, RESERVE messages travel in the 632 opposite direction (the QNI is at the side of the receiver of the 633 data flow) 635 3.2.3 Message sequencing 637 RESERVE messages affect the installed reservation state. Unlike 638 NOTIFY, QUERY and RESPONSE messages, the order in which RESERVE 639 messages are received influences the eventual reservation state that 640 will be stored at a QNE. Therefore, QoS NSLP supports detection of 641 RESERVE message re-ordering or duplication with Reservation Sequence 642 Number (RSN). 644 The RSN has local significance only, i.e. between QNEs. Attempting 645 to make an identifier that was unique in the context of a SESSION_ID 646 but the same along the complete path would be very hard. Since 647 RESERVE messages can be sent by any node on the path that maintains 648 reservation state (e.g. for path repair) we would have the difficult 649 task of attempting to keep the identifier synchronized along the 650 whole path. Since message ordering only ever matters between a pair 651 of peer QNEs, we can make the RSN unique just between a pair of 652 neighbouring stateful QNEs. By managing the sequence numbers in this 653 manner, the source of the RESERVE does not need to determine how the 654 next QNE will process the message. 656 Note that, since the RSN is unique within a SESSION_ID, it can be 657 used together with a SESSION_ID to refer to particular installed 658 state. 660 3.2.4 Explicit state installation confirmation and responses 662 A QNE may desire an explicit confirmation of its state installation 663 actions from the immediate upstream or downstream peer. This is 664 achieved by using an ACKNOWLEDGE (A) flag in the message header. 666 In addition to this, a QNE may require other information such as a 667 confirmation that the end-to-end reservation is in place or a reply 668 to a query along the path. For such requests, it must be able to 669 keep track of which request each response refers to. This is 670 supported by including a Request Identification Information (RII) 671 object in a QoS NSLP message. 673 3.2.5 Summary refreshes 675 For scalability, QoS NSLP supports an abbreviated form of refreshing 676 RESERVE message ("summary refresh"). In this case, the refreshing 677 RESERVE references the reservation using the RSN and the SESSION_ID, 678 rather than including the full reservation specification (including 679 QSPEC, ...). Summary refreshes require an explicit acknowledgment of 680 state installation to ensure that the RSN reference will be 681 understood. It is up to a QNE that receives a message containing an 682 RII to decide whether it wants to accept summary refreshes and 683 provide this explicit acknowledgment. 685 3.2.6 Message scoping 687 A QNE may use local policy when deciding whether to propagate a 688 message or not. The QoS NSLP also includes an explicit mechanism to 689 restrict message propagation by means of a scoping mechanism. 691 For a RESERVE or a QUERY message, a SCOPING flag limits the part of 692 the path on which state is installed or the downstream nodes that can 693 respond. When set to zero, it indicates that the scope is "whole 694 path" (default). When set to one, the scope is "single hop". 696 The propagation of a RESPONSE message is limited by the RII object, 697 which ensures that it is not forwarded back along the path further 698 than the node that requested the RESPONSE. 700 This specification does not support an explicit notion of a region 701 scope or "to the CRN". If needed, this can be easily proposed as an 702 extension later on,e.g. based on LRSVP [I-D.manner-lrsvp]. 704 3.2.7 Session binding 706 Session binding is defined as the enforcement of a relation between 707 different QoS NSLP sessions (i.e. signalling flows with different 708 SESSION_ID (SID) as defined in GIMPS [I-D.ietf-nsis-ntlp]). 710 Session binding indicates a (possibly asymmetric) 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 relation 713 to another session with SID_B (the bound session) by including a 714 BOUND_SESSION_ID object containing SID_B in its messages. The 715 dependency is asymmetric if the session with SID_B does not carry a 716 BOUND_SESSION_ID object containing SID_A. 718 The concept of session binding is used to indicate the dependency 719 between the end-to-end session and the aggregate session in case of 720 aggregate reservations. In case of bidirectional reservations, it is 721 used to express the dependency between the sessions used for forward 722 and reverse reservation. Note that the dependency indicated by 723 session binding is purely informative in nature and does not 724 automatically trigger any action in a QNE. However, a QNE may use 725 the information for local resource optimisation or to tear down 726 reservations that are no longer useful. 728 3.2.8 Layering 730 QoS NSLP supports layered reservations. Layered reservations may 731 occur when certain parts of the network (domains) implement one or 732 more local QoS models, or when they locally apply specific control 733 plane characteristics (e.g. GIMPS unreliable transfer mode instead 734 of reliable transfer mode). They may also occur when several 735 per-flow reservations are locally combined into an aggregate 736 reservation. 738 3.2.8.1 Local QoS models 740 A domain may have local policies regarding QSM implementation, i.e. 741 it may map incoming traffic to its own locally defined QSMs. QoS 742 NSLP supports this by allowing QSPEC objects to be stacked. 744 When a domain wants to apply a certain QSM to an incoming per-flow 745 reservation request, each edge of the domain is configured to map the 746 incoming QSPEC object to a local QSPEC object and push that object 747 onto the stack of QSPEC objects (typically immediately following the 748 Common Control Information, i.e. the first QSPEC that is found in 749 the message). QNEs inside the domain look at the top of the QSPEC 750 object stack to determine which QSM to apply for the reservation. 752 The position of the local QSPEC object in the stack implies a 753 tradeoff between the speed with which incoming messages can be 754 processed and the time it takes to construct the outgoing message (if 755 any). By mandating the locally valid object to be on top of the 756 stack we value ease of processing over ease of message construction. 758 3.2.8.2 Local control plane properties 760 The way signalling messages are handled is mainly determined by the 761 parameters that are sent over GIMPS-NSLP API and by the Common 762 Control Information. A domain may have a policy to implement local 763 control plane behaviour. It may, for instance, elect to use an 764 unreliable transport locally in the domain while still keeping 765 end-to-end reliability intact. 767 The QoS NSLP supports this situation by allowing two sessions to be 768 set up for the same reservation. The local session has the desired 769 local control plane properties and is interpreted in internal QNEs. 770 This solution poses two requirements: the end-to-end session must be 771 able to bypass intermediate nodes and the egress QNE needs to bind 772 both sessions together. 774 Intermediate node bypass is achieved with GIMPS. The local session 775 and the end-to-end session are bound at the egress QNE by means of 776 the BOUND_SESSION_ID object. 778 3.2.8.3 Aggregate reservations 780 In some cases it is desirable to create reservations for an 781 aggregate, rather than on a per-flow basis, in order to reduce the 782 amount of reservation state needed as well as the processing load for 783 signalling messages. The QoS NSLP, therefore, provides aggregation 784 facilities similar to RFC 3175 [RFC3175]. However, the aggregation 785 scenarios supported are wider than that proposed there. Note that 786 QoS NSLP does not specify how reservations need to be combined in an 787 aggregate or how end-to-end properties need to be computed but only 788 provides signalling support for it. 790 The essential difference with the layering approaches described in 791 Section 3.2.8.1 and Section 3.2.8.2 is that the aggregate reservation 792 needs a FlowID that describes all traffic carried in the aggregate 793 (e.g. a DSCP in case of IntServ over DiffServ). The need for a 794 different FlowID mandates the use of two different sessions, similar 795 to Section 3.2.8.2 and to the RSVP aggregation solution RFC 3175 796 [RFC3175]. 798 Edge QNEs of the aggregation domain that want to maintain some 799 end-to-end properties may establish a peering relation by sending the 800 end-to-end message transparantly over the domain (using the 801 intermediate node bypass capability described above). Updating the 802 end-to-end properties in this message may require some knowledge of 803 the aggregated session (e.g. for updating delay values). For this 804 purpose, the end-to-end session contains a BOUND_SESSION_ID carrying 805 the SESSION_ID of the aggregate session. 807 3.2.9 Priority 809 This specification acknowledges the fact that in some situations, 810 some messages or some reservations may be more important than others 811 and therefore foresees mechanisms to give these messages or 812 reservations priority. 814 Priority of certain signalling messages over others may be required 815 in mobile scenarios when a message loss during call set-up is less 816 harmful then during handover. This situation only occurs when GIMPS 817 or QoS NSLP processing is the congested part or scarce resource. 818 This specification requests GIMPS design to foresee a mechanism to 819 support a number of levels of message priority that can be requested 820 over the NSLP-GIMPS API. 822 Priority of certain reservations over others may be required when QoS 823 resources are oversubscribed. In that case, existing reservations 824 may be preempted in order to make room for new higher-priority 825 reservations. A typical approach to deal with priority and 826 preemption is through the specification of a setup priority and 827 holding priority for each reservation. The resource management 828 function at each QNE then keeps track of the resource consumption at 829 each priority level. Reservations are established when resources, at 830 their setup priority level, are still available. They may cause 831 preemption of reservations with a lower holding priority than their 832 setup priority. 834 Support of reservation priority is a QSM specific issue and therefore 835 outside the scope of this specification. 837 3.2.10 Rerouting (SII) 839 QoS NSLP needs to adapt to route changes in the data path. This 840 assumes the capability to detect rerouting events, perform QoS 841 reservation on the new path and optionally tear down reservations on 842 the old path. 844 Rerouting detection can be performed at three levels. First, routing 845 modules may detect route changes through their interaction with 846 routing protocols. Certain QNEs or GIMPS implementations may 847 interact with local routing module to receive quick notification of 848 route changes. This is largely implementation-specific and outside 849 of the scope of NSIS. Second, route changes may be detected at GIMPS 850 layer. This specification requests GIMPS design to foresee 851 notification of this information over the API. This is outside the 852 scope of the QoS NSLP specification. Third, rerouting may be 853 detected at the NSLP layer. A QoS NSLP node is able to detect 854 changes in its QoS NSLP peers by keeping track of a Source 855 Identification Information (SII) object that is similar in nature to 856 the RSVP_HOP object described in RFC 2205 [RFC2205]. When a RESERVE 857 message with an existing SESSION_ID and a different SII is received, 858 the QNE knows its upstream peer has changed. 860 Reservation on the new path happens when a refreshing RESERVE message 861 arrives at the QNE where the old and the new path diverge. The 862 refreshing RESERVE will be interpreted as a new RESERVE on the new 863 path. Depending on the transfer mode, this may require installation 864 of a new messaging association. Rapid recovery at the NSLP layer 865 therefore requires short refresh periods. Detection before the next 866 RESERVE message arrives is only possible at the IP layer or through 867 monitoring of GIMPS peering relations (e.g. by TTL counting the 868 number of GIMPS hops between NSLP peers or the observing changes in 869 the outgoing interface towards GIMPS peer). These mechanisms can 870 provide implementation specific optimisations, and are outside the 871 scope of this specification. 873 When the QoS NSLP is aware of the route change, it needs to set up 874 the reservation on the new path. This is done by incrementing the 875 RSN and then sending a new RESERVE message. On links that are common 876 to the old and the new path, this RESERVE message is interpreted as a 877 refreshing RESERVE. On new links, it creates the reservation. 879 After the reservation on the new path is set up, the branching node 880 or the merging node may want to tear down the reservation on the old 881 path (faster than what would result from normal soft-state time-out). 882 This functionality is supported by keeping track of the old SII. 883 This specification requests GIMPS design to provide support for an 884 SII that is interpreted as a random identifier at the QoS NSLP but 885 that allows, when passed over the API, to forward QoS NSLP messages 886 to the QNE identified by that SII. 888 A QNI or a branch node may wish to keep the reservation on the old 889 branch. This could for instance be the case when a mobile node has 890 experienced a mobility event and wishes to keep reservation to its 891 old attachment point in case it moves back there. For this purpose, 892 a REPLACE flag is foreseen in the common header, which, when set to 893 FALSE, indicates that the reservation on the old branch should be 894 kept. 896 4. Examples of QoS NSLP Operation 898 The QoS NSLP can be used in a number of ways. The examples given 899 here give an indication of some of the basic processing. However, 900 they are not exhaustive and do not attempt to cover the details of 901 the protocol processing. 903 4.1 Basic sender-initiated reservation 905 QNI QNE QNE QNR 906 | | | | 907 | RESERVE | | | 908 +--------->| | | 909 | | RESERVE | | 910 | +--------->| | 911 | | | RESERVE | 912 | | +--------->| 913 | | | | 914 | | | RESPONSE | 915 | | |<---------+ 916 | | RESPONSE | | 917 | |<---------+ | 918 | RESPONSE | | | 919 |<---------+ | | 920 | | | | 921 | | | | 923 Figure 5: Basic Sender Initiated Reservation 925 To make a new reservation, the QNI constructs a RESERVE message 926 containing a QSPEC object, from its chosen QSM, which describes the 927 required QoS parameters. 929 The RESERVE message is passed to GIMPS which transports it to the 930 next QNE. There it is delivered to the QoS NSLP processing which 931 examines the message. Policy control and admission control decisions 932 are made. The exact processing also takes into account the QSM being 933 used. The node performs appropriate actions (e.g. installing 934 reservation) based on the QSPEC object in the message. 936 The QoS NSLP then generates a new RESERVE message (usually based on 937 the one received). This is passed to GIMPS, which forwards it to the 938 next QNE. 940 The same processing is performed at further QNEs along the path, up 941 to the QNR. The determination that a node is the QNR may be made 942 directly (e.g. that node is the destination for the data flow), or 943 using some GIMPS functionality to determine that there are no more 944 QNEs between this node and the data flow destination. 946 A node can ask a confirmation of the installed state from its 947 immediate peer. It does so by setting the A flag, which causes a 948 RESPONSE message to be sent by the immediate peer. One use of this 949 is to confirm the installation of state, which allows the use of 950 summary refreshes that later refer to that state. A RESPONSE message 951 can also indicate an error when, for example, a reservation has 952 failed to be installed. 954 Any node may include a request for a RESPONSE in its RESERVE 955 messages. It does so by including a Request Identification 956 Information (RII) object in the RESERVE message. The RESPONSE is 957 forwarded peer-to-peer along the reverse of the path that the RESERVE 958 message took (using GIMPS path state), and so is seen by all the QNEs 959 on the reverse-path. It is only forwarded as far as the node which 960 requested the RESPONSE. 962 The reservation can subsequently be refreshed by sending further 963 RESERVE messages containing the complete reservation information, as 964 for the initial reservation. The reservation can also be modified in 965 the same way, by changing the QSM-specific data to indicate a 966 different set of resources to reserve. 968 The overhead required to perform refreshes can be reduced, in a 969 similar way to that proposed for RSVP in RFC 2961 [RFC2961]. Once a 970 RESPONSE message has been received indicating the successful 971 installation of a reservation, subsequent refreshing RESERVE messages 972 can simply refer to the existing reservation, rather than including 973 the complete reservation specification. 975 4.2 Sending a Query 977 QUERY messages can be used to gather information from QNEs along to 978 path. For example, it can be used to find out what resources are 979 available before a reservation is made. 981 In order to perform a query along a path, the QNE constructs a QUERY 982 message. This message includes QSM-specific objects containing the 983 actual query to be performed at QNEs along the path. It also 984 contains an object used to match the response back to the query, and 985 an indicator of the query scope (next node, whole path). 987 The QUERY message is passed to GIMPS to forward it along the path. 989 A QNE (including the QNR) receiving a QUERY message should inspect it 990 and create a new message, based on that received with the query 991 objects modified as required. For example, the query may request 992 information on whether a flow can be admitted, and so a node 993 processing the query might record the available bandwidth. The new 994 message is then passed to GIMPS for further forwarding (unless it 995 knows it is the QNR, or is the limit for the scope in the QUERY). 997 At the QNR, a RESPONSE message must be generated if the QUERY message 998 includes a Request Identification Information (RII) object. Into 999 this is copied various objects from the received QUERY message. It 1000 is then passed to GIMPS to be forwarded peer-to-peer back along the 1001 path. 1003 Each QNE receiving the RESPONSE message should inspect the RII object 1004 to see if it 'belongs' to it (i.e. it was the one that originally 1005 created it). If it does not then it simply passes the message back 1006 to GIMPS to be forwarded back down the path. 1008 4.3 Basic receiver-initiated reservation 1010 As described in the NSIS framework [I-D.ietf-nsis-fw] in some 1011 signalling applications, a node at one end of the data flow takes 1012 responsibility for requesting special treatment - such as a resource 1013 reservation - from the network. Both ends then agree whether sender 1014 or receiver-initiated reservation is to be done. In case of a 1015 receiver initiated reservation, both ends agree whether a "One Pass 1016 With Advertising" (OPWA) [_XREF_OPWA95] model is being used. This 1017 negotiation can be accomplished using mechanisms that are outside the 1018 scope of NSIS, see Section 9.2. 1020 To make a receiver-initiated reservation, the QNI constructs a QUERY 1021 message, which may contain a QSPEC object from its chosen QSM (see 1022 Figure 6). This QUERY message does not need to trigger a RESPONSE 1023 message and therefore, the QNI must not include the RII object 1024 (Section 5.4.2), into the QUERY message. The QUERY message may be 1025 used to gather information along the path, which is carried by the 1026 QSPEC object. An example of such information is the "One Pass With 1027 Advertising" (OPWA) [_XREF_OPWA95]. This QUERY message causes GIMPS 1028 reverse-path state to be installed. 1030 QNR QNE QNE QNI 1031 sender receiver 1032 | | | | 1033 | QUERY | | | 1034 +--------->| | | 1035 | | QUERY | | 1036 | +--------->| | 1037 | | | QUERY | 1038 | | +--------->| 1039 | | | | 1040 | | | RESERVE | 1041 | | |<---------+ 1042 | | RESERVE | | 1043 | |<---------+ | 1044 | RESERVE | | | 1045 |<---------+ | | 1046 | | | | 1047 | RESPONSE | | | 1048 +--------->| | | 1049 | | RESPONSE | | 1050 | +--------->| | 1051 | | | RESPONSE | 1052 | | +--------->| 1053 | | | | 1055 Figure 6: Basic Receiver Initiated Reservation 1057 The QUERY message is transported by GIMPS to the next downstream QoS 1058 NSLP node. There it is delivered to the QoS NSLP processing which 1059 examines the message. The exact processing also takes into account 1060 the QSM being used and may include gathering information on path 1061 characteristics that may be used to predict the end-to-end QoS. 1063 The QoS NSLP then generates a new QUERY message (usually based on the 1064 one received). This is passed to GIMPS, which forwards it to the 1065 next QNE. The same processing is performed at further QNEs along the 1066 path, up to the receiver, which in this situation is the QNR. The 1067 QNR detects that this QUERY message does not carry an RII object and 1068 by using the information contained in the received QUERY message, 1069 such as the QSPEC, constructs a RESERVE message. 1071 The RESERVE is forwarded peer-to-peer along the reverse of the path 1072 that the QUERY message took (using GIMPS reverse path state). 1073 Similar to the sender-initiated approach, any node may include an RII 1074 in its RESERVE messages. 1076 The reservation can subsequently be refreshed in the same way as for 1077 the sender-initiated approach. This RESERVE message may be also used 1078 to refresh GIMPS reverse path state. Alternatively, refreshing GIMPS 1079 reverse path state could be performed by sending periodic QUERY 1080 messages, which are needed in case of route changes anyway. 1082 4.4 Bidirectional Reservations 1084 Bidirectional reservations are supported by binding two 1085 uni-directional sessions together. We distinguish two cases: 1086 o Binding two sender-initiated reservations, e.g. one 1087 sender-initiated reservation from QNE A to QNE B and another one 1088 from QNE B to QNE A. 1089 o Binding a sender-intiated and a receiver-initiated reservation, 1090 e.g. a sender-initiated reservation from QNE A towards QNE B, and 1091 a receiver-initiated reservation from QNE A towards QNE B for the 1092 data flow in the opposite direction (from QNE B to QNE A). This 1093 case is particularly useful when one end of the communication has 1094 all required information to set up both sessions. 1096 Both ends have to agree on which bi-directional reservation type they 1097 need to use. This negotiation/agreement can be accomplished using 1098 mechanisms that are outside the scope of NSIS, see Section 9.2. 1100 The scenario with two sender-initiated reservation is shown on Figure 1101 7. Note that RESERVE messages for both directions may visit 1102 different QNEs along the path because of asymmetric routing. Both 1103 directions of the flows are bound by inserting the BOUND_SESSION_ID 1104 object at the QNI and QNR. RESPONSE messages are optional and not 1105 shown on the picture for simplicity. 1107 A QNE QNE B 1108 | | FLOW-1 | | 1109 |===============================>| 1110 |RESERVE-1 | | | 1111 QNI+--------->|RESERVE-1 | | 1112 | +-------------------->|QNR 1113 | | | | 1114 | | FLOW-2 | | 1115 |<===============================| 1116 | | |RESERVE-2 | 1117 | RESERVE-2 |<---------+QNI 1118 QNR|<--------------------+ | 1119 | | | | 1121 Figure 7: Bi-directional reservation for sender+sender scenario 1123 The scenario with a sender-initiated and a receiver-initiated 1124 reservation is shown on Figure 8. In this case, QNI B sends out two 1125 RESERVE messages, one for the sender-initiated and one for the 1126 receiver-initiated reservation. 1128 A QNE QNE B 1129 | | FLOW-1 | | 1130 |===============================>| 1131 | QUERY-1 | | | 1132 QNI+--------->| QUERY-1 | | 1133 | +-------------------->|QNR 1134 | | | | 1135 |RESERVE-1 | | | 1136 QNI+<---------|RESERVE-1 | | 1137 | +<--------------------|QNR 1138 | | | | 1139 | | FLOW-2 | | 1140 |<===============================| 1141 | | |RESERVE-2 | 1142 |RESERVE-2 | |<---------+QNI 1143 QNR|<--------------------+ | 1144 | | | | 1146 Figure 8: Bi-directional reservation for sender+receiver scenario 1148 4.5 Use of Local QoS Models 1150 In some cases it may be required to use a different QSM along a 1151 particular segment of the signalling. In this case a node at the 1152 edge of this region needs to map between the two resource 1153 descriptions (and any auxiliary data). 1155 +-------- QSM2 domain --------+ 1156 | | 1157 | | 1158 +----+ +----+ +----+ +----+ +----+ 1159 |QNI | |edge| |int.| |edge| |QNR | 1160 | |========>|QNE |========>|QNE |========>|QNE |========>| | 1161 +----+ RESERVE +----+ RESERVE +----+ RESERVE +----+ RESERVE +----+ 1162 QSPEC1 | QSPEC2 QSPEC2 | QSPEC1 1163 | {QSPEC1} {QSPEC1} | 1164 | | 1165 +-----------------------------+ 1167 Figure 9: Reservation with local QoS Models 1169 This initially proceeds as for the basic example, with peer-to-peer 1170 installation of reservations. However, within a region of the 1171 network a different QSM (QSM2) needs to be used. At the edge of this 1172 region the QNEs support both the end-to-end and local QoS models. 1173 When the RESERVE message reaches the QNE at the ingress, the initial 1174 processing of the RESERVE proceeds as normal. However, the QNE also 1175 determines the appropriate description using QSM2. The RESERVE 1176 message to be sent out is constructed mostly as usual but with a 1177 second QSPEC object added on top, which becomes the 'current' one. 1179 When this RESERVE message is received at an node internal to the QSM2 1180 domain the QoS NSLP only uses the QSPEC at the top of the stack (i.e. 1181 the 'current' one), rather than the end-to-end QSPEC. Otherwise, 1182 processing proceeds as usual. The RESERVE message that it generates 1183 should include the complete stack of QSPECs from the message it 1184 received. 1186 At the QNE at the egress of the region the local QSPEC is removed 1187 from the message so that subsequent QNEs receive only the end-to-end 1188 QSPEC. 1190 QSPECs can be stacked in this way to an arbitrary depth. 1192 4.6 Aggregate Reservations 1194 In order to reduce signalling and per-flow state in the network, the 1195 reservations for a number of flows may be aggregated together. 1197 QNI QNE QNE/QNI' QNE' QNR'/QNE QNR 1198 aggregator deaggregator 1199 | | | | | | 1200 | RESERVE | | | | | 1201 +--------->| | | | | 1202 | | RESERVE | | | | 1203 | +--------->| | | | 1204 | | | RESERVE | | | 1205 | | +-------------------->| | 1206 | | | RESERVE' | | | 1207 | | +=========>| RESERVE' | | 1208 | | | +=========>| RESERVE | 1209 | | | | +--------->| 1210 | | | | RESPONSE'| | 1211 | | | RESPONSE'|<=========+ | 1212 | | |<=========+ | | 1213 | | | | | RESPONSE | 1214 | | | | RESPONSE |<---------+ 1215 | | |<--------------------+ | 1216 | | RESPONSE | | | | 1217 | |<---------+ | | | 1218 | RESPONSE | | | | | 1219 |<---------+ | | | | 1220 | | | | | | 1221 | | | | | | 1223 Figure 10: Sender Initiated Reservation with Aggregation 1225 An end-to-end per-flow reservation is initiated as normal (with 1226 messages shown in Figure 10 as "RESERVE"). 1228 At the aggregator a reservation for the aggregated flow is initiated 1229 (shown in Figure 10 as "RESERVE'"). This may use the same QSM as the 1230 end-to-end reservation but has a flow identifier for the aggregated 1231 flow (e.g. tunnel) instead of for the individual flows. This 1232 document does not specify how the QSPEC of the aggregate session can 1233 be derived from the QSPECs of the end-to-end sessions. 1235 Markings are used so that intermediate routers do not need to inspect 1236 the individual flow reservations. The deaggregator then becomes the 1237 next hop QNE for the end-to-end per-flow reservation. 1239 Aggregator Deaggregator 1241 +---+ +---+ +---+ +---+ 1242 |QNI|-----|QNE|-----|QNE|-----|QNR| aggregate 1243 +---+ +---+ +---+ +---+ reservation 1245 +---+ +---+ ..... ..... +---+ +---+ 1246 |QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end 1247 +---+ +---+ ..... ..... +---+ +---+ reservation 1249 The deaggregator acts as the QNR for the aggregate reservation. 1251 Information is carried in the reservations to enable the deaggregator 1252 to associate the end-to-end and aggregate reservations with one 1253 another. 1255 The key difference between this example, and previous ones is that 1256 the flow identifier for the aggregate is expected to be different to 1257 that for the end-to-end reservation. The aggregate reservation can 1258 be updated independently of the per-flow end-to-end reservations. 1260 4.7 Reduced State or Stateless Interior Nodes 1262 This example uses a different QSM within a domain, in conjunction 1263 with GIMPS and NSLP functionality which allows the interior nodes to 1264 avoid storing GIMPS and QoS NSLP state. As a result the interior 1265 nodes only store the QSM-specific reservation state, or even no state 1266 at all. This allows the QSM to use a form of "reduced-state" 1267 operation, where reservation states with a coarser granularity (e.g. 1268 per-class) are used, or a "stateless" operation where no QoS NSLP 1269 state is needed (or created). 1271 The key difference between this example and the use of different QSMs 1272 in Section 4.5 is that the transport characteristics for the 'local' 1273 reservation can be different from that of the end-to-end reservation, 1274 i.e. GIMPS can be used in a different way for the edge-to-edge and 1275 hop-by-hop sessions. The reduced state reservation can be updated 1276 independently of the per-flow end-to-end reservations. 1278 QNE QNE QNE QNE 1279 ingress interior interior egress 1280 GIMPS stateful GIMPS stateless GIMPS stateless GIMPS stateful 1281 | | | | 1282 RESERVE | | | | 1283 -------->| RESERVE | | | 1284 +--------------------------------------------->| 1285 | RESERVE' | | | 1286 +-------------->| | | 1287 | | RESERVE' | | 1288 | +-------------->| | 1289 | | | RESERVE' | 1290 | | +------------->| 1291 | | | | RESERVE 1292 | | | +--------> 1293 | | | | RESPONSE 1294 | | | |<-------- 1295 | | | RESPONSE | 1296 |<---------------------------------------------+ 1297 RESPONSE| | | | 1298 <--------| | | | 1300 Figure 12: Sender-initiated reservation with Reduced State Interior 1301 Nodes 1303 The QNI performs the same processing as before to generate the 1304 initial RESERVE message, and it is forwarded by GIMPS as usual. At 1305 the QNEs at the edges of the stateless or reduced-state region the 1306 processing is different and the nodes support two QoS models. 1308 At the ingress the original RESERVE message is forwarded but ignored 1309 by the stateless or reduced-state nodes. The egress node is the next 1310 QoS NSLP hop for that session. After the initial discovery phase 1311 using unreliable GIMPS transfer mode, reliable GIMPS transfer mode 1312 between the ingress and egress can be used. At the egress node the 1313 RESERVE message is then forwarded normally. 1315 At the ingress a second RESERVE' message is also built. This makes 1316 use of a QSM suitable for a reduced state or stateless form of 1317 operation (such as the RMD per hop reservation). Since the original 1318 RESERVE and the RESERVE' messages are addressed identically, RESERVE' 1319 visits the same nodes that were visited, including the egress QNE. 1321 When processed by interior (stateless) nodes the QoS NSLP processing 1322 excercises its options to not keep state wherever possible, so that 1323 no per flow QoS NSLP state is stored. Some state, e.g. per class, 1324 for the QSM related data may be held at these interior nodes. The 1325 QoS NSLP also requests that GIMPS use different transport 1326 characteristics (i.e. sending of messages in unreliable GIMPS 1327 transfer mode). It also requests the local GIMPS processing not to 1328 retain messaging association state or reverse message routing state. 1330 Nodes, such as those in the interior of the stateless or 1331 reduced-state domain, that do not retain reservation state cannot 1332 send back RESPONSE messages (and so cannot use summary refreshes). 1334 At the egress node the RESERVE' message is interpreted in conjunction 1335 with the reservation state from the end-to-end RESERVE message (using 1336 information carried in the message to correlate the signalling 1337 flows). The RESERVE message is only forwarded further if the 1338 processing of the RESERVE' message was successful at all nodes in the 1339 local domain, otherwise the end-to-end reservation is regarded as 1340 having failed to be installed. 1342 Since GIMPS neighbour relations are not maintained in the 1343 reduced-state region, only sender initiated signalling can be 1344 supported. If a receiver-initiated reservation over a stateless or 1345 reduced state domain is required this can be implemented as shown 1346 below. 1348 QNE QNE QNE 1349 ingress interior egress 1350 GIMPS stateful GIMPS stateless GIMPS stateful 1351 | | | 1352 QUERY | | | 1353 -------->| QUERY | | 1354 +------------------------------>| 1355 | | | QUERY 1356 | | +--------> 1357 | | | RESERVE 1358 | | |<-------- 1359 | | RESERVE | 1360 |<------------------------------+ 1361 | RESERVE | RESERVE | 1362 |-------------->|-------------->| 1363 RESERVE | | | 1364 <--------| | | 1366 Figure 13: Receiver-initiated reservation with Reduced State Interior 1367 Nodes 1369 The RESERVE message that is received by the egress QNE of the 1370 stateless domain is sent transparantly to the ingress QNE (known as 1371 the source of the QUERY message). When the RESERVE message reaches 1372 the ingress, the ingress QNE knows it needs to send both a 1373 sender-initiated RESERVE over the stateless domain and send a RESERVE 1374 message further upstream. 1376 4.8 Re-routing scenario 1378 The QoS NSLP needs to adapt to route changes in the data path. This 1379 assumes the capability to detect rerouting events, perform QoS 1380 reservation on the new path and optionally tear down reservations on 1381 the old path. 1383 When the QoS NSLP is aware of the route change, it needs to set up 1384 the reservation on the new path. This is done by incrementing the 1385 RSN and sending a RESERVE message. On links that are common to the 1386 old and the new path, this RESERVE message is interpreted as a 1387 refreshing RESERVE. On new links, it creates the reservation. 1389 After the reservation on the new path is set up, the branching node 1390 or the merging node may want to tear down the reservation on the old 1391 path (faster than what would result from normal soft-state time-out). 1392 This functionality is supported by keeping track of the old SII. 1393 This specification requests GIMPS design to provide support for an 1394 SII. The SII is opaque to the QoS NSLP, i.e. QoS NSLP does not make 1395 any assumptions on how this identifier is constructed. When passed 1396 over the API, it allows QoS NSLP to indicate that its messages should 1397 be sent to the QNE identified by that SII. 1399 In case of a receiver-initiated reservation, a QNE can detect a route 1400 change by receiving a RESERVE message with a different SII. In case 1401 of a sender-initiated reservation, the same information is learned 1402 from a RESPONSE message, or from a NOTIFY message sent by the 1403 downstream peer. A QNE that has detected the route change via the 1404 SII change sends a RESERVE message towards the QNR on the old path 1405 (using the old SII) with the TEAR flag set. Note that in case of 1406 receiver-initiated reservations, this involves A QNE that is notified 1407 of the route change in another way and wants to tear down the old 1408 branch needs to send the RESERVE on the new path with an RII object. 1409 When it receives the RESPONSE message back, it can check whether its 1410 peer has effectively changed and send a RESERVE with the TEAR flag 1411 set if it has. Otherwise, teardown is not needed. A QNE that is 1412 unable to support an RII or does not receive a RESPONSE needs to rely 1413 on soft-state timeout on the old branch. 1415 A QNI or a branch node may wish to keep the reservation on the old 1416 branch. This could for instance be the case when a mobile node has 1417 experienced a mobility event and wishes to keep reservation to its 1418 old attachment point in case it moves back there. In that case, it 1419 sets the REPLACE flag in the common header to zero. 1421 4.9 Authorization Model Examples 1423 Various authorization models can be used in conjunction with the QoS 1424 NSLP. 1426 4.9.1 Authorization for the two party approach 1428 The two party approach is conceptually the simplest authorization 1429 model. 1431 +-------------+ QoS request +--------------+ 1432 | Entity |----------------->| Entity | 1433 | requesting | | authorizing | 1434 | resource |granted / rejected| resource | 1435 | |<-----------------| request | 1436 +-------------+ +--------------+ 1437 ^ ^ 1438 +...........................+ 1439 financial establishment 1441 Figure 14: Two party approach 1443 In this example the authorization decision only involves the two 1444 entities, or makes use of previous authorisation using an out-of-band 1445 mechanism to avoid the need for active participation of an external 1446 entity during the NSIS protocol execution. 1448 This type of model may be applicable, for example, between two 1449 neighbouring networks (inter-domain signalling) where a long-term 1450 contract (or other out-of-band mechanisms) exists to manage charging 1451 and provides sufficient information to authorize individual requests. 1453 4.9.2 Token based three party approach 1455 An alternative approach makes use of authorization tokens, such as 1456 those described in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used 1457 as part of the Open Settlement Protocol [OSP]. The former 1458 ('authorization tokens') are used to associate two different 1459 signalling protocols (i.e. SIP and NSIS) and their authorization 1460 with each other whereas the latter is a form of digital money. As an 1461 example, with the authorization token mechanism, some form of 1462 authorization is provided by the SIP proxy, which acts as the 1463 resource authorizing entity in Figure 15. If the request is 1464 authorized, then the SIP signalling returns an authorization token 1465 which can be included in the QoS signalling protocol messages to 1466 refer to the previous authorization decision. The tokens themselves 1467 may take a number of different forms, some of which may require the 1468 entity performing the QoS reservation to query external state. 1470 Authorization 1471 Token Request +--------------+ 1472 +-------------->| Entity C | financial settlement 1473 | | authorizing | <..................+ 1474 | | resource | . 1475 | +------+ request | . 1476 | | +--------------+ . 1477 | | . 1478 | |Authorization . 1479 | |Token . 1480 | | . 1481 | | . 1482 | | . 1483 | | QoS request . 1484 +-------------+ + Authz. Token +--------------+ . 1485 | Entity |----------------->| Entity B | . 1486 | requesting | | performing | . 1487 | resource |granted / rejected| QoS | <..+ 1488 | A |<-----------------| reservation | 1489 +-------------+ +--------------+ 1491 Figure 15: Token based three party approach 1493 For the digital money type of systems (e.g. OSP tokens), the token 1494 represents a limited amount of credit. So, new tokens must be sent 1495 with later refresh messages once the credit is exhausted. 1497 4.9.3 Generic three party approach 1499 Another method is for the node performing the QoS reservation to 1500 delegate the authorization decision to a third party, as illustrated 1501 in Figure 16. 1503 +--------------+ 1504 | Entity C | 1505 | authorizing | 1506 | resource | 1507 | request | 1508 +-----------+--+ 1509 ^ | 1510 | | 1511 QoS | | QoS 1512 authz| |authz 1513 req.| | res. 1514 | | 1515 QoS | v 1516 +-------------+ request +--+-----------+ 1517 | Entity |----------------->| Entity B | 1518 | requesting | | performing | 1519 | resource |granted / rejected| QoS | 1520 | A |<-----------------| reservation | 1521 +-------------+ +--------------+ 1523 Figure 16: Three party approach 1525 Authorization may be performed on a per-request basis, periodically, 1526 or on a per-session basis. The authorization request might make use 1527 of EAP authentication between entities A and C, and a subsequent 1528 protocol exchange between A and B to create a secure channel for 1529 further communications. Such a technique gives flexibility in terms 1530 of the authentication and key exchange protocols used. 1532 A further extension to this model is to allow Entity C to reference a 1533 AAA server in the user's home network when making the authorization 1534 decision. 1536 5. QoS NSLP Functional specification 1538 5.1 QoS NSLP Message and Object Formats 1540 A QoS NSLP message consists of a common header, followed by a body 1541 consisting of a variable number of variable-length, typed "objects". 1542 The common header and other objects are encapsulated together in a 1543 GIMPS NSLP-Data object. The following subsections define the formats 1544 of the common header and each of the QoS NSLP message types. In the 1545 message formats, the common header is denoted as COMMON_HEADER. 1547 For each QoS NSLP message type, there is a set of rules for the 1548 permissible choice of object types. These rules are specified using 1549 the Augmented Backus-Naur Form (BNF) specified in RFC 2234 [RFC2234]. 1550 The BNF implies an order for the objects in a message. However, in 1551 many (but not all) cases, object order makes no logical difference. 1552 An implementation should create messages with the objects in the 1553 order shown here, but accept the objects in any permissible order. 1555 5.1.1 Common header 1557 All GIMPS NSLP-Data objects for the QoS NSLP MUST contain this common 1558 header as the first 32 bits of the object. 1560 0 1 2 3 1561 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 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | Message Type | Flags | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 The fields in the common header are as follows: 1568 Msg Type: 16 bits 1569 1 = RESERVE 1570 2 = QUERY 1571 3 = RESPONSE 1572 4 = NOTIFY 1574 Flags: 16 bits 1575 The set of appropriate flags depends on the particular message 1576 being processed. Any bit not defined as a flag for a 1577 particular message MUST be set to zero on sending and MUST be 1578 ignored on receiving. 1580 5.1.2 Message formats 1582 5.1.2.1 RESERVE 1584 The format of a RESERVE message is as follows: 1586 RESERVE = COMMON_HEADER 1587 RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] 1588 [ POLICY_DATA ] [ *QSPEC ] 1590 The RSN is the only mandatory object and MUST always be present. 1592 If any QSPEC objects are present, they MUST occur at the end of the 1593 message. There are no other requirements on transmission order, 1594 although the above order is recommended. 1596 Four flags are defined for use in the common header with the RESERVE 1597 message. These are: 1599 TEAR (T) - when set, indicates that reservation state and QoS NSLP 1600 operation state should be torn down. This is indicated to the 1601 RMF. 1603 SCOPING (S) - when set, indicates that the message is scoped and 1604 should not travel down the entire path but only as far as the next 1605 QNE (scope="next hop"). By default, this flag is not set (default 1606 scope="whole path"). 1608 ACKNOWLEDGE (A) - when set, indicates that an explicit 1609 confirmation of the state installation action is REQUIRED. This 1610 flag SHOULD be set on transmission by default. 1612 REPLACE (R) - when set, indicates that a RESERVE with different 1613 Flow Routing Information (FRI) replaces an existing one, so the 1614 old one MAY be torn down immediately. This is the default 1615 situation. This flag may be unset to indicate a desire from an 1616 upstream node to keep an existing reservation on an old branch in 1617 place. 1619 If the REFRESH_PERIOD is not present, a default value of 30 seconds 1620 is assumed. 1622 If the session of this message is bound to another session, then the 1623 RESERVE message MUST include the SESSION_ID of that other session in 1624 a BOUND_SESSION_ID object. 1626 5.1.2.2 QUERY 1628 The format of a QUERY message is as follows: 1630 QUERY = COMMON_HEADER 1631 [ RII ][ BOUND_SESSION_ID ] 1632 [ POLICY_DATA ] [ *QSPEC ] 1634 A QUERY message MUST contain an RII object to match an incoming 1635 RESPONSE to the QUERY, unless the QUERY is being used to initiate 1636 reverse-path state for a receiver-initiated reservation. 1638 A QUERY message MAY contain one or more QSPEC objects and a 1639 POLICY_DATA object. The QSPEC object describes what is being queried 1640 for and may contain objects that gather information along the data 1641 path. The POLICY_DATA object authorizes the requestor of the QUERY 1642 message. If any QSPEC objects are present, they MUST occur at the 1643 end of the message. There are no other requirements on transmission 1644 order, although the above order is recommended. 1646 One flag is defined for use in the common header with the QUERY 1647 message. This is: 1649 SCOPING - when set, indicates that the message is scoped an should 1650 not travel down the entire path but only as far as the next QNE 1651 (scope="next hop"). By default, this flag is not set (default 1652 scope="whole path"). 1654 If the session of this message is bound to another session, then the 1655 RESERVE message MUST include the SESSION_ID of that other session in 1656 a BOUND_SESSION_ID object. 1658 5.1.2.3 RESPONSE 1660 The format of a RESPONSE message is as follows: 1662 RESPONSE = COMMON_HEADER 1663 [ RII / RSN ] ERROR_SPEC 1664 [ *QSPEC ] 1666 A RESPONSE message MUST contain an ERROR_SPEC object which indicates 1667 the success of a reservation installation or an error condition. 1668 Depending on the value of the ERROR_SPEC, the RESPONSE MAY also 1669 contain a QSPEC object. 1671 If any QSPEC objects are present, they MUST occur at the end of the 1672 message. There are no other requirements on transmission order, 1673 although the above order is recommended. 1675 One flag is defined for use in the common header with the RESPONSE 1676 message. This is: 1678 SCOPING - when set, indicates that the message is scoped and 1679 should not travel down the entire path but only as far as the next 1680 QNE (scope="next hop"). By default, this flag is not set (default 1681 scope="whole path"). 1683 5.1.2.4 NOTIFY 1685 The format of a NOTIFY message is as follows: 1687 NOTIFY = COMMON_HEADER 1688 ERROR_SPEC [ QSPEC ] 1690 A NOTIFY message MUST contain an ERROR_SPEC object indicating the 1691 reason for the notification. Depending on the ERROR_SPEC value, it 1692 MAY contain a QSPEC providing additional information. 1694 No flags are defined for use with the NOTIFY message. 1696 5.1.3 Object Formats 1698 The QoS NSLP uses the Type-Length-Value (TLV) object format defined 1699 by GIMPS [I-D.ietf-nsis-ntlp]. Every object consists of one or more 1700 32-bit words with a one-word header. For convenience the standard 1701 object header is shown here: 1703 0 1 2 3 1704 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 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 |r|r|r|r| Type |r|r|r|r| Length | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 The value for the Type field comes from GIMPS object type space. The 1710 Length field is given in units of 32 bit words and and measures the 1711 length of the Value component of the TLV object (i.e. it does not 1712 include the standard header). 1714 The object diagrams here use '//' to indicate a variable sized field 1715 and ':' to indicate a field that is optionally present. 1717 A QoS NSLP implementation must recognize objects of the following 1718 types: RII, RSN, REFRESH_PERIOD, BOUND_SESSION_ID, ERROR_SPEC, QSPEC 1719 and POLICY_DATA. 1721 NB: This draft does not currently include the codepoints for the QoS 1722 NSLP related object types. To aid those writing experimental early 1723 implementations a temporary set of NSIS-related numbers are given at 1724 . 1726 The object header is followed by the Value field, which varies for 1727 different objects. The format of the Value field for currently 1728 defined objects is specified below. 1730 5.1.3.1 Request Identification Information (RII) 1732 Type: RII 1733 Length: Fixed - 1 32-bit word 1734 Value: An identifier which must be (probabilistically) unique within 1735 the context of a SESSION_ID, and SHOULD be different every time a 1736 RESPONSE is desired. Used by a QNE to match back a RESPONSE to a 1737 request in a RESERVE or QUERY message. 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | Response Identification Information (RII) | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 5.1.3.2 Reservation Sequence Number (RSN) 1745 Type: RSN 1746 Length: Fixed - 1 32-bit word 1747 Value: An incrementing sequence number that indicates the order in 1748 which state modifying actions are performed by a QNE. The RSN has 1749 local significance only, i.e. between a pair of neighbouring 1750 stateful QNEs. 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Reservation Sequence Number (RSN) | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 5.1.3.3 REFRESH_PERIOD 1758 Type: REFRESH_PERIOD 1759 Length: Fixed - 1 32-bit word 1760 Value: The refresh timeout period R used to generate this message; in 1761 milliseconds. 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | Refresh Period (R) | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 5.1.3.4 BOUND_SESSION_ID 1769 Type: BOUND_SESSION_ID 1770 Length: Fixed - 4 32-bit words 1771 Value: Specifies the SESSION_ID (as specified in GIMPS 1772 [I-D.ietf-nsis-ntlp]) of the session that must be bound to the 1773 session associated with the message carrying this object. 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | | 1777 + + 1778 | | 1779 + Session ID + 1780 | | 1781 + + 1782 | | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 5.1.3.5 ERROR_SPEC 1787 The error object shares a common format with GIMPS and is specified 1788 in the GIMPS [I-D.ietf-nsis-ntlp] specification. 1790 Type: ERROR 1791 Length: Variable 1792 Value: Contains a 1 byte error class and 3 byte error code, an error 1793 source identifier and optionally variable length error-specific 1794 information. 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Error Class | Error Code | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | ESI-Length | Reserved | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 // Error Source Identifier // 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 // Optional error-specific information // 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 The first byte of the error code indicates the severity level. The 1807 currently defined severity levels are: 1808 o 0x01 - Informational 1809 o 0x02 - Success 1810 o 0x03 - Protocol Error 1811 o 0x04 - Transient Failure 1812 o 0x05 - Permanent Failure 1814 Within each severity class a number of error values are defined. 1815 o Informational: 1816 * 0x01000001 - Unknown BOUND_SESSION_ID: the message refers to an 1817 unknown SESSION_ID in its BOUND_SESSION_ID object. 1818 o Success: 1819 * 0x02000001 - State installation succeeded 1820 * 0x02000002 - Reservation created: reservation installed on 1821 complete path (sent by last node). 1822 * 0x02000003 - Reservation accepted: reservation installed at 1823 this QNE, but not yet installed on the rest of the path. 1824 * 0x02000004 - Reservation created but modified: reservation 1825 installed, but bandwidth reserved was not the maximum 1826 requested. 1827 o Protocol Error: 1828 * 0x03000001 - Illegal message type: the type given in the 1829 Message Type field of the common header is unknown. 1830 * 0x03000002 - Wrong message length: the length given for the 1831 message does not match the length of the message data. 1832 * 0x03000003 - Bad flags value: an undefined flag or combination 1833 of flags was set. 1834 * 0x03000004 - Mandatory object missing: an object required in a 1835 message of this type was missing. 1836 * 0x03000005 - Illegal object present: an object was present 1837 which must not be used in a message of this type. 1838 * 0x03000006 - Unknown object present: an object of an unknown 1839 type was present in the message. 1840 * 0x03000007 - Wrong object length: the length given for the 1841 object did not match the length of the object data present. 1842 * 0x03000008 - Unknown QSPEC type (Unknown QSM): the QSM ID 1843 refers to a QSM which is not known by this QNE. 1845 o Transient Failure: 1846 * 0x04000001 - Requested resources not available 1847 * 0x04000002 - Insufficient bandwidth available 1848 * 0x04000003 - Delay requirement cannot be met 1849 * 0x04000004 - Transient QSM-specific error 1850 * 0x04000005 - Resources pre-empted 1851 * 0x04000006 - No GIMPS reverse-path forwarding state 1852 * 0x04000007 - NSLP soft-state expired 1853 o Permanent Failure: 1854 * 0x05000001 - Authentication failure 1855 * 0x05000002 - Unable to agree transport security with peer 1856 * 0x05000003 - Internal or system error 1857 * 0x05000004 - Resource request denied (authorization failed) 1858 * 0x05000005 - Permanent QSM-specific error 1860 5.1.3.6 QSPEC 1862 Type: QSPEC 1863 Length: Variable 1864 Value: This object contains a 4 byte QSM ID and a variable length 1865 QSPEC (QoS specification) information, which is QSM specific. 1866 Such a QSM can be a standardized one, a private one, or a 1867 well-known one. 1869 The contents and encoding rules for this object are specified in 1870 other documents, prepared by QSPEC template designers. 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | QoS Signaling Policy Identifier (QSP ID) | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | | 1876 // QSpec Data // 1877 | | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 5.1.3.7 POLICY_DATA 1882 POLICY_DATA objects may contain various items to authenticate the 1883 user and allow the reservation to be authorised. Some possible 1884 contents are given in Appendix A, and some issues are also discussed 1885 in Section 3.1.4. 1887 5.2 General Processing Rules 1888 5.2.1 State Manipulation 1890 The processing of a message and its component objects involves 1891 manipulating the QoS NSLP and reservation state of a QNE. 1893 For each flow, a QNE stores (QSM specific) reservation state which is 1894 different for each QSM and QoS NSLP operation state which includes 1895 non-persistent state (e.g. the API parameters while a QNE is 1896 processing a message) and persistent state which is kept as long as 1897 the session is active. 1899 The persistent QoS NSLP state is conceptually organised in a table 1900 with the following structure. The primary key (index) for the table 1901 is the SESSION_ID: 1902 SESSION_ID 1904 A large identifier provided by GIMPS or set locally. 1906 The state information for a given key includes: 1907 Flow ID 1909 Copied from GIMPS. Several entries are possible in case of 1910 mobility events. 1912 QSM ID 1914 32 bit identification of the QSM. 1916 SII for each upstream and downstream peer 1918 The SII is a large identifier (minimum 128 bits) generated by the 1919 QoS NSLP and passed over the API. 1921 RSN from each upstream peer 1923 The RSN is a 32 bit counter. 1925 Current own RSN 1927 A 32 bit random number. 1929 List of RII for outstanding responses with processing information 1931 the RII is a 32 bit number. 1933 State lifetime 1935 The state lifetime indicates how long the state that is being 1936 signalled for remains valid. 1938 BOUND_SESSION_ID 1940 The BOUND_SESSION_ID is a 128 bit random number. 1942 Adding the state requirements of all these items gives an upper bound 1943 on the state to be kept by a QNE. The need to keep state depends on 1944 the desired functionality at the NSLP layer. 1946 5.2.2 Message Forwarding 1948 QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP 1949 does not have the concept of a message being sent along the entire 1950 path. Instead, messages are received by a QNE, which may then send 1951 another message (which may be identical to the received message, or 1952 contain some subset of objects from it) to continue in the same 1953 direction (i.e. towards QNI or QNR) as the message received. 1955 The decision on whether to generate a message to forward may be 1956 affected by the value of the SCOPING flag or by the presence of an 1957 RII object. 1959 5.2.3 Standard Message Processing Rules 1961 If a mandatory object is missing from a message then the receiving 1962 QNE MUST NOT propagate the message any further. It MUST construct an 1963 RESPONSE message indicating the error condition and send it back to 1964 the peer QNE that sent the message. 1966 If a message contains an object of an unrecognised type, then the 1967 behaviour depends on the object type value. 1969 5.3 Object Processing 1971 5.3.1 Reservation Sequence Number (RSN) 1973 A QNE's own RSN is a sequence number which applies to a particular 1974 NSIS signalling session (i.e. with a particular GIMPS SESSION_ID). 1975 It MUST be incremented for each new RESERVE message where the 1976 reservation for the session changes. Once the RSN has reached its 1977 maximum value, the next value it takes is zero. 1979 When receiving a RESERVE message a QNE uses the RSN given in the 1980 message to determine whether the state being requested is different 1981 to that already stored. If the RSN is the same as for the current 1982 reservation the current state MUST be refreshed. If the RSN is 1983 greater than the current stored value, the current reservation MUST 1984 be modified appropriately (provided that admission control and policy 1985 control succeed), and the stored RSN value updated to that for the 1986 new reservation. If the RSN is less than the current value, then it 1987 indicates an out-of-order message and the RESERVE message MUST be 1988 discarded. 1990 If the QNE does not store per-session state (and so does not keep any 1991 previous RSN values) then it MAY ignore the value of the RSN. It 1992 MUST also copy the same RSN into the RESERVE message (if any) it 1993 sends as a consequence of receiving this one. 1995 5.3.2 Request Identification Information (RII) 1997 A QNE sending some types of messages may require a response to be 1998 sent. It does so by including a Request Identification Information 1999 (RII) object. 2001 When creating an RII object the sender MUST select the value for the 2002 RII such that it is probabilistically unique within the given 2003 session. 2005 A number of choices are available when implementing this. 2006 Possibilities might include using a totally random value, or a node 2007 identifier together with a counter. If the value is selected by 2008 another QNE then RESPONSE messages may be incorrectly terminated, and 2009 not passed back to the node that requested them. 2011 When sending a message containing an RII object the sending node MUST 2012 remember the value used in the RII to match back any RESPONSE 2013 received. It SHOULD use a timer to identify situations where it has 2014 taken too long to receive the expected RESPONSE. If the timer 2015 expires without receiving a RESPONSE it MAY perform a retransmission. 2017 When receiving a message containing an RII object the node MUST send 2018 a RESPONSE if either 2019 o The SCOPING flag is set to one ('next hop' scope), or 2020 o This QNE is the last one on the path for the given session. 2021 and the QNE keeps per-session state for the given session. 2023 A message contains at most one RII object that is unique within a 2024 session and different for each message, in order to allow responses 2025 to be matched back to requests (without incorrectly matching at other 2026 nodes). Downstream nodes that desire responses may keep track of 2027 this RII to identify the RESPONSE when it passes back through them. 2029 5.3.3 BOUND_SESSION_ID 2031 As shown in the examples in Section 4, the QoS NSLP can relate 2032 multiple sessions together. It does this by including the SESSION_ID 2033 from one session in a BOUND_SESSION_ID object in messages in another 2034 session. 2036 When receiving a message with a BOUND_SESSION_ID object, a QNE MUST 2037 copy the BOUND_SESSION_ID object into all messages it sends for the 2038 same session. A QNE that stores per-session state SHOULD store the 2039 value of the BOUND_SESSION_ID. 2041 The BOUND_SESSION_ID is only indicative in nature. However, a QNE 2042 implementation MAY use BOUND_SESSION_ID information to optimize 2043 resource allocation, e.g. for bidirectional reservations. When 2044 receiving a tearing RESERVE for an aggregate reservation, it MAY use 2045 this information to initiate a tearing RESERVE for end-to-end 2046 sessions bound to the aggregate. 2048 5.3.4 REFRESH_PERIOD 2050 Refresh timer management values are carried by the REFRESH_PERIOD 2051 object which has local significance only. At the expiration of a 2052 "refresh timeout" period, each QNE independently examines its state 2053 and sends a refreshing RESERVE message to the next QNE peer where it 2054 is absorbed. This peer-to-peer refreshing (as opposed to the QNI 2055 initiating a refresh which travels all the way to the QNR) allows 2056 QNEs to choose refresh intervals as appropriate for their 2057 environment. For example, it is conceivable that refreshing 2058 intervals in the backbone, where reservations are relatively stable, 2059 are much larger than in an access network. The "refresh timeout" is 2060 calculated within the QNE and is not part of the protocol; however, 2061 it must be chosen to be compatible with the reservation lifetime as 2062 expressed by the REFRESH_PERIOD, and an assessment of the reliability 2063 of message delivery. 2065 The details of timer management and timer changes (slew handling and 2066 so on) are identical to the ones specified in Section 3.7 of RFC 2205 2067 [RFC2205]. 2069 There are two time parameters relevant to each QoS NSLP state in a 2070 node: the refresh period R between generation of successive refreshes 2071 for the state by the neighbor node, and the local state's lifetime L. 2072 Each RESERVE message may contain a REFRESH_PERIOD object specifying 2073 the R value that was used to generate this (refresh) message. This R 2074 value is then used to determine the value for L when the state is 2075 received and stored. The values for R and L may vary from peer to 2076 peer. This peer-to-peer refreshing (as opposed to the QNI initiating 2077 a refresh which travels all the way to the QNR) allows QNEs to choose 2078 refresh intervals as appropriate for their environment. For example, 2079 it is conceivable that refreshing intervals in the backbone, where 2080 reservations are relatively stable, are much larger than in an access 2081 network. 2083 In more detail: 2084 1. Floyd and Jacobson [_XREF_FJ94] have shown that periodic 2085 messages generated by independent network nodes can become 2086 synchronized. This can lead to disruption in network services as 2087 the periodic messages contend with other network traffic for link 2088 and forwarding resources. Since QoS NSLP sends periodic refresh 2089 messages, it must avoid message synchronization and ensure that 2090 any synchronization that may occur is not stable. For this 2091 reason, it is recommended that the the refresh timer should be 2092 randomly set to a value in the range [0.5R, 1.5R]. 2093 2. To avoid premature loss of state, L must satisfy L >= (K + 2094 0.5)*1.5*R, where K is a small integer. Then in the worst case, 2095 K-1 successive messages may be lost without state being deleted. 2096 To compute a lifetime L for a collection of state with different R 2097 values R0, R1, ..., replace R by max(Ri). 2098 Currently K = 3 is suggested as the default. However, it may be 2099 necessary to set a larger K value for hops with high loss rate. K 2100 may be set either by manual configuration per interface, or by 2101 some adaptive technique that has not yet been specified. 2102 3. Each RESERVE message carries a REFRESH_PERIOD object 2103 containing the refresh time R used to generate refreshes. The 2104 recipient node uses this R to determine the lifetime L of the 2105 stored state created or refreshed by the message. 2106 4. The refresh time R is chosen locally by each node. If the 2107 node does not implement local repair of reservations disrupted by 2108 route changes, a smaller R speeds up adaptation to routing 2109 changes, while increasing the QOS-NSLP overhead. With local 2110 repair, a router can be more relaxed about R since the periodic 2111 refresh becomes only a backstop robustness mechanism. A node may 2112 therefore adjust the effective R dynamically to control the amount 2113 of overhead due to refresh messages. 2114 The current suggested default for R is 30 seconds. However, the 2115 default value Rdef should be configurable per interface. 2116 5. When R is changed dynamically, there is a limit on how fast it 2117 may increase. Specifically, the ratio of two successive values 2118 R2/R1 must not exceed 1 + Slew.Max. 2119 Currently, Slew.Max is 0.30. With K = 3, one packet may be lost 2120 without state timeout while R is increasing 30 percent per refresh 2121 cycle. 2122 6. To improve robustness, a node may temporarily send refreshes 2123 more often than R after a state change (including initial state 2124 establishment). 2126 7. The values of Rdef, K, and Slew.Max used in an implementation 2127 should be easily modifiable per interface, as experience may lead 2128 to different values. The possibility of dynamically adapting K 2129 and/or Slew.Max in response to measured loss rates is for future 2130 study. 2132 5.3.5 ERROR_SPEC 2134 ERROR_SPEC processing rules are still to be defined in more detail. 2136 5.3.6 QSPEC 2138 The contents of the QSPEC depends on the QSM being used. It may be 2139 that parts of the QSPEC are standardised across multiple QSMs. This 2140 topic is currently under further study. 2142 Upon reception, the complete QSPEC is passed to the Resource 2143 Management Function (RMF). 2145 A QNE that receives a QSPEC stack MUST only look at the top QSPEC in 2146 the stack. If this QSPEC is not understood by the RMF, the QNE MUST 2147 send an RESPONSE containing an ERROR_SPEC and MUST NOT attempt to 2148 recover by inspecting the rest of the stack. 2150 Parameters of the QSM that is being signalled for are carried in the 2151 QSPEC object. A domain may have local policies regarding QoS model 2152 implementation, i.e. it may map incoming traffic to its own locally 2153 defined QSMs. The QoS NSLP supports this by allowing QSPEC objects 2154 to be stacked. 2156 When a domain wants to apply a certain QSM to an incoming per-flow 2157 reservation request, each edge of the domain is configured to map the 2158 incoming QSPEC object to a local QSPEC object and push that object 2159 onto the stack of QSPEC objects (typically immediately following the 2160 Common Control Information, i.e. the first QSPEC that is found in 2161 the message). 2163 A QNE that knows it is the last QNE to understand a local QSPEC 2164 object (e.g. by configuration of the egress QNEs of a domain) SHOULD 2165 remove the topmost QSPEC object from the stack. It SHOULD update the 2166 underlying QSM parameters if needed. 2168 A QNE that receives a message with a QSPEC object stack of which the 2169 topmost object is not understood MUST NOT forward the message and 2170 MUST send an error indication to its upstream neighbour. It MUST NOT 2171 attempt local recovery by inspecting the stack for a QSPEC object it 2172 understands. 2174 If the RMF indicates it cannot process the QSPEC, e.g. because the 2175 QSM is not supported the QNE sends a RESPONSE with the appropriate 2176 ERROR_SPEC. 2178 5.4 Message Processing Rules 2180 5.4.1 RESERVE Messages 2182 The RESERVE message is used to manipulate QoS reservation state in 2183 QNEs. A RESERVE message may create, refresh, modify or remove such 2184 state. The format of a RESERVE message is repeated here for 2185 convenience: 2187 RESERVE = COMMON_HEADER 2188 RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] 2189 [ POLICY_DATA ] [ *QSPEC ] 2191 RESERVE messages MUST only be sent towards the QNR. 2193 A QNE that receives a RESERVE message checks the message format. In 2194 case of malformed messages, the QNE sends a RESPONSE message with the 2195 appropriate ERROR_SPEC. 2197 Before performing any state changing actions a QNE MUST determine 2198 whether the request is authorized. It SHOULD exercise its local 2199 policy in conjunction with the POLICY_DATA object to do this. 2201 When the RESERVE is authorized, a QNE checks the COMMON_HEADER flags. 2202 If the TEAR flag is set, the message is a tearing RESERVE which 2203 indicates complete QoS NSLP state removal (as opposed to a 2204 reservation of zero resources). On receiving such a RESERVE message 2205 the QNE MUST inform the RMF that the reservation is no longer 2206 required. The QNE SHOULD remove the QoS NSLP state. It MAY signal 2207 to GIMPS (over the API) that reverse path state for this reservation 2208 is no longer required. If the QNE has reservations which are bound 2209 to this session (they contained the SESSION_ID of this session in 2210 their BOUND_SESSION_ID object), it MUST send a NOTIFY message for 2211 each of these reservations with an appropriate ERROR_SPEC. The QNE 2212 MAY elect to send RESERVE messages with the TEAR flag set for these 2213 reservations. 2215 The default behaviour of a QNE that receives a RESERVE with a 2216 SESSION_ID for which it already has state installed but with a 2217 different flow ID is to replace the existing reservation (and tear 2218 down the reservation on the old branch if the RESERVE is received 2219 with a different SII). 2221 In some cases, this may not be the desired behaviour. In that case, 2222 the QNI or a QNE may set the REPLACE flag in the common header to 2223 zero to indicate that the new session does not replace the existing 2224 one. A QNE that receives a RESERVE with the REPLACE flag set to zero 2225 but with the same SII will update the flow ID and indicate REPLACE=0 2226 to the RMF (where it will be used for the resource handling). If the 2227 SII is different, this means that the QNE is a merge point. In that 2228 case, the REPLACE=0 also indicates that a tearing RESERVE SHOULD NOT 2229 be sent on the old branch. 2231 When a QNE receives a (refreshing) RESERVE message with an unknown 2232 SESSION_ID, it MAY send a NOTIFY message to its upstream peer, 2233 indicating the unknown SESSION_ID. This indicates a downstream route 2234 change to the upstream peer. The upstream peer SHOULD send a 2235 complete RESERVE on the new path (new SII). It identifies the old 2236 signalling association (old SII) and MAY start sending complete 2237 RESERVE messages for other SESSION_IDs linked to this association. 2239 At a QNE, resource handling is performed by the RMF. For sessions 2240 with the REPLACE flag set to zero, we assume that the QSP includes 2241 directions to deal with resource sharing. This may include, adding 2242 the reservations, or taking the maximum of the two or more complex 2243 mathematical operations. 2245 This resource handling mechanism in the QSM is also applicable to 2246 sessions with different SESSION_ID but related through the 2247 BOUND_SESSION_ID object. Session replacement is not an issue here, 2248 but the QSM may specify whether to let the sessions that are bound 2249 together share resources on common links or not. 2251 Finally, it is possible that a RESERVE is received with no QSPEC at 2252 all. This is the case of a summary refresh. In this case, rather 2253 than sending a refreshing RESERVE with the full QSPEC, only the 2254 SESSION_ID and the SII are sent to refresh the reservation. Note 2255 that this mechanism just reduces the message size (and probably eases 2256 processing). One RESERVE per session is still needed. 2258 If the REPLACE flag is set, the QNE SHOULD update the reservation 2259 state according to the QSPEC contained in the message. It MUST 2260 update the lifetime of the reservation. If the REPLACE flag is not 2261 set, a QNE SHOULD NOT remove the old reservation state if the SII 2262 which is passed by GIMPS over the API is different than the SII that 2263 was stored for this reservation. The QNE MAY elect to keep sending 2264 refreshing RESERVE messages. 2266 If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state 2267 installation action. It does so by sending a RESPONSE with an 2268 ERROR_SPEC value of 0x02000003, indicating that the reservation is 2269 installed at the QNE. 2271 If the SCOPING flag is set, or if the QNE is the last QNE on the path 2272 to the destination, the QNE MUST send a RESPONSE message. 2274 When a QNE receives a RESERVE message, its processing may involve 2275 sending out another RESERVE message. When sending a RESERVE message, 2276 the QNE may insert or remove 'local' QSPEC objects from the top of 2277 the stack. If there are one or more QSPECs in the received RESERVE 2278 message, the last QSPEC MUST NOT be removed when sending on the 2279 RESERVE message. 2281 Upon transmission, a QNE SHOULD set the ACKNOWLEDGE flag. It MUST do 2282 so if it wishes to use the reduced overhead refresh mechanism 2283 described in Section 3.2.3. It MUST NOT send a reduced overhead 2284 refresh message (i.e. a RESERVE with a non-incremented RSN and no 2285 QSPEC) unless it has received a RESPONSE message for that RESERVE 2286 message. 2288 If the session of this message is bound to another session, then the 2289 RESERVE message MUST include the SESSION_ID of that other session in 2290 a BOUND_SESSION_ID object. 2292 In case of receiver-initiated reservations, the RESERVE message must 2293 follow the same path that has been followed by the QUERY message. 2294 Therefore, GIMPS is informed, over the QoS NSLP/GIMPS API, to pass 2295 the message upstream, i.e., by setting GIMPS "D" flag, see GIMPS 2296 [I-D.ietf-nsis-ntlp]. 2298 5.4.2 QUERY Messages 2300 A QUERY message is used to request information about the data path 2301 without making a reservation. This functionality can be used to 2302 'probe' the network for path characteristics or for support of 2303 certain QoS models. 2305 The format of a QUERY message is as follows: 2307 QUERY = COMMON_HEADER 2308 [ RII ] [ BOUND_SESSION_ID ] 2309 [ POLICY_DATA ] [ *QSPEC ] 2311 On receiving a QUERY message, a QNE checks whether an RII object is 2312 present. If not, the QUERY is an empty QUERY which is used to 2313 install reverse path state. In this case, if the QNE is not the QNR, 2314 it creates a new QUERY message to send downstream. If the QUERY 2315 contained a QSPEC, this MUST be passed to the RMF where it MAY be 2316 modified by QSM specific QUERY processing. If the QNE is the QNR, 2317 the QNE creates a RESERVE message, which contains a QSPEC received 2318 from the RMF and which MAY be based on the received QSPEC. If this 2319 node was not expecting to perform a receiver-initiated reservation 2320 then an error MUST be sent back along the path. 2322 If an RII object is present, and if the QNE is the QNR or the SCOPING 2323 flag is set, the QNE MUST generate a RESPONSE message and pass it 2324 back along the reverse of the path used by the QUERY. 2326 When generating a QUERY to send out to pass the query further along 2327 the path, the QNE MUST copy the RII object (if present) into the new 2328 QUERY message unchanged. A QNE that is also interested in the 2329 response to the query keeps track of the RII to identify the RESPONSE 2330 when it passes through it. 2332 5.4.3 RESPONSE Messages 2334 The RESPONSE message is used to provide information about the result 2335 of a previous QoS NSLP message, e.g. confirmation of a reservation 2336 or information resulting from a query. The RESPONSE message is 2337 impotent, it does not cause any state to be installed or modified. 2339 The format of a RESPONSE message is repeated here for convenience: 2341 RESPONSE = COMMON_HEADER 2342 [ RII / RSN ] ERROR_SPEC 2343 [ *QSPEC ] 2345 A RESPONSE message MUST be sent where the QNE is the last node to 2346 process a RESERVE or QUERY message containing an RII object (based on 2347 scoping of the RESERVE or QUERY, or because this is the last node on 2348 the path). In this case, the RESPONSE MUST copy the RII object from 2349 the RESERVE or QUERY. 2351 In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE 2352 flag is set or when an error occurs while processing a received 2353 message. If the received message contains an RII object, this object 2354 MUST be put in the RESPONSE, as described above. If the RESPONSE is 2355 sent as a result of the receipt of a RESERVE message without an RII 2356 object, then the RSN of the received RESERVE message MUST be copied 2357 into the RESPONSE message. 2359 On receipt of a RESPONSE message containing an RII object, the QNE 2360 MUST attempt to match it to the outstanding response requests for 2361 that signalling session. If the match succeeds, then the RESPONSE 2362 MUST NOT be forwarded further along the path. If the match fails, 2363 then the QNE MUST attempt to forward the RESPONSE to the next peer 2364 QNE. 2366 On receipt of a RESPONSE message containing an RSN object, the QNE 2367 MUST compare the RSN to that of the appropriate signalling session. 2368 If the match succeeds then the ERROR_SPEC MUST be processed. The 2369 RESPONSE message MUST NOT be forwarded further along the path whether 2370 or not the match succeeds. 2372 5.4.4 NOTIFY Messages 2374 NOTIFY messages are used to convey information to a QNE 2375 asynchronously. The format of a NOTIFY message is as follows: 2377 NOTIFY = COMMON_HEADER 2378 ERROR_SPEC [ QSPEC ] 2380 NOTIFY messages are impotent. They do not cause any state to be 2381 installed or modified and they do do not directly cause other 2382 messages to be sent. NOTIFY messages are sent asynchronously, rather 2383 than in response to other messages. They may be sent in either 2384 direction (upstream or downstream). 2386 6. IANA considerations 2388 This section provides guidance to the Internet Assigned Numbers 2389 Authority (IANA) regarding registration of values related to the QoS 2390 NSLP, in accordance with BCP 26 RFC 2434 [RFC2434]. 2392 The QoS NSLP requires IANA to create two new registries. One for QoS 2393 NSLP Message Types, the other for QoS Signaling Policy Identifiers. 2395 The QoS NSLP Message Type is a 16 bit value. The allocation of 2396 values for new message types requires standards action. This 2397 specification defines four QoS NSLP message types, which form the 2398 initial contents of this registry: RESERVE, QUERY, RESPONSE and 2399 NOTIFY. 2401 The QoS Signaling Policy Identifier (QSP ID) is a 32 bit value 2402 carried in a QSPEC object. The allocation policy for new QSP IDs is 2403 TBD. 2405 This specification defines a NSLP for use with GIMPS. Consequently, 2406 a new identifier must be assigned for it from GIMPS NSLP Identifier 2407 registry. 2409 This document also defines six new objects for the QoS NSLP: RII, 2410 RSN, REFRESH_PERIOD, BOUND_SESSION_ID, QSPEC and POLICY_DATA. Values 2411 are to be assigned for them from GIMPS Object Type registry. 2413 In addition it defines a number of Error Codes for the QoS NSLP. 2414 These can be found in section Section 5.1.3 and are to be assigned 2415 values from GIMPS Error Code registry. 2417 7. QoS use of GIMPS service interface 2419 This section describes the use of GIMPS service interface to 2420 implement QoS NSLP requirements on GIMPS. 2422 7.1 Example sender-initiated reservation 2424 We first describe the use of the service interface in a very basic 2425 scenario: message reception and transmission for a RESERVE message in 2426 a sender-initiated reservation. 2428 A QNE that wishes to initiate a sender-initiated reservation 2429 constructs a new RESERVE message to send downstream. The use of 2430 GIMPS service interface in this case is explained on Figure 33. Note 2431 that we assume the SII handling in GIMPS [I-D.ietf-nsis-ntlp] is 2432 extended to distinguish between own and peer SII. 2434 GIMPS QoS NSLP 2435 | | 2436 |<=====================================| 2437 | SendMessage{ | 2438 | NSLP-Data=RESERVE, | 2439 | Retain-State=TRUE, | 2440 | Size=X bytes, | 2441 | Message-Handle=NULL, | 2442 | NSLP-ID=QoS, | 2443 | Session-ID=SID_X, | 2444 | MRI=MRI, | 2445 | Direction=downstream, | 2446 | Own-SII-Handle=Own_SII_X, | 2447 | Peer-SII-Handle=empty | 2448 | Transfer-attributes=default, | 2449 | Timeout=default, | 2450 | IP-TTL=default} | 2451 | | 2453 Figure 33: GIMPS service interface usage for sending a 2454 sender-initiated reservation 2456 Note that an explicit preference for a particular type of transport, 2457 such as reliable/unreliable, may change the values of some service 2458 interface parameters (e.g. Transfer-attributes=unreliable). 2460 The message is received by the peer QNE. The use of GIMPS service 2461 interface when receiving a RESERVE message for a sender-initiated 2462 reservation is explained on Figure 34. 2464 GIMPS QoS NSLP 2465 | | 2466 |=====================================>| 2467 | RecvMessage{ | 2468 | NSLP-Data=RESERVE, | 2469 | Size=X bytes, | 2470 | Message-Handle=GIMPS_X, | 2471 | NSLP-ID=QoS, | 2472 | Session-ID=SID_X, | 2473 | MRI=MRI, | 2474 | Direction=downstream, | 2475 | Peer-SII-Handle=UP_SII_X, | 2476 | Transfer-attributes=default, | 2477 | IP-TTL=TTL_X, | 2478 | Original-TTL=TTL_Y} | 2479 | | 2480 |<=====================================| 2481 | MessageReceived{ | 2482 | Message-Handle=GIMPS_X, | 2483 | Retain-State=TRUE | 2484 | | 2486 Figure 34: GIMPS service interface usage for message reception of 2487 sender-initiated reservation 2489 7.2 Session identification 2491 The QoS NSLP keeps message and reservation state per session. A 2492 session is identified by a Session Identifier (SESSION_ID). The 2493 SESSION_ID is the primary index for stored NSLP state and needs to be 2494 constant and unique (with a sufficiently high probability) along a 2495 path through the network. On Figure 33, QoS NSLP picks a value SID_X 2496 for Session-ID. This value is subsequently used by GIMPS and QoS 2497 NSLP to refer to this session. 2499 7.3 Support for bypassing intermediate nodes 2501 The QoS NSLP may want to restrict the handling of its messages to 2502 specific nodes. This functionality is needed to support layering 2503 (explained in Section 3.2.8), when only the edge QNEs of a domain 2504 process the message. This requires a mechanism at GIMPS level (which 2505 can be invoked by the QoS NSLP) to bypass intermediates nodes between 2506 the edges of the domain. 2508 As a suggestion, we identified two ways for bypassing intermediate 2509 nodes. One solution is for the end-to-end session to carry a 2510 different protocol ID (QoS NSLP-E2E-IGNORE protocol ID, similar to 2511 the RSVP-E2E-IGNORE that is used for RSVP aggregation (RFC 3175 2512 [RFC3175]). Another solution is based on the use of multiple levels 2513 of the router alert option. In that case, internal routers are 2514 configured to handle only certain levels of router alerts. The 2515 choice between both approaches or another approach that fulfills the 2516 requirement is left to GIMPS design. 2518 7.4 Support for peer change identification 2520 There are several circumstances where it is necessary for a QNE to 2521 identify the adjacent QNE peer, which is the source of a signalling 2522 application message; for example, it may be to apply the policy that 2523 "state can only be modified by messages from the node that created 2524 it" or it might be that keeping track of peer identity is used as a 2525 (fallback) mechanism for rerouting detection at the NSLP layer. 2527 This functionality is implemented in GIMPS service interface with 2528 SII-handle. As shown in the above example, we assume the 2529 SII-handling will support both own SII and peer SII. 2531 Keeping track of the SII of a certain reservation also provides a 2532 means for the QoS NSLP to detect route changes. When a QNE receives 2533 a RESERVE referring to existing state but with a different SII, it 2534 knows that its upstream peer has changed. It can then use the old 2535 SII to initiate a teardown along the old section of the path. This 2536 functionality is supported in GIMPS service interface when the peer's 2537 SII which is stored on message reception is passed to GIMPS upon 2538 message transmission. 2540 7.5 Support for stateless operation 2542 Stateless or reduced state QoS NSLP operation makes the most sense 2543 when some nodes are able to operate in a stateless way at GIMPS level 2544 as well. Such nodes should not worry about keeping reverse state, 2545 message fragmentation and reassembly (at GIMPS), congestion control 2546 or security associations. A stateless or reduced state QNE will be 2547 able to inform the underlying GIMPS of this situation. GIMPS service 2548 interface supports this functionality with the Retain-State attribute 2549 in the MessageReceived primitive. 2551 7.6 Last node detection 2553 There are situations in which a QNE needs to determine whether it is 2554 the last QNE on the data path (QNR), e.g. to construct and send a 2555 RESPONSE message. 2557 A number of conditions may result in a QNE determining that it is the 2558 QNR: 2560 o the QNE may be the flow destination 2561 o the QNE have some other prior knowledge that it should act as the 2562 QNR 2563 o the QNE may be the last NSIS-capable node on the path 2564 o the QNE may be the last NSIS-capable node on the path supporting 2565 the QoS NSLP 2567 Of these four conditions, the last two can only be detected by GIMPS. 2568 We rely on GIMPS to inform the QoS NSLP about these cases by 2569 providing a trigger to the QoS NSLP when it determines that it is the 2570 last NE on the path, which supports the QoS NSLP. GIMPS supports 2571 this by the MessageDeliverError primitive. The error type 'no next 2572 node found' which is given as an example can be used. It is expected 2573 that additional error codes need to be defined. 2575 7.7 Re-routing detection 2577 Route changes may be detected at GIMPS layer or the information may 2578 be obtained by GIMPS through local interaction with or notification 2579 from routing protocols or modules. GIMPS allows to pass such 2580 information over the service interface using the NetworkNotification 2581 primitive with the appropriate 'downstream route change' or 'upstream 2582 route change' notification. 2584 7.8 Priority of signalling messages 2586 The QoS NSLP will generate messages with a range of performance 2587 requirements for GIMPS. These requirements may result from a 2588 prioritization at the QoS NSLP (Section 3.2.8) or from the 2589 responsiveness expected by certain applications supported by the QoS 2590 NSLP. 2592 GIMPS design should be able to ensure that performance for one class 2593 of messages was not degraded by aggregation with other classes of 2594 messages. GIMPS service interface supports this with the 'priority' 2595 transfer attribute. 2597 7.9 Knowledge of intermediate QoS NSLP unaware nodes 2599 In some cases it is useful to know that a reservation has not been 2600 installed at every router along the path. It is not possible to 2601 determine this using only NSLP functionality. 2603 GIMPS should be able to provide information to the NSLP about whether 2604 the message has passed through nodes that did not provide support for 2605 this NSLP. 2607 GIMPS service interface supports this by keeping track of IP-TTL and 2608 Original-TTL in the RecvMessage primitive. A difference between the 2609 two indiactes the number of QoS NSLP unaware nodes. 2611 7.10 NSLP Data Size 2613 When GIMPS passes the QoS NSLP data to the NSLP for processing, it 2614 must also indicate the size of that data. This is supported by the 2615 NSLP-Data-Size attribute. 2617 7.11 Notification of GIMPS 'D' flag value 2619 When GIMPS passes the QoS NSLP data to the NSLP for processing, it 2620 must also indicate the value of the 'D' (Direction) flag for that 2621 message. This is done in the Direction attribute of the SendMessage 2622 and RecvMessage primitives. 2624 7.12 NAT Traversal 2626 The QoS NSLP relies on GIMPS for NAT traversal. 2628 8. Assumptions on the QSM 2630 8.1 Resource sharing 2632 This specification assumes that resource sharing is possible between 2633 flows with the same SESSION_ID that originate from the same QNI or 2634 between flows with a different SESSION_ID that are related through 2635 the BOUND_SESSION_ID object. For flows with the same SESSION_ID, 2636 resource sharing is only applicable when the existing reservation is 2637 not just replaced (which is indicated by the REPLACE flag in the 2638 common header. 2640 The Resource Management Function (RMF) reserves resources for each 2641 flow. We assume that the QoS model supports resource sharing between 2642 flows. A QSM may elect to implement a more general behaviour of 2643 supporting relative operations on existing reservations, such as 2644 ADDING or SUBTRACTING a certain amount of resources from the current 2645 reservation. A QSM may also elect to allow resource sharing more 2646 generally, e.g. between all flows with the same DSCP. 2648 8.2 Reserve/commit support 2650 Reserve/commit behaviour means that the time at which the reservation 2651 is made may be different from the time when the reserved resources 2652 are actually set aside for the requesting session. This 2653 specification acknowledges the usefulness of such a mechanism but 2654 assumes that its implementation is opaque to QoS NSLP and is fully 2655 handled by the QSM. 2657 9. Open issues 2659 9.1 Peering agreements on interdomain links 2661 This specification proposes ways to carry AAA information that may be 2662 used at the edges of a domain to check whether the requestor is 2663 allowed to use the requested resources. It is less likely that the 2664 AAA information will be used inside a domain. In practice, there may 2665 be peering relations between domains that allow for a certain amount 2666 of traffic to be sent on an interdomain link without the need to 2667 check the authorization of each individual session (effectively 2668 making the peering domain the requestor of the resources). The 2669 per-session authorization check may be avoided by setting up an 2670 aggregate reservation on the inter-domain link for a specified amount 2671 of resources and relating the end-to-end sessions to it using the 2672 BOUND_SESSION_ID. In this way, the aggregate session is authorized 2673 once (and infrequently updated). An alternative is for the edge node 2674 of a domain to insert a token that authorizes the flow for the next 2675 domain. 2677 9.2 Protocol Operating Environment Assumptions 2679 The NSIS protocol is not used alone. Rather, it is used in 2680 conjunction with a variety of applications. For receiver initiated 2681 and bidirectional reservations the question arises of what the 2682 interactions are between the NSIS protocols and the end-to-end 2683 applications. An assumption needs to be made about what information 2684 should be determined outside the NSIS protocols, and what should be 2685 carried end-to-end in NSLP messages in order to initiate signalling. 2687 For a receiver initiated reservation, the we have the questions: How 2688 do the sender and receiver determine that a receiver initiated 2689 reservation is to be performed? And, how does information needed by 2690 the receiver to perform the reservation, but only available at the 2691 sender, be made transferred to the receiver so that the RESERVE 2692 message can be sent? 2694 In the bi-directional reservation case, we can either perform this as 2695 a pair of two sender-initiated reservations or as a combination of 2696 sender-initiated and receiver-initiated reservations. The latter 2697 case has the same issues as for the general receiver initiated 2698 reservation problem. The former raises similar questions: How does 2699 the remote end know that a reservation is needed? And, how does it 2700 know what resources to request? 2702 Is it reasonable to assume that the decision that an end should 2703 initiate a reservation is made totally outside the QoS NSLP itself 2704 (e.g. through prior configuration, or application end-to-end 2705 signalling such as SIP) or, should the QoS NSLP messages include some 2706 method to trigger the other end to perform a reservation (whether 2707 that be a receiver initiated reservation, or a sender initiated 2708 reservation for the first bidirectional reservation case)? 2710 In addition, should the QoS NSLP messages be able to carry extra data 2711 (e.g. a QSPEC object for the reverse direction) end-to-end that is 2712 needed by the remote end to perform its reservation? (And, should 2713 this be in the QoS NSLP, or through individual QoS models?) The 2714 alternative to providing support in the QoS NSLP for this is to leave 2715 it to application signalling to transfer any required information. 2717 10. Security Considerations 2719 10.1 Introduction and Threat Overview 2721 The security requirement for the QoS NSLP is to protect the 2722 signalling exchange for establishing QoS reservations against 2723 identified security threats. For the signalling problem as a whole, 2724 these threats have been outlined in NSIS threats 2725 [I-D.ietf-nsis-threats]; the NSIS framework [I-D.ietf-nsis-fw] 2726 assigns a subset of the responsibility to GIMPS and the remaining 2727 threats need to be addressed by NSLPs. The main issues to be handled 2728 can be summarised as: 2729 Authorization: 2731 The QoS NSLP must assure that the network is protected against 2732 theft-of-service by offering mechanisms to authorize the QoS 2733 reservation requestor. A user requesting a QoS reservation might 2734 want proper resource accounting and protection against spoofing 2735 and other security vulnerabilities which lead to denial of service 2736 and financial loss. In many cases authorization is based on the 2737 authenticated identity. The authorization model must provide 2738 guarantees that replay attacks are either not possible or limited 2739 to a certain extent. Authorization can also be based on traits 2740 which enables the user to remain anonymous. Support for user 2741 identity confidentiality can be accomplished. 2743 Message Protection: 2745 Signalling message content should be protected against 2746 modification, replay, injection and eavesdropping while in 2747 transit. Authorization information, such as authorization tokens, 2748 need protection. This type of protection at the NSLP layer is 2749 neccessary to protect messages between NSLP nodes which includes 2750 end-to-middle, middle-to-middle and even end-to-end protection. 2752 In addition to the above-raised issues we see the following 2753 functionality provided at the NSLP layer: 2754 Prevention of Denial of Service Attacks: 2756 GIMPS and QoS NSLP nodes have finite resources (state storage, 2757 processing power, bandwidth). The protocol mechanisms suggested 2758 in this document should try to minimise exhaustion attacks against 2759 these resources when performing authentication and authorization 2760 for QoS resources. 2762 To some extent the QoS NSLP relies on the security mechanisms 2763 provided by GIMPS which by itself relies on existing authentication 2764 and key exchange protocols. Some signalling messages cannot be 2765 protected by GIMPS and hence should be used with care by the QoS 2766 NSLP. An API must ensure that the QoS NSLP implementation is aware 2767 of the underlying security mechanisms and must be able to indicate 2768 which degree of security is provided between two GIMPS peers. If a 2769 level of security protection for QoS NSLP messages is required which 2770 goes beyond the security offered by GIMPS or underlying security 2771 mechanisms, additional security mechanisms described in this document 2772 must be used. The different usage environments and the different 2773 scenarios where NSIS is used make it very difficult to make general 2774 statements without reducing its flexibility. 2776 10.2 Trust Model 2778 For this version of the document we will rely on a model which 2779 requires trust between neighboring NSLP nodes to establish a 2780 chain-of-trust along the QoS signalling path. This model is simple 2781 to deploy, was used in previous QoS authorization environments (such 2782 as RSVP) and seems to provide sufficiently strong security 2783 properties. We refer to this model as the 'New Jersey Turnpike' 2784 model. 2786 On the New Jersey Turnpike, motorists pick up a ticket at a toll 2787 booth when entering the highway. At the highway exit the ticket is 2788 presented and payment is made at the toll booth for the distance 2789 driven. For QoS signalling in the Internet this procedure is roughly 2790 similar. In most cases the data sender is charged for transmitted 2791 data traffic where charging is provided only between neighboring 2792 entities. 2794 +------------------+ +------------------+ +------------------+ 2795 | Network | | Network | | Network | 2796 | X | | Y | | Z | 2797 | | | | | | 2798 | -----------> -----------> | 2799 | | | | | | 2800 | | | | | | 2801 +--------^---------+ +------------------+ +-------+----------+ 2802 | . 2803 | . 2804 | v 2805 +--+---+ Data Data +--+---+ 2806 | Node | ==============================> | Node | 2807 | A | Sender Receiver | B | 2808 +------+ +------+ 2810 Legend: 2812 ----> Peering relationship which allows neighboring 2813 networks/entities to charge each other for the 2814 QoS reservation and data traffic 2816 ====> Data flow 2818 ..... Communication to the end host 2820 Figure 35: New Jersey Turnpike Model 2822 The model shown in Figure 35 uses peer-to-peer relationships between 2823 different administrative domains as a basis for accounting and 2824 charging. As mentioned above, based on the peering relationship a 2825 chain-of-trust is established. There are several issues which come 2826 to mind when considering this type of model: 2827 o This model allows authorization on a request basis or on a 2828 per-session basis. Authorization mechanisms will be elaborated in 2829 Section 4.9. The duration for which the QoS authorization is 2830 valid needs to be controlled. Combining the interval with the 2831 soft-state interval is possible. Notifications from the networks 2832 also seem to be viable approach. 2833 o The price for a QoS reservation needs to be determined somehow and 2834 communicated to the charged entity and to the network where the 2835 charged entity is attached. Price distribution protocols are not 2836 covered in this version of the document. This model assumes, per 2837 default, that the data sender is authorizing the QoS reservation. 2838 Please note that this is only a simplification and further 2839 extensions are possible and left for a future version of this 2840 document. 2842 o This architecture seems to be simple enough to allow a scalable 2843 solution (ignoring reverse charging, multicast issues and price 2844 distribution). 2846 Charging the data sender as performed in this model simplifies 2847 security handling by demanding only peer-to-peer security protection. 2848 Node A would perform authentication and key establishment. The 2849 established security association (together with the session key) 2850 would allow the user to protect QoS signalling messages. The 2851 identity used during the authentication and key establishment phase 2852 would be used by Network X (see Figure 35) to perform the so-called 2853 policy-based admission control procedure. In our context this user 2854 identifier would be used to establish the necessary infrastructure to 2855 provide authorization and charging. Signalling messages later 2856 exchanged between the different networks are then also subject to 2857 authentication and authorization. The authenticated entity thereby 2858 is, however, the neighboring network and not the end host. 2860 The New Jersey Turnpike model is attractive because of its 2861 simplicity. S. Schenker et. al. [shenker-pricing] discuss various 2862 accounting implications and introduced the edge pricing model. The 2863 edge pricing model shows similarity to the model described in this 2864 section with the exception that mobility and the security 2865 implications itself are not addressed. 2867 10.3 Computing the authorization decision 2869 Whenever an authorization decision has to be made then there is the 2870 question which information serves as an input to the authorizing 2871 entity. The following information items have been mentioned in the 2872 past for computing the authorization decision (in addition to the 2873 authenticated identity): 2874 Price 2875 QoS objects 2876 Policy rules 2878 Policy rules include attributes like time of day, subscription to 2879 certain services, membership, etc. into consideration when computing 2880 an authorization decision. 2882 A detailed description of the authorization handling will be left for 2883 a future version of this document. The authors assume that the QoS 2884 NSLP needs to provide a number of attributes to support the large 2885 range of scenarios. 2887 11. Change History 2889 Changes from -00 2890 * Additional explanation of RSN versus Session ID differences. 2891 (Session IDs still need to be present and aren't replaced by 2892 RSNs. Explain how QoS NSLP could react once it notes that it 2893 maintains stale state.) 2894 * Additional explanation of message types - why we don't just 2895 have RESERVE and RESPONSE. 2896 * Clarified that figure 1 is not an implementation restriction. 2897 Changes from -01 2898 * Significant restructuring. 2899 * Added more concrete details of message formats and processing. 2900 * Added description of layering/aggregation concepts. 2901 * Added details of authentication/authorisation aspects. 2902 Changes from -02 2903 * Addressed comments from early review. 2904 * Added text on receiver-initiated and bi-directional 2905 reservations. 2906 * Extended description of session binding. Added support for 2907 fate sharing. 2908 * Restructured message formats and processing section. 2909 * Clarified refresh reduction mechanism. 2910 * Added assumptions on QSM. 2911 * Added assumptions on operating environment. 2912 Changes from -03 2913 * Removed overlaps between sections. 2914 * Clarified document does not specify how to aggregate individual 2915 end-to-end flow from a resource point of view but rather how 2916 such an aggregate can be signalled for. 2917 * Made session binding purely informational. 2918 * Clarified QSPEC stacking. 2919 * Added object format for ERROR_SPEC object. 2920 * Made RII a separate object from RESPONSE_REQUEST and outside of 2921 the SCOPING object. Then removed RESPONSE_REQUEST and made 2922 SCOPING a flag rather than an object. 2923 * Closed open issue of "PATH" message functionality. An empty 2924 QUERY is used to install reverse state along the path. 2925 * Made all flag names positive. Removed NO_FATE_SHARING flag: 2926 fate sharing is not supported by the signalling. 2927 * Removed the open issue on one-sided bidirectional reservation. 2928 Clarified how it can be done, even for stateless or reduced 2929 state domains in an example. 2930 * Removed open issue on priority. Message priority will be 2931 handled over GIMPS API, reservation priority is an issue for 2932 the RMF. 2934 Changes from -04 2935 * Resolved a number of outstanding comments on clarifications 2936 (likelihood of transport type, bidirectional reservations, 2937 handle of RESERVE messages inside a domain in case of 2938 aggregation or reduced state operation) from the mailing list. 2939 * Introduced a default value for REFRESH_PERIOD. 2940 * Introduced explicit feedback mechanism in case of route 2941 changes. 2942 * State acknowledgment is now supported by means of an 2943 ACKNOWLEDGE flag. This is made the default case. 2944 * Changed section 7 to reflect the use of GIMPS service 2945 interface. 2947 12. Acknowledgements 2949 The authors would like to thank Eleanor Hepworth, Ruediger Geib, 2950 Roland Bless and Nemeth Krisztian for their useful comments. 2952 13. Contributors 2954 This draft combines work from three individual drafts. The following 2955 authors from these drafts also contributed to this document: Robert 2956 Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia 2957 Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and 2958 Maarten Buechli (Dante) and Eric Waegeman (Alcatel). 2960 Yacine El Mghazli (Alcatel) contributed text on AAA. 2962 14. References 2964 14.1 Normative References 2966 [I-D.ietf-nsis-ntlp] 2967 Schulzrinne, H., "GIMPS: General Internet Messaging 2968 Protocol for Signaling", draft-ietf-nsis-ntlp-03 (work in 2969 progress), July 2004. 2971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2972 Requirement Levels", BCP 14, RFC 2119, March 1997. 2974 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2975 Specifications: ABNF", RFC 2234, November 1997. 2977 14.2 Informative References 2979 [I-D.ash-nsis-nslp-qos-sig-proof-of-concept] 2980 Ash, J., "NSIS Network Service Layer Protocol QoS 2981 Signaling Proof-of-Concept", 2982 draft-ash-nsis-nslp-qos-sig-proof-of-concept-01 (work in 2983 progress), February 2004. 2985 [I-D.bader-nsis-rmd-diffserv-qsm] 2986 Bader, A., Westberg, L., Karagiannis, G., Kappler, C. and 2987 T. Phelan, "Resource Management in Diffserv (RMD) 2988 Framework", draft-bader-nsis-rmd-diffserv-qsm-00.txt, 2989 work in progress, July 2004. 2991 [I-D.bader-rmd-qos-model] 2992 Bader, A., "RMD (Resource Management in Diffserv) QoS-NSLP 2993 model", draft-bader-rmd-qos-model-00 (work in progress), 2994 February 2004. 2996 [I-D.ietf-nsis-fw] 2997 Hancock, R., "Next Steps in Signaling: Framework", 2998 draft-ietf-nsis-fw-06 (work in progress), July 2004. 3000 [I-D.ietf-nsis-threats] 3001 Tschofenig, H. and D. Kroeselberg, "Security Threats for 3002 NSIS", draft-ietf-nsis-threats-05 (work in progress), June 3003 2004. 3005 [I-D.kappler-nsis-qosmodel-controlledload] 3006 Kappler, C., "A QoS Model for Signaling IntServ 3007 Controlled-Load Service with NSIS", 3008 draft-kappler-nsis-qosmodel-controlledload-00 (work in 3009 progress), February 2004. 3011 [I-D.manner-lrsvp] 3012 Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K. 3013 Raatikainen, "Localized RSVP", draft-manner-lrsvp-03.txt, 3014 work in progress, January 2004. 3016 [I-D.tschofenig-nsis-aaa-issues] 3017 Tschofenig, H., "NSIS Authentication, Authorization and 3018 Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 3019 (work in progress), March 2003. 3021 [I-D.tschofenig-nsis-qos-authz-issues] 3022 Tschofenig, H., "QoS NSLP Authorization Issues", 3023 draft-tschofenig-nsis-qos-authz-issues-00 (work in 3024 progress), June 2003. 3026 [I-D.westberg-rmd-framework] 3027 Westberg, L., "Resource Management In Diffserv: An NSIS 3028 QoS Signalling Model for Diffserv Networks", 3029 draft-westberg-rmd-framework-04.txt, work in progress, 3030 September 2003. 3032 [MEF.EthernetServicesModel] 3033 Metro Ethernet Forum, "Ethernet Services Model", letter 3034 ballot document , August 2003. 3036 [OSP] ETSI, "Telecommunications and internet protocol 3037 harmonization over networks (tiphon); open settlement 3038 protocol (osp) for inter- domain pricing, authorization, 3039 and usage exchange", Technical Specification 101 321, 3040 version 2.1.0. 3042 [RFC1633] Braden, B., Clark, D. and S. Shenker, "Integrated Services 3043 in the Internet Architecture: an Overview", RFC 1633, June 3044 1994. 3046 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. 3047 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 3048 Functional Specification", RFC 2205, September 1997. 3050 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 3051 Services", RFC 2210, September 1997. 3053 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3054 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3055 October 1998. 3057 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 3058 and W. Weiss, "An Architecture for Differentiated 3059 Services", RFC 2475, December 1998. 3061 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and 3062 S. Molendini, "RSVP Refresh Overhead Reduction 3063 Extensions", RFC 2961, April 2001. 3065 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, 3066 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3067 3175, September 2001. 3069 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session 3070 Authorization Policy Element", RFC 3520, April 2003. 3072 [RFC3521] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session 3073 Set-up with Media Authorization", RFC 3521, April 2003. 3075 [RFC3583] Chaskar, H., "Requirements of a Quality of Service (QoS) 3076 Solution for Mobile IP", RFC 3583, September 2003. 3078 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3079 3726, April 2004. 3081 [_XREF_FJ94] 3082 Jacobson, V., "Synchronization of Periodic Routing 3083 Messages", IEEE/ACM Transactions on Networking , Vol. 2 , 3084 No. 2 , April 1994. 3086 [_XREF_OPWA95] 3087 Breslau, L., "Two Issues in Reservation Establishment", 3088 Proc. ACM SIGCOMM '95 , Cambridge , MA , August 1995. 3090 [shenker-pricing] 3091 Shenker, S., Clark, D., Estrin, D. and S. Herzog, "Pricing 3092 in computer networks: Reshaping the research agenda", 3093 Proc. of TPRC 1995, 1995. 3095 Authors' Addresses 3097 Sven Van den Bosch 3098 Alcatel 3099 Francis Wellesplein 1 3100 Antwerpen B-2018 3101 Belgium 3103 EMail: sven.van_den_bosch@alcatel.be 3104 Georgios Karagiannis 3105 University of Twente/Ericsson 3106 P.O. Box 217 3107 Enschede 7500 AE 3108 The Netherlands 3110 EMail: karagian@cs.utwente.nl 3112 Andrew McDonald 3113 Siemens/Roke Manor Research 3114 Roke Manor Research Ltd. 3115 Romsey, Hants SO51 0ZN 3116 UK 3118 EMail: andrew.mcdonald@roke.co.uk 3120 Appendix A. POLICY_DATA Class 3122 This section presents a set of specifications for supporting generic 3123 authorization in QoS NSLP. These specs include the standard format 3124 of POLICY_DATA objects, and a description of QoS NSLP handling of 3125 authorization events. This section does not advocate a particular 3126 authorization approach (2-party, 3-party, token-based 3-party). 3128 The traffic control block is responsible for controlling and 3129 enforcing access and usage policies. 3131 A.1 Base Format 3133 POLICY_DATA object: Class=7, C-Type=1 3135 +-------------------------------------------------------+ 3136 | | 3137 // Option List // 3138 | | 3139 +-------------------------------------------------------+ 3140 | | 3141 // Policy Element List // 3142 | | 3143 +-------------------------------------------------------+ 3145 Option List: Variable length. See more details in Appendix A.2. 3146 Policy Element List: Variable length. See more details in Appendix 3147 A.3. 3149 A.2 Options 3151 This section describes a set of options that may appear in 3152 POLICY_DATA objects. Some policy options appear as QoS NSLP objects 3153 but their semantic is modified when used as policy data options. 3155 Policy Refresh TIME_VALUES (PRT) object: 3157 The Policy Refresh TIME_VALUES (PRT) option is used to slow policy 3158 refresh frequency for policies that have looser timing constraints 3159 relative to QoS NSLP. If the PRT option is present, policy 3160 refreshes can be withheld as long as at least one refresh is sent 3161 before the policy refresh timer expires. A minimal value for PRT 3162 is the NSLP session refresh period R; lower values are assumed to 3163 be R (neither error nor warning should be triggered). This option 3164 is especially useful to combine strong (high overhead) and weak 3165 (low overhead) authentication certificates as policy data. In 3166 such schemes the weak certificate can support admitting a 3167 reservation only for a limited time, after which the strong 3168 certificate is required. This approach may reduce the overhead of 3169 POLICY_DATA processing. Strong certificates could be transmitted 3170 less frequently, while weak certificates are included in every QoS 3171 NSLP refresh. 3173 Policy Source Identification Information (PSII) object: 3175 The Policy SII object identifies the neighbor/peer policy-capable 3176 QN that constructed the policy object. When policy is enforced at 3177 border QNEs, peer policy nodes may be several NSLP hops away from 3178 each other and the SII is the basis for the mechanism that allows 3179 them to recognize each other and communicate safely and directly. 3180 As stated above, we assume such an (P)SII to be available from a 3181 service from GIMPS. If no PSII object is present, the policy data 3182 is implicitly assumed to have been constructed by the QoS NSLP HOP 3183 indicated in the SII (i.e., the neighboring QoS NSLP node is 3184 policy-capable). 3186 A.3 Policy Elements 3188 There are no requirements for all nodes to process this container. 3189 Policy data is opaque to NSLP, which simply passes it to policy 3190 control when required. 3192 The content of policy elements is opaque to the QoS NSLP layer. Only 3193 policy peers understand their internal format and NSLP layer simply 3194 passes it to policy control when required. 3196 Policy Elements have the following format: 3198 +-------------+-------------+-------------+-------------+ 3199 | Length | P-Type | 3200 +---------------------------+---------------------------+ 3201 | | 3202 // Policy information (Opaque to QoS NSLP) // 3203 | | 3204 +-------------------------------------------------------+ 3206 A.3.1 Authorization token Policy Element 3208 The AUTHZ_TOKEN policy element contains a list of fields, which 3209 describe the session, along with other attributes. 3211 +-------------+-------------+-------------+-------------+ 3212 | Length | P-Type = AUTHZ_TOKEN | 3213 +-------------+-------------+-------------+-------------+ 3214 // Session Authorization Attribute List // 3215 +-------------------------------------------------------+ 3217 Session Authorization Attribute List: variable length. The 3218 session authorization attribute list is a collection of objects 3219 which describes the session and provides other information 3220 necessary to verify the resource reservation request. See 3221 [RFC3520] for a details. 3222 Session Authorization Attributes. A session authorization 3223 attribute may contain a variety of information and has both an 3224 attribute type and subtype. The attribute itself MUST be a 3225 multiple of 4 octets in length, and any attributes that are not a 3226 multiple of 4 octets long MUST be padded to a 4-octet boundary. 3227 All padding bytes MUST have a value of zero. 3229 +--------+--------+--------+--------+ 3230 | Length | X-Type |SubType | 3231 +--------+--------+--------+--------+ 3232 | Value ... | 3233 +--------+--------+--------+--------+ 3235 Length: 16 bits 3237 The length field is two octets and indicates the actual length of 3238 the attribute (including Length, X-Type and SubType fields) in 3239 number of octets. The length does NOT include any bytes padding 3240 to the value field to make the attribute a multiple of 4 octets 3241 long. 3243 X-Type: 8 bits 3245 Session authorization attribute type (X-Type) field is one octet. 3246 IANA acts as a registry for X-Types as described in Section 6. 3247 Initially, the registry contains the following X-Types: 3248 1 AUTH_ENT_ID: The unique identifier of the entity which 3249 authorized the session. 3250 2 SESSION_ID: Unique identifier for this session. 3251 3 SOURCE_ADDR: Address specification for the session originator. 3253 4 DEST_ADDR: Address specification for the session end-point. 3254 5 START_TIME: The starting time for the session. 3255 6 END_TIME: The end time for the session. 3256 7 RESOURCES: The resources which the user is authorized to 3257 request. 3258 8 AUTHENTICATION_DATA: Authentication data of the session 3259 authorization policy element. 3260 SubType: 8 bits 3262 Session authorization attribute sub-type is one octet in length. 3263 The value of the SubType depends on the X-Type. 3265 Value: variable length 3267 The attribute specific information is defined in [RFC3520]. 3269 A.3.2 OSP Token Policy Element 3271 To be completed. 3273 A.3.3 User Identity Policy element 3275 To be completed. 3277 Intellectual Property Statement 3279 The IETF takes no position regarding the validity or scope of any 3280 Intellectual Property Rights or other rights that might be claimed to 3281 pertain to the implementation or use of the technology described in 3282 this document or the extent to which any license under such rights 3283 might or might not be available; nor does it represent that it has 3284 made any independent effort to identify any such rights. Information 3285 on the procedures with respect to rights in RFC documents can be 3286 found in BCP 78 and BCP 79. 3288 Copies of IPR disclosures made to the IETF Secretariat and any 3289 assurances of licenses to be made available, or the result of an 3290 attempt made to obtain a general license or permission for the use of 3291 such proprietary rights by implementers or users of this 3292 specification can be obtained from the IETF on-line IPR repository at 3293 http://www.ietf.org/ipr. 3295 The IETF invites any interested party to bring to its attention any 3296 copyrights, patents or patent applications, or other proprietary 3297 rights that may cover technology that may be required to implement 3298 this standard. Please address the information to the IETF at 3299 ietf-ipr@ietf.org. 3301 Disclaimer of Validity 3303 This document and the information contained herein are provided on an 3304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3311 Copyright Statement 3313 Copyright (C) The Internet Society (2004). This document is subject 3314 to the rights, licenses and restrictions contained in BCP 78, and 3315 except as set forth therein, the authors retain all their rights. 3317 Acknowledgment 3319 Funding for the RFC Editor function is currently provided by the 3320 Internet Society.