idnits 2.17.1 draft-ietf-nsis-qos-nslp-03.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3372. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3388), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1126 has weird spacing: '...eas the way t...' == Line 2997 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 (May 11, 2004) is 7290 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: '1' is defined on line 2899, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2943, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 2988, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '7') (Obsoleted by RFC 5226) == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-05 == Outdated reference: A later version (-14) exists of draft-kappler-nsis-qosmodel-controlledload-00 == Outdated reference: A later version (-06) exists of draft-ietf-nsis-threats-04 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 Signaling S. Van den Bosch 3 Internet-Draft Alcatel 4 Expires: November 9, 2004 G. Karagiannis 5 University of Twente/Ericsson 6 A. McDonald 7 Siemens/Roke Manor Research 8 May 11, 2004 10 NSLP for Quality-of-Service signaling 11 draft-ietf-nsis-qos-nslp-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 9, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This draft describes an NSIS Signaling Layer Protocol (NSLP) for 45 signaling QoS reservations in the Internet. It is in accordance with 46 the framework and requirements developed in NSIS. 48 Together with GIMPS, it provides functionality similar to RSVP and 49 extends it. The QoS-NSLP is independent of the underlying QoS 50 specification or architecture and provides support for different 51 reservation models. It is simplified by the elimination of support 52 for multicast flows. 54 This version of the draft focuses on the basic protocol structure. 55 It identifies the different message types and describes the basic 56 operation of the protocol to create, refresh, modify and teardown a 57 reservation or to obtain information on the characteristics of the 58 associated data path. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.1 Scope and background . . . . . . . . . . . . . . . . . . . 6 70 1.2 Model of operation . . . . . . . . . . . . . . . . . . . . 6 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 73 3.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.2 GIMPS Interactions . . . . . . . . . . . . . . . . . . . . 11 75 3.3 Authentication and authorization . . . . . . . . . . . . . 11 76 3.4 Aggregation . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.5 Examples of QoS NSLP Operation . . . . . . . . . . . . . . 12 78 3.5.1 Simple Resource Reservation . . . . . . . . . . . . . 13 79 3.5.2 Sending a Query . . . . . . . . . . . . . . . . . . . 14 80 3.5.3 Basic Receiver Initiated Reservation . . . . . . . . . 15 81 3.5.4 Bidirectional Reservations . . . . . . . . . . . . . . 17 82 3.5.5 Use of Local QoS Models . . . . . . . . . . . . . . . 20 83 3.5.6 Aggregate Reservations . . . . . . . . . . . . . . . . 21 84 3.5.7 Reduced State or Stateless Interior Nodes . . . . . . 23 85 3.6 Authorization Model Examples . . . . . . . . . . . . . . . 25 86 3.6.1 Authorization for the two party approach . . . . . . . 25 87 3.6.2 Token based three party approach . . . . . . . . . . . 26 88 3.6.3 Generic three party approach . . . . . . . . . . . . . 26 89 4. Design decisions . . . . . . . . . . . . . . . . . . . . . . . 27 90 4.1 Message types . . . . . . . . . . . . . . . . . . . . . . 27 91 4.1.1 RESERVE . . . . . . . . . . . . . . . . . . . . . . . 28 92 4.1.2 QUERY . . . . . . . . . . . . . . . . . . . . . . . . 28 93 4.1.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 29 94 4.1.4 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 29 95 4.2 Control information . . . . . . . . . . . . . . . . . . . 30 96 4.2.1 Message sequencing . . . . . . . . . . . . . . . . . . 30 97 4.2.2 Requesting responses . . . . . . . . . . . . . . . . . 31 98 4.2.3 Message scoping . . . . . . . . . . . . . . . . . . . 31 99 4.2.4 State handling . . . . . . . . . . . . . . . . . . . . 32 100 4.2.5 State timers . . . . . . . . . . . . . . . . . . . . . 32 101 4.2.6 Session binding . . . . . . . . . . . . . . . . . . . 33 102 4.3 Layering . . . . . . . . . . . . . . . . . . . . . . . . . 34 103 4.3.1 Local QoS models . . . . . . . . . . . . . . . . . . . 34 104 4.3.2 Local control plane properties . . . . . . . . . . . . 35 105 4.3.3 Aggregate reservations . . . . . . . . . . . . . . . . 35 106 4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . 36 107 4.5 Priority . . . . . . . . . . . . . . . . . . . . . . . . . 37 108 4.6 Rerouting . . . . . . . . . . . . . . . . . . . . . . . . 37 109 4.7 State storage . . . . . . . . . . . . . . . . . . . . . . 39 110 4.8 Authentication and authorization . . . . . . . . . . . . . 40 111 4.8.1 Policy Ignorant Nodes . . . . . . . . . . . . . . . . 40 112 4.8.2 Policy Data . . . . . . . . . . . . . . . . . . . . . 41 113 5. QoS-NSLP Functional specification . . . . . . . . . . . . . . 42 114 5.1 QoS-NSLP Message and Object Formats . . . . . . . . . . . 42 115 5.1.1 Common header . . . . . . . . . . . . . . . . . . . . 42 116 5.1.2 Object Formats . . . . . . . . . . . . . . . . . . . . 42 117 5.2 General Processing Rules . . . . . . . . . . . . . . . . . 44 118 5.2.1 State Manipulation . . . . . . . . . . . . . . . . . . 44 119 5.2.2 Message Forwarding . . . . . . . . . . . . . . . . . . 44 120 5.2.3 Standard Message Processing Rules . . . . . . . . . . 44 121 5.3 Object Processing . . . . . . . . . . . . . . . . . . . . 45 122 5.3.1 Reservation Sequence Number . . . . . . . . . . . . . 45 123 5.3.2 Response Request . . . . . . . . . . . . . . . . . . . 45 124 5.3.3 Bound Session ID . . . . . . . . . . . . . . . . . . . 46 125 5.3.4 Refresh Period . . . . . . . . . . . . . . . . . . . . 46 126 5.3.5 Scoping . . . . . . . . . . . . . . . . . . . . . . . 47 127 5.3.6 Error Spec . . . . . . . . . . . . . . . . . . . . . . 48 128 5.3.7 Policy Data . . . . . . . . . . . . . . . . . . . . . 48 129 5.3.8 QSpec . . . . . . . . . . . . . . . . . . . . . . . . 48 130 5.4 Message Processing Rules . . . . . . . . . . . . . . . . . 48 131 5.4.1 RESERVE Messages . . . . . . . . . . . . . . . . . . . 48 132 5.4.2 QUERY Messages . . . . . . . . . . . . . . . . . . . . 49 133 5.4.3 RESPONSE Messages . . . . . . . . . . . . . . . . . . 51 134 5.4.4 NOTIFY Messages . . . . . . . . . . . . . . . . . . . 52 135 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 52 136 7. Requirements for the NSIS Transport Layer Protocol (GIMPS) . . 54 137 7.1 Session identification . . . . . . . . . . . . . . . . . . 54 138 7.2 Support for bypassing intermediate nodes . . . . . . . . . 54 139 7.3 Support for peer change identification . . . . . . . . . . 54 140 7.4 Support for stateless operation . . . . . . . . . . . . . 55 141 7.5 Last node detection . . . . . . . . . . . . . . . . . . . 55 142 7.6 Re-routing detection . . . . . . . . . . . . . . . . . . . 56 143 7.7 Priority of signalling messages . . . . . . . . . . . . . 56 144 7.8 Knowledge of intermediate QoS NSLP unaware nodes . . . . . 56 145 7.9 NSLP Data Size . . . . . . . . . . . . . . . . . . . . . . 56 146 7.10 Notification of NTLP 'D' flag value . . . . . . . . . . . 56 147 7.11 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57 148 8. Assumptions on the QoS model . . . . . . . . . . . . . . . . . 57 149 8.1 Resource sharing . . . . . . . . . . . . . . . . . . . . . 57 150 8.2 Reserve/commit support . . . . . . . . . . . . . . . . . . 57 151 9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 57 152 9.1 Region scoping . . . . . . . . . . . . . . . . . . . . . . 57 153 9.2 Priority of reservations . . . . . . . . . . . . . . . . . 58 154 9.3 Peering agreements on interdomain links . . . . . . . . . 58 155 9.4 GIMPS Modifications for Refresh Overhead Reduction . . . . 59 156 9.5 Path state maintenance implementation at NSLP . . . . . . 59 157 9.6 GIMPS Path State Maintenance . . . . . . . . . . . . . . . 59 158 9.7 Protocol Operating Environment Assumptions . . . . . . . . 60 159 10. Security Considerations . . . . . . . . . . . . . . . . . . 60 160 10.1 Introduction and Threat Overview . . . . . . . . . . . . . 61 161 10.2 Trust Model . . . . . . . . . . . . . . . . . . . . . . . 62 162 10.3 Computing the authorization decision . . . . . . . . . . . 64 163 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 64 164 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 165 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65 166 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 167 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 65 168 14.2 Informative References . . . . . . . . . . . . . . . . . . . 66 169 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 68 170 A. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 68 171 A.1 RESPONSE_REQUEST Class . . . . . . . . . . . . . . . . . . 68 172 A.2 RSN Class . . . . . . . . . . . . . . . . . . . . . . . . 69 173 A.3 REFRESH_PERIOD Class . . . . . . . . . . . . . . . . . . . 69 174 A.4 SESSION_ID Class . . . . . . . . . . . . . . . . . . . . . 70 175 A.5 SCOPING Class . . . . . . . . . . . . . . . . . . . . . . 71 176 A.6 ERROR_SPEC Class . . . . . . . . . . . . . . . . . . . . . 71 177 A.7 POLICY_DATA Class . . . . . . . . . . . . . . . . . . . . 72 178 A.7.1 Base Format . . . . . . . . . . . . . . . . . . . . . 73 179 A.7.2 Options . . . . . . . . . . . . . . . . . . . . . . . 73 180 A.7.3 Policy Elements . . . . . . . . . . . . . . . . . . . 74 181 A.8 QSPEC Class . . . . . . . . . . . . . . . . . . . . . . . 76 182 Intellectual Property and Copyright Statements . . . . . . . . 77 184 1. Introduction 186 1.1 Scope and background 188 This document defines a Quality of Service (QoS) NSIS Signaling Layer 189 Protocol (NSLP), henceforth referred to as the "QoS-NSLP". This 190 protocol establishes and maintains state at nodes along the path of a 191 data flow for the purpose of providing some forwarding resources for 192 that flow. It is intended to satisfy the QoS-related requirements of 193 [14]. This QoS-NSLP is part of a larger suite of signaling 194 protocols, whose structure is outlined in [15]; this defines a common 195 NSIS Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out 196 many aspects of signaling message delivery. The specification of the 197 NTLP is done in another document [3]. 199 The design of QoS-NSLP is conceptually similar to RSVP [5], and uses 200 soft-state peer-to-peer refresh messages as the primary state 201 management mechanism (i.e. state installation/refresh is performed 202 between pairs of adjacent NSLP nodes, rather than in an end-to-end 203 fashion along the complete signalling path). Although there is no 204 backwards compatibility at the level of protocol messages, 205 interworking with RSVP at a signaling application gateway would be 206 possible in some circumstances. QoS-NSLP extends the set of 207 reservation mechanisms to meet the requirements of [14], in 208 particular support of sender or receiver-initiated reservations, as 209 well as a type of bi-directional reservation and support of 210 reservations between arbitrary nodes, e.g. edge-to-edge, 211 end-to-access, etc. On the other hand, there is no support for IP 212 multicast. 214 QoS-NSLP does not mandate any specific 'QoS Model', i.e. a 215 particular QoS provisioning method or QoS architecture; this is 216 similar to (but stronger than) the decoupling between RSVP and the 217 IntServ architecture [4]. It should be able to carry information for 218 various QoS models; the specification of Integrated Services for use 219 with RSVP given in [6] could form the basis of one QoS model. 221 1.2 Model of operation 223 This section presents a logical model for the operation of the QoS- 224 NSLP and associated provisioning mechanisms within a single node. It 225 is adapted from the discussion in section 1 of [5]. The model is 226 shown in Figure 1. 228 +---------------+ 229 | Local | 230 |Applications or| 231 |Management (e.g| 232 |for aggregates)| 233 +---------------+ 234 ^ 235 ^ 236 V 237 V 238 +----------+ +----------+ +---------+ 239 | QoS-NSLP | | Resource | | Policy | 240 |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control | 241 +----------+ +----------+ +---------+ 242 . ^ | * ^ 243 | V . * ^ 244 +----------+ * ^ 245 | GIMPS | * ^ 246 |Processing| * V 247 +----------+ * V 248 | | * V 249 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 250 . . * V 251 | | * ............................. 252 . . * . Traffic Control . 253 | | * . +---------+. 254 . . * . |Admission|. 255 | | * . | Control |. 256 +----------+ +------------+ . +---------+. 257 <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> 258 | Packet | | Interface | .+----------+ +---------+. 259 ===>|Processing|====| Selection |===.| Packet |====| Packet |.==> 260 | | |(Forwarding)| .|Classifier| Scheduler|. 261 +----------+ +------------+ .+----------+ +---------+. 262 ............................. 263 <.-.-> = signaling flow 264 =====> = data flow (sender --> receiver) 265 <<<>>> = control and configuration operations 266 ****** = routing table manipulation 268 Figure 1: QoS-NSLP in a Node 270 This diagram shows an example implementation scenario where QoS 271 conditioning is performed on the output interface. However, this 272 does not limit the possible implementations. For example, in some 273 cases traffic conditioning may be performed on the incoming 274 interface, or it may be split over the input and output interfaces. 276 From the perspective of a single node, the request for QoS may result 277 from a local application request, or from processing an incoming QoS- 278 NSLP message. 279 o The 'local application case' includes not only user applications 280 (e.g. multimedia applications) but also network management (e.g. 281 initiating a tunnel to handle an aggregate, or interworking with 282 some other reservation protocol - such as RSVP) and the policy 283 control module (e.g. for explicit teardown triggered by AAA). In 284 this sense, the model does not distinguish between hosts and 285 routers. 286 o The 'incoming message' case requires NSIS messages to be captured 287 during input packet processing and handled by GIMPS. Only 288 messages related to QoS are passed to the QoS-NSLP. GIMPS may 289 also generate triggers to the QoS-NSLP (e.g. indications that a 290 route change has occurred). 292 The QoS request is handled by a local 'resource management' function, 293 which coordinates the activities required to grant and configure the 294 resource. 295 o The grant processing involves two local decision modules, 'policy 296 control' and 'admission control'. Policy control determines 297 whether the user has administrative permission to make the 298 reservation. Admission control determines whether the node has 299 sufficient available resources to supply the requested QoS. 300 o If both checks succeed, parameters are set in the packet 301 classifier and in the link layer interface (e.g., in the packet 302 scheduler) to obtain the desired QoS. Error notifications are 303 passed back to the request originator. The resource management 304 function may also manipulate the forwarding tables at this stage, 305 to select (or at least pin) a route; this must be done before 306 interface-dependent actions are carried out (including forwarding 307 outgoing messages over any new route), and is in any case 308 invisible to the operation of the protocol. 310 Policy control is expected to make use of a AAA service external to 311 the node itself. Some discussion can be found in [16] and [17]. 312 More generally, the processing of policy and resource management 313 functions may be outsourced to an external node leaving only 'stubs' 314 co-located with the NSLP; this is not visible to the protocol 315 operation, although it may have some influence on the detailed design 316 of protocol messages to allow the stub to be minimally complex. A 317 more detailed discussion on authentication and authorization can be 318 found in Section 4.8. The definition of the POLICY_DATA class is 319 given in Appendix A.7. 321 The group of user plane functions, which implement QoS for a flow 322 (admission control, packet classification, and scheduling) is 323 sometimes known as 'traffic control'. 325 Admission control, packet scheduling, and any part of policy control 326 beyond simple authentication have to be implemented using specific 327 definitions for types and levels of QoS; we refer to this as a QoS 328 model. Our assumption is that the QoS-NSLP is independent of the QoS 329 model, that is, QoS parameters (e.g. IntServ service elements) are 330 interpreted only by the resource management and associated functions, 331 and are opaque to the QoS-NSLP itself. QoS Models are discussed 332 further in Section 3.1. 334 The final stage of processing for a resource request is to indicate 335 to the QoS-NSLP protocol processing that the required resources have 336 been configured. The QoS-NSLP may generate an acknowledgement 337 message in one direction, and may propagate the resource request 338 forwards in the other. Message routing is (by default) carried out 339 by GIMPS module. Note that while Figure 1 shows a unidirectional 340 data flow, the signaling messages can pass in both directions through 341 the node, depending on the particular message and orientation of the 342 reservation. 344 2. Terminology 346 The terminology defined in [3] applies to this draft. In addition, 347 the following terms are used: 348 QNE: an NSIS Entity (NE), which supports the QoS-NSLP. 349 QNI: the first node in the sequence of QNEs that issues a reservation 350 request for a session. 351 QNR: the last node in the sequence of QNEs that receives a 352 reservation request for a session. 353 Source or message source: The one of two adjacent NSLP peers that is 354 sending a signalling message (maybe the upstream or the downstream 355 peer). NB: this is not necessarily the QNI. 357 QoS NSLP nodes 358 IP address (QoS unware NSIS nodes are IP address 359 = Flow not shown) = Flow 360 Source | | | Destination 361 Address | | | Address 362 V V V 363 +--------+ Data +------+ +------+ +------+ +--------+ 364 | Flow |-------|------|------|------|-------|------|---->| Flow | 365 | Sender | Flow | | | | | | |Receiver| 366 +--------+ | QNI | | QNE | | QNR | +--------+ 367 | | | | | | 368 +------+ +------+ +------+ 369 =====================> 370 <===================== 371 Signaling 372 Flow 374 3. Protocol Overview 376 The QoS NSLP uses four message types: RESERVE, QUERY, RESPONSE and 377 NOTIFY. These contain three types of objects: Control Information 378 (CI), QSpecs, and Policy objects. The set of objects permissible 379 depends on the message type. 381 An interface exists between the NSLP processing and GIMPS processing 382 for sending/receiving NSIS messages. In addition to the NSLP message 383 data itself, other meta-data (e.g. session identifier, flow routing 384 information) can be transferred across this interface. 386 Control information objects carry general information for the QoS 387 NSLP processing, such as sequence numbers or whether a response is 388 required. 390 QSpec objects describe the actual resources that are required and are 391 specific to the QoS Model being used. Besides any resource 392 description they may also contain QoS Model specific control 393 information used by the QoS Model's processing. 395 The Policy objects contain data used to authorise the reservation of 396 resources. 398 3.1 QoS Models 400 A QoS model is a defined mechanism for achieving QoS as a whole. The 401 specification of a QoS model includes a description of its QoS 402 parameter information, as well as how that information should be 403 treated or interpreted in the network. In that sense, the QoS model 404 goes beyond the QoS-NSLP protocol level in that it could also 405 describe underlying assumptions, conditions and/or specific 406 provisioning mechanisms appropriate for it. 408 A QoS model provides a specific set of parameters to be carried in 409 the QSpec, or restricts the values these parameters can take. 410 Integrated Services [4], Differentiated Services [8] and RMD [22] are 411 all examples that could provide the basis of an NSIS QoS model. 412 There is no restriction on the number of QoS models. QoS models may 413 be local (private to one network), implementation/vendor specific, or 414 global (implementable by different networks and vendors). The 415 authors are currently aware of three efforts related to QoS model 416 specification: [18], [19] and [20]. This specification will not 417 attempt to select between the moppling number of possible QoS models. 419 The QSpec contains a set of parameters and values describing the 420 requested resources. It is opaque to the QoS-NSLP and similar in 421 purpose to the TSpec, RSpec and AdSpec specified in [5][6]. At each 422 QNE, its content is interpreted by the resource management function 423 for the purposes of policy control and traffic control (including 424 admission control and configuration of the packet classifier and 425 scheduler). 427 3.2 GIMPS Interactions 429 The QoS NSLP uses GIMPS for delivery of all its messages. Messages 430 are normally passed from the NSLP to the GIMPS via an API, which also 431 specifies additional information, including an identifier for the 432 signaling application (e.g. 'QoS-NSLP'), the flow/session 433 identifier, and an indication of the intended direction - towards 434 data sender or receiver. On reception, GIMPS provides the same 435 information to the QoS-NSLP. 437 The QoS NSLP does not provide any method of interacting with 438 firewalls or Network Address Translators (NATs). It assumes that a 439 basic NAT traversal service is provided by the GIMPS. 441 3.3 Authentication and authorization 443 The QoS signaling protocol needs to exchange information which is 444 subsequently used as input to the AAA infrastructure. The response 445 from the AAA infrastructure must also returned and processed by the 446 respective entities. 448 +-------------+ 449 | Entity | 450 | authorizing | 451 | resource | 452 | request | 453 +-----+-------+ 454 | 455 | 456 /-\----+-----/\ 457 //// \\\\ 458 || || 459 | AAA Cloud | 460 || || 461 \\\\ //// 462 \-------+-----/ 463 | 464 +-------------+ QoS signaling +---+--+ 465 | Entity |<=================>| |<=========> 466 | requesting | Data Flow | QNE | 467 | resource |-------------------|------|----------> 468 +-------------+ +------+ 470 3.4 Aggregation 472 In some cases it is desirable to create reservations for an 473 aggregate, rather than on a per-flow basis, in order to reduce the 474 amount of reservation state needed as well as the processing load for 475 signalling messages. 477 The QoS NSLP, therefore, provides facilities to provide similar 478 aggregation facilities to [10]. However, the aggregation scenarios 479 supported are wider than that proposed there. Aggregate reservations 480 are further described in Section 4.3.3. 482 3.5 Examples of QoS NSLP Operation 484 The QoS NSLP can be used in a number ways. The examples given here 485 give an indication of some of the basic processing. However, they 486 are not exhaustive and do not attempt to cover the details of the 487 protocol processing. 489 3.5.1 Simple Resource Reservation 491 NI NF NF NR 492 | | | | 493 | RESERVE | | | 494 +--------->| | | 495 | | RESERVE | | 496 | +--------->| | 497 | | | RESERVE | 498 | | +--------->| 499 | | | | 500 | | | RESPONSE | 501 | | |<---------+ 502 | | RESPONSE | | 503 | |<---------+ | 504 | RESPONSE | | | 505 |<---------+ | | 506 | | | | 507 | | | | 509 Figure 4: Basic Sender Initiated Reservation 511 To make a new reservation, the QNI constructs a RESERVE message 512 containing a QSpec object, from its chosen QoS model, which describes 513 the required QoS parameters. 515 The RESERVE message is passed to GIMPS which transports it to the 516 next QoS NSLP node. There it is delivered to the QoS NSLP processing 517 which examines the message. Policy control and admission control 518 decisions are made. The exact processing also takes into account the 519 QoS Model being used. The node performs appropriate actions (e.g. 520 installing reservation) based on the QSpec object in the message. 522 The QoS NSLP then generates a new RESERVE message (usually based on 523 the one received). This is passed to the GIMPS, which forwards it to 524 the next QNE. 526 The same processing is performed at further QNEs along the path, up 527 to the QNR. The determination that a node is the QNR may be made 528 directly (e.g. that node is the destination for the data flow), or 529 using some GIMPS functionality to determine that there are no more 530 QNEs between this node and the data flow destination. 532 Any node may include a request for a RESPONSE in its RESERVE 533 messages. One such use is to confirm the installation of state, 534 which allows the use of summary refreshes that later refer to that 535 state. The RESPONSE is forwarded peer-to-peer along the reverse of 536 the path that the RESERVE message took (using GIMPS path state), and 537 so is seen by all the QNEs on the reverse-path. It is only forwarded 538 as far as the node which requested the RESPONSE. A RESPONSE message 539 can also indicate an error when, for example, a reservation has 540 failed to be installed. 542 The reservation can subsquently be refreshed by sending further 543 RESERVE messages containing the complete reservation information, as 544 for the initial reservation. The reservation can also be modified in 545 the same way, by changing the QoS model specific data to indicate a 546 different set of resources to reserve. 548 The overhead required to perform refreshes can be reduced, in a 549 similar way to that proposed for RSVP in [9]. Once a RESPONSE 550 message has been received indicating the successful installation of a 551 reservation, subsequent refreshing RESERVE messages can simply refer 552 to the existing reservation, rather than including the complete 553 reservation specification. 555 3.5.2 Sending a Query 557 QUERY messages can be used to gather information from QNEs along to 558 path. For example, it can be used to find out what resources are 559 available before a reservation is made. 561 In order to perform a query along a path, the QNE constructs a QUERY 562 message. This message includes QoS model specific objects containing 563 the actual query to be performed at QoS NSLP nodes along the path. 564 It also contains an object used to match the response back to the 565 query, and an indicator of the query scope (next node, whole path). 567 The QUERY message is passed to GIMPS to forward it along the path. 569 A QNE (including the QNR) receiving a QUERY message should inspect it 570 and create a new message, based on that received with the query 571 objects modified as required. For example, the query may request 572 information on whether a flow can be admitted, and so a node 573 processing the query might record the available bandwidth. The new 574 message is then passed to GIMPS for further forwarding (unless it 575 knows it is the QNR, or is the limit for the scope in the QUERY). 577 At the QNR, a RESPONSE message must be generated if the QUERY 578 includes a RESPONSE_REQUEST object. Into this is copied various 579 objects from the received QUERY message. It is then passed to GIMPS 580 to be forwarded peer-to-peer back along the path. 582 Each QNE receiving the RESPONSE message should inspect the 583 RESPONSE_REQUEST object to see if it 'belongs' to it (i.e. it was 584 the one that originally created it). If it does not then it simply 585 passes the message back to GIMPS to be forwarded back down the path. 587 3.5.3 Basic Receiver Initiated Reservation 589 As described in [15] in some signaling applications, a node at one 590 end of the data flow takes responsibility for requesting special 591 treatment - such as a resource reservation - from the network. Both 592 ends then agree whether sender or receiver initiated reservation is 593 to be done. In case of a receiver initiated reservation, both ends 594 agree whether a "One Pass With Advertising" (OPWA) [23] model is 595 being used. This negotiation can be accomplished using mechanisms 596 that are outside the scope of NSIS, see Section 9.7. 598 To make a receiver initiated reservation, see Figure 5, the QNI 599 constructs a QUERY message containing a QSpec object, from its chosen 600 QoS model, which describes, among others, the required QoS 601 parameters. This QUERY message does not need to trigger a RESPONSE 602 message and therefore, the QNI must not include the RESPONSE_REQUEST 603 object, see Section 5.4.2, into the QUERY message. The QUERY message 604 may be used to to gather information along the path, which is carried 605 by the QSPEC object. An example of such information is the "One Pass 606 With Advertising" (OPWA) [23]. This QUERY message is instructing the 607 QoS-NSLP process running on each QNE's located on the path followed 608 by this QUERY message to install GIMPS reverse-path state. 610 NI NF NF NR 611 | | | | 612 | QUERY | | | 613 +--------->| | | 614 | | QUERY | | 615 | +--------->| | 616 | | | QUERY | 617 | | +--------->| 618 | | | | 619 | | | RESERVE | 620 | | |<---------+ 621 | | RESERVE | | 622 | |<---------+ | 623 | RESERVE | | | 624 |<---------+ | | 625 | | | | 626 | RESPONSE | | | 627 +--------->| | | 628 | | RESPONSE | | 629 | +--------->| | 630 | | | RESPONSE | 631 | | +--------->| 632 | | | | 634 Figure 5: Basic Receiver Initiated Reservation 636 The QUERY message is transported by the NTLP to the next downstream 637 QoS NSLP node. There it is delivered to the QoS NSLP processing 638 which examines the message. The exact processing also takes into 639 account the QoS Model being used. The node performs appropriate 640 actions, such as installing GIMPS reverse path state. Another action 641 that may be performed by the node is to gather advertising 642 information that may be used to predict the end-to-end QoS. 644 The QoS NSLP then generates a new QUERY message (usually based on the 645 one received). This is passed to the NTLP, which forwards it to the 646 next QNE. The same processing is performed at further QNEs along the 647 path, up to the receiver, which in this situation is the QNR. The 648 QNR detects that this QUERY message does not carry a RESPONSE_REQUEST 649 object and by using the information contained in the received QUERY 650 message, such as the QSPEC, constructs a RESERVE message, which can 651 be used as a reservation request. 653 The RESERVE message must follow the same path that has been followed 654 by the QUERY message. Therefore, the NTLP is informed, over the 655 NSLP/NTLP API, to pass the message upstream, i.e., by setting the 656 GIMPS "D" flag, see [3]. 658 The RESERVE is forwarded peer-to-peer along the reverse of the path 659 that the QUERY message took (using the NTLP reverse path state). It 660 is only forwarded as far as the QNI. The RESERVE message received by 661 a QNE is delivered to the QoS-NSLP processing, which examines the 662 message. The NTLP includes the value of the 'D' flag in the 663 information it passes with the message over the NTLP/NSLP API 664 (Section 7.10). The exact processing of this message is accomplished 665 in the same way as for the processing of a RESERVE message received 666 by a QNE in a sender initiated approach. The main difference is that 667 the RESERVE message has to be forwarded peer-to-peer along the 668 reverse of the path that the QUERY message took. Therefore, the 669 QoS-NSLP functionality of each QNE requires the NTLP, over the NSLP/ 670 NTLP API, to pass the message upstream, i.e.,by setting the GIMPS "D" 671 flag. 673 Similar to the sender initiated approach, any node may include a 674 request for a RESPONSE in its RESERVE messages. The RESPONSE is 675 forwarded peer-to-peer along the path that the initial QUERY message 676 took (using NTLP path state). It is only forwarded as far as the 677 node which requested the RESPONSE. Note that the use of RESPONSE is 678 optional. 680 The reservation can subsquently be refreshed in the same was as for 681 the refresh procedure of a reservation in a sender initiated 682 approach, by sending further RESERVE messages containing the complete 683 reservation information, as for the initial reservation. This 684 RESERVE message may be also used to refresh the NTLP reverse path 685 state. Additionally, refreshing the NTLP reverse path state could be 686 performed by sending periodic QUERY messages. However, it might 687 potentially also be done by the NTLP, without needing any downstream 688 NSLP messages. This is an open issue (see Section 9.6), and it will 689 be worked out in a future version of this draft. 691 3.5.4 Bidirectional Reservations 693 A bi-directional reservation combines the reservations for a pair of 694 coupled flows going in opposite directions. The main difficulty here 695 is that the two flows, although between the same end points, may 696 traverse different paths across the Internet. 698 We distinguish two types of bi-directional reservations: 699 o sender+sender: where a sender-initiated reservation is done in one 700 direction, e.g., from QNE A towards QNE B, and then another 701 sender-initiated reservation that is done back, the opposite 702 direction, i.e., from QNE B towards QNE A, 703 o sender+receiver: where a sender-initiated reservation is done in 704 one direction, e.g., from QNE A towards QNE B, and a 705 receiver-initiated reservation that is done for the opposite 706 direction, i.e., a reservation from QNE A towards QNE B for the 707 data flow from QNE B to QNE A. 709 Both ends have to agree on which bi-directional reservation type they 710 need to use. This negotiation/agreement can be accomplished using 711 mechanisms that are outside the scope of NSIS, see Section 9.7. 713 In the sender+sender bi-directional reservation scenario (see Figure 714 6) the QNI, i.e., QNE A, generates a sender initiated reservation by 715 creating and sending a RESERVE message towards the QNR, i.e., QNE B. 717 When performing this type of bi-directional reservation, there are 718 situations where the QNR, i.e., QNE B, is not able to retrieve the 719 QoS parameter set required to perform a reservation in the downstream 720 direction from QNE B to QNE A, while the QNI, i.e., QNE A, is able to 721 retrieve and maintain the Qos parameter sets required to perform the 722 reservation in both downstream directions. In these situations there 723 is a need to carry both QoS parameter sets in QoS-NSLP messages from 724 the QNI, i.e., QNE A, to the QNR, i.e., QNE B. 726 The RESERVE is passed to the NTLP, which forwards it to the next QNE. 727 The same processing is performed at further QNEs along the path, up 728 to the receiver, which in this situation is the QNR, i.e., QNE B. 729 Considering that the QNE B, knows that it has to start a 730 sender-initiated reservation, the QNE B creates and sends a RESERVE 731 message downstream towards the QNE A. This RESERVE message carries 732 among others the QoS parameter set required to perform the sender 733 initiated reservation in the downstream direction from QNE B to QNE 734 A. Furthermore, the QNI, (i.e., QNE A), and QNR, (i.e., QNE B), 735 might be willing to bind the two sessions. In this situation the 736 QoS-NSLP messages that are used in the direction from QNE B to QNE A, 737 may carry information that identifies the two bound sessions. This 738 can be accomplished by using the BOUND_SESSION_ID object. 740 Note that any node may generate RESPONSE messages as answer to the 741 received RESERVE messages, but this is optional. 743 A NF1 NF2 NF3 NF4 B 744 | RESERVE | | | | | 745 +--------->|RESERVE | | | | 746 | +-------------------->| RESERVE | | 747 | | | +-------------------->| 748 | | | | | RESERVE | 749 | | | RESERVE | |<---------| 750 | RESERVE | |<--------------------| | 751 |<--------------------| | | | 752 | | | | | | 754 Figure 6: Bi-directional reservation for sender+sender scenario 756 In the sender+receiver bi-directional reservation scenario (see 757 Figure 7) the QNI, i.e., QNE A, generates both a sender initiated and 758 a receiver-initiated reservation. Note that before that the QNI, 759 i.e., QNE A, is starting this procedure it must receive a QUERY 760 message from the QNR, i.e., QNE B, that requires from the QNI a 761 receiver initiated reservation, see Section 3.5.3. Note that the 762 QUERY message is carrying the QSPEC that can be used by the receiver 763 initiated reservation. 765 The QNI, i.e., QNE A, creates two RESERVE messages. One RESERVE 766 message that is used for the sender initiated reservation (session 767 A->B), see Section [(reference to the sender initiated section)] and 768 another RESERVE message that is used for the receiver initiated 769 reservation (session B->A), see Section 3.5.3. Furthermore, the 770 QNI, (i.e., QNE A), and QNR, (i.e., QNE B), might be willing to bind 771 the two sessions. In this situation the QoS-NSLP messages that are 772 used in the bi-directional scenario may carry information that 773 identifies the two bound sessions. This can be accomplished by using 774 the BOUND_SESSION_ID object. When these two RESERVE messages follow 775 exactly the same path, then it should be possible that these two 776 RESERVE messages are bundled at the NTLP level, by using the GIMPS 777 message bundling feature. 779 Note that any node may generate RESPONSE messages as answer to the 780 received RESERVE messages, but this is optional. 782 A NF1 NF2 B 783 | | | QUERY | 784 | | QUERY |<--------------------| 785 | QUERY |<--------------------| | 786 |<---------+ | | 787 | RESERVE | | | 788 +--------->|RESERVE | | 789 | +-------------------->| RESERVE | 790 | | +-------------------->| 791 | RESERVE | | | 792 +--------->|RESERVE | | 793 | +-------------------->| RESERVE | 794 | | +-------------------->| 795 | | | | 797 Figure 7: Bi-directional reservation for sender+receiver scenario 799 3.5.5 Use of Local QoS Models 801 In some cases it may be required to use a different QoS Model along a 802 particular segment of the signalling. In this case a node at the 803 edge of this region needs to map between the two resource 804 descriptions (and any auxiliary data). 806 | | | | | 807 | RESERVE | | | | 808 | {QSpec1} | | | | 809 +-------------->| | | | 810 | | RESERVE | | | 811 | |{QSpec2,QSpec1}| | | 812 | +-------------->| | | 813 | | | RESERVE | | 814 | | |{QSpec2,QSpec1}| | 815 | | +-------------->| | 816 | | | | RESERVE | 817 | | | | {QSpec1} | 818 | | | +-------------->| 819 | | | | | 821 Figure 8: Reservation with local QoS Models 823 This initially proceeds as for the basic example, with peer-to-peer 824 installation of reservations. However, within a region of the 825 network a different QoS Model needs to be used. At the edge of this 826 region the QNEs support both the end-to-end and local QoS models. 828 When the RESERVE message reaches the QNE at the ingress, the initial 829 processing of the RESERVE proceeds as normal. However, the QNE also 830 determines the appropriate description using the second QoS model. 831 The RESERVE message to be sent out is constructed mostly as usual but 832 with a second QSpec object added, which becomes the 'current' one. 834 When this RESERVE message is received at the next node the QoS NSLP 835 only uses the QSpec at the top of the stack (i.e. the 'current' 836 one), rather than the end-to-end QSpec. Otherwise, processing 837 proceeds as usual. The RESERVE message that it generates should 838 include the complete stack of QSpecs from the message it received. 840 At the QNE at the egress of the region the local QSpec is removed 841 from the message so that subsequent QNEs receive only the end-to-end 842 QSpec. 844 QSpecs can be stacked in this way to an arbitrary depth. 846 3.5.6 Aggregate Reservations 848 In order to reduce signalling and per-flow state in the network, the 849 reservations for a number of flows may be aggregated together. 851 NI NF NF/NI' NF' NR'/NF NR 852 aggregator deaggregator 853 | | | | | | 854 | RESERVE | | | | | 855 +--------->| | | | | 856 | | RESERVE | | | | 857 | +--------->| | | | 858 | | | RESERVE | | | 859 | | +-------------------->| | 860 | | | RESERVE' | | | 861 | | +=========>| RESERVE' | | 862 | | | +=========>| RESERVE | 863 | | | | +--------->| 864 | | | | RESPONSE'| | 865 | | | RESPONSE'|<=========+ | 866 | | |<=========+ | | 867 | | | | | RESPONSE | 868 | | | | RESPONSE |<---------+ 869 | | |<--------------------+ | 870 | | RESPONSE | | | | 871 | |<---------+ | | | 872 | RESPONSE | | | | | 873 |<---------+ | | | | 874 | | | | | | 875 | | | | | | 877 Figure 9: Sender Initiated Reservation with Aggregation 879 An end-to-end per-flow reservation is initiated as normal (with 880 messages shown in Figure 9 as "RESERVE"). 882 At the aggregator a reservation for the aggregated flow is initiated 883 (shown in Figure 9 as "RESERVE'"). This may use the same QoS model 884 as the end-to-end reservation but has a flow identifier for the 885 aggregated flow (e.g. tunnel) instead of for the individual flows. 887 Markings are used so that intermediate routers do not need to inspect 888 the individual flow reservations. The deaggregator then becomes the 889 next hop QoS NSLP node for the end-to-end per-flow reservation. 891 Aggregator Deaggregator 893 +---+ +---+ +---+ +---+ 894 |QNI|-----|QNE|-----|QNE|-----|QNR| aggregate 895 +---+ +---+ +---+ +---+ reservation 897 +---+ +---+ ..... ..... +---+ +---+ 898 |QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end 899 +---+ +---+ ..... ..... +---+ +---+ reservation 901 The deaggregator acts as the QNR for the aggregate reservation. 903 Information is carried in the reservations to enable the deaggregator 904 to associate the end-to-end and aggregate reservations with one 905 another. For example, this is necessary so that the size of the 906 aggregate reservation can be reduced when the end-to-end reservation 907 is removed. 909 The key difference between this example, and previous ones is that 910 the flow identifier for the aggregate is expected to be different to 911 that for the end-to-end reservation. The aggregate reservation can 912 be updated independently of the per-flow end-to-end reservations. 914 3.5.7 Reduced State or Stateless Interior Nodes 916 This example uses a different QoS model within a domain, in 917 conjunction with GIMPS and NSLP functionality which allows the 918 interior nodes to avoid storing GIMPS and QoS NSLP state. As a 919 result the interior nodes only store the QoS model specific 920 reservation state, or even no state at all. This allows the QoS 921 model to use a form of "reduced-state" operation, where reservation 922 states with a coarser granularity (e.g. per-class) are used, or a 923 "stateless" operation where no reservation state is needed (or 924 created). 926 The key difference between this example and the use of different QoS 927 Models in Section 3.5.5 is that the transport characteristics for the 928 'local' reservation can be different from that of the end-to-end 929 reservation, i.e. GIMPS can be used in a different way for the 930 edge-to-edge and hop-by-hop sessions. The reduced state reservation 931 can be updated independently of the per-flow end-to-end reservations. 933 NF NF NF NF 934 ingress interior interior egress 935 GIMPS stateful GIMPS stateless GIMPS stateless GIMPS stateful 936 | | | | 937 RESERVE | | | | 938 -------->| RESERVE | | | 939 +--------------------------------------------->| 940 | RESERVE' | | | 941 +-------------->| | | 942 | | RESERVE' | | 943 | +-------------->| | 944 | | | RESERVE' | 945 | | +------------->| 946 | | | | RESERVE 947 | | | +--------> 948 | | | | RESPONSE 949 | | | |<-------- 950 | | | RESPONSE | 951 |<---------------------------------------------+ 952 RESPONSE| | | | 953 <--------| | | | 955 Figure 11: Reservation with Reduced State Interior Nodes 957 The QNI performs the same processing as before to generate the 958 initial RESERVE message, and it is forwarded by GIMPS as usual. At 959 the QNEs at the edges of the stateless or reduced-state region the 960 processing is different and the nodes support two QoS models. 962 At the ingress the original RESERVE message is forwarded but ignored 963 by the stateless or reduced-state nodes. The egress node is the next 964 QoS NSLP hop for that session. After the initial discovery phase 965 using datagram mode, connection mode between the ingress and egress 966 can be used. At the egress node the RESERVE message is then 967 forwarded normally. 969 At the ingress a second RESERVE' message is also built. This makes 970 use of a QoS model suitable for a reduced state or stateless form of 971 operation (such as the RMD per hop reservation). When processed by 972 interior (stateless) nodes the QoS NSLP processing excercises its 973 options to not keep state wherever possible, so that no per flow QoS 974 NSLP state is stored. Some state, e.g. per class, for the QoS model 975 related data may be held at these interior nodes. The QoS NSLP also 976 requests that GIMPS use different transport characteristics (i.e. 977 sending of messages in datagram mode, and not retaining optional 978 reverse path state). 980 Nodes, such as those in the interior of the stateless or 981 reduced-state domain, that do not retain reservation state cannot 982 send back RESPONSE messages (and so cannot use summary refreshes). 984 At the egress node the RESERVE' message is interpreted in conjunction 985 with the reservation state from the end-to-end RESERVE message (using 986 information carried in the message to correlate the signalling 987 flows). The RESERVE message is only forwarded further if the 988 processing of the RESERVE' message was successful at all nodes in the 989 local domain, otherwise the end-to-end reservation is regarded as 990 having failed to be installed. 992 Since GIMPS neighbour relations are not maintained in the 993 reduced-state region, only sender initiated signalling can be 994 supported. If a bi-directional reservation is required then the 995 end-to-end QoS model must provide an object that requests the last 996 node to generate a sender initiated session in the reverse direction. 998 3.6 Authorization Model Examples 1000 Various authorization models can be used in conjunction with the QoS 1001 NSLP. 1003 3.6.1 Authorization for the two party approach 1005 The two party approach is conceptually the simplest authorization 1006 model. 1008 +-------------+ QoS request +--------------+ 1009 | Entity |----------------->| Entity | 1010 | requesting | | authorizing | 1011 | resource |granted / rejected| resource | 1012 | |<-----------------| request | 1013 +-------------+ +--------------+ 1014 ^ ^ 1015 +...........................+ 1016 financial establishment 1018 Figure 12: Two party approach 1020 In this example the the authorization decision only involves the two 1021 entities, or makes use of previous authorisation using an out-of-band 1022 mechanism to avoid the need for active participation of an external 1023 entity during the NSIS protocol execution. 1025 This type of model may be applicable, for example, between two 1026 neighboring networks (inter-domain signaling) where a long-term 1027 contract (or other out-of-band mechanisms) exist to manage charging 1028 and provide sufficient information to authorize individual requests. 1030 3.6.2 Token based three party approach 1032 An alternative approach makes use of authorization tokens, such as 1033 those described in [11] and [12] or used as part of the Open 1034 Settlement protocol [27]. The former ('authorization tokens') are 1035 used to associate two different signaling protocols (i.e. SIP and 1036 NSIS) and their authorization with each other whereas the latter is a 1037 form of digital money. As an example, with the authorization token 1038 mechanism, some form of authorization is provided by the SIP proxy, 1039 which acts as the resource authorizing entity in Figure 13. If the 1040 request is authorized, then the SIP signaling returns an 1041 authorization token which can be included in the QoS signaling 1042 protocol messages to refer to the previous authorization decision. 1043 The tokens themselves may take a number of different forms, some of 1044 which may require the entity performing the QoS reservation to query 1045 external state. 1047 Authorization 1048 Token Request +--------------+ 1049 +-------------->| Entity C | financial settlement 1050 | | authorizing | <..................+ 1051 | | resource | . 1052 | +------+ request | . 1053 | | +--------------+ . 1054 | | . 1055 | |Authorization . 1056 | |Token . 1057 | | . 1058 | | . 1059 | | . 1060 | | QoS request . 1061 +-------------+ + Authz. Token +--------------+ . 1062 | Entity |----------------->| Entity B | . 1063 | requesting | | performing | . 1064 | resource |granted / rejected| QoS | <..+ 1065 | A |<-----------------| reservation | 1066 +-------------+ +--------------+ 1068 Figure 13: Token based three party approach 1070 For the digital money type of systems (e.g. OSP tokens), the token 1071 represents a limited amount of credit. So, new tokens must be sent 1072 with later refresh messages once the credit is exhausted. 1074 3.6.3 Generic three party approach 1076 Another method is for the node performing the QoS reservation to 1077 delegate the authorization decision to a third party, as illustrated 1078 in Figure 14. 1080 +--------------+ 1081 | Entity C | 1082 | authorizing | 1083 | resource | 1084 | request | 1085 +-----------+--+ 1086 ^ | 1087 | | 1088 QoS | | QoS 1089 authz| |authz 1090 req.| | res. 1091 | | 1092 QoS | v 1093 +-------------+ request +--+-----------+ 1094 | Entity |----------------->| Entity B | 1095 | requesting | | performing | 1096 | resource |granted / rejected| QoS | 1097 | A |<-----------------| reservation | 1098 +-------------+ +--------------+ 1100 Figure 14: Three party approach 1102 Authorization may be performed on a per-request basis, periodically, 1103 or on a per-session basis. The authorization request might make use 1104 of EAP authentication between entities A and C, and a subsequent 1105 protocol exchange between A and B to create a secure channel for 1106 further communications. Such a technique gives flexibility in terms 1107 of the authentication and key exchange protocols used. 1109 A further extension to this model is to allow Entity C to reference a 1110 AAA server in the user's home network when making the authorization 1111 decision. 1113 4. Design decisions 1115 4.1 Message types 1117 The QoS-NSLP specifies four message types: RESERVE, QUERY, RESPONSE 1118 and NOTIFY. 1120 The fundamental properties of each message determine how it is 1121 analyzed from the perspective of re-ordering, loss, end-to-end 1122 reliability and so on. It is important for applications to know 1123 whether NSLP messages can be repeated, discarded or merged and so on 1124 (e.g. for edge mobility support, rerouting, etc). Indeed, the 1125 ordering of messages that do not manipulate state at QNEs does not 1126 matter, whereas the way that messages that manipulate state are 1127 interleaved matters very much. Therefore NSLP is designed such that 1128 the message type identifies whether a message is manipulating state 1129 (in which case it is idempotent) or not (it is impotent). 1131 4.1.1 RESERVE 1133 The RESERVE message is the only message that manipulates QoS 1134 reservation state. It is used to create, refresh, modify and remove 1135 such state. The common message header contains a TEAR flag that 1136 indicates complete QoS NSLP state removal (as opposed to a 1137 reservation of zero resources). This QoS NSLP state comprises 1138 reservation state and QoS NSLP operation state. The QoS NSLP 1139 indicates to GIMPS that it is no longer interested in the 1140 corresponding GIMPS state. The GIMPS then autonomously decides 1141 whether or not to keep this state. 1143 The RESERVE message opaquely transports one or more QSPEC objects, 1144 describing the desired service level and a POLICY_DATA object, 1145 authorizing the requestor of the service. It carries the lifetime of 1146 the reservation in the Common Control Information. 1148 RESERVE messages are sent peer-to-peer. This means that a QNE 1149 considers its adjacent upstream or downstream peer to be the source 1150 of the RESERVE message. 1152 The RESERVE message is idempotent; the resultant effect is the same 1153 whether a message is received once or many times. In addition, the 1154 ordering of RESERVE messages matters - an old RESERVE message should 1155 not replace a newer one. Both of these features are required for 1156 protocol robustness - messages may be re-ordered on route (e.g. 1157 because of mobility, or at intermediate GIMPS nodes) or spuriously 1158 retransmitted. Handling of message re-ordering is supported by the 1159 inclusion of the Reservation Sequence Number (RSN) in the RESERVE 1160 message. 1162 The sender of a RESERVE message may want to receive confirmation of 1163 successful state installation from a downstream node. Therefore, a 1164 RESERVE message optionally contains a RESPONSE_REQUEST object 1165 (Section 4.2.2). 1167 4.1.2 QUERY 1169 A QUERY message is used to request information about the data path 1170 without making a reservation. This functionality can be used to 1171 'probe' the network for path characteristics or for support of 1172 certain QoS models. The information obtained from a QUERY may be 1173 used in the admission control process of a QNE (e.g. in case of 1174 measurement-based admission control). Note that a QUERY does not 1175 change existing reservation state, nor does it cause state to be 1176 installed in nodes other than the one that generated the QUERY. 1178 A QUERY message contains one or more QSPEC objects and a POLICY_DATA 1179 object. The QSPEC object describes what is being queried for and may 1180 contain objects that gather information along the data path. The 1181 POLICY_DATA object authorizes the requestor of the QUERY message. 1183 A QUERY message may be scoped if a RESPONSE message from some other 1184 node than the QNR is desired. 1186 A QUERY message may contain a RESPONSE_REQUEST object (Section 1187 4.2.2), the contents of which allow matching back RESPONSE messages 1188 to the QUERY request. The RESPONSE_REQUEST object is transported 1189 unchanged along the data path and may be used to scope the RESPONSE 1190 to a QUERY message (Section 4.2.3). 1192 4.1.3 RESPONSE 1194 The REPONSE message is used to provide information about the result 1195 of a previous QoS-NSLP message. This includes explicit confirmation 1196 of the state manipulation signaled in the RESERVE message, the 1197 response to a QUERY message or an error code if the QNE or QNR is 1198 unable to provide the requested information or if the response is 1199 negative. For this purpose, the RESPONSE message carries one or more 1200 QSPEC objects. 1202 The RESPONSE message is impotent, it does not cause any reservation 1203 state to be installed or modified. 1205 4.1.4 NOTIFY 1207 NOTIFY messages are used to convey information to a QNE. NOTIFY 1208 messages are impotent (they do not cause a change in state directly). 1209 They may carry one or more QSPEC objects. An example use of NOTIFY 1210 would be to indicate when a reservation has been pre-empted. 1212 NOTIFY messages differ from RESPONSE messages in that they need not 1213 refer to any particular state or previously received message. They 1214 are sent asynchronously. The NOTIFY message itself does not trigger 1215 or mandate any action in the receiving QNE. 1217 The information conveyed by a NOTIFY message is typically related to 1218 error conditions. One example would be notification to an upstream 1219 peer about state being torn down. 1221 4.2 Control information 1223 Control information conveys information on how specific messages 1224 should be handled by a QNE, e.g. sequencing of messages. This may 1225 include some mechanisms that are useful for many QoS models (Common 1226 Control Information) and some that are for a particular QoS model 1227 only (QoS-model specific Control Information). QoS-model specific 1228 Control Information is specified together with a QoS model. This 1229 specification only defines Common Control Information. Currently, 1230 Common Control Information is defined for session identification, 1231 message sequencing, response request, message scoping and session 1232 lifetime. 1234 4.2.1 Message sequencing 1236 RESERVE messages affect the installed reservation state. Unlike 1237 NOTIFY, QUERY and RESPONSE messages, the order in which RESERVE 1238 messages are received influences the eventual reservation state that 1239 will be stored at a QNE. Therefore, a QNE may need to detect 1240 re-ordered or duplicated RESERVE messages. 1242 Detection of RESERVE message re-ordering or duplication is supported 1243 by the Reservation Sequence Number (RSN). The RSN is a counter, 1244 locally chosen to be unique (on a hop-by-hop basis) within a session. 1245 The RSN has local significance only, i.e. between QNEs. Attempting 1246 to make an identifier that was unique in the context of a SESSION_ID 1247 but the same along the complete path would be very hard. Since 1248 RESERVE messages can be sent by any node on the path that maintains 1249 reservation state (e.g. for path repair) we would have the difficult 1250 task of attempting to keep the identifier synchronized along the 1251 whole path. Since message ordering only ever matters between a pair 1252 of peer QNEs, this means that we can make the Reservation Sequence 1253 Number unique just between a pair of neighboring stateful QNEs. By 1254 managing the sequence numbers in this manner, the source of the 1255 RESERVE does not need to determine how the next NSLP node will 1256 process the message. 1258 The RSN refers to a particular instance of the RESERVE state. This 1259 allows explicit acknowledgment of state installation actions (by 1260 including the RSN in a RESPONSE). It also allows an abbreviated form 1261 of refreshing RESERVE message ("summary refresh"). In this case, the 1262 refreshing RESERVE references the reservation using the RSN (and the 1263 SESSION_ID), rather than including the full reservation specification 1264 (including QSPEC, ...). Note that summary refreshes require an 1265 explicit acknowledgment of state installation to ensure that the RSN 1266 reference will be understood. It is up to a QNE that receives a 1267 RESPONSE_REQUEST to decide whether it wants to accept summary 1268 refreshes and provide this explicit acknowledgment. 1270 4.2.2 Requesting responses 1272 Some QNEs may require explicit responses to messages they send. A 1273 QNE which sends a QUERY message (Section 4.1), for instance, will 1274 require a response with the requested information to be sent to it. 1275 A QNE which sends a RESERVE message may want explicit confirmation 1276 that the requested reservation state was installed. 1278 A QNE that desires an explicit response includes a RESPONSE_REQUEST 1279 object in its message. RESPONSE_REQUEST objects are used in RESERVE 1280 and QUERY messages. The RESPONSE_REQUEST object may be used in 1281 combination with message scoping (Section 4.2.3) to influence which 1282 QNE will respond. 1284 A message contains at most one RESPONSE_REQUEST object. The 1285 RESPONSE_REQUEST object contains Request Identification Information 1286 (RII) that is unique within a session and different for each message, 1287 in order to allow responses to be matched back to requests (without 1288 incorrectly matching at other nodes). Downstream nodes that desire 1289 responses may keep track of this RII to identify the RESPONSE when it 1290 passes back through them. 1292 A message containing a RESPONSE_REQUEST object causes a RESPONSE 1293 message to be sent back. The RESPONSE message contains the original 1294 RESPONSE_REQUEST object and may be scoped, e.g. using the RII 1295 (Section 4.2.3), to influence which (upstream) QNEs will receive the 1296 RESPONSE. 1298 4.2.3 Message scoping 1300 For some messages, QNEs may want to restrict message propagation. 1301 For a RESERVE message, this may be the case when state installation 1302 is required on part of the path towards the destination only. For a 1303 QUERY message, it allows limiting the nodes that can respond to the 1304 QUERY. For a RESPONSE message, it allows limiting the nodes that 1305 receive the RESPONSE. 1307 Message scoping is supported by a SCOPING object. Different scopes 1308 are supported. By default, no SCOPING object is present which 1309 indicates that the scope is either "whole path" or limited by 1310 configuration (and therefore not signalled). Other supported scopes 1311 are "single hop" and "back to me". The latter is supported by 1312 copying the RII from the RESPONSE_REQUEST object into the SCOPING 1313 object that is put in the RESPONSE message, so that its forwarding 1314 can be terminated by the node that requested the RESPONSE. 1316 This specification does not support an explicit notion of a region 1317 scope or "to the CRN". If needed, this can be easily proposed as an 1318 extension later on. 1320 4.2.4 State handling 1322 The default behaviour of a QNE that receives a RESERVE with a 1323 SESSION_ID for which it already has state installed but with a 1324 different flow ID is to replace the existing reservation (and tear 1325 down the reservation on the old branch if the RESERVE is received 1326 with a different SII). 1328 In some cases, this may not be the desired behaviour. In that case, 1329 the QNI or a QNE may set the NO_REPLACE flag in the common header to 1330 indicate that the new session does not replace the existing one. A 1331 QNE that receives a RESERVE with the NO_REPLACE flag set but with the 1332 same SII will update the flow ID and indicate NO_REPLACE to the RMF 1333 (where it will be used for the resource handling). If the SII is 1334 different, this means that the QNE is a merge point. In that case, 1335 the NO_REPLACE also indicates that a tearing RESERVE SHOULD NOT be 1336 sent on the old branch. 1338 At a QNE, resource handling is performed by the RMF. For sessions 1339 with the NO_REPLACE flag set, we assume that the QoS-model specific 1340 control information includes directions to deal with resource 1341 sharing. This may include, adding the reservations, or taking the 1342 maximum of the two or more complex mathematical operations. 1344 This resource handling mechanism in the QoS model is also applicable 1345 to sessions with different SESSION_ID but related through the 1346 BOUND_SESSION_ID object. Session replacement is not an issue here, 1347 but the QoS model may specify whether to let the sessions that are 1348 bound together share resources on common links or not. 1350 Finally, it is possible that a RESERVE is received with no QSPEC at 1351 all. This is the case of a summary refresh. In this case, rather 1352 than sending a refreshing RESERVE with the full QSPEC, only the 1353 SESSION_ID and the SII are sent to refresh the reservation. Note 1354 that this mechanism just reduces the message size (and probably eases 1355 processing). One RESERVE per session is still needed. The 1356 combination of different SESSION_IDs (and SIIs) in the same 1357 refreshing RESERVE message is currently an open issue. 1359 4.2.5 State timers 1361 The NSIS protocol suite takes a soft-state approach to state 1362 management. This means that reservation state in QNEs must be 1363 periodically refreshed. The frequency with which state installation 1364 is refreshed is expressed in the REFRESH_PERIOD object. This object 1365 contains a value in seconds indicating how long the state that is 1366 signalled for remains valid. Maintaining the reservation beyond this 1367 lifetime can be done by sending a ("refreshing") RESERVE message. 1369 The REFRESH_PERIOD has local significance only. At the expiration of 1370 a "refresh timeout" period, each QNE independently examines its state 1371 and sends a refreshing RESERVE message to the next QNE peer where it 1372 is absorbed. This peer-to-peer refreshing (as opposed to the QNI 1373 initiating a refresh which travels all the way to the QNR) allows 1374 QNEs to choose refresh intervals as appropriate for their 1375 environment. For example, it is conceivable that refreshing 1376 intervals in the backbone, where reservations are relatively stable, 1377 are much larger than in an access network. The "refresh timeout" is 1378 calculated within the QNE and is not part of the protocol; however, 1379 it must be chosen to be compatible with the reservation lifetime as 1380 expressed by the REFRESH_PERIOD, and an assessment of the reliability 1381 of message delivery. 1383 The details of timer management and timer changes (slew handling and 1384 so on) are given in Section 5. 1386 4.2.6 Session binding 1388 Session binding is defined as the enforcement of a relation between 1389 different QoS NSLP sessions (i.e. signalling flows with different 1390 SESSION_ID (SID) as defined in [3]). 1392 A relation between two sessions is indicated by including the 1393 BOUND_SESSION_ID object in the messages. A session with SID_A (the 1394 binding session) can express its relation to another session with 1395 SID_B (the bound session) by including a BOUND_SESSION_ID object 1396 containing SID_B in its messages. Note that the session with SID_B 1397 may or may not carry a BOUND_SESSION_ID object containing SID_A. 1399 Three examples where session binding can be used for aggregate 1400 reservation, bi-directional reservation and fate sharing are 1401 described below. 1403 Aggregated sessions may have a different flow ID from the end-to-end 1404 message. If the edge QNEs of the aggregation domain want to maintain 1405 some end-to-end properties, they may establish a peering relation by 1406 sending the end-to-end message transparantly over the domain. 1407 Updating the end-to-end properties in this message may require some 1408 knowledge of the aggregated session (e.g. for updating delay 1409 values). For this purpose, the end-to-end session contains a 1410 BOUND_SESSION_ID carrying the SESSION_ID of the aggregate session. 1412 Including the BOUND_SESSION_ID object in a session indicates a 1413 dependency relation. By default, a session that is bound to another 1414 session with the BOUND_SESSION_ID object shares fate with it. This 1415 means that if a bound session is torn down, every binding session 1416 should be torn down as well. The reverse is not true. If a binding 1417 session is torn down, the bound session and other binding sessions 1418 remain. A QNE that wants to prevent fate sharing sets a flag in the 1419 common header (NO_FATE_SHARING). 1421 Bi-directional reservations are a special case of fate sharing. In 1422 this case, a reservation in one direction only makes sense if the 1423 reservation in the reverse direction is also up. In some cases 1424 bi-directional reservations also allow local optimizations. 1425 Therefore, when a reverse reservation is set up, it should carry a 1426 BOUND_SESSION_ID containing the SESSION_ID of the forward direction. 1427 This SESSION_ID is copied from the sender-initiated (forward) RESERVE 1428 or from the QUERY message triggering the sender-initiated (reverse) 1429 RESERVE message. Alternatively, it can be inserted by the QNE that 1430 sets up both the sender-initiated RESERVE and the receiver-initiated 1431 RESERVE. 1433 4.3 Layering 1435 The QoS NSLP supports layered reservations. Layered reservations may 1436 occur when certain parts of the network (domains) implement one or 1437 more local QoS models, or when they locally apply specific control 1438 plane characteristics (e.g. datagram mode instead of connection 1439 mode). They may also occur when several per-flow reservations are 1440 locally combined into an aggregate reservation. 1442 4.3.1 Local QoS models 1444 Parameters of the QoS model that is being signalled for are carried 1445 in the QSPEC object. A domain may have local policies regarding QoS 1446 model implementation, i.e. it may map incoming traffic to its own 1447 locally defined QoS models. The QoS NSLP supports this by allowing 1448 QSPEC objects to be stacked. 1450 When a domain wants to apply a certain QoS model to an incoming 1451 per-flow reservation request, each edge of the domain is configured 1452 to map the incoming QSPEC object to a local QSPEC object and push 1453 that object onto the stack of QSPEC objects (typically immediately 1454 following the Common Control Information, i.e. the first QSPEC that 1455 is found in the message). QNEs inside the domain look at the top of 1456 the QSPEC object stack to determine which QoS model to apply for the 1457 reservation. 1459 The position of the local QSPEC object in the stack implies a 1460 tradeoff between the speed with which incoming messages can be 1461 processed and the time it takes to construct the outgoing message (if 1462 any). By mandating the locally valid object to be on top of the 1463 stack we value ease of processing over ease of message construction. 1465 A QNE that knows it is the last QNE to understand a local QSPEC 1466 object (e.g. by configuration of the egress QNEs of a domain) SHOULD 1467 remove the topmost QSPEC object from the stack. It SHOULD update the 1468 underlying QoS model parameters if needed. 1470 A QNE that receives a message with a QSPEC object stack of which the 1471 topmost object is not understood MUST NOT forward the message and 1472 MUST send an error indication to its upstream neighbour. It MUST NOT 1473 attempt local recovery by inspecting the stack for a QSPEC object it 1474 understands. 1476 4.3.2 Local control plane properties 1478 The way signalling messages are handled is mainly determined by the 1479 parameters that are sent over GIMPS-NSLP API and by the Common 1480 Control Information. A domain may have a policy to implement local 1481 control plane behaviour. It may, for instance, elect to use an 1482 unreliable transport locally in the domain while still keeping 1483 end-to-end reliability intact. 1485 The QoS NSLP supports this situation by allowing two sessions to be 1486 set up for the same reservation. The local session has the desired 1487 local control plane properties and is interpreted in internal QNEs. 1488 This solution poses two requirements: the end-to-end session must be 1489 able to bypass intermediate nodes and the egress QNE needs to bind 1490 both sessions together. 1492 The local session and the end-to-end session are bound at the egress 1493 QNE by means of the BOUND_SESSION_ID object. One approach could be 1494 that the end-to-end session carries the SESSION_ID of the local 1495 session in its session binding object. Another approach could be 1496 that the local session carries the SESSION_ID of the end-to-end 1497 session in its BOUND_SESSION_ID object. This allows the QNE that 1498 performs session binding to maintain end-to-end connection mode. 1500 4.3.3 Aggregate reservations 1502 For scalability reasons, a domain may want to combine two or more 1503 end-to-end reservations into a single local aggregate reservation. 1504 The domain over which the aggregation is done is limited by 1505 configuration. 1507 The essential difference with the layering approaches described in 1508 Section 4.3.1 and Section 4.3.2 is that the aggregate reservation 1509 needs a FlowID that describes all traffic carried in the aggregate 1510 (e.g. a DSCP in case of IntServ over DiffServ). 1512 The need for a different FlowID mandates the use of two different 1513 sessions, similar to Section 4.3.2 and to the RSVP aggregation 1514 solution [10]. In addition to the different FlowID, the aggregate 1515 session may specify a local QoS model and local control plane 1516 parameters as explained above. 1518 The aggregate reservation may or may not change source and 1519 destination IP addresses, i.e. either the end-to-end adresses may be 1520 used (if possible) or the IP address of ingress and egress of the 1521 domain may be used as source and destination IP address. In some 1522 cases, the latter option may cause data plane divergence between both 1523 sessions. RSVP solves this by using tunnelling between the edges of 1524 the domain. 1526 In any case, session binding and a solution for intermediate node 1527 bypass (as explained before) are required in this case as well. 1529 4.4 Extensibility 1531 The QoS NSLP specification foresees future specification of new error 1532 codes and new Common Control Information objects. Specification of 1533 new messages is not foreseen but not explicitly precluded. 1535 Specification of new error codes and Common Control Information 1536 objects is subject to IANA approval and assignment of ClassNum and 1537 CType. ClassNum and CType of currently existing objects and error 1538 codes are described in Section 6. New Common Control Information 1539 objects need to specify whether they are mandatory or optional to 1540 implement. Mandatory CCI that is not understood by a QNE needs to 1541 generate an error. Optional CCI that is not understood by a QNE 1542 needs to be passed transparantly. 1544 The QoS NSLP specification allows future QoS model specific 1545 extensions, including the definition of new QoS models, the 1546 specification of new objects for existing QoS models, the 1547 specification of new processing rules for new or existing objects and 1548 the specification of new QoS model specific error codes. 1550 Different types of QoS models are foreseen: standardized QoS models, 1551 well-known QoS models and QoS models for private use. We assume the 1552 IANA registry of QoS models to distinguish between those. Apart from 1553 the QoS model ID, all QoS model specific extensions are opaque to the 1554 QoS NSLP (and have no impact on its IANA considerations section). 1556 4.5 Priority 1558 This specification acknowledges the fact that in some situations, 1559 some messages or some reservations may be more important than others 1560 and therefore foresees mechanisms to give these messages or 1561 reservations priority. 1563 Priority of certain signalling messages over others may be required 1564 in mobile scenarios when a message loss during call set-up is less 1565 harmful then during handover. This situation only occurs when GIMPS 1566 or QoS NSLP processing is the congested part or scarce resource. 1567 This specification requests GIMPS design to foresee a mechanism to 1568 support a number of levels of message priority that can be requested 1569 over the NSLP-GIMPS API. 1571 Priority of certain reservations over others may be required when QoS 1572 resources are oversubscribed. In that case, existing reservations 1573 may be preempted in other to make room for new higher-priority 1574 reservations. A typical approach to deal with priority and 1575 preemption is through the specification of a setup priority and 1576 holding priority for each reservation. The resource management 1577 function at each QNE then keeps track of the resource consumption at 1578 each priority level. Reservations are established when resource at 1579 their setup priority level are still available. They may cause 1580 preemption of reservations with a lower holding priority than their 1581 setup priority. 1583 Support of reservation priority is a QoS model specific issue and 1584 therefore outside the scope of this specification. However, the 1585 concepts of setup and holding priority are widely accepted and we 1586 expect the specification of a Priority object in the QSPEC template 1587 to be useful for a wide range of QoS models. 1589 4.6 Rerouting 1591 The QoS NSLP needs to adapt to route changes in the data path. This 1592 assumes the capability to detect rerouting events, perform QoS 1593 reservation on the new path and optionally tear down reservations on 1594 the old path. 1596 Rerouting detection can be performed at three levels. First, routing 1597 modules may detect route changes through their interaction with 1598 routing protocols. Certain QNEs or GIMPS implementations may 1599 interact with local routing module to receive quick notification of 1600 route changes. This is largely implementation-specific and outside 1601 of the scope of NSIS. Second, route changes may be detected at GIMPS 1602 layer. This specification requests GIMPS design to foresee 1603 notification of this information over the API. This is outside the 1604 scope of the QoS NSLP specification. Third, rerouting may be 1605 detected at the NSLP layer. A QoS NSLP node is able to detect 1606 changes in its QoS NSLP peers by keeping track of a Source 1607 Identification Information (SII) object that is similar in nature to 1608 the RSVP_HOP object described in [5]. When a RESERVE message with an 1609 existing SESSION_ID and a different SII is received, the QNE knows 1610 its upstream peer has changed. 1612 Reservation on the new path automatically happens when a refreshing 1613 RESERVE message arrives at the QNE where the old and the new path 1614 diverge. Rapid recovery at the NSLP layer therefore requires short 1615 refresh periods. Detection before the next RESERVE message arrives 1616 is only possible at the IP layer or through monitoring of GIMPS 1617 peering relations (e.g. by TTL counting the number of GIMPS hops 1618 between NSLP peers or the observing changes in the outgoing interface 1619 towards GIMPS peer). These mechanisms are outside the scope of this 1620 specification. 1622 When the QoS NSLP is aware of the route change, it needs to set up 1623 the reservation on the new path. This is done by sending a RESERVE 1624 message with RSN+1. On links that are common to the old and the new 1625 path, this RESERVE message is interpreted as a refreshing RESERVE. 1626 On new links, it creates the reservation. 1628 After the reservation on the new path is set up, the branching node 1629 or the merging node may want to tear down the reservation on the old 1630 path (faster than what would result from normal soft-state time-out). 1631 This functionality is supported by keeping track of the old SII. 1632 This specification requests GIMPS design to provide support for an 1633 SII that is interpreted as a random identifier at the QoS NSLP but 1634 that allows, when passed over the API, to forward QoS NSLP messages 1635 to the QNE identified by that SII. 1637 A QNE that has detected the route change via the SII change sends a 1638 RESERVE with the TEAR flag set. A QNE that is notified of the route 1639 change in another way and want to tear down the old branch needs to 1640 send the RESERVE on the new path with a RESPONSE_REQUEST. When it 1641 receives the RESPONSE message back, it can check whether its peer has 1642 effectively changed and send a RESERVE with the TEAR flag set if it 1643 has. Otherwise, teardown is not needed. A QNE that is unable to 1644 perform RESPONSE_REQUEST or does not receive a RESPONSE needs to rely 1645 on sof-state timeout on the old branch. 1647 A QNI or a branch node may wish to keep the reservation on the old 1648 branch. This could for instance be the case when a mobile node has 1649 experienced a mobility event and wishes to keep reservation to its 1650 old attachment point in case it moves back there. In that case, it 1651 sets the NO_REPLACE flag in the common header. 1653 4.7 State storage 1655 For each flow, a QNE stores (QoS model specific) reservation state 1656 which is different for each QoS model and QoS NSLP operation state 1657 which includes non-persistent state (e.g. the API parameters while a 1658 QNE is processing a message) and persistent state which is kept as 1659 long as the session is active. 1661 The persistent QoS NSLP state is conceptually organised in a table 1662 with the following structure. The primary key (index) for the table 1663 is the Session ID: 1664 SESSION_ID 1666 A large identifier provided by GIMPS or set locally. 1668 The state information for a given key includes: 1669 Flow ID 1671 Copied from GIMPS. Several entries are possible in case of 1672 mobility events. 1674 QoS model ID 1676 8 bit identification of the QoS model. 1678 SII for each upstream and downstream peer 1680 The SII is a large identifier (minimum 128 bits) generated by the 1681 GIMPS and passed over the API. 1683 RSN from each upstream peer 1685 The RSN is a 32 bit counter. 1687 Current own RSN 1689 A 32 bit random number. 1691 List of RII for outstanding responses with processing information 1693 the RII is a 32 bit number. 1695 State lifetime 1697 The state lifetime indicates how long the state that is being 1698 signalled for remains valid. 1700 BOUND_SESSION_ID 1702 The BOUND_SESSION_ID is a 128 bit random number. 1704 Adding the state requirements of all these items gives an upper bound 1705 on the state to be kept by a QNE. The need to keep state depends on 1706 the desired functionality at the NSLP layer. 1708 4.8 Authentication and authorization 1710 QoS NSLP requests allow particular user(s) to obtain preferential 1711 access to network resources. To prevent abuse, some form of an 1712 access control (also known as policy based admission control) will 1713 generally be required on users who make reservations. Typically, 1714 such authorization is expected to make use of an AAA service external 1715 to the node itself. In any case, cryptographic user identification 1716 and selective admission will generally be needed when a reservation 1717 is requested. 1719 The QoS NSLP request is handled by a local 'resource management' 1720 function, which coordinates the activities required to grant and 1721 configure the resource. The grant processing involves two local 1722 decision modules, 'policy control' and 'admission control'. Policy 1723 control determines whether the user is sufficiently authorized to 1724 make the reservation. Admission control determines whether the node 1725 has sufficient available resources to offer the requested QoS. 1727 4.8.1 Policy Ignorant Nodes 1729 It is generally assumed that policy enforcement is likely to 1730 concentrate on border nodes between administrative domains. Figure 1731 15 below illustrates a simple administrative domain with: 1732 o two boundary nodes (A, C), which represent QNEs authorized by AAA 1733 entities. 1734 o A core node (B) represents an Policy Ignorant QNE (PIN) with 1735 capabilities limited to default admission control handling. 1737 Authorizing Entity 1 Authorizing Entity 2 1738 | | 1739 | | 1740 +---+ +---+ +---+ 1741 | A +---------+ B +---------+ C | 1742 +---+ +---+ +---+ 1743 QNE1 PIN QNE2 1745 Figure 15: Administrative Domain scenario 1747 Here, policy objects transmitted across the domain traverse an 1748 intermediate PIN node (B) that is allowed to process QoS NSLP message 1749 but considered non-trusted for handling policy information. 1751 4.8.2 Policy Data 1753 The input to policy control is referred to as "Policy data", which 1754 QoS NSLP carries in the Policy object. Policy data may include 1755 credentials identifying entities and traits depending on the 1756 authorization model in use (2-party, 3-party, token-based 3-party). 1757 There are no requirements for all nodes to process this object. 1758 Policy data itself is opaque to the QoS NSLP, which simply passes it 1759 to policy control when required. The policy data is independent from 1760 the QoS model in use. 1762 Policy control depends on successful user authentication and 1763 authorization of a QoS NSLP reservation request. The authorization 1764 decision might be valid for a certain amount of time or even for the 1765 entire lifetime of the session. It is a decision of the involved 1766 party to trigger a re-authorization procedure. This feature is 1767 supported by the Policy Refresh Timer (PRT) option of the Policy 1768 object. 1770 Policy objects are carried by QoS NSLP messages and contain policy 1771 information. All policy-capable nodes (at any location in the 1772 network) can generate, modify, or remove policy objects, even when 1773 senders or receivers do not provide, and may not even be aware of 1774 policy data objects. 1776 The exchange of Policy objects between policy-capable QNEs along the 1777 data path, supports the generation of consistent end-to-end policies. 1779 Furthermore, such policies can be successfully deployed across 1780 multiple administrative domains when border nodes manipulate and 1781 translate Policy objects according to established sets of bilateral 1782 agreements. 1784 5. QoS-NSLP Functional specification 1786 5.1 QoS-NSLP Message and Object Formats 1788 A QoS-NSLP message consists of a common header, followed by a body 1789 consisting of a variable number of variable-length, typed "objects". 1790 The following subsections define the formats of the common header, 1791 the standard object header, and each of the QoS-NSLP message types. 1793 For each QoS-NSLP message type, there is a set of rules for the 1794 permissible choice of object types. These rules are specified using 1795 the Augmented Backus-Naur Form (BNF) specified in [2]. The BNF 1796 implies an order for the objects in a message. However, in many (but 1797 not all) cases, object order makes no logical difference. An 1798 implementation should create messages with the objects in the order 1799 shown here, but accept the objects in any permissible order. 1801 5.1.1 Common header 1803 0 1 2 3 1804 +-------------+-------------+-------------+-------------+ 1805 | Message Type | Flags | 1806 +-------------+-------------+-------------+-------------+ 1808 The fields in the common header are as follows: 1810 Msg Type: 16 bits 1811 1 = RESERVE 1812 2 = QUERY 1813 3 = RESPONSE 1814 4 = NOTIFY 1815 Flags: 16 bits 1816 The set of appropriate flags depend on the particular message 1817 being processed. Any bit not defined as a flag for a 1818 particular message MUST be set to zero on sending and MUST 1819 ignored on receiving. 1821 5.1.2 Object Formats 1823 Every object consists of one or more 32-bit words with a one-word 1824 header, with the following format: 1826 0 1 2 3 1827 +-------------+-------------+-------------+-------------+ 1828 | Length (bytes) | Class-Num | C-Type | 1829 +-------------+-------------+-------------+-------------+ 1830 | | 1831 // (Object contents) // 1832 | | 1833 +-------------+-------------+-------------+-------------+ 1835 An object header has the following fields: 1837 Length: 1838 A 16-bit field containing the total object length in bytes. 1839 Must always be a multiple of 4, and at least 4. 1840 Class-Num: 1841 Identifies the object class; values of this field are defined 1842 in Appendix A. Each object class has a name, which is always 1843 capitalized in this document. An QoS-NSLP implementation must 1844 recognize the following classes: 1845 RESPONSE_REQUEST: 1846 Contains the request for the generation of a response 1847 message and the Request Identification Information (RII). 1848 RSN: 1849 The Reservation Sequence Number (RSN) contains an 1850 incrementing sequence number that indicates the order in 1851 which state modifying actions are performed by a QNE. 1852 The RSN has local significance only, i.e. between a pair 1853 of neighbouring stateful QNEs. RSN is a common control 1854 information object. 1855 REFRESH_PERIOD: 1856 Contains the value for the refresh period R used by the 1857 creator of the message. Required in every RESERVE 1858 message. REFRESH_PERIOD is a common control information 1859 object. 1860 BOUND_SESSION_ID: 1861 It represents the Session ID as specified in [15] of the 1862 session that must be bound to the session associated to 1863 the message carrying this object. 1864 SCOPING: 1865 contains information that limits the scope of the message 1866 carrying this object. When no SCOPING object is 1867 available in a message it means that its scoping is 1868 either the whole path or it is defined by configuration. 1869 SCOPING is a common control information object. 1870 ERROR_SPEC: 1871 Contains an error code and can be carried by a Response 1872 or a NOTIFY message. ERROR_SPEC is a common control 1873 information object. 1875 POLICY_DATA: 1876 Carries authentication, authorization and accounting 1877 information. 1878 QSPEC: 1879 Carries the information that is QoS model specific. This 1880 information consists of the QoS model specific control 1881 information and the QoS specification parameters. 1882 C-Type: 1883 Object type, unique within Class-Num. Values are defined in 1884 Appendix A. 1886 The maximum object content length is 65528 bytes. The Class-Num and 1887 C-Type fields may be used together as a 16-bit number to define a 1888 unique type for each object. 1890 The high-order two bits of the Class-Num are used to determine what 1891 action a node should take if it does not recognize the Class-Num of 1892 an object. The first two bits of the Class-Num take one of the 1893 following three values: 1894 00 - Abort processing and send error back 1895 01 - Ignore object, and do not forward it in onward message 1896 10 - Ignore object, but forward it in onward message 1898 5.2 General Processing Rules 1900 5.2.1 State Manipulation 1902 The processing of a message and its component objects involves 1903 manipulating the QoS NSLP and reservation state of a QNE. 1905 The state used by the QoS NSLP is listed in Section 4.7. 1907 5.2.2 Message Forwarding 1909 QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP 1910 does not have the concept of a message being sent along the entire 1911 path. Instead, messages are received by a QNE, which may then send 1912 another message (which may be identical to the received message, or 1913 contain some subset of objects from it) to continue in the same 1914 direction (i.e. towards NI or NR) as the message received. 1916 The decision on whether to generate a message to forward may be 1917 affected by the presence of a SCOPING object. 1919 5.2.3 Standard Message Processing Rules 1921 If a mandatory object is missing from a message then the receiving 1922 QNE MUST NOT propagate the message any further. It MUST construct an 1923 RESPONSE message indicating the error condition and send it back to 1924 the peer QNE that sent the message. 1926 If a message contains an object of an unrecognised type, then the 1927 behaviour depends on the first two bits in the type value. 1929 5.3 Object Processing 1931 5.3.1 Reservation Sequence Number 1933 A QNE's own RSN is a sequence number which applies to a particular 1934 NSIS signalling session (i.e. with a particular GIMPS Session ID). 1935 It MUST be incremented for each new RESERVE message where the 1936 reservation for the session changes. Once the RSN has reached its 1937 maximum value, the next value it takes is zero. 1939 When receiving a RESERVE message a QNE uses the RSN given in the 1940 message to determine whether the state being requested is different 1941 to that already stored. If the RSN is the same as for the current 1942 reservation the current state MUST be refreshed. If the RSN is 1943 greater than the current stored value, the current reservation MUST 1944 be modified appropriately (provided that admission control and policy 1945 control succeed), and the stored RSN value updated to that for the 1946 new reservation. If the RSN is less than the current value, then it 1947 indicates an out-of-order message and the RESERVE message MUST be 1948 discarded. 1950 If the QNE does not store per-session state (and so not keep any 1951 previous RSN values) then it MAY ignore the value of the RSN. It 1952 MUST also copy the same RSN into the RESERVE message (if any) it 1953 sends as a consequence of receiving this one. 1955 5.3.2 Response Request 1957 A QNE sending some types of message may require a response to be 1958 sent. It does so by including a RESPONSE_REQUEST object. 1960 When creating a RESPONSE_REQUEST object the sender MUST select the 1961 value for the RII such that it is probabilistically unique within the 1962 given session. 1964 A number of choices are available when implementing this. 1965 Possibilities might include using a totally random value, or a node 1966 identifier together with a counter. If the value is selected by 1967 another QNE then RESPONSE messages may be incorrectly terminated, and 1968 not passed back to the node that requested them. 1970 When sending a RESPONSE_REQUEST the sending node MUST remember the 1971 value used in the RII to match back any RESPONSE received. It SHOULD 1972 use a timer to identify situations where it has taken too long to 1973 receive the expected RESPONSE. If the timer expires without 1974 receiving a RESPONSE it MAY perform a retransmission. 1976 When receiving a message containing a RESPONSE_REQUEST object the 1977 node MUST send a RESPONSE if either 1978 o The message contained a SCOPING object with a value of 'next hop', 1979 or 1980 o This QNE is the last one on the path for the given session. 1981 and the QNE keeps per-session state for the given session. 1983 5.3.3 Bound Session ID 1985 As shown in the examples in Section 3.5, the QoS NSLP can relate 1986 multiple sessions together. It does this by including the Session ID 1987 from one session in a BOUND_SESSION_ID object in messages in another 1988 session. 1990 5.3.4 Refresh Period 1992 Refresh timer management values are carried by the REFRESH_PERIOD 1993 object. The details of timer management and timer changes (slew 1994 handling and so on) are identical to the ones specified in Section 1995 3.7 of [5]. There are two time parameters relevant to each QoS-NSLP 1996 state in a node: the refresh period R between generation of 1997 successive refreshes for the state by the neighbor node, and the 1998 local state's lifetime L. Each RESERVE message may contain a 1999 REFRESH_PERIOD object specifying the R value that was used to 2000 generate this (refresh) message. This R value is then used to 2001 determine the value for L when the state is received and stored. The 2002 values for R and L may vary from peer to peer. This peer-to-peer 2003 refreshing (as opposed to the QNI initiating a refresh which travels 2004 all the way to the QNR) allows QNEs to choose refresh intervals as 2005 appropriate for their environment. For example, it is conceivable 2006 that refreshing intervals in the backbone, where reservations are 2007 relatively stable, are much larger than in an access network. 2009 In more detail: 2010 1. Floyd and Jacobson [26] have shown that periodic messages 2011 generated by independent network nodes can become synchronized. 2012 This can lead to disruption in network services as the periodic 2013 messages contend with other network traffic for link and 2014 forwarding resources. Since QoS-NSLP sends periodic refresh 2015 messages, it must avoid message synchronization and ensure that 2016 any synchronization that may occur is not stable. For this 2017 reason, it is recommended that the the refresh timer should be 2018 randomly set to a value in the range [0.5R, 1.5R]. 2020 2. To avoid premature loss of state, L must satisfy L >= (K + 2021 0.5)*1.5*R, where K is a small integer. Then in the worst case, 2022 K-1 successive messages may be lost without state being deleted. 2023 To compute a lifetime L for a collection of state with different R 2024 values R0, R1, ..., replace R by max(Ri). 2025 Currently K = 3 is suggested as the default. However, it may be 2026 necessary to set a larger K value for hops with high loss rate. K 2027 may be set either by manual configuration per interface, or by 2028 some adaptive technique that has not yet been specified. 2029 3. Each RESERVE message carries a REFRESH_PERIOD object 2030 containing the refresh time R used to generate refreshes. The 2031 recipient node uses this R to determine the lifetime L of the 2032 stored state created or refreshed by the message. 2033 4. The refresh time R is chosen locally by each node. If the 2034 node does not implement local repair of reservations disrupted by 2035 route changes, a smaller R speeds up adaptation to routing 2036 changes, while increasing the QOS-NSLP overhead. With local 2037 repair, a router can be more relaxed about R since the periodic 2038 refresh becomes only a backstop robustness mechanism. A node may 2039 therefore adjust the effective R dynamically to control the amount 2040 of overhead due to refresh messages. 2041 The current suggested default for R is 30 seconds. However, the 2042 default value Rdef should be configurable per interface. 2043 5. When R is changed dynamically, there is a limit on how fast it 2044 may increase. Specifically, the ratio of two successive values 2045 R2/R1 must not exceed 1 + Slew.Max. 2046 Currently, Slew.Max is 0.30. With K = 3, one packet may be lost 2047 without state timeout while R is increasing 30 percent per refresh 2048 cycle. 2049 6. To improve robustness, a node may temporarily send refreshes 2050 more often than R after a state change (including initial state 2051 establishment). 2052 7. The values of Rdef, K, and Slew.Max used in an implementation 2053 should be easily modifiable per interface, as experience may lead 2054 to different values. The possibility of dynamically adapting K 2055 and/or Slew.Max in response to measured loss rates is for future 2056 study. 2058 5.3.5 Scoping 2060 When sending some types of message, the node may wish to limit the 2061 distance that the message should travel along the path (the default 2062 being the whole path). To do so a node MUST include a SCOPING 2063 object. 2065 When receiving a message, before sending the message further, the QNE 2066 MUST inspect any scoping object to determine if it has reached the 2067 end of the scoped region. If so, it MUST NOT pass it further, and 2068 MUST generate a RESPONSE if a RESPONSE_REQUEST object is present. 2070 5.3.6 Error Spec 2072 The ERROR_SPEC object contains a value which indicates the condition 2073 that occurred. Error values are to be specified for various 2074 conditions, such as: 2075 o OK 2076 o Message type not supported 2077 o Object type not supported 2078 o Insufficient resources 2079 o Authentication failure 2080 o Authorisation denied 2081 o QoS model specific condition occurred 2082 o ... 2084 5.3.7 Policy Data 2086 POLICY_DATA objects may contain various items to authenticate the 2087 user and allow the reservation to be authorised. Some possible 2088 contents are given in Appendix A.7, and some issues are also 2089 discussed in Section 3.3. 2091 5.3.8 QSpec 2093 The contents of the QSpec depends on the QoS model being used. It 2094 may be that parts of the QSpec are standardised across multiple QoS 2095 models. This topic is currently the topic of further study. 2097 5.4 Message Processing Rules 2099 5.4.1 RESERVE Messages 2101 The RESERVE message is used to manipulate QoS reservation state in 2102 QNEs. A RESERVE message may create, refresh, modify or remove such 2103 state. 2105 The format of a RESERVE message is as follows: 2107 RESERVE = COMMON_HEADER 2108 RSN [ SCOPING ] [ RESPONSE_REQUEST ] 2109 [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] 2110 [ POLICY_DATA ] [ *QSPEC ] 2112 If any QSPEC objects are present, they MUST occur at the end of the 2113 message. There are no other requirements on transmission order, 2114 although the above order is recommended. 2116 Three flags are defined for use in the common header with the RESERVE 2117 message. These are: 2118 TEAR - when set, indicates that reservation state and QoS NSLP 2119 operation state should be torn down. This is indicated to the 2120 RMF. 2121 NO_REPLACE - when set, indicates that a RESERVE with different 2122 Flow Routing Information (FRI) does not replace an existing one, 2123 so the old one should not be torn down immediately 2124 NO_FATE_SHARING - when set, indicates that sessions in the bundle 2125 should not share fate with one another 2127 An RSN MUST be present. 2129 RESERVE messages MUST only be sent towards the NR. 2131 If the QNE sending a RESERVE message wishes to use the reduced 2132 overhead refresh mechanism described in Section 4.2.1, then it SHOULD 2133 include a RESPONSE_REQUEST in the RESERVE message. It MUST NOT send 2134 a reduced overhead refresh message (i.e. a RESERVE with a 2135 non-incremented RSN and no QSPEC) unless it has received a RESPONSE 2136 message for that RESERVE message. 2138 If the session of this message is bound to another session, then the 2139 RESERVE message MUST include the SESSION_ID of that other session in 2140 a BOUND_SESSION_ID object. 2142 Before admitting a reservation a QNE MUST determine whether the 2143 request is authorized. It SHOULD exercise its local policy in 2144 conjunction with the POLICY_DATA object to do this. 2146 When a QNE receives a RESERVE message, its processing may involve 2147 sending out a RESERVE message. When doing so, the QNE may insert or 2148 remove 'local' QSPEC objects from the top of the stack. If there are 2149 one or more QSPECs in the received RESERVE message, the last QSPEC 2150 MUST NOT be removed when sending on the RESERVE message. 2152 When a reservation is no longer required the QNI SHOULD send a 2153 RESERVE message with the TEAR bit set in the header. On receiving 2154 such a RESERVE message the QNE MUST remove any reservation state for 2155 that session. It SHOULD remove the QoS NSLP state. It MAY signal to 2156 the NTLP that it is no longer interested in NTLP state for that 2157 session. 2159 5.4.2 QUERY Messages 2161 A QUERY message is used to request information about the data path 2162 without making a reservation. This functionality can be used to 2163 'probe' the network for path characteristics or for support of 2164 certain QoS models. The information obtained from a QUERY may be 2165 used in the admission control process of a QNE (e.g. in case of 2166 measurement-based admission control). Note that a QUERY does not 2167 change existing reservation state, nor does it cause state to be 2168 installed in nodes other than the one that generated the QUERY. 2170 The format of a QUERY message is as follows: 2172 QUERY = COMMON_HEADER 2173 [ SCOPING ] [ RESPONSE_REQUEST ] 2174 [ BOUND_SESSION_ID ] 2175 [ POLICY_DATA ] [ *QSPEC ] 2177 If any QSPEC objects are present, they MUST occur at the end of the 2178 message. There are no other requirements on transmission order, 2179 although the above order is recommended. 2181 No flags are defined are defined for use with the QUERY message. 2183 A QUERY message MAY be scoped using the SCOPING object. 2185 A QUERY message MUST contain a RESPONSE_REQUEST object, unless the 2186 QUERY is being used to initiate reverse-path state for a 2187 receiver-initiated reservation. 2189 If the session of this message is bound to another session, then the 2190 RESERVE message MUST include the SESSION_ID of that other session in 2191 a BOUND_SESSION_ID object. 2193 On receiving a QUERY message, the QoS model specific QUERY processing 2194 MAY cause the QSpec to be modified, to provide the answer to the 2195 query. Future QoS NSLP objects may be added to the protocol with 2196 similar properties in this respect. 2198 If this is last node to process this QUERY message (either because it 2199 is the last node on the path, or because of scoping), and a 2200 RESPONSE_REQUEST object is present, then a RESPONSE message MUST be 2201 generated and passed back along the reverse of the path used by the 2202 QUERY. 2204 If this is the last node and a RESPONSE_REQUEST object is not present 2205 then the QUERY is a trigger to initiate a reservation in the reverse 2206 direction. If this node was not expecting to perform a 2207 receiver-initiated reservation then an error MUST be sent back along 2208 the path. 2210 When generating a QUERY to send out to pass the query further along 2211 the path, the QNE MUST copy the RESPONSE_REQUEST (if present) into 2212 the new QUERY message unchanged. 2214 5.4.3 RESPONSE Messages 2216 The RESPONSE message is used to provide information about the result 2217 of a previous QoS-NSLP message, e.g. confirmation of a reservation 2218 or information resulting from a query. The RESPONSE message is 2219 impotent, it does not cause any state to be installed or modified. 2221 The format of a RESPONSE message is as follows: 2223 RESPONSE = COMMON_HEADER 2224 [ SCOPING / RSN ] ERROR_SPEC 2225 [ *QSPEC ] 2227 If any QSPEC objects are present, they MUST occur at the end of the 2228 message. There are no other requirements on transmission order, 2229 although the above order is recommended. 2231 No flags are defined are defined for use with the RESPONSE message. 2233 A RESPONSE message MUST be sent where the QNE is the last node to 2234 process a RESERVE or QUERY message containing a RESPONSE_REQUEST 2235 object (based on scoping of the RESERVE or QUERY, or because this is 2236 the last node on the path). In this case, the RESPONSE MUST contain 2237 a SCOPING object of type RII. The contents of the RESPONSE_REQUEST 2238 object in the received RESERVE or QUERY message MUST be copied into 2239 this SCOPING object in the RESPONSE. 2241 In addition, a RESPONSE message MUST be sent when an error occurs 2242 while processing a received message message. If the received message 2243 contains a RESPONSE_REQUEST object, then an RII SCOPING object MUST 2244 be put in the RESPONSE, as described above. If the RESPONSE is sent 2245 as a result of the receipt of a RESERVE message without a 2246 RESPONSE_REQUEST object, then the RSN of the received RESERVE message 2247 MUST be copied into the RESPONSE message. 2249 A RESPONSE message MUST contain an ERROR_SPEC object which indicates 2250 the success of a reservation installation or an error condition. 2251 Depending on the value of the ERROR_SPEC, the RESPONSE MAY also 2252 contain a QSPEC object. 2254 On receipt of a RESPONSE message containing an RII SCOPING object, 2255 the QNE MUST attempt to match it to the outstanding response requests 2256 for that signalling session. If the match succeeds, then the 2257 RESPONSE MUST NOT be forwarded further along the path. If the match 2258 fails, then the QNE MUST attempt to forward the RESPONSE to the next 2259 peer QNE. 2261 On receipt of a RESPONSE message containing an RSN object, the QNE 2262 MUST compare the RSN to that of the appropriate signalling session. 2263 If the match succeeds then the error MUST be processed. The RESPONSE 2264 message MUST NOT be forwarded further along the path whether or not 2265 the match succeeds. 2267 5.4.4 NOTIFY Messages 2269 NOTIFY messages are used to convey information to a QNE 2270 asynchronously. NOTIFY messages are impotent (they do not cause a 2271 change in state directly). 2273 The format of a NOTIFY message is as follows: 2275 NOTIFY = COMMON_HEADER 2276 ERROR_SPEC [ QSPEC ] 2278 No flags are defined are defined for use with the NOTIFY message. 2280 A NOTIFY message MUST contain an ERROR_SPEC object indicating the 2281 reason for the notification. Depending on the ERROR_SPEC value, it 2282 MAY contain a QSpec providing additional information. 2284 NOTIFY messages are sent asynchronously, rather than in response to 2285 other messages. They may be sent in either direction (upstream or 2286 downstream). 2288 6. IANA considerations 2290 This section provides guidance to the Internet Assigned Numbers 2291 Authority (IANA) regarding registration of values related to the 2292 QoS-NSLP, in accordance with BCP 26 [7]. 2294 The QoS NSLP requires IANA to create two registries. One for QoS 2295 NSLP message types, the other for QoS NSLP objects. 2297 This specification defines four message types: RESERVE=1, QUERY=2, 2298 RESPONSE=3 and NOTIFY=4. Values are taken from the Message type name 2299 space (8 bits). New Message types may be defined and assigned values 2300 by IANA. For this, standards action is required. 2302 Common Control Information has a Class and C-type assigned by IANA. 2303 This specification defines the following Common Control Information 2304 objects 2305 RESPONSE_REQUEST: Class=1 2306 C-type=1: empty 2307 C-type=2: Request Identification Information 2309 RSN: Class=2 2311 C-type=1: RSN 2313 REFRESH_PERIOD: Class=3 2315 C-type=1: REFRESH_PERIOD 2317 SESSION_ID: Class=4 2319 C-type=1: SESSION_ID 2321 SCOPING: Class=5 2323 C-type=1: single hop 2324 C-type=2: Region scoping 2325 C-type=3: RII scoping 2327 ERROR_SPEC: Class=6 2329 C-type=1: empty 2331 IANA will assign new ClassNum values and/or C-type for Common Control 2332 Information upon specification. The required specification needs to 2333 indicate what the correct behaviour is in case the new ClassNum or 2334 C-type is not understood. 2336 This specification defines a QSPEC object with assigned class = 8. 2337 The C-type identifies the QoS model, which can be standardized, 2338 well-known or private. 2339 Standardized 2341 Standardized QoS models have a C-type value in the range of 1-64. 2342 C-type values for standardized QoS models are assigned by IANA and 2343 require standards action. 2345 Well-known 2347 Well-known QoS models have a C-type value in the range of 65-128. 2348 They are assigned by IANA and require IETF consensus. 2350 Private 2352 C-type values from the range 129-256 are for private use. 2354 7. Requirements for the NSIS Transport Layer Protocol (GIMPS) 2356 For the moment this section will merely describe what we assume and/ 2357 or request to be available from GIMPS. This section will later be 2358 updated to describe the eventual interface when GIMPS work gets 2359 finalized. 2361 7.1 Session identification 2363 The QoS NSLP keeps message and reservation state per session. A 2364 session is identified by a Session Identifier (SESSION_ID). The 2365 SESSION_ID is the primary index for stored NSLP state and needs to be 2366 constant and unique (with a sufficiently high probability) along a 2367 path through the network. QoS NSLP will pick a value for the 2368 SESSION_ID and pass it over the API. 2370 7.2 Support for bypassing intermediate nodes 2372 The QoS NSLP may want to restrict the handling of its messages to 2373 specific nodes. This functionality is needed to support layering 2374 (explained in Section 4.3), when only the edge QNEs of a domain 2375 process the message. This requires a mechanism at GIMPS level (which 2376 can be invoked by the QoS NSLP) to bypass intermediates nodes between 2377 the edges of the domain. 2379 As a suggestion, we identified two ways for bypassing intermediate 2380 nodes. One solution is for the end-to-end session to carry a 2381 different protocol ID (QoS-NSLP-E2E-IGNORE protocol ID, similar to 2382 the RSVP-E2E-IGNORE that is used for RSVP aggregation ([10]). 2383 Another solution is based on the use of multiple levels of the router 2384 alert option. In that case, internal routers are configured to 2385 handle only certain levels of router alerts. The choice between both 2386 approaches or another approach that fulfills the requirement is left 2387 to GIMPS design. 2389 7.3 Support for peer change identification 2391 There are several circumstances where it is necessary for a QNE to 2392 identify the adjacent QNE peer, which is the source of a signaling 2393 application message; for example, it may be to apply the policy that 2394 "state can only be modified by messages from the node that created 2395 it" or it might be that keeping track of peer identity is used as a 2396 (fallback) mechanism for rerouting detection at the NSLP layer. 2398 We rely on GIMPS to provide this functionality and suggest it be 2399 implemented as an opaque identifier (Source Identification 2400 Information (SII)) which, by default, all outgoing QoS-NSLP messages 2401 are tagged with at GIMPS layer. This identifier is propagated to the 2402 next QNE, where it can be used to identify the state associated with 2403 the message; The SII is logically similar to the RSVP_HOP object of 2404 [5]; however, any IP (and possibly higher level) addressing 2405 information is not interpreted in the QoS-NSLP. Indeed, the 2406 intermediate GIMPS nodes could enforce topology hiding by masking the 2407 content of the SII (provided this is done in a stable way). 2409 Keeping track of the SII of a certain reservation also provides a 2410 means for the QoS-NSLP to detect route changes. When a QNE receives 2411 a RESERVE referring to existing state but with a different SII, it 2412 knows that its upstream peer has changed. It can then use the old 2413 SII to send initiate a teardown along the old section of the path. 2414 This functionality would require GIMPS to be able to route based on 2415 the SII. We would like this functionality to be available as a 2416 service from GIMPS. 2418 7.4 Support for stateless operation 2420 Stateless or reduced state QoS-NSLP operation makes the most sense 2421 when some nodes are able to operate in a stateless way at GIMPS level 2422 as well. Such nodes should not worry about keeping reverse state, 2423 message fragmentation and reassembly (at GIMPS), congestion control 2424 or security associations. A stateless or reduced state QNE will be 2425 able to inform the underlying GIMPS of this situation. We rely on 2426 GIMPS design to allow for a mode of operation that can take advantage 2427 of this information. 2429 7.5 Last node detection 2431 There are situations in which a QNE needs to determine whether it is 2432 the last QNE on the data path (QNR), e.g. to construct and send a 2433 RESPONSE message. 2435 A number of conditions may result in a QNE determining that it is the 2436 QNR: 2437 o the QNE may be the flow destination 2438 o the QNE have some other prior knowledge that it should act as the 2439 QNR 2440 o the QNE may be the last NSIS-capable node on the path 2441 o the QNE may be the last NSIS-capable node on the path supporting 2442 the QoS NSLP 2444 Of these four conditions, the last two can only be detected by GIMPS. 2445 We rely on GIMPS to inform the QoS-NSLP about these cases by 2446 providing a trigger to the QoS-NSLP when it determines that it is the 2447 last NE on the path, which supports the QoS-NSLP. It requires GIMPS 2448 to have an error message indicating that no more NSLPs of a 2449 particular type are available on the path. 2451 7.6 Re-routing detection 2453 Route changes may be detected at the GIMPS layer or the information 2454 may be obtained by GIMPS through local interaction with or 2455 notification from routing protocols or modules. This specification 2456 requests the GIMPS design to foresee notification of a route change 2457 (over the API) to the QNEs upstream of the NE where the route change 2458 is detected. 2460 7.7 Priority of signalling messages 2462 The QoS-NSLP will generate messages with a range of performance 2463 requirements for GIMPS. These requirements may result from a 2464 prioritization at the QoS-NSLP (Section 4.3) or from the 2465 responsiveness expected by certain applications supported by the 2466 QoS-NSLP. 2468 GIMPS design should be able to ensure that performance for one class 2469 of messages was not degraded by aggregation with other classes of 2470 messages. It is currently an open issue how many priority levels are 2471 required. 2473 7.8 Knowledge of intermediate QoS NSLP unaware nodes 2475 In some cases it is useful to know that a reservation has not been 2476 installed at every router along the path. It is not possible to 2477 determine this using only NSLP functionality. 2479 GIMPS should be able to provide information to the NSLP about whether 2480 the message has passed through nodes that did not provide support for 2481 this NSLP. 2483 This might be realised by GIMPS by a mixture of GIMPS node counting, 2484 and examination of the IP TTL or Hop Limit. The QoS NSLP, however, 2485 does not need to know the number of intermediate nodes, only that one 2486 or more exists. 2488 7.9 NSLP Data Size 2490 When GIMPS passes the QoS NSLP data to the NSLP for processing, it 2491 must also indicate the size of that data. (It is assumed that GIMPS 2492 message structure will indicate how long this part of GIMPS message 2493 is.) 2495 7.10 Notification of NTLP 'D' flag value 2497 When the NTLP passes the QoS NSLP data to the NSLP for processing, it 2498 must also indicate the value of the 'D' (Direction) flag for that 2499 message. 2501 7.11 NAT Traversal 2503 The QoS NSLP relies on GIMPS for NAT traversal. 2505 8. Assumptions on the QoS model 2507 8.1 Resource sharing 2509 This specification assumes that resource sharing is possible between 2510 flows with the same SESSION_ID that originate from the same QNI or 2511 between flows with a different SESSION_ID that are related through 2512 the BOUND_SESSION_ID object. For flows with the same SESSION_ID, 2513 resource sharing is only applicable when the existing reservation is 2514 not just replaced (which is indicated by the NO_REPLACE flag in the 2515 common header. 2517 The Resource Management Function (RMF) reserves resources for each 2518 flow. We assume that the QoS model supports resource sharing between 2519 flows. A QoS model may elect to implement a more general behaviour 2520 of supporting relative operations on existing reservations, such as 2521 ADDING or SUBTRACTING a certain amount of resources from the current 2522 reservation. A QoS model may also elect to allow resource sharing 2523 more generally, e.g. between all flows with the same DSCP. 2525 8.2 Reserve/commit support 2527 Reserve/commit behaviour means that the time at which the reservation 2528 is made may be different from the time when the reserved resources 2529 are actually set aside for the requesting session. This 2530 specification acknowledges the usefulness of such a mechanism but 2531 assumes that its implementation is opaque to QoS NSLP and is fully 2532 handled by the QoS model. A COMMIT flag in the QoS-model specific 2533 control information is suggested as a way to support this 2534 functionality. 2536 9. Open issues 2538 9.1 Region scoping 2540 This specification allows QNEs to scope their messages, i.e. to 2541 restrict the extent to which messages may travel along and be 2542 interpreted on the path. For this, the scopes of whole path, single 2543 hop and back to me (RII) are defined. Also, a region can be 2544 configured administratively or it can be derived from some other 2545 means (e.g. RAO levels) in case of aggregation. 2547 This specification currently does not define and support a more 2548 generic notion of region (e.g. to implement region policies 2549 independent from aggregation regions,...). It is proposed to use the 2550 concept of Localized RSVP for regions. 2552 9.2 Priority of reservations 2554 Priority of certain reservations over others may be required when QoS 2555 resources are oversubscribed. In that case, existing reservations 2556 may be preempted in other to make room for new higher-priority 2557 reservations. A typical approach to deal with priority and 2558 preemption is through the specification of a setup priority and 2559 holding priority for each reservation. The resource management 2560 function at each QNE then keeps track of the resource consumption at 2561 each priority level. Reservations are established when resource at 2562 their setup priority level are still available. They may cause 2563 preemption of reservations with a lower holding priority than their 2564 setup priority. 2566 Support of reservation priority is a QoS model specific issue and 2567 therefore outside the scope of this specification. However, the 2568 concepts of setup and holding priority are widely accept and we 2569 expect the specification of a Priority object in the QSPEC template 2570 to be useful for a wide range of QoS models. 2572 It is an open question to the NSIS community whether the concepts of 2573 setup and holding priority are useful enough to define a priority 2574 object in this specification. Alternatively, this could be left as 2575 QoS model specific. 2577 9.3 Peering agreements on interdomain links 2579 This specification proposes ways to carry AAA information that may be 2580 used at the edges of a domain to check whether the requestor is 2581 allowed to use the requested resources. It is less likely that the 2582 AAA information will be used inside a domain. In practice, there may 2583 be peering relations between domains that allow for a certain amount 2584 of traffic to be sent on an interdomain link without the need to 2585 check the authorization of each individual session (effectively 2586 making the peering domain the requestor of the resources). The 2587 per-session authorization check may be avoided by setting up an 2588 aggregate reservation on the inter-domain link for a specified amount 2589 of resources and relating the end-to-end sessions to it using the 2590 BOUND_SESSION_ID. In this way, the aggregate session is authorized 2591 once (and infrequently updated). An alternative is for the edge node 2592 of a domain to insert a token that authorizes the flow for the next 2593 domain. 2595 9.4 GIMPS Modifications for Refresh Overhead Reduction 2597 As described in Section 4.2.4 a mechanism is available to reduce the 2598 overhead of refresh messages. As currently specified, GIMPS may opt 2599 to bundle several NSLP messages together. However, this still has 2600 some additional overhead, particularly due to the requirement to 2601 include Flow Routing Information (FRI) in every message. This may 2602 not be strictly necessary for a message going only to the next GIMPS 2603 hop. 2605 It is an open issue to examine what additional optimisations are 2606 possible and appropriate for refresh overhead reduction. 2608 9.5 Path state maintenance implementation at NSLP 2610 As currently described in Section 3.5.3, a QoS NSLP message is 2611 required to create the necessary GIMPS reverse path state so that the 2612 receiver-initiated RESERVE message can be sent upstream. (This must 2613 be an NSLP message so that it visits the correct subset of GIMPS 2614 nodes on the path.) This message may also be used to refresh the 2615 GIMPS path state (see Section 9.6). 2617 In this version, we have implemented this functionality by making the 2618 RESPONSE_REQUEST object in QUERY optional. Basically, this means 2619 that we send an empty QUERY message along the path. It is not clear 2620 whether this path state maintenance functionality is sufficiently 2621 different from QUERY to warrant the definition of a separate (NULL) 2622 message. 2624 It is also worth investigating whether other NSLPs have a similar 2625 need and whether in that case it would be better to define a separate 2626 NULL message across all NSLPs. 2628 9.6 GIMPS Path State Maintenance 2630 As currently described in Section 3.5.3, when performing 2631 receiver-initiated reservations the QoS NSLP sends periodic 2632 downstream QUERY messages to ensure that GIMPS reverse path state is 2633 refreshed. 2635 It is unclear how often such messages need to be sent, since the 2636 lifetime of the path state is a matter for GIMPS. It, therefore, may 2637 be necessary for GIMPS to inform the NSLP about this state lifetime. 2639 An alternative solution to the refreshing of GIMPS path state by NSLP 2640 messages is for GIMPS to refresh (and, where necessary, detect 2641 changes in) its path state automatically, by sending periodic probe/ 2642 refresh messages of its own. The transmission of upstream messages 2643 (such as the RESERVE in a receiver-initiated QoS NSLP reservation) 2644 can be used to indicate that the reverse path state is still needed. 2645 Whether such a technique is appropriate is for further consideration. 2647 9.7 Protocol Operating Environment Assumptions 2649 For receiver initiated and bidirectional reservations the question 2650 arises of what assumptions to make about what end-to-end information 2651 should be determined outside the NSIS protocols and what should be 2652 carried end-to-end in NSLP messages in order to initiate signalling. 2653 The NSIS protocol is not used alone. It is used in conjunction with 2654 a variety of applications. The question arises of what the 2655 interactions between NSIS (and the NSLP in particular) and these 2656 applications is. 2658 For a receiver initiated reservation, the we have the questions: How 2659 do the sender and receiver determine that a receiver initiated 2660 reservation is to be performed? And, how does information needed by 2661 the receiver to perform the reservation, but only available at the 2662 sender, be made transferred to the receiver so that the RESERVE 2663 message can be sent? 2665 In the bi-directional reservation case, we can either perform this as 2666 a pair of two sender-initiated reservations or as a combination of 2667 sender-initiated and receiver-initiated reservations. The latter 2668 case has the same issues as for the general receiver initiated 2669 reservation problem. The former raises similar questions: How does 2670 the remote end know that a reservation is needed? And, how does it 2671 know what resources to request? 2673 Is it reasonable to assume that the decision that an end should 2674 initiate a reservation is made totally outside the QoS NSLP itself 2675 (e.g. through prior configuration, or application end-to-end 2676 signalling such as SIP) or, should the QoS NSLP messages include some 2677 method to trigger the other end to perform a reservation (whether 2678 that be a receiver initiated reservation, or a sender initiated 2679 reservation for the first bidirectional reservation case)? 2681 In addition, should the QoS NSLP messages be able to carry extra data 2682 (e.g. a QSpec object for the reverse direction) end-to-end that is 2683 needed by the remote end to perform its reservation? (And, should 2684 this be in the QoS NSLP, or through individual QoS models?) The 2685 alternative to providing support in the QoS NSLP for this is to leave 2686 it to application signalling to transfer any required information. 2688 10. Security Considerations 2689 10.1 Introduction and Threat Overview 2691 The security requirement for the QoS NSLP is to protect the signaling 2692 exchange for establishing QoS reservations against identified 2693 security threats. For the signaling problem as a whole, these 2694 threats have been outlined in [21]; the NSIS framework [15] assigns a 2695 subset of the responsibility to GIMPS and the remaining threats need 2696 to be addressed by NSLPs. The main issues to be handled can be 2697 summarised as: 2698 Authorization: 2700 The QoS NSLP must assure that the network is protected against 2701 theft-of-service by offering mechanisms to authorize the QoS 2702 reservation requestor. A user requesting a QoS reservation might 2703 want proper resource accounting and protection against spoofing 2704 and other security vulnerabilities which lead to denial of service 2705 and financial loss. In many cases authorization is based on the 2706 authenticated identity. The authorization model must provide 2707 guarantees that replay attacks are either not possible or limited 2708 to a certain extent. Authorization can also be based on traits 2709 which enables the user to remain anonymous. Support for user 2710 identity confidentiality can be accomplished. 2712 Message Protection: 2714 Signaling message content should be protected against 2715 modification, replay, injection and eavesdropping while in 2716 transit. Authorization information, such as authorization tokens, 2717 need protection. This type of protection at the NSLP layer is 2718 neccessary to protect messages between NSLP nodes which includes 2719 end-to-middle, middle-to-middle and even end-to-end protection. 2721 In addition to the above-raised issues we see the following 2722 functionality provided at the NSLP layer: 2723 Prevention of Denial of Service Attacks: 2725 GIMPS and QoS NSLP nodes have finite resources (state storage, 2726 processing power, bandwidth). The protocol mechanisms suggested 2727 in this document should try to minimise exhaustion attacks against 2728 these resources when performing authentication and authorization 2729 for QoS resources. 2731 To some extent the QoS NSLP relies on the security mechanisms 2732 provided by GIMPS which by itself relies on existing authentication 2733 and key exchange protocols. Some signaling messages cannot be 2734 protected by GIMPS and hence should be used with care by the QoS 2735 NSLP. An API must ensure that the QoS NSLP implementation is aware 2736 of the underlying security mechanisms and must be able to indicate 2737 which degree of security is provided between two GIMPS peers. If a 2738 level of security protection for QoS NSLP messages is required which 2739 goes beyond the security offered by GIMPS or underlying security 2740 mechanisms, additional security mechanisms described in this document 2741 must be used. The different usage environments and the different 2742 scenarios where NSIS is used make it very difficult to make general 2743 statements without reducing its flexibility. 2745 10.2 Trust Model 2747 For this version of the document we will rely on a model which 2748 requires trust between neighboring NSLP nodes to establish a 2749 chain-of-trust along the QoS signaling path. This model is simple to 2750 deploy, was used in previous QoS authorization environments (such as 2751 RSVP) and seems to provide sufficiently strong security properties. 2752 We refer to this model as the 'New Jersey Turnpike' model. 2754 On the New Jersey Turnpike, motorists pick up a ticket at a toll 2755 booth when entering the highway. At the highway exit the ticket is 2756 presented and payment is made at the toll booth for the distance 2757 driven. For QoS signaling in the Internet this procedure is roughly 2758 similar. In most cases the data sender is charged for transmitted 2759 data traffic where charging is provided only between neighboring 2760 entities. 2762 +------------------+ +------------------+ +------------------+ 2763 | Network | | Network | | Network | 2764 | X | | Y | | Z | 2765 | | | | | | 2766 | -----------> -----------> | 2767 | | | | | | 2768 | | | | | | 2769 +--------^---------+ +------------------+ +-------+----------+ 2770 | . 2771 | . 2772 | v 2773 +--+---+ Data Data +--+---+ 2774 | Node | ==============================> | Node | 2775 | A | Sender Receiver | B | 2776 +------+ +------+ 2778 Legend: 2780 ----> Peering relationship which allows neighboring 2781 networks/entities to charge each other for the 2782 QoS reservation and data traffic 2784 ====> Data flow 2786 ..... Communication to the end host 2788 Figure 22: New Jersey Turnpike Model 2790 The model shown in Figure 22 uses peer-to-peer relationships between 2791 different administrative domains as a basis for accounting and 2792 charging. As mentioned above, based on the peering relationship a 2793 chain-of-trust is established. There are several issues which come 2794 to mind when considering this type of model: 2795 o This model allows authorization on a request basis or on a 2796 per-session basis. Authorization mechanisms will be elaborated in 2797 Section 3.6. The duration for which the QoS authorization is 2798 valid needs to be controlled. Combining the interval with the 2799 soft-state interval is possible. Notifications from the networks 2800 also seem to be viable approach. 2801 o The price for a QoS reservation needs to be determined somehow and 2802 communicated to the charged entity and to the network where the 2803 charged entity is attached. Price distribution protocols are not 2804 covered in this version of the document. This model assumes, per 2805 default, that the data sender is authorizing the QoS reservation. 2806 Please note that this is only a simplification and further 2807 extensions are possible and left for a future version of this 2808 document. 2810 o This architecture seems to be simple enough to allow a scalable 2811 solution (ignoring reverse charging, multicast issues and price 2812 distribution). 2814 Charging the data sender as performed in this model simplifies 2815 security handling by demanding only peer-to-peer security protection. 2816 Node A would perform authentication and key establishment. The 2817 established security association (together with the session key) 2818 would allow the user to protect QoS signaling messages. The identity 2819 used during the authentication and key establishment phase would be 2820 used by Network X (see Figure 22) to perform the so-called 2821 policy-based admission control procedure. In our context this user 2822 identifier would be used to establish the necessary infrastructure to 2823 provide authorization and charging. Signaling messages later 2824 exchanged between the different networks are then also subject to 2825 authentication and authorization. The authenticated entity thereby 2826 is, however, the neighboring network and not the end host. 2828 The New Jersey Turnpike model is attractive because of its 2829 simplicity. S. Schenker et. al. [24] discuss various accounting 2830 implications and introduced the edge pricing model. The edge pricing 2831 model shows similarity to the model described in this section with 2832 the exception that mobility and the security implications itself are 2833 not addressed. 2835 10.3 Computing the authorization decision 2837 Whenever an authorization decision has to be made then there is the 2838 question which information serves as an input to the authorizing 2839 entity. The following information items have been mentioned in the 2840 past for computing the authorization decision (in addition to the 2841 authenticated identity): 2842 Price 2843 QoS objects 2844 Policy rules 2846 Policy rules include attributes like time of day, subscription to 2847 certain services, membership, etc. into consideration when computing 2848 an authorization decision. 2850 A detailed description of the authorization handling will be left for 2851 a future version of this document. The authors assume that the QoS 2852 NSLP needs to provide a number of attributes to support the large 2853 range of scenarios. 2855 11. Change History 2856 Changes from -00 2857 * Additional explanation of RSN versus Session ID differences. 2858 (Session IDs still need to be present and aren't replaced by 2859 RSNs. Explain how QoS-NSLP could react once it notes that it 2860 maintains stale state.) 2861 * Additional explanation of message types - why we don't just 2862 have RESERVE and RESPONSE. 2863 * Clarified that figure 1 is not an implementation restriction. 2864 Changes from -01 2865 * Significant restructuring. 2866 * Added more concrete details of message formats and processing. 2867 * Added description of layering/aggregation concepts. 2868 * Added details of authentication/authorisation aspects. 2869 Changes from -02 2870 * Addressed comments from early review. 2871 * Added text on receiver-initiated and bi-directional 2872 reservations. 2873 * Extended description of session binding. Added support for 2874 fate sharing. 2875 * Restructured message formats and processing section. 2876 * Clarified refresh reduction mechanism. 2877 * Added assumptions on QoS model. 2878 * Added assumptions on operating environment. 2880 12. Acknowledgements 2882 The authors would like to thank Eleanor Hepworth for her useful 2883 comments. 2885 13. Contributors 2887 This draft combines work from three individual drafts. The following 2888 authors from these drafts also contributed to this document: Robert 2889 Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia 2890 Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and 2891 Maarten Buechli (Dante) and Eric Waegeman (Alcatel). 2893 Yacine El Mghazli (Alcatel) contributed text on AAA. 2895 14. References 2897 14.1 Normative References 2899 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2900 Levels", BCP 14, RFC 2119, March 1997. 2902 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2903 Specifications: ABNF", RFC 2234, November 1997. 2905 [3] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for 2906 Signaling", draft-ietf-nsis-ntlp-01 (work in progress), February 2907 2004. 2909 14.2 Informative References 2911 [4] Braden, B., Clark, D. and S. Shenker, "Integrated Services in 2912 the Internet Architecture: an Overview", RFC 1633, June 1994. 2914 [5] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 2915 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 2916 Specification", RFC 2205, September 1997. 2918 [6] Wroclawski, J., "The Use of RSVP with IETF Integrated 2919 Services", RFC 2210, September 1997. 2921 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2922 Considerations Section in RFCs", BCP 26, RFC 2434, October 2923 1998. 2925 [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. 2926 Weiss, "An Architecture for Differentiated Services", RFC 2475, 2927 December 1998. 2929 [9] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. 2930 Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2931 2961, April 2001. 2933 [10] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, 2934 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 2935 September 2001. 2937 [11] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session 2938 Authorization Policy Element", RFC 3520, April 2003. 2940 [12] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session 2941 Set-up with Media Authorization", RFC 3521, April 2003. 2943 [13] Chaskar, H., "Requirements of a Quality of Service (QoS) 2944 Solution for Mobile IP", RFC 3583, September 2003. 2946 [14] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 2947 April 2004. 2949 [15] Hancock, R., "Next Steps in Signaling: Framework", 2950 draft-ietf-nsis-fw-05 (work in progress), October 2003. 2952 [16] Tschofenig, H., "NSIS Authentication, Authorization and 2953 Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 (work 2954 in progress), March 2003. 2956 [17] Tschofenig, H., "QoS NSLP Authorization Issues", 2957 draft-tschofenig-nsis-qos-authz-issues-00 (work in progress), 2958 June 2003. 2960 [18] Ash, J., "NSIS Network Service Layer Protocol QoS Signaling 2961 Proof-of-Concept", 2962 draft-ash-nsis-nslp-qos-sig-proof-of-concept-01 (work in 2963 progress), February 2004. 2965 [19] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load 2966 Service with NSIS", 2967 draft-kappler-nsis-qosmodel-controlledload-00 (work in 2968 progress), February 2004. 2970 [20] Bader, A., "RMD (Resource Management in Diffserv) QoS-NSLP 2971 model", draft-bader-rmd-qos-model-00 (work in progress), 2972 February 2004. 2974 [21] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 2975 draft-ietf-nsis-threats-04 (work in progress), February 2004. 2977 [22] Westberg, L., "Resource Management in Diffserv (RMD) 2978 Framework", draft-westberg-rmd-framework-04.txt, work in 2979 progress, September 2003. 2981 [23] Breslau, L., "Two Issues in Reservation Establishment", Proc. 2982 ACM SIGCOMM '95 , Cambridge , MA , August 1995. 2984 [24] Shenker, S., Clark, D., Estrin, D. and S. Herzog, "Pricing in 2985 computer networks: Reshaping the research agenda", Proc. of 2986 TPRC 1995, 1995. 2988 [25] Metro Ethernet Forum, "Ethernet Services Model", letter ballot 2989 document , August 2003. 2991 [26] Jacobson, V., "Synchronization of Periodic Routing Messages", 2992 IEEE/ACM Transactions on Networking , Vol. 2 , No. 2 , April 2993 1994. 2995 [27] ETSI, "Telecommunications and internet protocol harmonization 2996 over networks (tiphon); open settlement protocol (osp) for 2997 inter- domain pricing, authorization, and usage exchange", 2998 Technical Specification 101 321, version 2.1.0. 3000 Authors' Addresses 3002 Sven Van den Bosch 3003 Alcatel 3004 Francis Wellesplein 1 3005 Antwerpen B-2018 3006 Belgium 3008 EMail: sven.van_den_bosch@alcatel.be 3010 Georgios Karagiannis 3011 University of Twente/Ericsson 3012 P.O. Box 217 3013 Enschede 7500 AE 3014 The Netherlands 3016 EMail: karagian@cs.utwente.nl 3018 Andrew McDonald 3019 Siemens/Roke Manor Research 3020 Roke Manor Research Ltd. 3021 Romsey, Hants SO51 0ZN 3022 UK 3024 EMail: andrew.mcdonald@roke.co.uk 3026 Appendix A. Object Definitions 3028 The currentlly specified C-Types definitions are contained in this 3029 Appendix. To accommodate other address families, additional C-Types 3030 could easily be defined. 3032 All unused fields should be sent as zero and ignored on receipt. 3034 A.1 RESPONSE_REQUEST Class 3036 RESPONSE_REQUEST Class = 1. 3038 RESPONSE_REQUEST object: Class = 1, C-Type = 1 3040 The object content is empty 3042 RESPONSE_REQUEST object: Class = 1, C-Type = 2 3044 +-------------+-------------+-------------+-------------+ 3045 | Request Identification Information (RII)(4 bytes) | 3046 +-------------+-------------+-------------+-------------+ 3048 Request Identification Information (RII) (4 bytes) 3050 An identifier which must be (probabilistically) unique 3051 within the context of a SESSION_ID, and SHOULD be different 3052 for each response request. Used by a node to match back a 3053 RESPONSE to a request in a RESERVE or QUERY message. 3055 A.2 RSN Class 3057 RSN class = 2. 3059 RSN object: Class = 2, C-Type = 1 3061 +-------------+-------------+-------------+-------------+ 3062 | Reservation Sequence Number (RSN) (4 bytes) | 3063 +-------------+-------------+-------------+-------------+ 3065 Reservation Sequence Number (RSN) (4 bytes) 3067 An incrementing sequence number that indicates the order in 3068 which state modifying actions are performed by a QNE. It 3069 has local significance only, i.e. between a pair of 3070 neighbouring stateful QNEs. 3072 A.3 REFRESH_PERIOD Class 3074 REFRESH_PERIOD class = 3. 3076 REFRESH_PERIOD Object: Class = 3, C-Type = 1 3078 +-------------+-------------+-------------+-------------+ 3079 | Refresh Period R (4 bytes) | 3080 +-------------+-------------+-------------+-------------+ 3082 Refresh Period R (4 bytes) 3084 The refresh timeout period R used to generate this message; 3085 in milliseconds. 3087 A.4 SESSION_ID Class 3089 SESSION_ID class = 4. 3091 SESSION_ID Object: Class = 4, C-Type = 1 3093 +-------------+-------------+-------------+-------------+ 3094 | | 3095 + + 3096 | | 3097 + SESSION_ID (16 bytes) + 3098 | | 3099 + + 3100 | | 3101 +-------------+-------------+-------------+-------------+ 3103 SESSION_ID (16 bytes) 3105 It represents the SESSION_ID as specified in [15] of the 3106 session that must be bound to the session associated to the 3107 message carrying this object. 3109 A.5 SCOPING Class 3111 SCOPING class = 5. 3113 SCOPING Object: Class = 5, C-Type = 1 3115 No content value. Selection of a single hop message scoping. 3117 SCOPING Object: Class = 5, C-Type = 2 3119 +-------------+-------------+-------------+-------------+ 3120 | Region scoping (4 bytes) | 3121 +-------------+-------------+-------------+-------------+ 3123 Region scoping (4 bytes) 3125 Ordered number, forwarded by routers belonging to region 3126 with same or higher number; 3128 SCOPING Object: Class = 5, C-Type = 3 3130 +-------------+-------------+-------------+-------------+ 3131 | RII scoping (4 bytes) | 3132 +-------------+-------------+-------------+-------------+ 3134 RII (back to me) scoping (4 bytes) 3136 An identifier which must be (probabilistically) unique 3137 within the context of a SESSION_ID, and SHOULD be different 3138 for each response request. Used by a node to match back a 3139 RESPONSE to a request in a RESERVE or QUERY message. 3141 A.6 ERROR_SPEC Class 3142 ERROR_SPEC class = 6. 3144 ERROR_SPEC object: Class = 6, C-Type = 1 3146 +-------------+-------------+-------------+-------------+ 3147 | Error (4 bytes) | 3148 +-------------+-------------+-------------+-------------+ 3149 | Flags | Error Code | Error Value | 3150 +-------------+-------------+-------------+-------------+ 3152 Error (4 bytes) 3154 To be done 3156 Flags (1 byte) 3158 To be done 3160 Error Code (1 byte) 3162 A one-octet error description. 3164 Error Value (2 bytes) 3166 A two-octet field containing additional information about 3167 the error. Its contents depend upon the Error Type. 3169 The values for Error Code and Error Value are defined in 3170 Appendix B (to be done). 3172 A.7 POLICY_DATA Class 3174 This section presents a set of specifications for supporting generic 3175 authorization in QoS NSLP. These specs include the standard format 3176 of POLICY_DATA objects, and a description of QoS NSLP handling of 3177 authorization events. This section does not advocate a particular 3178 authorization approach (2-party, 3-party, token-based 3-party). 3180 The traffic control block is responsible for controlling and 3181 enforcing access and usage policies. 3183 A.7.1 Base Format 3185 POLICY_DATA object: Class=7, C-Type=1 3187 +-------------------------------------------------------+ 3188 | | 3189 // Option List // 3190 | | 3191 +-------------------------------------------------------+ 3192 | | 3193 // Policy Element List // 3194 | | 3195 +-------------------------------------------------------+ 3197 Option List: Variable length. See more details in Appendix A.7.2. 3198 Policy Element List: Variable length. See more details in Appendix 3199 A.7.3. 3201 A.7.2 Options 3203 This section describes a set of options that may appear in 3204 POLICY_DATA objects. Some policy options appear as QoS NSLP objects 3205 but their semantic is modified when used as policy data options. 3207 Policy Refresh TIME_VALUES (PRT) object: 3209 The Policy Refresh TIME_VALUES (PRT) option is used to slow policy 3210 refresh frequency for policies that have looser timing constraints 3211 relative to QoS NSLP. If the PRT option is present, policy 3212 refreshes can be withheld as long as at least one refresh is sent 3213 before the policy refresh timer expires. A minimal value for PRT 3214 is the NSLP session refresh period R; lower values are assumed to 3215 be R (neither error nor warning should be triggered). This option 3216 is especially useful to combine strong (high overhead) and weak 3217 (low overhead) authentication certificates as policy data. In 3218 such schemes the weak certificate can support admitting a 3219 reservation only for a limited time, after which the strong 3220 certificate is required. This approach may reduce the overhead of 3221 POLICY_DATA processing. Strong certificates could be transmitted 3222 less frequently, while weak certificates are included in every QoS 3223 NSLP refresh. 3225 Policy Source Identification Information (PSII) object: 3227 The Policy SII object identifies the neighbor/peer policy-capable 3228 QN that constructed the policy object. When policy is enforced at 3229 border QNEs, peer policy nodes may be several NSLP hops away from 3230 each other and the SII is the basis for the mechanism that allows 3231 them to recognize each other and communicate safely and directly. 3232 As stated above, we assume such an (P)SII to be available from a 3233 service from GIMPS. If no PSII object is present, the policy data 3234 is implicitly assumed to have been constructed by the QoS NSLP HOP 3235 indicated in the SII (i.e., the neighboring QoS NSLP node is 3236 policy-capable). 3238 Integrity object: 3240 The INTEGRITY object option inside POLICY_DATA object creates 3241 direct secure communications between non-neighboring policy aware 3242 nodes without involving PIN nodes. 3244 A.7.3 Policy Elements 3246 There are no requirements for all nodes to process this container. 3247 Policy data is opaque to NSLP, which simply passes it to policy 3248 control when required. 3250 The content of policy elements is opaque to the QoS NSLP layer. Only 3251 policy peers understand their internal format and NSLP layer simply 3252 passes it to policy control when required. 3254 Policy Elements have the following format: 3256 +-------------+-------------+-------------+-------------+ 3257 | Length | P-Type | 3258 +---------------------------+---------------------------+ 3259 | | 3260 // Policy information (Opaque to QoS NSLP) // 3261 | | 3262 +-------------------------------------------------------+ 3264 A.7.3.1 Authorization token Policy Element 3266 The AUTHZ_TOKEN policy element contains a list of fields, which 3267 describe the session, along with other attributes. 3269 +-------------+-------------+-------------+-------------+ 3270 | Length | P-Type = AUTHZ_TOKEN | 3271 +-------------+-------------+-------------+-------------+ 3272 // Session Authorization Attribute List // 3273 +-------------------------------------------------------+ 3275 Session Authorization Attribute List: variable length. The 3276 session authorization attribute list is a collection of objects 3277 which describes the session and provides other information 3278 necessary to verify the resource reservation request. See [11] 3279 for a details. 3280 Session Authorization Attributes. A session authorization 3281 attribute may contain a variety of information and has both an 3282 attribute type and subtype. The attribute itself MUST be a 3283 multiple of 4 octets in length, and any attributes that are not a 3284 multiple of 4 octets long MUST be padded to a 4-octet boundary. 3285 All padding bytes MUST have a value of zero. 3287 +--------+--------+--------+--------+ 3288 | Length | X-Type |SubType | 3289 +--------+--------+--------+--------+ 3290 | Value ... | 3291 +--------+--------+--------+--------+ 3293 Length: 16 bits 3295 The length field is two octets and indicates the actual length of 3296 the attribute (including Length, X-Type and SubType fields) in 3297 number of octets. The length does NOT include any bytes padding 3298 to the value field to make the attribute a multiple of 4 octets 3299 long. 3301 X-Type: 8 bits 3303 Session authorization attribute type (X-Type) field is one octet. 3304 IANA acts as a registry for X-Types as described in Section 6. 3305 Initially, the registry contains the following X-Types: 3306 1 AUTH_ENT_ID: The unique identifier of the entity which 3307 authorized the session. 3308 2 SESSION_ID: Unique identifier for this session. 3309 3 SOURCE_ADDR: Address specification for the session originator. 3311 4 DEST_ADDR: Address specification for the session end-point. 3312 5 START_TIME: The starting time for the session. 3313 6 END_TIME: The end time for the session. 3314 7 RESOURCES: The resources which the user is authorized to 3315 request. 3316 8 AUTHENTICATION_DATA: Authentication data of the session 3317 authorization policy element. 3318 SubType: 8 bits 3320 Session authorization attribute sub-type is one octet in length. 3321 The value of the SubType depends on the X-Type. 3323 Value: variable length 3325 The attribute specific information is defined in [11]. 3327 A.7.3.2 OSP Token Policy Element 3329 To be completed. 3331 A.7.3.3 User Identity Policy element 3333 To be completed. 3335 A.8 QSPEC Class 3337 QSPEC class = 8. 3339 QSPEC object: Class = 8, C-Type = (QoS model ID) 3341 This object contains the QSPEC (QoS specification) information. 3342 Its content has a variable length and it is QoS model specific. 3343 Such a QoS model can be a standardized one, a private one, or a 3344 well-known one. The C-Type contains the QoS model ID that 3345 identifies the used QSPEC. 3347 The contents and encoding rules for this object are specified 3348 in other documents, prepared by QoS model designers. 3350 Intellectual Property Statement 3352 The IETF takes no position regarding the validity or scope of any 3353 Intellectual Property Rights or other rights that might be claimed to 3354 pertain to the implementation or use of the technology described in 3355 this document or the extent to which any license under such rights 3356 might or might not be available; nor does it represent that it has 3357 made any independent effort to identify any such rights. Information 3358 on the procedures with respect to rights in RFC documents can be 3359 found in BCP 78 and BCP 79. 3361 Copies of IPR disclosures made to the IETF Secretariat and any 3362 assurances of licenses to be made available, or the result of an 3363 attempt made to obtain a general license or permission for the use of 3364 such proprietary rights by implementers or users of this 3365 specification can be obtained from the IETF on-line IPR repository at 3366 http://www.ietf.org/ipr. 3368 The IETF invites any interested party to bring to its attention any 3369 copyrights, patents or patent applications, or other proprietary 3370 rights that may cover technology that may be required to implement 3371 this standard. Please address the information to the IETF at 3372 ietf-ipr@ietf.org. 3374 Disclaimer of Validity 3376 This document and the information contained herein are provided on an 3377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3379 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3380 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3381 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3384 Copyright Statement 3386 Copyright (C) The Internet Society (2004). This document is subject 3387 to the rights, licenses and restrictions contained in BCP 78, and 3388 except as set forth therein, the authors retain all their rights. 3390 Acknowledgment 3392 Funding for the RFC Editor function is currently provided by the 3393 Internet Society.