idnits 2.17.1 draft-ietf-nsis-qos-nslp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3733. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6767 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) == Missing Reference: 'RFC1982' is mentioned on line 2337, but not defined == Missing Reference: 'QoS-Template' is mentioned on line 2551, but not defined == Missing Reference: 'FIXME' is mentioned on line 3339, but not defined == Unused Reference: 'RFC2119' is defined on line 3371, but no explicit reference was found in the text == Unused Reference: 'I-D.kappler-nsis-qosmodel-controlledload' is defined on line 3396, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 3436, but no explicit reference was found in the text == Unused Reference: 'RFC3583' is defined on line 3454, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-10) exists of draft-ietf-nsis-y1541-qosm-00 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-06 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-rmd-03 == Outdated reference: A later version (-14) exists of draft-kappler-nsis-qosmodel-controlledload-01 == Outdated reference: A later version (-02) exists of draft-loughney-nsis-ext-00 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Next Steps in Signalling J. Manner (ed.) 3 Internet-Draft University of Helsinki 4 Expires: April, 2006 G. Karagiannis 5 University of Twente/Ericsson 6 A. McDonald 7 Siemens/Roke Manor Research 8 S. Van den Bosch 9 Alcatel 10 October 2005 12 NSLP for Quality-of-Service signalling 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire in April, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This draft describes an NSIS Signalling Layer Protocol (NSLP) for 47 signalling QoS reservations in the Internet. It is in accordance with 48 the framework and requirements developed in NSIS. Together with 49 GIST, it provides functionality similar to RSVP and extends it. The 50 QoS NSLP is independent of the underlying QoS specification or 51 architecture and provides support for different reservation models. 52 It is simplified by the elimination of support for multicast flows. 53 This draft explains the overall protocol approach, design decisions 54 made and provides examples. It specifies object and message formats 55 and processing rules. 57 Table of Contents 59 1 Introduction ................................................. 4 60 1.1 Scope and background ....................................... 4 61 1.2 Model of operation ......................................... 5 62 2 Terminology .................................................. 7 63 3 Protocol Overview ............................................ 9 64 3.1 Overall approach ........................................... 9 65 3.1.1 GIST Interactions ........................................ 9 66 3.1.2 Protocol messages ........................................ 9 67 3.1.3 QoS Models and QoS Specifications ........................ 10 68 3.1.4 Policy control ........................................... 11 69 3.2 Design decisions ........................................... 13 70 3.2.1 Soft-state ............................................... 13 71 3.2.2 Sender-receiver initiation ............................... 13 72 3.2.3 Message sequencing ....................................... 13 73 3.2.4 Explicit state installation confirmation and responses ... 14 74 3.2.5 Reduced refresh .......................................... 14 75 3.2.6 Message scoping .......................................... 14 76 3.2.7 Session binding .......................................... 15 77 3.2.8 Layering ................................................. 15 78 3.2.8.1 Local QoS models ....................................... 15 79 3.2.8.2 Local control plane properties ......................... 16 80 3.2.8.3 Aggregate reservations ................................. 16 81 3.2.9 Priority ................................................. 17 82 3.2.10 Rerouting ............................................... 17 83 4 Examples of QoS NSLP Operation ............................... 20 84 4.1 Basic sender-initiated reservation ......................... 20 85 4.2 Sending a Query ............................................ 22 86 4.3 Basic receiver-initiated reservation ....................... 22 87 4.4 Bidirectional Reservations ................................. 24 88 4.5 Use of Local QoS Models .................................... 25 89 4.6 Aggregate Reservations ..................................... 26 90 4.7 Reduced State or Stateless Interior Nodes .................. 27 91 4.8 Re-routing scenario ........................................ 29 92 4.9 Authorization Model Examples ............................... 30 93 4.9.1 Authorization for the two party approach ................. 31 94 4.9.2 Token based three party approach ......................... 31 95 4.9.3 Generic three party approach ............................. 32 96 5 QoS NSLP Functional specification ............................ 33 97 5.1 QoS NSLP Message and Object Formats ........................ 33 98 5.1.1 Common header ............................................ 33 99 5.1.2 Message formats .......................................... 34 100 5.1.2.1 RESERVE ................................................ 34 101 5.1.2.2 QUERY .................................................. 35 102 5.1.2.3 RESPONSE ............................................... 36 103 5.1.2.4 NOTIFY ................................................. 37 104 5.1.3 Object Formats ........................................... 37 105 5.1.3.1 Request Identification Information (RII) ............... 38 106 5.1.3.2 Reservation Sequence Number (RSN) ...................... 38 107 5.1.3.3 REFRESH_PERIOD ......................................... 39 108 5.1.3.4 BOUND_SESSION_ID ....................................... 39 109 5.1.3.5 PACKET_CLASSIFIER ...................................... 39 110 5.1.3.6 INFO_SPEC .............................................. 41 111 5.1.3.7 QSPEC .................................................. 43 112 5.1.3.8 POLICY_DATA ............................................ 43 113 5.2 General Processing Rules ................................... 44 114 5.2.1 State Manipulation ....................................... 44 115 5.2.2 Message Forwarding ....................................... 45 116 5.2.3 Standard Message Processing Rules ........................ 45 117 5.2.4 Retransmissions .......................................... 45 118 5.3 Object Processing .......................................... 46 119 5.3.1 Reservation Sequence Number (RSN) ........................ 46 120 5.3.2 Request Identification Information (RII) ................. 46 121 5.3.3 BOUND_SESSION_ID ......................................... 47 122 5.3.4 REFRESH_PERIOD ........................................... 48 123 5.3.5 INFO_SPEC ................................................ 50 124 5.3.6 QSPEC .................................................... 50 125 5.4 Message Processing Rules ................................... 50 126 5.4.1 RESERVE Messages ......................................... 51 127 5.4.2 QUERY Messages ........................................... 54 128 5.4.3 RESPONSE Messages ........................................ 55 129 5.4.4 NOTIFY Messages .......................................... 56 130 6 IANA considerations .......................................... 56 131 7 QoS use of GIST service interface ............................ 57 132 7.1 Example sender-initiated reservation ....................... 57 133 7.2 Session identification ..................................... 58 134 7.3 Support for bypassing intermediate nodes ................... 58 135 7.4 Support for peer change identification ..................... 59 136 7.5 Support for stateless operation ............................ 59 137 7.6 Last node detection ........................................ 59 138 7.7 Re-routing detection ....................................... 60 139 7.8 Priority of signalling messages ............................ 60 140 7.9 Knowledge of intermediate QoS NSLP unaware nodes ........... 60 141 7.10 NSLP Data Size ............................................ 61 142 7.11 Notification of GIST 'D' flag value ....................... 61 143 7.12 NAT Traversal ............................................. 61 144 8 Assumptions on the QoS Model ................................. 61 145 8.1 Resource sharing ........................................... 61 146 8.2 Reserve/commit support ..................................... 62 147 9 Security Considerations ...................................... 62 148 9.1 Introduction and Threat Overview ........................... 62 149 9.2 Trust Model ................................................ 63 150 9.3 Computing the authorization decision ....................... 65 151 10 Open Issues ................................................. 65 152 11 Acknowledgements ............................................ 65 153 12 Contributors ................................................ 66 154 13 References .................................................. 66 155 13.1 Normative References ...................................... 66 156 13.2 Informative References .................................... 66 158 1. Introduction 160 1.1. Scope and background 162 This document defines a Quality of Service (QoS) NSIS Signalling 163 Layer Protocol (NSLP), henceforth referred to as the "QoS NSLP". This 164 protocol establishes and maintains state at nodes along the path of a 165 data flow for the purpose of providing some forwarding resources for 166 that flow. It is intended to satisfy the QoS-related requirements of 167 RFC 3726 [RFC3726]. This QoS NSLP is part of a larger suite of 168 signalling protocols, whose structure is outlined in the NSIS 169 framework [RFC4080]; this defines a common NSIS Transport Layer 170 Protocol (NTLP) which QoS NSLP uses to carry out many aspects of 171 signalling message delivery. A specification of the NTLP, GIST [I- 172 D.ietf-nsis-ntlp] is done in another document. 174 The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 175 [RFC2205], and uses soft-state peer-to-peer refresh messages as the 176 primary state management mechanism (i.e. state installation/refresh 177 is performed between pairs of adjacent NSLP nodes, rather than in an 178 end-to-end fashion along the complete signalling path). Although 179 there is no backwards compatibility at the level of protocol 180 messages, interworking with RSVP at a signalling application gateway 181 would be possible in some circumstances. QoS NSLP extends the set of 182 reservation mechanisms to meet the requirements of RFC 3726 183 [RFC3726], in particular support of sender or receiver-initiated 184 reservations, as well as a type of bi-directional reservation and 185 support of reservations between arbitrary nodes, e.g. edge-to-edge, 186 end-to-access, etc. On the other hand, there is no explicit support 187 for IP multicast. 189 A distinction is made between the operation of the signalling 190 protocol and the information required for the operation of the 191 Resource Management Function (RMF). This document describes the 192 signalling protocol, whilst [I-D.ietf-nsis-qspec] describes the RMF- 193 related information carried in the QSPEC (QoS Specification) object 194 in QoS NSLP messages. This is similar to the decoupling between RSVP 195 and the IntServ architecture, RFC 1633 [RFC1633]. The QSPEC carries 196 information on resources available, resources required, traffic 197 descriptions and other information required by the RMF. 199 This document is structured as follows. The overall approach to 200 protocol design is outlined in Section 3.1. The operation and use of 201 QoS NSLP is then clarified by means of a number of examples in 202 Section 4. These sections should be read by readers interested in the 203 protocol capabilities. The functional specification Section 5 204 contains more detailed object and message formats and processing 205 rules and should be the basis for implementers. The subsequent 206 sections describe extensibility (IANA), requirements on GIST API and 207 security considerations. 209 1.2. Model of operation 211 This section presents a logical model for the operation of the QoS- 212 NSLP and associated provisioning mechanisms within a single node. 213 The model is shown in Figure 1. 215 +---------------+ 216 | Local | 217 |Applications or| 218 |Management (e.g| 219 |for aggregates)| 220 +---------------+ 221 ^ 222 V 223 V 224 +----------+ +----------+ +---------+ 225 | QoS NSLP | | Resource | | Policy | 226 |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control | 227 +----------+ +----------+ +---------+ 228 . ^ | * ^ 229 | V . * ^ 230 +----------+ * ^ 231 | NTLP | * ^ 232 |Processing| * V 233 +----------+ * V 234 | | * V 235 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 236 . . * V 237 | | * ............................. 238 . . * . Traffic Control . 239 | | * . +---------+. 240 . . * . |Admission|. 241 | | * . | Control |. 242 +----------+ +------------+ . +---------+. 243 <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> 244 | Packet | | Interface | .+----------+ +---------+. 245 ===>|Processing|====| Selection |===.| Packet |====| Packet |.==> 246 | | |(Forwarding)| .|Classifier| Scheduler|. 247 +----------+ +------------+ .+----------+ +---------+. 248 ............................. 249 <.-.-> = signalling flow 250 =====> = data flow (sender --> receiver) 251 <<<>>> = control and configuration operations 252 ****** = routing table manipulation 254 Figure 1: QoS NSLP in a Node 256 This diagram shows an example implementation scenario where QoS 257 conditioning is performed on the output interface. However, this 258 does not limit the possible implementations. For example, in some 259 cases traffic conditioning may be performed on the incoming 260 interface, or it may be split over the input and output interfaces. 261 Also, the interactions with the Policy Control component may be more 262 complex, involving more than a simple interaction with the Resource 263 Management Function. 265 From the perspective of a single node, the request for QoS may result 266 from a local application request, or from processing an incoming QoS- 267 NSLP message. 269 o The request from a local application includes not only user 270 applications (e.g. multimedia applications) but also network 271 management (e.g. initiating a tunnel to handle an aggregate, or 272 interworking with some other reservation protocol - such as RSVP) 273 and the policy control module (e.g. for explicit teardown 274 triggered by AAA). In this sense, the model does not distinguish 275 between hosts and routers. 277 o Incoming messages are captured during input packet processing 278 and handled by GIST. Only messages related to QoS are passed to 279 the QoS NSLP. GIST may also generate triggers to the QoS NSLP 280 (e.g. indications that a route change has occurred). 282 The QoS request is handled by a local 'resource management' 283 function, which coordinates the activities required to grant and 284 configure the resource. It also handles policy-specific aspects 285 of QoS signaling. 287 o The grant processing involves two local decision modules, 288 'policy control' and 'admission control'. Policy control 289 determines whether the user has administrative permission to make 290 the reservation. Admission control determines whether the node 291 has sufficient available resources to supply the requested QoS. 293 o If both checks succeed, parameters are set in the packet 294 classifier and in the link layer interface (e.g., in the packet 295 scheduler) to obtain the desired QoS. Error notifications are 296 passed back to the request originator. The resource management 297 function may also manipulate the forwarding tables at this stage, 298 to select (or at least pin) a route; this must be done before 299 interface-dependent actions are carried out (including forwarding 300 outgoing messages over any new route), and is in any case 301 invisible to the operation of the protocol. 303 Policy control is expected to make use of a AAA service external to 304 the node itself. Some discussion can be found in a separate document 305 on AAA issues [I-D.tschofenig-nsis-aaa-issues] and one on 306 authorization issues [I-D.tschofenig-nsis-qos-authz-issues]. More 307 generally, the processing of policy and resource management functions 308 may be outsourced to an external node leaving only 'stubs' co-located 309 with the NSLP; this is not visible to the protocol operation, 310 although it may have some influence on the detailed design of 311 protocol messages to allow the stub to be minimally complex. A more 312 detailed discussion on authentication and authorization can be found 313 in Section 3.1.4. 315 The group of user plane functions, which implement QoS for a flow 316 (admission control, packet classification, and scheduling) is 317 sometimes known as 'traffic control'. 319 Admission control, packet scheduling, and any part of policy control 320 beyond simple authentication have to be implemented using specific 321 definitions for types and levels of QoS; Our assumption is that the 322 QoS NSLP is independent of the QoS parameters (e.g. IntServ service 323 elements). These are captured in a QoS Model and interpreted only by 324 the resource management and associated functions, and are opaque to 325 the QoS NSLP itself. QoS Models are discussed further in Section 326 3.1.3. 328 The final stage of processing for a resource request is to indicate 329 to the QoS NSLP protocol processing that the required resources have 330 been configured. The QoS NSLP may generate an acknowledgement 331 message in one direction, and may forward the resource request in the 332 other. Message routing is (by default) carried out by the GIST 333 module. Note that while Figure 1 shows a unidirectional data flow, 334 the signalling messages can pass in both directions through the node, 335 depending on the particular message and orientation of the 336 reservation. 338 2. Terminology 340 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 341 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 342 document are to be interpreted as described in RFC 2119. 344 The terminology defined by GIST [I-D.ietf-nsis-ntlp] applies to this 345 draft. 347 In addition, the following terms are used: 349 QNE: an NSIS Entity (NE), which supports the QoS NSLP. 351 QNI: the first node in the sequence of QNEs that issues a 352 reservation request for a session. 354 QNR: the last node in the sequence of QNEs that receives a 355 reservation request for a session. 357 Session: A "session" is essentially a signaling application 358 concept, since it is only used in non-trivial state management 359 actions that are application specific. A session defines an 360 association between a QNI and QNR related to a data flow. All QNEs 361 on the path, including the QNI and QNR, use the same identifier to 362 refer to the state stored for the association. The same QNI and 363 QNR may have more than one session active at any one time. The 364 session identifier should be (probabilistically) globally unique, 365 and it should not be modified end-to-end. 367 Session Identification (SESSION_ID, SID): This is a 368 cryptographically random and (probabilistically) globally unique 369 identifier of the application layer session that associated with a 370 certain flow. For a given flow, different signaling applications 371 may or may not use the same session identifier. Often there will 372 only be one flow for a given session, but in mobility/multihoming 373 scenarios there may be more than one and they may be differently 374 routed [RFC4080]. 376 Source or message source: The one of two adjacent NSLP peers that 377 is sending a signalling message (maybe the upstream or the 378 downstream peer). NB: this is not necessarily the QNI. 380 QoS NSLP operation state: state used/kept by QoS NSLP processing 381 to handle messaging aspects. 383 QoS reservation state: state used/kept by Resource Management 384 Function to describe reserved resources for a session. 386 Figure 2 shows the components that have a role in a QoS NSLP 387 signaling session. The flow sender and receiver would in most cases 388 be part of the QNI and QNR nodes. Yet, these may be separate nodes, 389 too. 391 QoS NSLP nodes 392 IP address (QoS unaware NSIS nodes are IP address 393 = Flow not shown) = Flow 394 Source | | | Destination 395 Address | | | Address 396 V V V 397 +--------+ Data +------+ +------+ +------+ +--------+ 398 | Flow |-------|------|------|------|-------|------|---->| Flow | 399 | Sender | Flow | | | | | | |Receiver| 400 +--------+ | QNI | | QNE | | QNR | +--------+ 401 | | | | | | 402 +------+ +------+ +------+ 403 =====================> 404 <===================== 405 Signalling 406 Flow 407 Figure 2: Components of the QoS NSLP architecture. 409 A glossary of terms and abbreviations used in this document can be 410 found in Appendix A. 412 3. Protocol Overview 414 3.1. Overall approach 416 3.1.1. GIST Interactions 418 The QoS NSLP uses GIST for delivery of all its messages. Messages 419 are normally passed from the NSLP to GIST via an API (defined in 420 Appendix D of [I-D.ietf-nsis-ntlp]), which also specifies additional 421 information, including an identifier for the signalling application 422 (e.g. 'QoS NSLP'), the flow/session identifier, and an indication of 423 the intended direction - towards data sender or receiver. On 424 reception, GIST provides the same information to the QoS NSLP. In 425 addition to the NSLP message data itself, other meta-data (e.g. 426 session identifier, flow routing information) can be transferred 427 across this interface. 429 The QoS NSLP does not provide any method of interacting with 430 firewalls or Network Address Translators (NATs). It assumes that a 431 basic NAT traversal service is provided by GIST. 433 3.1.2. Protocol messages 435 The QoS NSLP uses four message types: 437 RESERVE: The RESERVE message is the only message that manipulates 438 QoS NSLP reservation state. It is used to create, refresh, modify 439 and remove such state. The RESERVE message is idempotent; the 440 resultant effect is the same whether a message is received once or 441 many times. 443 QUERY: A QUERY message is used to request information about the 444 data path without making a reservation. This functionality can be 445 used to 'probe' the network for path characteristics, for 446 receiver- initiated reservations or for support of certain QoS 447 models. The information obtained from a QUERY may be used in the 448 admission control process of a QNE (e.g. in case of measurement- 449 based admission control). Note that a QUERY does not change 450 existing reservation state. It does not cause QoS NSLP state to 451 be installed in nodes other than the one that generated the QUERY. 453 RESPONSE: The RESPONSE message is used to provide information 454 about the result of a previous QoS NSLP message. This includes 455 explicit confirmation of the state manipulation signaled in the 456 RESERVE message, the response to a QUERY message or an error code 457 if the QNE or QNR is unable to provide the requested information 458 or if the response is negative. The RESPONSE message is impotent, 459 it does not cause any reservation state to be installed or 460 modified. 462 NOTIFY: NOTIFY messages are used to convey information to a QNE. 464 They differ from RESPONSE messages in that they are sent 465 asynchronously and need not refer to any particular state or 466 previously received message. The information conveyed by a NOTIFY 467 message is typically related to error conditions. Examples would 468 be notification to an upstream peer about state being torn down or 469 to indicate when a reservation has been pre-empted. 471 QoS NSLP messages are sent peer-to-peer. This means that a QNE 472 considers its adjacent upstream or downstream peer to be the source 473 of the each message. 475 Each protocol message has a common header which indicates the message 476 type and contains flags. Message formats are defined in Section 477 5.1.2. Message processing rules are defined in Section 5.4. 479 QoS NSLP messages contain three types of objects: 481 1. Control Information: Control information objects carry general 482 information for the QoS NSLP processing, such as sequence numbers 483 or whether a response is required. 485 2. QoS specifications (QSPECs): QSPEC objects describe the actual 486 resources that are required and depend on the QoS model being 487 used. Besides any resource description they may also contain 488 other control information used by the RMF's processing. 490 3. Policy objects: Policy objects contain data used to authorise 491 the reservation of resources. 493 Object formats are defined in Section 5.1.3. Object processing rules 494 are defined in Section 5.3. 496 3.1.3. QoS Models and QoS Specifications 498 QoS NSLP provides flexibility over the exact patterns of signalling 499 messages that are exchanged. The decoupling of QoS NSLP and QSPEC 500 allows the QoS NSLP to be ignorant about the ways in which traffic, 501 resources, etc. are described, and it can treat the QSPEC as an 502 opaque object. 504 The QSPEC fulfills a similar purpose to the TSpec, RSpec and AdSpec 505 objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC 506 2210 [RFC2210]. At each QNE, its content is interpreted by the 507 Resource Management Function and the Policy Control Function for the 508 purposes of policy control and traffic control (including admission 509 control and configuration of the packet classifier and scheduler). 511 QoS NSLP does not mandate any particular behaviour for the RMF, 512 instead demanding interoperability at the signalling protocol whilst 513 leaving the validation of RMF behaviour to SLAs or contracts external 514 to the protocol itself. The RMF may make use of various elements from 515 the QoS NSLP message, not only the QSPEC object. 517 The QSPEC carries a collection of objects that can describe QoS 518 specifications in a number of different ways. A QSPEC will usually 519 contain some objects which need to be understood by all 520 implementations, and it can also be enhanced with additional objects 521 to provide a more exact definition to the RMF, which may be better 522 able to use its specific resource management mechanisms (which may, 523 e.g., be link specific) as a result. 525 A QoS Model defines the behavior of the RMF, including inputs and 526 outputs, and how QSPEC information is used to describe resources 527 available, resources required, traffic descriptions, and control 528 information required by the RMF. A QoS Model also describes the 529 minimum set of parameters QNEs should use in the QSPEC when signaling 530 about this QoS Model. 532 QoS Models may be local (private to one network), implementation/ 533 vendor specific, or global (implementable by different networks and 534 vendors). The authors are currently aware of three efforts related 535 to QoS Model specification: IntServ Controlled Load [I-D.kappler- 536 nsis-qosmodel-controlledload], ITU Y.1541 [I-D.ash-nsis-y1541-qosm], 537 and Resource Management for DiffServ (RMD) [I-D.ietf-nsis-rmd]. 539 The definition of a QoS model may also have implications on how local 540 behaviour should be implemented in the areas where the QoS NSLP gives 541 freedom to implementers. For example, it may be useful to identify 542 recommended behaviour for how a RESERVE message that is forwarded 543 relates to that received, or when additional signalling sessions 544 should be started based on existing sessions, such as required for 545 aggregate reservations. In some cases, suggestions may be made on 546 whether state that may optionally be retained should be held in 547 particular scenarios. Moreover, a QoS model may specify reservation 548 pre-emption, e.g., an incoming resource request may cause removal of 549 an earlier reservation. 551 An ongoing effort attempts to specify a QSPEC template [I-D.ietf- 552 nsis-qspec]. The QSPEC template contains object formats for 553 generally useful elements of the QoS description, which is designed 554 to ensure interoperability when using the basic set of objects. 556 3.1.4. Policy control 558 Getting access to network resources typically involves some kind of 559 policy control. One example of this is authorisation of the resource 560 requester. Policy control for QoS NSLP resource reservation 561 signalling is conceptually organised as illustrated below in Figure 562 3. 564 +-------------+ 565 | Policy | 566 | Decision | 567 | Point (PDP) | 568 +------+------+ 569 | 570 | 571 /-\-----+-----/\ 572 //// \\\\ 573 || || 574 | Policy transport | 575 || || 576 \\\\ //// 577 \-------+------/ 578 | 579 +-------------+ QoS signalling +------+------+ 580 | Entity |<==============>| QNE = Policy|<=========> 581 | requesting | Data Flow | Enforcement | 582 | resource |----------------|-Point (PEP)-|----------> 583 +-------------+ +-------------+ 585 Figure 3: Policy control with the QoS NSLP signaling. 587 From QoS NSLP point of view, the policy control model is essentially 588 a two-party model between neighbouring QNEs. The actual policy 589 decision may depend on the involvement of a third entity (the policy 590 decision point, PDP), but this happens outside of the QoS NSLP 591 protocol by means of existing policy infrastructure (COPS, Diameter, 592 etc). The policy control model for the entire end-to-end chain of 593 QNEs is therefore one of transitivity, where each of the QNEs 594 exchanges policy information with its QoS NSLP policy peer. 596 The input to policy control is referred to as "Policy data", some of 597 which QoS NSLP carries in the POLICY_DATA object while other 598 information is provided across the GIST API. Policy data itself is 599 opaque to the QoS NSLP, which simply passes it to policy control when 600 required. The policy data is independent from the QoS model in use. 602 Two options are currently considered for support by QoS NSLP policy 603 control: 605 a. Reuse of GIST channel security mechanisms 607 b. Carrying (authorisation) tokens 609 The fist option is preferred as it relies on existing security 610 measures. This can be controlled through the GIST API. The second 611 option is supported through [FIXME: FILL IN HANNES' WORK] 613 It is generally assumed that policy enforcement is likely to 614 concentrate on border nodes between administrative domains. In some 615 cases policy objects transmitted across the domain traverse an 616 intermediate Policy Ignorant Node (PIN) that is allowed to process 617 QoS NSLP message but does not handle policy information. The policy 618 peering between ingress and egress edge of a domain therefore relies 619 on the internal chain of trust between the nodes in the domain. If 620 this is not acceptable, a separate signalling session can be set up 621 between the edge node in order to exchange policy information. This 622 is similar to the aggregation mechanism. 624 3.2. Design decisions 626 QoS NSLP was designed according to the following principles. 628 3.2.1. Soft-state 630 The NSIS protocol suite takes a soft-state approach to state 631 management. This means that reservation state in QNEs must be 632 periodically refreshed. The frequency with which state installation 633 is refreshed is expressed in the REFRESH_PERIOD object. This object 634 contains a value in milliseconds indicating how long the state that 635 is signalled for remains valid. Maintaining the reservation beyond 636 this lifetime can be done by sending periodically a RESERVE message. 638 3.2.2. Sender-receiver initiation 640 QoS NSLP supports both sender-initiated and receiver-initiated 641 reservations. For a sender-initiated reservation, RESERVE messages 642 travel in the same direction as the dataflow that is being signalled 643 for (the QNI is at the side of the source of the dataflow). 645 For a receiver-initiated reservation, RESERVE messages travel in the 646 opposite direction (the QNI is at the side of the receiver of the 647 data flow). Before sending the RESERVE, the sender of the data first 648 sends a QUERY message with the R-bit set that creates the required 649 GIST path state. The QUERY message is needed due to the asymmetric 650 nature of IP routing. 652 Note: these definitions follow the definitions in Section 3.3.1. of 653 RFC 4080 [RFC4080]. The question is, which node is in charge of 654 requesting and maintaining the resouce reservation. In a receiver- 655 initiated reservation, even though the sender sends the initial 656 QUERY, the receiver is still in charge of making the actual resource 657 request, and maintaining the reservation. 659 3.2.3. Message sequencing 661 RESERVE messages affect the installed reservation state. Unlike 662 NOTIFY, QUERY and RESPONSE messages, the order in which RESERVE 663 messages are received influences the eventual reservation state that 664 will be stored at a QNE. Therefore, QoS NSLP supports detection of 665 RESERVE message re-ordering or duplication with Reservation Sequence 666 Number (RSN). 668 The RSN has local significance only, i.e. between QNEs. Attempting 669 to make an identifier that was unique in the context of a SESSION_ID 670 but the same along the complete path would be very hard. Since 671 RESERVE messages can be sent by any node on the path that maintains 672 reservation state (e.g. for path repair) we would have the difficult 673 task of attempting to keep the identifier synchronized along the 674 whole path. Since message ordering only ever matters between a pair 675 of peer QNEs, we can make the RSN unique just between a pair of 676 neighbouring stateful QNEs. By managing the sequence numbers in this 677 manner, the source of the RESERVE does not need to determine how the 678 next QNE will process the message. 680 Note that, since the RSN is unique within a SESSION_ID, it can be 681 used together with a SESSION_ID to refer to particular installed 682 state. 684 3.2.4. Explicit state installation confirmation and responses 686 A QoS NSLP instance MAY request an explicit confirmation of its state 687 installation actions from the immediate upstream or downstream peer. 688 This is achieved by using an ACKNOWLEDGE (A) flag in the message 689 header. 691 In addition to this, a QNE may require other information such as a 692 confirmation that the end-to-end reservation is in place or a reply 693 to a query along the path. For such requests, it must be able to 694 keep track of which request each response refers to. This is 695 supported by including a Request Identification Information (RII) 696 object in a QoS NSLP message. 698 3.2.5. Reduced refresh 700 For scalability, QoS NSLP supports an abbreviated form of refresh 701 RESERVE message. In this case, the refresh RESERVE references the 702 reservation using the RSN and the SESSION_ID, and does not include 703 the full reservation specification (including QSPEC). These reduced 704 refreshes require an explicit acknowledgment of state installation to 705 ensure that the RSN reference will be understood. It is up to a QNE 706 that receives a message containing an RII to decide whether it wants 707 to accept reduced refreshes and provide this explicit 708 acknowledgement. 710 3.2.6. Message scoping 712 A QNE may use local policy when deciding whether to propagate a 713 message or not. The QoS NSLP also includes an explicit mechanism to 714 restrict message propagation by means of a scoping mechanism. 716 For a RESERVE or a QUERY message, a SCOPING flag limits the part of 717 the path on which state is installed or the downstream nodes that can 718 respond. When set to zero, it indicates that the scope is "whole 719 path" (default). When set to one, the scope is "single hop". 721 The propagation of a RESPONSE message is limited by the RII object, 722 which ensures that it is not forwarded back along the path further 723 than the node that requested the RESPONSE. 725 This specification does not support an explicit notion of a region 726 scope or "to a mobility-related path branch/merge point". If needed, 727 this can be easily proposed as an extension later on,e.g. based on 728 LRSVP [I-D.manner-lrsvp]. 730 3.2.7. Session binding 732 Session binding is defined as the enforcement of a relation between 733 different QoS NSLP sessions (i.e. signalling flows with different 734 SESSION_ID (SID) as defined in GIST [I-D.ietf-nsis-ntlp]). 736 Session binding indicates a (possibly asymmetric) dependency relation 737 between two or more sessions by including a BOUND_SESSION_ID object. 738 A session with SID_A (the binding session) can express its relation 739 to another session with SID_B (the bound session) by including a 740 BOUND_SESSION_ID object containing SID_B in its messages. The 741 dependency is asymmetric if the session with SID_B does not carry a 742 BOUND_SESSION_ID object containing SID_A. 744 The concept of session binding is used to indicate the dependency 745 between the end-to-end session and the aggregate session in case of 746 aggregate reservations. In case of bidirectional reservations, it is 747 used to express the dependency between the sessions used for forward 748 and reverse reservation. Note that the dependency indicated by 749 session binding is purely informative in nature and does not 750 automatically trigger any action in a QNE. However, a QNE may use 751 the information for local resource optimisation or to tear down 752 reservations that are no longer useful. 754 3.2.8. Layering 756 QoS NSLP supports layered reservations. Layered reservations may 757 occur when certain parts of the network (domains) implement one or 758 more local QoS models, or when they locally apply specific control 759 plane characteristics (e.g. GIST unreliable transfer mode instead of 760 reliable transfer mode). They may also occur when several per-flow 761 reservations are locally combined into an aggregate reservation. 763 3.2.8.1. Local QoS models 765 A domain may have local policies regarding QoS model implementation, 766 i.e. it may map incoming traffic to its own locally defined QoS 767 models. QoS NSLP supports this by allowing QSPEC objects to be 768 stacked. 770 When a domain wants to apply a certain QoS model to an incoming per- 771 flow reservation request, each edge of the domain is configured to 772 map the incoming QSPEC object to a local QSPEC object and push that 773 object onto the stack of QSPEC objects (typically immediately 774 following the Common Control Information, i.e., before the first 775 QSPEC that is found in the message). QNEs inside the domain look at 776 the top of the QSPEC object stack to determine which QoS model to 777 apply for the reservation. 779 The position of the local QSPEC object in the stack implies a 780 tradeoff between the speed with which incoming messages can be 781 processed and the time it takes to construct the outgoing message (if 782 any). By mandating the locally valid object to be on top of the 783 stack we value ease of processing over ease of message construction. 785 Note that the use of multiple QSPEC objects may require complex 786 processing. A QNE while processing the QSPEC on the top of the stack 787 may also need to process inner QSPEC objects. For example, a domain 788 may want to hide its existence from the end hosts, and for doing that 789 may need to process objects and fields in the inner QSPEC used 790 originally by the end hosts. 792 3.2.8.2. Local control plane properties 794 The way signalling messages are handled is mainly determined by the 795 parameters that are sent over GIST-NSLP API and by the Common Control 796 Information. A domain may have a policy to implement local control 797 plane behaviour. It may, for instance, elect to use an unreliable 798 transport locally in the domain while still keeping end-to-end 799 reliability intact. 801 The QoS NSLP supports this situation by allowing two sessions to be 802 set up for the same reservation. The local session has the desired 803 local control plane properties and is interpreted in internal QNEs. 804 This solution poses two requirements: the end-to-end session must be 805 able to bypass intermediate nodes and the egress QNE needs to bind 806 both sessions together. 808 Intermediate node bypass is achieved with GIST. The local session 809 and the end-to-end session are bound at the egress QNE by means of 810 the BOUND_SESSION_ID object. 812 3.2.8.3. Aggregate reservations 814 In some cases it is desirable to create reservations for an 815 aggregate, rather than on a per-flow basis, in order to reduce the 816 amount of reservation state needed as well as the processing load for 817 signalling messages. The QoS NSLP, therefore, provides aggregation 818 facilities similar to RFC 3175 [RFC3175]. However, the aggregation 819 scenarios supported are wider than that proposed there. Note that 820 QoS NSLP does not specify how reservations need to be combined in an 821 aggregate or how end-to-end properties need to be computed but only 822 provides signalling support for it. 824 The essential difference with the layering approaches described in 825 Section 3.2.8.1 and Section 3.2.8.2 is that the aggregate reservation 826 needs a FlowID, ie., MRI, that describes all traffic carried in the 827 aggregate (e.g. a DSCP in case of IntServ over DiffServ). The need 828 for a different FlowID mandates the use of two different sessions, 829 similar to Section 3.2.8.2 and to the RSVP aggregation solution in 830 RFC 3175 [RFC3175]. 832 Edge QNEs of the aggregation domain that want to maintain some end- 833 to-end properties may establish a peering relation by sending the 834 end-to-end message transparently over the domain (using the 835 intermediate node bypass capability described above). Updating the 836 end-to-end properties in this message may require some knowledge of 837 the aggregated session (e.g. for updating delay values). For this 838 purpose, the end-to-end session contains a BOUND_SESSION_ID carrying 839 the SESSION_ID of the aggregate session. 841 3.2.9. Priority 843 This specification acknowledges the fact that in some situations, 844 some messages or some reservations may be more important than others 845 and therefore foresees mechanisms to give these messages or 846 reservations priority. 848 Priority of certain signalling messages over others may be required 849 in mobile scenarios when a message loss during call set-up is less 850 harmful than during handover. This situation only occurs when GIST 851 or QoS NSLP processing is the congested part or scarce resource. 853 Priority of certain reservations over others may be required when QoS 854 resources are oversubscribed. In that case, existing reservations 855 may be preempted in order to make room for new higher-priority 856 reservations. A typical approach to deal with priority and 857 preemption is through the specification of a setup priority and 858 holding priority for each reservation. The resource management 859 function at each QNE then keeps track of the resource consumption at 860 each priority level. Reservations are established when resources, at 861 their setup priority level, are still available. They may cause 862 preemption of reservations with a lower holding priority than their 863 setup priority. 865 Support of reservation priority is a QSPEC parameter and therefore 866 outside the scope of this specification. The GIST specification 867 provides a mechanism to support a number of levels of message 868 priority that can be requested over the NSLP-GIST API. 870 3.2.10. Rerouting 872 QoS NSLP needs to adapt to route changes in the data path. This 873 assumes the capability to detect rerouting events, perform QoS 874 reservation on the new path and optionally tear down reservations on 875 the old path. 877 Rerouting detection can be performed at three levels. First, routing 878 modules may detect route changes through their interaction with 879 routing protocols. Certain QNEs or GIST implementations may interact 880 with local routing module to receive quick notification of route 881 changes. This is largely implementation-specific and outside of the 882 scope of NSIS. Second, route changes may be detected at GIST layer. 883 This specification requests GIST design to foresee notification of 884 this information over the API. This is outside the scope of the QoS 885 NSLP specification. Third, rerouting may be detected at the NSLP 886 layer. A QoS NSLP node is able to detect changes in its QoS NSLP 887 peers by keeping track of a Source Identification Information (SII) 888 object that is similar in nature to the RSVP_HOP object described in 889 RFC 2205 [RFC2205]. When a RESERVE message with an existing 890 SESSION_ID and a different SII is received, the QNE knows its 891 upstream or downstream peer has changed, for sender- and receiver- 892 oriented reservations, respectively. 894 Reservation on the new path happens when a refreshing RESERVE message 895 arrives at the QNE where the old and the new path diverge. The 896 refreshing RESERVE will be interpreted as a new RESERVE on the new 897 path. Depending on the transfer mode, this may require installation 898 of a new messaging association. Rapid recovery at the NSLP layer 899 therefore requires short refresh periods. Detection before the next 900 RESERVE message arrives is only possible at the IP layer or through 901 monitoring of GIST peering relations (e.g. by TTL counting the number 902 of GIST hops between NSLP peers or the observing changes in the 903 outgoing interface towards GIST peer). These mechanisms can provide 904 implementation specific optimisations, and are outside the scope of 905 this specification. 907 When the QoS NSLP is aware of the route change, it needs to set up 908 the reservation on the new path. This is done by incrementing the 909 RSN and then sending a new RESERVE message. On links that are common 910 to the old and the new path, this RESERVE message is interpreted as a 911 refreshing RESERVE. On new links, it creates the reservation. 913 After the reservation on the new path is set up, the branching node 914 or the merging node may want to tear down the reservation on the old 915 path (faster than what would result from normal soft-state time-out). 916 This functionality is supported by keeping track of the old SII. 917 This specification requests GIST design to provide support for an SII 918 that is interpreted as a random identifier at the QoS NSLP but that 919 allows, when passed over the API, to forward QoS NSLP messages to the 920 QNE identified by that SII. 922 A QNI or a branch node may wish to keep the reservation on the old 923 branch. This could for instance be the case when a mobile node has 924 experienced a mobility event and wishes to keep reservation to its 925 old attachment point in case it moves back there. For this purpose, 926 a REPLACE flag is foreseen in the common header, which, when set to 927 FALSE, indicates that the reservation on the old branch should be 928 kept. 930 The design of the QoS-NSLP allows reservations to be installed at a 931 subset of the nodes along a path, including cases where those nodes 932 might not included the endpoints of the application data flow. 934 In the case where the data flow receiver does not support the QoS- 935 NSLP, some particular considerations must be given to node discovery 936 and rerouting at the end of the signalling path. 938 There are three cases for the last node on the signalling path: 1) 939 Last node is the data receiver 2) Last node is a configured proxy for 940 the data receiver 3) Last node is not the data receiver and is not 941 explicitly configured to act as a signalling proxy on behalf of the 942 data receiver. 944 Cases (1) and (2) can be handled by the QoS-NSLP itself during the 945 initial path setup, since the QNE knows that it should terminate the 946 signalling. Case (3) requires some assistance from GIST which 947 provides messages across the API to indicate that no further QoS-NSLP 948 supporting GIST nodes are present downstream. 950 We can consider two particular cases for rerouting. In the first, 951 referred to as "Path Extension", rerouting occurs such that an 952 additional QNE is inserted into the signalling path between the old 953 last node and the data receiver, as shown in Figure 4. 955 /-------\ Initial route 956 / v 957 /-\ 958 /--|B|--\ +-+ 959 / \-/ \ |x| = QoS-NSLP aware 960 +-+ /-\ +-+ 961 ----|A| |D| 962 +-+ \-/ /-\ 963 \ +-+ / |x| = QoS-NSLP unaware 964 \--|C|--/ \-/ 965 +-+ 966 \ ^ 967 \-------/ Updated route 969 Figure 4: Path Extension 971 When rerouting occurs, the data path changes from A-B-D to A-C-D. 972 Initially the signalling path ends at A. Despite initially being the 973 last node, node A MUST continue to attempt to send messages 974 downstream to probe for path changes, unless it has been explicitly 975 configured as a signalling proxy for the data flow receiver. This is 976 required so that the signalling path change is detected, and C will 977 become the new last QNE. 979 In a second case, referred to as "Path Truncation", rerouting occurs 980 such that the QNE that was the last node on the signalling path is no 981 longer on the data path. This is shown in Figure 5. 983 /-------\ Initial route 984 / v 985 +-+ 986 /--|B|--\ +-+ 987 / +-+ \ |x| = QoS-NSLP aware 988 +-+ /-\ +-+ 989 ----|A| |D| 990 +-+ \-/ /-\ 991 \ /-\ / |x| = QoS-NSLP unaware 992 \--|C|--/ \-/ 993 \-/ 994 \ ^ 995 \-------/ Updated route 997 Figure 5: Path Truncation 999 When rerouting occurs, the data path again changes from A-B-D to A-C- 1000 D. The signalling path initially ends at C, but this node is not on 1001 the new path. In this case, the normal GIST path change detection 1002 procedures at A will detect the path change and notify the QoS-NSLP. 1003 GIST will also notify the signalling application that no downstream 1004 GIST nodes supporting the QoS-NSLP are present. Node A MUST take over 1005 as the last node on the signalling path 1007 4. Examples of QoS NSLP Operation 1009 The QoS NSLP can be used in a number of ways. The examples given 1010 here give an indication of some of the basic processing. However, 1011 they are not exhaustive and do not attempt to cover the details of 1012 the protocol processing. 1014 4.1. Basic sender-initiated reservation 1016 QNI QNE QNE QNR 1017 | | | | 1018 | RESERVE | | | 1019 +--------->| | | 1020 | | RESERVE | | 1021 | +--------->| | 1022 | | | RESERVE | 1023 | | +--------->| 1024 | | | | 1025 | | | RESPONSE | 1026 | | |<---------+ 1027 | | RESPONSE | | 1028 | |<---------+ | 1029 | RESPONSE | | | 1030 |<---------+ | | 1031 | | | | 1032 | | | | 1033 Figure 4: Basic Sender Initiated Reservation 1035 To make a new reservation, the QNI constructs a RESERVE message 1036 containing a QSPEC object, from its chosen QoS model, which describes 1037 the required QoS parameters. 1039 The RESERVE message is passed to GIST which transports it to the next 1040 QNE. There it is delivered to the QoS NSLP processing which examines 1041 the message. Policy control and admission control decisions are 1042 made. The exact processing also takes into account the QoS model 1043 being used. The node performs appropriate actions (e.g. installing 1044 reservation) based on the QSPEC object in the message. 1046 The QoS NSLP then generates a new RESERVE message (usually based on 1047 the one received). This is passed to GIST, which forwards it to the 1048 next QNE. 1050 The same processing is performed at further QNEs along the path, up 1051 to the QNR. The determination that a node is the QNR may be made 1052 directly (e.g. that node is the destination for the data flow), or 1053 using some GIST functionality to determine that there are no more 1054 QNEs between this node and the data flow destination. 1056 A node can ask a confirmation of the installed state from its 1057 immediate peer. It does so by setting the A flag, which causes a 1058 RESPONSE message to be sent by the immediate peer. One use of this 1059 is to confirm the installation of state, which allows the use of 1060 reduced refreshes that later refer to that state. A RESPONSE message 1061 can also indicate an error when, e.g., a reservation has failed to be 1062 installed. 1064 Any node may include a request for a RESPONSE in its RESERVE 1065 messages. It does so by including a Request Identification 1066 Information (RII) object in the RESERVE message. If the message 1067 already includes an RII, an interested QNE must not add a new RII 1068 object nor replace the old RII object, but may simply remember that 1069 RII to match the related RESPONSE it is interested in later. When it 1070 receives the RESPONSE, it forwards the RESPONSE upstream towards the 1071 RII originating node. 1073 The RESPONSE is forwarded peer-to-peer along the reverse of the path 1074 that the RESERVE message took (using GIST path state), and so is seen 1075 by all the QNEs on the reverse-path. It is only forwarded as far as 1076 the node which requested the RESPONSE originally. 1078 The reservation can subsequently be refreshed by sending further 1079 RESERVE messages containing the complete reservation information, as 1080 for the initial reservation. The reservation can also be modified in 1081 the same way, by changing the QSPEC data to indicate a different set 1082 of resources to reserve. 1084 The overhead required to perform refreshes can be reduced, in a 1085 similar way to that proposed for RSVP in RFC 2961 [RFC2961]. Once a 1086 RESPONSE message has been received indicating the successful 1087 installation of a reservation, subsequent refreshing RESERVE messages 1088 can simply refer to the existing reservation, rather than including 1089 the complete reservation specification. 1091 4.2. Sending a Query 1093 QUERY messages can be used to gather information from QNEs along the 1094 path. For example, it can be used to find out what resources are 1095 available before a reservation is made. 1097 In order to perform a query along a path, the QNE constructs a QUERY 1098 message. This message includes a QSPEC containing the actual query to 1099 be performed at QNEs along the path. It also contains an object used 1100 to match the response back to the query, and an indicator of the 1101 query scope (next node, whole path). The QUERY message is passed to 1102 GIST to forward it along the path. 1104 A QNE (including the QNR) receiving a QUERY message should inspect it 1105 and create a new message, based on that received with the query 1106 objects modified as required. For example, the query may request 1107 information on whether a flow can be admitted, and so a node 1108 processing the query might record the available bandwidth. The new 1109 message is then passed to GIST for further forwarding (unless it 1110 knows it is the QNR, or is the limit for the scope in the QUERY). 1112 At the QNR, a RESPONSE message must be generated if the QUERY message 1113 includes a Request Identification Information (RII) object. Into 1114 this is copied various objects from the received QUERY message. It 1115 is then passed to GIST to be forwarded peer-to-peer back along the 1116 path. 1118 Each QNE receiving the RESPONSE message should inspect the RII object 1119 to see if it 'belongs' to it (i.e. it was the one that originally 1120 created it). If it does not then it simply passes the message back 1121 to GIST to be forwarded back down the path. 1123 4.3. Basic receiver-initiated reservation 1125 As described in the NSIS framework [RFC4080] in some signalling 1126 applications, a node at one end of the data flow takes responsibility 1127 for requesting special treatment - such as a resource reservation - 1128 from the network. Both ends then agree whether sender or receiver- 1129 initiated reservation is to be done. In case of a receiver initiated 1130 reservation, both ends agree whether a "One Pass With Advertising" 1131 (OPWA) [_XREF_OPWA95] model is being used. This negotiation can be 1132 accomplished using mechanisms that are outside the scope of NSIS. 1134 To make a receiver-initiated reservation, the QNR constructs a QUERY 1135 message, which may contain a QSPEC object from its chosen QoS model 1136 (see Figure 5). The QUERY must have the R-bit set. This QUERY message 1137 does not need to trigger a RESPONSE message and therefore, the QNI 1138 must not include the RII object (Section 5.4.2), into the QUERY 1139 message. The QUERY message may be used to gather information along 1140 the path, which is carried by the QSPEC object. An example of such 1141 information is the "One Pass With Advertising" (OPWA) [_XREF_OPWA95]. 1142 This QUERY message causes GIST reverse-path state to be installed. 1144 QNR QNE QNE QNI 1145 sender receiver 1146 | | | | 1147 | QUERY | | | 1148 +--------->| | | 1149 | | QUERY | | 1150 | +--------->| | 1151 | | | QUERY | 1152 | | +--------->| 1153 | | | | 1154 | | | RESERVE | 1155 | | |<---------+ 1156 | | RESERVE | | 1157 | |<---------+ | 1158 | RESERVE | | | 1159 |<---------+ | | 1160 | | | | 1161 | RESPONSE | | | 1162 +--------->| | | 1163 | | RESPONSE | | 1164 | +--------->| | 1165 | | | RESPONSE | 1166 | | +--------->| 1167 | | | | 1169 Figure 5: Basic Receiver Initiated Reservation 1171 The QUERY message is transported by GIST to the next downstream QoS 1172 NSLP node. There it is delivered to the QoS NSLP processing which 1173 examines the message. The exact processing also takes into account 1174 the QoS model being used and may include gathering information on 1175 path characteristics that may be used to predict the end-to-end QoS. 1177 The QNE generates a new QUERY message (usually based on the one 1178 received). This is passed to GIST, which forwards it to the next QNE. 1179 The same processing is performed at further QNEs along the path, up 1180 to the flow receiver. The receiver detects that this QUERY message 1181 carries the R-bit and by using the information contained in the 1182 received QUERY message, such as the QSPEC, constructs a RESERVE 1183 message. 1185 The RESERVE is forwarded peer-to-peer along the reverse of the path 1186 that the QUERY message took (using GIST reverse path state). Similar 1187 to the sender-initiated approach, any node may include an RII in its 1188 RESERVE messages. The RESPONSE is sent back to confirm the resources 1189 are set up. 1191 The reservation can subsequently be refreshed in the same way as for 1192 the sender-initiated approach. This RESERVE message may be also used 1193 to refresh GIST reverse path state. Alternatively, refreshing GIST 1194 reverse path state could be performed by sending periodic QUERY 1195 messages, which are needed in case of route changes anyway. 1197 4.4. Bidirectional Reservations 1199 Bidirectional reservations are supported by binding two uni- 1200 directional sessions together. We distinguish two cases: 1202 o Binding two sender-initiated reservations, e.g. one sender- 1203 initiated reservation from QNE A to QNE B and another one from QNE B 1204 to QNE A. 1206 o Binding a sender-initiated and a receiver-initiated reservation, 1207 e.g. a sender-initiated reservation from QNE A towards QNE B, and a 1208 receiver-initiated reservation from QNE A towards QNE B for the data 1209 flow in the opposite direction (from QNE B to QNE A). This case is 1210 particularly useful when one end of the communication has all 1211 required information to set up both sessions. 1213 Both ends have to agree on which bi-directional reservation type they 1214 need to use. This negotiation/agreement can be accomplished using 1215 mechanisms that are outside the scope of NSIS. 1217 The scenario with two sender-initiated reservation is shown on Figure 1218 6. Note that RESERVE messages for both directions may visit 1219 different QNEs along the path because of asymmetric routing. Both 1220 directions of the flows are bound by inserting the BOUND_SESSION_ID 1221 object at the QNI and QNR. RESPONSE messages are optional and not 1222 shown on the picture for simplicity. 1224 A QNE QNE B 1225 | | FLOW-1 | | 1226 |===============================>| 1227 |RESERVE-1 | | | 1228 QNI+--------->|RESERVE-1 | | 1229 | +-------------------->|QNR 1230 | | | | 1231 | | FLOW-2 | | 1232 |<===============================| 1233 | | |RESERVE-2 | 1234 | RESERVE-2 |<---------+QNI 1235 QNR|<--------------------+ | 1236 | | | | 1238 Figure 6: Bi-directional reservation for sender+sender scenario 1240 The scenario with a sender-initiated and a receiver-initiated 1241 reservation is shown on Figure 7. In this case, QNI B sends out two 1242 RESERVE messages, one for the sender-initiated and one for the 1243 receiver-initiated reservation. 1245 A QNE QNE B 1246 | | FLOW-1 | | 1247 |===============================>| 1248 | QUERY-1 | | | 1249 QNI+--------->| QUERY-1 | | 1250 | +-------------------->|QNR 1251 | | | | 1252 |RESERVE-1 | | | 1253 QNI+<---------|RESERVE-1 | | 1254 | +<--------------------|QNR 1255 | | | | 1256 | | FLOW-2 | | 1257 |<===============================| 1258 | | |RESERVE-2 | 1259 |RESERVE-2 | |<---------+QNI 1260 QNR|<--------------------+ | 1261 | | | | 1263 Figure 7: Bi-directional reservation for sender+receiver scenario 1265 4.5. Use of Local QoS Models 1267 In some cases it may be required to use a different QoS model along a 1268 particular segment of the signalling. In this case a node at the 1269 edge of this region needs to add the additional local QSpec 1270 information, based on the end-to-end QSpec. This allows the QoS 1271 description to be tailored to the QoS provisioning mechanism 1272 available in the network. 1274 +-------- QoSM2 domain -------+ 1275 | | 1276 | | 1277 +----+ +----+ +----+ +----+ +----+ 1278 |QNI | |edge| |int.| |edge| |QNR | 1279 | |========>|QNE |========>|QNE |========>|QNE |========>| | 1280 +----+ RESERVE +----+ RESERVE +----+ RESERVE +----+ RESERVE +----+ 1281 QSPEC1 | QSPEC2 QSPEC2 | QSPEC1 1282 | {QSPEC1} {QSPEC1} | 1283 | | 1284 +-----------------------------+ 1286 Figure 8: Reservation with local QoS Models 1288 This initially proceeds as for the basic example, with peer-to-peer 1289 installation of reservations. However, within a region of the 1290 network a different QoSM (QoSM2) needs to be used. At the edge of 1291 this region the QNEs support both the end-to-end and local QoS 1292 models. When the RESERVE message reaches the QNE at the ingress, the 1293 initial processing of the RESERVE proceeds as normal. However, the 1294 QNE also determines the appropriate description using QoSM2. The 1295 RESERVE message to be sent out is constructed mostly as usual but 1296 with a second QSPEC object added on top, which becomes the 'current' 1297 one. 1299 When this RESERVE message is received at an node internal to the 1300 QoSM2 domain the QoS NSLP only uses the local QSPEC, rather than the 1301 end-to-end QSPEC. Otherwise, processing proceeds as usual. The 1302 RESERVE message that it generates should include both of the QSPECs 1303 from the message it received. 1305 At the QNE at the egress of the region the local QSPEC is removed 1306 from the message so that subsequent QNEs receive only the end-to-end 1307 QSPEC. 1309 A message can contain at most two QSpec objects, i.e. the end-to-end 1310 QSpec and a local QSpec. 1312 4.6. Aggregate Reservations 1314 In order to reduce signalling and per-flow state in the network, the 1315 reservations for a number of flows may be aggregated together. 1317 QNI QNE QNE/QNI' QNE' QNR'/QNE QNR 1318 aggregator deaggregator 1319 | | | | | | 1320 | RESERVE | | | | | 1321 +--------->| | | | | 1322 | | RESERVE | | | | 1323 | +--------->| | | | 1324 | | | RESERVE | | | 1325 | | +-------------------->| | 1326 | | | RESERVE' | | | 1327 | | +=========>| RESERVE' | | 1328 | | | +=========>| RESERVE | 1329 | | | | +--------->| 1330 | | | | RESPONSE'| | 1331 | | | RESPONSE'|<=========+ | 1332 | | |<=========+ | | 1333 | | | | | RESPONSE | 1334 | | | | RESPONSE |<---------+ 1335 | | |<--------------------+ | 1336 | | RESPONSE | | | | 1337 | |<---------+ | | | 1338 | RESPONSE | | | | | 1339 |<---------+ | | | | 1340 | | | | | | 1341 | | | | | | 1343 Figure 9: Sender Initiated Reservation with Aggregation 1345 An end-to-end per-flow reservation is initiated as normal (with 1346 messages shown in Figure 9 as "RESERVE"). 1348 At the aggregator a reservation for the aggregated flow is initiated 1349 (shown in Figure 9 as "RESERVE'"). This may use the same QoS model 1350 as the end-to-end reservation but has a flow identifier for the 1351 aggregated flow (e.g. tunnel) instead of for the individual flows. 1353 This document does not specify how the QSPEC of the aggregate session 1354 can be derived from the QSPECs of the end-to-end sessions. 1356 The messages used for the signaling of the individual reservation 1357 need to be marked such that the intermediate routers will not inspect 1358 them. The marking MUST be accomplished by the Aggregator by 1359 modifying the QoS-NSLP default NSLP-ID value to a NSLP-ID predefined 1360 value. The De-aggregator MUST stop this marking process by 1361 reassigning the QoS-NSLP default NSLP-ID value to these signaling 1362 messages. The deaggregator then becomes the next hop QNE for the end- 1363 to-end per-flow reservation. 1365 Aggregator Deaggregator 1367 +---+ +---+ +---+ +---+ 1368 |QNI|-----|QNE|-----|QNE|-----|QNR| aggregate 1369 +---+ +---+ +---+ +---+ reservation 1371 +---+ +---+ ..... ..... +---+ +---+ 1372 |QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end 1373 +---+ +---+ ..... ..... +---+ +---+ reservation 1375 The deaggregator acts as the QNR for the aggregate reservation. 1377 Information is carried in the reservations to enable the deaggregator 1378 to associate the end-to-end and aggregate reservations with one 1379 another. 1381 The key difference between this example, and previous ones is that 1382 the flow identifier for the aggregate is expected to be different to 1383 that for the end-to-end reservation. The aggregate reservation can 1384 be updated independently of the per-flow end-to-end reservations. 1386 4.7. Reduced State or Stateless Interior Nodes 1388 This example uses a different QoS model within a domain, in 1389 conjunction with GIST and NSLP functionality which allows the 1390 interior nodes to avoid storing GIST and QoS NSLP state. As a result 1391 the interior nodes only store the QSPEC-related reservation state, or 1392 even no state at all. This allows the QoS model to use a form of 1393 "reduced-state" operation, where reservation states with a coarser 1394 granularity (e.g. per-class) are used, or a "stateless" operation 1395 where no QoS NSLP state is needed (or created). 1397 The key difference between this example and the use of different QoS 1398 models in Section 4.5 is that the transport characteristics for the 1399 �local' reservation can be different from that of the end-to-end 1400 reservation, i.e. GIST can be used in a different way for the edge- 1401 to-edge and hop-by-hop sessions. The reduced state reservation can 1402 be updated independently of the per-flow end-to-end reservations. 1404 QNE QNE QNE QNE 1405 ingress interior interior egress 1407 GIST stateful GIST stateless GIST stateless GIST stateful 1408 | | | | 1409 RESERVE | | | | 1410 -------->| RESERVE | | | 1411 +--------------------------------------------->| 1412 | RESERVE' | | | 1413 +-------------->| | | 1414 | | RESERVE' | | 1415 | +-------------->| | 1416 | | | RESERVE' | 1417 | | +------------->| 1418 | | | | RESERVE 1419 | | | +--------> 1420 | | | | RESPONSE 1421 | | | |<-------- 1422 | | | RESPONSE | 1423 |<---------------------------------------------+ 1424 RESPONSE| | | | 1425 <--------| | | | 1427 Figure 11: Sender-initiated reservation with Reduced State Interior 1428 Nodes 1430 The QNI performs the same processing as before to generate the 1431 initial RESERVE message, and it is forwarded by GIST as usual. At 1432 the QNEs at the edges of the stateless or reduced-state region the 1433 processing is different and the nodes support two QoS models. 1435 At the ingress the original RESERVE message is forwarded but ignored 1436 by the stateless or reduced-state nodes. This is accomplished by 1437 marking this message, i.e., modifying the QoS-NSLP default NSLP-ID 1438 value to another NSLP-ID predefined value. The marking MUST be 1439 accomplished by the ingress by modifying the QoS_NSLP default NSLP-ID 1440 value to a NSLP-ID predefined value. The egress MUST stop this 1441 marking process by reassigning the QoS-NSLP default NSLP-ID value to 1442 the original RESERVE message. An example of such operation is given 1443 in [I-D.ietf-nsis-rmd]. 1445 The egress node is the next QoS NSLP hop for that session. After the 1446 initial discovery phase using unreliable GIST transfer mode, reliable 1447 GIST transfer mode between the ingress and egress can be used. At 1448 the egress node the RESERVE message is then forwarded normally. 1450 At the ingress a second RESERVE' message is also built. This makes 1451 use of a QoS model suitable for a reduced state or stateless form of 1452 operation (such as the RMD per hop reservation). Since the original 1453 RESERVE and the RESERVE' messages are addressed identically, RESERVE' 1454 visits the same nodes that were visited, including the egress QNE. 1456 When processed by interior (stateless) nodes the QoS NSLP processing 1457 exercises its options to not keep state wherever possible, so that no 1458 per flow QoS NSLP state is stored. Some state, e.g. per class, for 1459 the QSPEC related data may be held at these interior nodes. The QoS 1460 NSLP also requests that GIST use different transport characteristics 1461 (i.e. sending of messages in unreliable GIST transfer mode). It also 1462 requests the local GIST processing not to retain messaging 1463 association state or reverse message routing state. 1465 Nodes, such as those in the interior of the stateless or reduced- 1466 state domain, that do not retain reservation state cannot send back 1467 RESPONSE messages (and so cannot use reduced refreshes). 1469 At the egress node the RESERVE' message is interpreted in conjunction 1470 with the reservation state from the end-to-end RESERVE message (using 1471 information carried in the message to correlate the signalling 1472 flows). The RESERVE message is only forwarded further if the 1473 processing of the RESERVE' message was successful at all nodes in the 1474 local domain, otherwise the end-to-end reservation is regarded as 1475 having failed to be installed. 1477 Since GIST neighbour relations are not maintained in the reduced- 1478 state region, only sender initiated signalling can be supported. If 1479 a receiver-initiated reservation over a stateless or reduced state 1480 domain is required this can be implemented as shown below. 1482 QNE QNE QNE 1483 ingress interior egress 1484 GIST stateful GIST stateless GIST stateful 1485 | | | 1486 QUERY | | | 1487 -------->| QUERY | | 1488 +------------------------------>| 1489 | | | QUERY 1490 | | +--------> 1491 | | | RESERVE 1492 | | |<-------- 1493 | | RESERVE | 1494 |<------------------------------+ 1495 | RESERVE | RESERVE | 1496 |-------------->|-------------->| 1497 RESERVE | | | 1498 <--------| | | 1500 Figure 12: Receiver-initiated reservation with Reduced State Interior 1501 Nodes 1503 The RESERVE message that is received by the egress QNE of the 1504 stateless domain is sent transparently to the ingress QNE (known as 1505 the source of the QUERY message). When the RESERVE message reaches 1506 the ingress, the ingress QNE knows it needs to send both a sender- 1507 initiated RESERVE over the stateless domain and send a RESERVE 1508 message further upstream. 1510 4.8. Re-routing scenario 1512 The QoS NSLP needs to adapt to route changes in the data path. This 1513 assumes the capability to detect rerouting events, perform QoS 1514 reservation on the new path and optionally tear down reservations on 1515 the old path. 1517 When the QoS NSLP is aware of the route change, it needs to set up 1518 the reservation on the new path. This is done by incrementing the 1519 RSN and sending a RESERVE message. On links that are common to the 1520 old and the new path, this RESERVE message is interpreted as a 1521 refreshing RESERVE. On new links, it creates the reservation. 1523 After the reservation on the new path is set up, the branching node 1524 or the merging node may want to tear down the reservation on the old 1525 path (faster than what would result from normal soft-state time-out). 1526 This functionality is supported by keeping track of the old SII. 1527 This specification requests GIST design to provide support for an 1528 SII. The SII is opaque to the QoS NSLP, i.e. QoS NSLP does not make 1529 any assumptions on how this identifier is constructed. When passed 1530 over the API, it allows QoS NSLP to indicate that its messages should 1531 be sent to the QNE identified by that SII. 1533 In case of a receiver-initiated reservation, a QNE can detect a route 1534 change by receiving a RESERVE message with a different SII. In case 1535 of a sender-initiated reservation, the same information is learned 1536 from a RESPONSE message, or from a NOTIFY message sent by the 1537 downstream peer. A QNE that has detected the route change via the 1538 SII change sends a RESERVE message towards the QNR on the old path 1539 (using the old SII) with the TEAR flag set. Note that in case of 1540 receiver-initiated reservations, this involves A QNE that is notified 1541 of the route change in another way and wants to tear down the old 1542 branch needs to send the RESERVE on the new path with an RII object. 1543 When it receives the RESPONSE message back, it can check whether its 1544 peer has effectively changed and send a RESERVE with the TEAR flag 1545 set if it has. Otherwise, teardown is not needed. A QNE that is 1546 unable to support an RII or does not receive a RESPONSE needs to rely 1547 on soft-state timeout on the old branch. 1549 A QNI or a branch node may wish to keep the reservation on the old 1550 branch. This could for instance be the case when a mobile node has 1551 experienced a mobility event and wishes to keep reservation to its 1552 old attachment point in case it moves back there. In that case, it 1553 sets the REPLACE flag in the common header to zero. Note that keeping 1554 old reservations affects the resources available to other nodes. 1555 Thus, the operator of the access network must make the final decision 1556 on whether this behavior is allowed. Also, the QNEs in the access 1557 network may add this flag even if the mobile node has not used the 1558 flag initially. 1560 4.9. Authorization Model Examples 1562 Various authorization models can be used in conjunction with the QoS 1563 NSLP. 1565 4.9.1. Authorization for the two party approach 1567 The two party approach is conceptually the simplest authorization 1568 model. 1570 +-------------+ QoS request +--------------+ 1571 | Entity |----------------->| Entity | 1572 | requesting | | authorizing | 1573 | resource |granted / rejected| resource | 1574 | |<-----------------| request | 1575 +-------------+ +--------------+ 1576 ^ ^ 1577 +...........................+ 1578 financial establishment 1580 Figure 13: Two party approach 1582 In this example the authorization decision only involves the two 1583 entities, or makes use of previous authorisation using an out-of-band 1584 mechanism to avoid the need for active participation of an external 1585 entity during the NSIS protocol execution. 1587 This type of model may be applicable, e.g., between two neighbouring 1588 networks (inter-domain signalling) where a long-term contract (or 1589 other out-of-band mechanisms) exists to manage charging and provides 1590 sufficient information to authorize individual requests. 1592 4.9.2. Token based three party approach 1594 An alternative approach makes use of authorization tokens, such as 1595 those described in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used 1596 as part of the Open Settlement Protocol [OSP]. The former 1597 ('authorization tokens') are used to associate two different 1598 signalling protocols (i.e. SIP and NSIS) and their authorization 1599 with each other whereas the latter is a form of digital money. As an 1600 example, with the authorization token mechanism, some form of 1601 authorization is provided by the SIP proxy, which acts as the 1602 resource authorizing entity in Figure 14. If the request is 1603 authorized, then the SIP signalling returns an authorization token 1604 which can be included in the QoS signalling protocol messages to 1605 refer to the previous authorization decision. The tokens themselves 1606 may take a number of different forms, some of which may require the 1607 entity performing the QoS reservation to query external state. 1609 Authorization 1610 Token Request +--------------+ 1611 +-------------->| Entity C | financial settlement 1612 | | authorizing | <..................+ 1613 | | resource | . 1614 | +------+ request | . 1615 | | +--------------+ . 1616 | | . 1617 | |Authorization . 1619 | |Token . 1620 | | . 1621 | | . 1622 | | . 1623 | | QoS request . 1624 +-------------+ + Authz. Token +--------------+ . 1625 | Entity |----------------->| Entity B | . 1626 | requesting | | performing | . 1627 | resource |granted / rejected| QoS | <..+ 1628 | A |<-----------------| reservation | 1629 +-------------+ +--------------+ 1631 Figure 14: Token based three party approach 1633 For the digital money type of systems (e.g. OSP tokens), the token 1634 represents a limited amount of credit. So, new tokens must be sent 1635 with later refresh messages once the credit is exhausted. 1637 4.9.3. Generic three party approach 1639 Another method is for the node performing the QoS reservation to 1640 delegate the authorization decision to a third party, as illustrated 1641 in Figure 15. 1643 +--------------+ 1644 | Entity C | 1645 | authorizing | 1646 | resource | 1647 | request | 1648 +-----------+--+ 1649 ^ | 1650 | | 1651 QoS | | QoS 1652 authz| |authz 1653 req.| | res. 1654 | | 1655 QoS | v 1656 +-------------+ request +--+-----------+ 1657 | Entity |----------------->| Entity B | 1658 | requesting | | performing | 1659 | resource |granted / rejected| QoS | 1660 | A |<-----------------| reservation | 1661 +-------------+ +--------------+ 1663 Figure 15: Three party approach 1665 Authorization may be performed on a per-request basis, periodically, 1666 or on a per-session basis. The authorization request might make use 1667 of EAP authentication between entities A and C, and a subsequent 1668 protocol exchange between A and B to create a secure channel for 1669 further communications. Such a technique gives flexibility in terms 1670 of the authentication and key exchange protocols used. 1672 A further extension to this model is to allow Entity C to reference a 1673 AAA server in the user's home network when making the authorization 1674 decision. 1676 5. QoS NSLP Functional specification 1678 5.1. QoS NSLP Message and Object Formats 1680 A QoS NSLP message consists of a common header, followed by a body 1681 consisting of a variable number of variable-length, typed "objects". 1682 The common header and other objects are encapsulated together in a 1683 GIST NSLP-Data object. The following subsections define the formats 1684 of the common header and each of the QoS NSLP message types. In the 1685 message formats, the common header is denoted as COMMON_HEADER. 1687 For each QoS NSLP message type, there is a set of rules for the 1688 permissible choice of object types. These rules are specified using 1689 the Augmented Backus-Naur Form (ABNF) specified in RFC 2234 1690 [RFC2234]. The ABNF implies an order for the objects in a message. 1691 However, in many (but not all) cases, object order makes no logical 1692 difference. An implementation should create messages with the 1693 objects in the order shown here, but accept the objects in any order, 1694 except for QSPEC object(s) which always appear last in the message, 1695 and whose mutual order matters. 1697 5.1.1. Common header 1699 All GIST NSLP-Data objects for the QoS NSLP MUST contain this common 1700 header as the first 32 bits of the object (this is not the same as 1701 the GIST Common Header). 1703 0 1 2 3 1704 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Message Type | Message Flags | Generic Flags | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 The fields in the common header are as follows: 1711 Msg Type: 8 bits 1713 1 = RESERVE 1715 2 = QUERY 1717 3 = RESPONSE 1719 4 = NOTIFY 1721 Message-specific flags: 8 bits 1722 Generic flags: 16 bits 1724 The set of appropriate flags depends on the particular message 1725 being processed. Any bit not defined as a flag for a particular 1726 message MUST be set to zero on sending and MUST be ignored on 1727 receiving. 1729 5.1.2. Message formats 1731 5.1.2.1. RESERVE 1733 The format of a RESERVE message is as follows: 1735 RESERVE = COMMON_HEADER 1736 RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] 1737 [ POLICY_DATA ] *2QSPEC 1739 The RSN is the only mandatory object and MUST always be present. 1741 If any QSPEC objects are present, they MUST occur at the end of the 1742 message. There are no other requirements on transmission order, 1743 although the above order is recommended. 1745 Three message-specific flags are defined for use in the common header 1746 with the RESERVE message. These are: 1748 +-+-+-+-+-+-+-+-+ 1749 |Reserved |T|A|R| 1750 +-+-+-+-+-+-+-+-+ 1752 TEAR (T) - when set, indicates that reservation state and QoS NSLP 1753 operation state should be torn down. This is indicated to the 1754 RMF. Depending on the QoS model, the tear message may include a 1755 QSPEC to further specify state removal. 1757 ACKNOWLEDGE (A) - when set, indicates that an explicit 1758 confirmation of the state installation action is REQUIRED. This 1759 flag SHOULD be set on transmission by default. 1761 REPLACE (R) - when set, indicates that a RESERVE with different 1762 Message Routing Information (MRI) replaces an existing one, so the 1763 old one MAY be torn down immediately. This is the default 1764 situation. This flag may be unset to indicate a desire from an 1765 upstream node to keep an existing reservation on an old branch in 1766 place. 1768 One generic flag is used with the RESERVE message: 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Reserved |S| 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 SCOPING (S) - when set, indicates that the message is scoped and 1775 should not travel down the entire path but only as far as the next 1776 QNE (scope="next hop"). By default, this flag is not set (default 1777 scope="whole path"). 1779 If the REFRESH_PERIOD is not present, a default value of 30 seconds 1780 is assumed. 1782 If the session of this message is bound to another session, then the 1783 RESERVE message MUST include the SESSION_ID of that other session in 1784 a BOUND_SESSION_ID object. 1786 A "reservation collision" may occur if the sender believes that a 1787 sender-initiated reservation should be performed for a flow, whilst 1788 the other end believes that it should be starting a receiver- 1789 initiated reservation. If different session identifiers are used 1790 then this error condition is transparent to the QoS NSLP though it 1791 may result in an error from the RMF, otherwise the removal of the 1792 duplicate reservation is left to the QNIs/QNRs for the two sessions. 1794 If a reservation is already installed and a RESERVE message is 1795 received with the same session identifier from the other direction 1796 (i.e. going upstream where the reservation was installed by a 1797 downstream RESERVE message, or vice versa) then an error indicating 1798 "RESERVE received from wrong direction" MUST be sent in a RESPONSE 1799 message to the signalling message source for this second RESERVE. 1801 A refresh right along the path can be forced by requesting a RESPONSE 1802 from the far end (i.e. by including an RII object in the RESERVE 1803 message). Without this, a refresh RESERVE would not trigger RESERVE 1804 messages to be sent further along the path, as each hop has its own 1805 refresh timer. If the routing path changed due to mobility, the 1806 mobile node's IP address changed, and it sent a Mobile IP binding 1807 update, the resulting refresh is a new RESERVE. This RESERVE includes 1808 new MRI and will be propagated end-to-end without requesting a 1809 RESPONSE. 1811 Note: It is possible for a host to use this mechanism to constantly 1812 force the QNEs on the path to send refresh RESERVE messages. It may, 1813 therefore, be appropriate for QNEs to perform rate limiting on the 1814 refresh messages that they send. 1816 5.1.2.2. QUERY 1818 The format of a QUERY message is as follows: 1820 QUERY = COMMON_HEADER 1821 [ RII ][ BOUND_SESSION_ID ] 1823 [ POLICY_DATA ] *2QSPEC 1825 A QUERY message MUST contain an RII object to match an incoming 1826 RESPONSE to the QUERY, unless the QUERY is being used to initiate 1827 reverse-path state for a receiver-initiated reservation. 1829 A QUERY message MAY contain one or two QSPEC objects and a 1830 POLICY_DATA object. The QSPEC object describes what is being queried 1831 for and may contain objects that gather information along the data 1832 path. The POLICY_DATA object authorizes the requester of the QUERY 1833 message. If any QSPEC objects are present, they MUST occur at the 1834 end of the message. There are no other requirements on transmission 1835 order, although the above order is recommended. 1837 One message-specific flag is defined for use in the common header 1838 with the QUERY message. This is: 1840 +-+-+-+-+-+-+-+-+ 1841 |Reserved |R| 1842 +-+-+-+-+-+-+-+-+ 1844 RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger 1845 for the recipient to make a resource reservation by sending a 1846 RESERVE. 1848 One generic flag is defined for use in the common header with the 1849 QUERY message. This is: 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | Reserved |S| 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 SCOPING (S) - when set, indicates that the message is scoped an 1856 should not travel down the entire path but only as far as the next 1857 QNE (scope="next hop"). By default, this flag is not set (default 1858 scope="whole path"). 1860 If the session of this message is bound to another session, then the 1861 RESERVE message MUST include the SESSION_ID of that other session in 1862 a BOUND_SESSION_ID object. 1864 5.1.2.3. RESPONSE 1866 The format of a RESPONSE message is as follows: 1868 RESPONSE = COMMON_HEADER 1869 [ RII / RSN ] INFO_SPEC 1870 *2QSPEC 1872 A RESPONSE message MUST contain an INFO_SPEC object which indicates 1873 the success of a reservation installation or an error condition. 1874 Depending on the value of the INFO_SPEC, the RESPONSE MAY also 1875 contain a QSPEC object. 1877 If any QSPEC objects are present, they MUST occur at the end of the 1878 message. There are no other requirements on transmission order, 1879 although the above order is recommended. 1881 No message-specific flags are defined. 1883 One generic flag is defined for use in the common header with the 1884 RESPONSE message. This is: 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | Reserved |S| 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 SCOPING (S) - when set, indicates that the message is scoped and 1891 should not travel down the entire path but only as far as the next 1892 QNE (scope="next hop"). By default, this flag is not set (default 1893 scope="whole path"). 1895 5.1.2.4. NOTIFY 1897 The format of a NOTIFY message is as follows: 1899 NOTIFY = COMMON_HEADER 1900 INFO_SPEC *2QSPEC 1902 A NOTIFY message MUST contain an INFO_SPEC object indicating the 1903 reason for the notification. Depending on the INFO_SPEC value, it 1904 MAY contain one or two QSPEC objects providing additional 1905 information. 1907 No flags are defined for use with the NOTIFY message. 1909 5.1.3. Object Formats 1911 The QoS NSLP uses the Type-Length-Value (TLV) object format defined 1912 by GIST [I-D.ietf-nsis-ntlp]. Every object consists of one or more 1913 32-bit words with a one-word header. For convenience the standard 1914 object header is shown here: 1916 0 1 2 3 1917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 |r|r|r|r| Type |r|r|r|r| Length | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 The value for the Type field comes from GIST object type space. The 1922 Length field is given in units of 32 bit words and measures the 1923 length of the Value component of the TLV object (i.e. it does not 1924 include the standard header). 1926 The object diagrams here use '//' to indicate a variable sized field 1927 and ':' to indicate a field that is optionally present. 1929 A QoS NSLP implementation must recognize objects of the following 1930 types: RII, RSN, REFRESH_PERIOD, BOUND_SESSION_ID, INFO_SPEC, QSPEC 1931 and POLICY_DATA. 1933 NB: This draft does not currently include the codepoints for the QoS 1934 NSLP related object types. The object header is followed by the 1935 Value field, which varies for different objects. The format of the 1936 Value field for currently defined objects is specified below. 1938 5.1.3.1. Request Identification Information (RII) 1940 Type: RII 1942 Length: Fixed - 1 32-bit word 1944 Value: An identifier which must be (probabilistically) unique within 1945 the context of a SESSION_ID, and SHOULD be different every time a 1946 RESPONSE is desired. Used by a QNE to match back a RESPONSE to a 1947 request in a RESERVE or QUERY message. 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | Response Identification Information (RII) | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 5.1.3.2. Reservation Sequence Number (RSN) 1955 Type: RSN 1957 Length: Fixed - 2 32-bit word 1959 Value: An incrementing sequence number that indicates the order in 1960 which state modifying actions are performed by a QNE, and an epoc 1961 identifier to allow the identification of peer restarts. The RSN has 1962 local significance only, i.e. between a pair of neighbouring stateful 1963 QNEs. 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1966 Reservation Sequence Number (RSN) | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1968 Epoch Identifier | 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 5.1.3.3. REFRESH_PERIOD 1973 Type: REFRESH_PERIOD 1975 Length: Fixed - 1 32-bit word 1977 Value: The refresh timeout period R used to generate this message; in 1978 milliseconds. 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Refresh Period (R) | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 5.1.3.4. BOUND_SESSION_ID 1986 Type: BOUND_SESSION_ID 1988 Length: Fixed - 4 32-bit words 1990 Value: Specifies the SESSION_ID (as specified in GIST [I-D.ietf-nsis- 1991 ntlp]) of the session that must be bound to the session associated 1992 with the message carrying this object. 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | | 1996 + + 1997 | | 1998 + Session ID + 1999 | | 2000 + + 2001 | | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 5.1.3.5. PACKET_CLASSIFIER 2006 [FIXME: This is a first attempt at this for discussion (see also 2007 previous discussion on mailing list). Should the PACKET_CLASSIFIER be 2008 in here, or in the QSPEC?] 2010 Type: Packet Classifier 2012 Length: Variable 2014 Value: Contains a 2 byte value indicating the MRM being used, and 2015 then additional variable length MRM-specific data 2017 [FIXME: do we need to duplicate the MRM value here? could we just get 2018 it from the MRI in the GIST part of the message? however, duplicating 2019 it seems not unreasonable from a sanity checking perspective.] 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | Message-Routing-Method | | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2023 // Method-specific classifier data (variable) // 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 For the basic path-coupled routing MRM, the method specific data is 2027 two bytes long and consists of a set of flags: 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 |X|Y|P|T|F|S|A|B| Reserved | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 The flags are: 2035 X - Source Address and Prefix 2037 Y - Destination Address and Prefix 2039 P - Protocol 2041 T - Traffic Class 2043 F - Flow Label 2045 S - SPI 2047 A - Source Port 2049 B - Destination Port 2051 [FIXME: Some of the flag identifiers seem strange. They were selected 2052 so that they didn't conflict with any flag names in the GIST MRI, 2053 i.e. make D in GIST be something different here] 2055 The flags indicate which fields from the MRI should be used by the 2056 packet classifier. Flags MUST only be set if the data is present in 2057 the MRI (i.e. if there is a flag for it in GIST, then that must also 2058 be set). 2060 The appropriate set of flags set may depend, to some extent, on the 2061 QoS model being used. 2063 [FIXME: I assume we don't need flags for prefixes. Do we need 2064 separate flags for the two ports?] 2066 [FIXME: Should this object be mandatory or optional? Optional might 2067 mean 'use all information from the MRI'. Currently specified as 2068 mandatory.] 2070 5.1.3.6. INFO_SPEC 2072 Type: INFO 2074 Length: Variable 2076 Value: Contains a 4-bit error class, a 12-bit error code, an 8-bit 2077 NSLP-specific error subcode, an 8-bit error source identifier length, 2078 an error source identifier and optionally variable length error- 2079 specific information. 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | Class | Error Code | Error subcode | ESI-Length | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 // Error Source Identifier // 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 // Optional error-specific information // 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 The first four bits of the error code indicates the severity class. 2090 The currently defined severity classes are: 2092 o 0x01 - Informational 2094 o 0x02 - Success 2096 o 0x03 - Protocol Error 2098 o 0x04 - Transient Failure 2100 o 0x05 - Permanent Failure 2102 o 0x06 - NSLP-specific Error 2104 Within each severity class a number of error values are defined. 2106 o Informational: 2108 * 0x01 - Unknown BOUND_SESSION_ID: the message refers to an 2109 unknown SESSION_ID in its BOUND_SESSION_ID object. 2111 o Success: 2113 * 0x01 - State installation succeeded 2115 * 0x02 - Reservation created: reservation installed on 2116 complete path (sent by last node). 2118 * 0x03 - Reservation accepted: reservation installed at this 2119 QNE, but not yet installed on the rest of the path. 2121 * 0x04 - Reservation created but modified: reservation 2122 installed, but bandwidth reserved was not the maximum 2123 requested. 2125 o Protocol Error: 2127 * 0x01 - Illegal message type: the type given in the Message 2128 Type field of the common header is unknown. 2130 * 0x02 - Wrong message length: the length given for the 2131 message does not match the length of the message data. 2133 * 0x03 - Bad flags value: an undefined flag or combination of 2134 flags was set. 2136 * 0x04 - Mandatory object missing: an object required in a 2137 message of this type was missing. 2139 * 0x05 - Illegal object present: an object was present which 2140 must not be used in a message of this type. 2142 * 0x06 - Unknown object present: an object of an unknown type 2143 was present in the message. 2145 * 0x07 - Wrong object length: the length given for the object 2146 did not match the length of the object data present. 2148 * 0x08 - Unknown QSPEC type: the QoS Model ID refers to a QoS 2149 Model which is not known by this QNE. 2151 * 0x09 - RESERVE received from wrong direction. 2153 o Transient Failure: 2155 * 0x01 - Requested resources not available 2157 * 0x02 - Insufficient bandwidth available 2159 * 0x03 - Delay requirement cannot be met 2161 * 0x04 - Transient RMF-related error 2163 * 0x05 - Resources pre-empted 2165 * 0x06 - No GIST reverse-path forwarding state 2167 * 0x07 - NSLP soft-state expired 2169 * 0x08 - No path state for RESERVE, when doing a receiver- 2170 oriented 2171 reservation 2173 * 0x09 - Reservation pre-empted 2175 * 0x10 - RII conflict 2177 o Permanent Failure: 2179 * 0x01 - Authentication failure 2181 * 0x02 - Unable to agree transport security with peer 2183 * 0x03 - Internal or system error 2185 * 0x04 - Resource request denied (authorization failed) 2187 * 0x05000005 - Permanent RMF-related error 2189 o NSLP-specific Error: 2191 This error class may be used, if an NSLP needs to indicate 2192 errors, which do not fit any of the pre-defined error levels. 2193 The interpretation of these errors is defined in each NSLP 2194 separately. 2196 Values in the error subcode field are defined in each NSLP 2197 separately. For the QoS NSLP, these are defined in the different QoS 2198 model specifications. 2200 5.1.3.7. QSPEC 2202 Type: QSPEC 2204 Length: Variable 2206 Value: Variable length QSPEC (QoS specification) information, which 2207 is QoS Model dependent. 2209 The contents and encoding rules for this object are specified in 2210 other documents. See [I-D.ietf-nsis-qspec]. 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 | | 2214 // QSPEC Data // 2215 | | 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 5.1.3.8. POLICY_DATA 2220 POLICY_DATA objects may contain various items to authenticate the 2221 user and allow the reservation to be authorised. Some related issues 2222 are also discussed in Section 3.1.4. 2224 [FIXME: Need to fix this when Hannes is done] 2226 5.2. General Processing Rules 2228 5.2.1. State Manipulation 2230 The processing of a message and its component objects involves 2231 manipulating the QoS NSLP and reservation state of a QNE. 2233 For each flow, a QNE stores (RMF-related) reservation state which 2234 depends on the QoS model / QSPEC used and QoS NSLP operation state 2235 which includes non-persistent state (e.g. the API parameters while a 2236 QNE is processing a message) and persistent state which is kept as 2237 long as the session is active. 2239 The persistent QoS NSLP state is conceptually organised in a table 2240 with the following structure. The primary key (index) for the table 2241 is the SESSION_ID: 2243 SESSION_ID 2245 A large identifier provided by GIST or set locally. 2247 The state information for a given key includes: 2249 Flow ID 2251 Copied from GIST. Several entries are possible in case of 2252 mobility events. 2254 QoS Model ID 2256 32 bit identification of the QoS Model. 2258 SII-Handle for each upstream and downstream peer 2260 The SII-Handle is a local identifier generated by GIST and passed 2261 over the API. It is a handle that allows to refer to a particular 2262 GIST next hop. See SII-Handle in [I-D.ietf-nsis-ntlp] for more 2263 information. 2265 RSN from each upstream peer 2267 The RSN is a 32 bit counter. 2269 Current own RSN 2271 A 32 bit random number. 2273 List of RII for outstanding responses with processing information the 2274 RII is a 32 bit number. 2276 State lifetime 2277 The state lifetime indicates how long the state that is being 2278 signalled for remains valid. 2280 BOUND_SESSION_ID 2282 The BOUND_SESSION_ID is a 128 bit random number. 2284 Adding the state requirements of all these items gives an upper bound 2285 on the state to be kept by a QNE. The need to keep state depends on 2286 the desired functionality at the NSLP layer. 2288 5.2.2. Message Forwarding 2290 QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP 2291 does not have the concept of a message being sent along the entire 2292 path. Instead, messages are received by a QNE, which may then send 2293 another message (which may be identical to the received message, or 2294 contain some subset of objects from it) to continue in the same 2295 direction (i.e. towards QNI or QNR) as the message received. 2297 The decision on whether to generate a message to forward may be 2298 affected by the value of the SCOPING flag or by the presence of an 2299 RII object. 2301 5.2.3. Standard Message Processing Rules 2303 If a mandatory object is missing from a message then the receiving 2304 QNE MUST NOT propagate the message any further. It MUST construct an 2305 RESPONSE message indicating the error condition and send it back to 2306 the peer QNE that sent the message. 2308 If a message contains an object of an unrecognised type, then the 2309 behaviour depends on the object type value. The usual operation is to 2310 skip unknown objects. See the GIST specification for more 2311 information. 2313 5.2.4. Retransmissions 2315 QoS-NSLP messages for which a response is requested but fail to 2316 elicit a response are retransmitted. The initial retransmission 2317 occurs after a QOSNSLP_REQUEST_RETRY wait period. Retransmissions 2318 MUST be made with exponentially increasing wait intervals (doubling 2319 the wait each time). QoS-NSLP messages should be retransmitted until 2320 either a response (which might be an error) has been obtained, or 2321 until QOSNSLP_RETRY_MAX seconds after the initial transmission. 2323 QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial 2324 retransmit of the message 2326 QOSNSLP_RETRY_MAX: 30 seconds Give up retrying to send the 2327 message 2329 5.3. Object Processing 2331 5.3.1. Reservation Sequence Number (RSN) 2333 A QNE's own RSN is a sequence number which applies to a particular 2334 NSIS signalling session (i.e. with a particular GIMPS SESSION_ID). 2335 It MUST be incremented for each new RESERVE message where the 2336 reservation for the session changes. The RSN is manipulated using the 2337 serial number arithmetic rules from [RFC1982], which also defines 2338 wrapping rules and the meaning of 'equals', 'less than' and 'greater 2339 than' for comparing sequence numbers in a circular sequence space. 2341 The RSN object also contains an Epoch Identifier, which provides a 2342 method for determining when a peer has restarted (e.g. due to node 2343 reboot or software restart). The exact method for providing this 2344 value is implementation defined. Options include storing a serial 2345 number which is incremented on each restart, picking a random value 2346 on each restart or using the restart time. 2348 On receiving a RESERVE message a QNE examines the Epoch Identifier to 2349 determine if the peer sending the message has restarted. If the Epoch 2350 Identifier is different to that stored for the reservation then the 2351 RESERVE message MUST be treated as an updated reservation (even if 2352 the RSN is less than the current stored value), and the stored RSN 2353 and Epoch Identifier MUST be updated to the new values. 2355 When receiving a RESERVE message a QNE uses the RSN given in the 2356 message to determine whether the state being requested is different 2357 to that already stored. If the RSN is equal to that stored for the 2358 current reservation the current state MUST be refreshed. If the RSN 2359 is greater than the current stored value, the current reservation 2360 MUST be modified appropriately (provided that admission control and 2361 policy control succeed), and the stored RSN value updated to that for 2362 the new reservation. If the RSN is less than the current value, then 2363 it indicates an out-of-order message and the RESERVE message MUST be 2364 discarded. 2366 If the QNE does not store per-session state (and so does not keep any 2367 previous RSN values) then it MAY ignore the value of the RSN. It 2368 MUST also copy the same RSN into the RESERVE message (if any) it 2369 sends as a consequence of receiving this one. 2371 5.3.2. Request Identification Information (RII) 2373 A QNE sending some types of messages may require a response to be 2374 sent. It does so by including a Request Identification Information 2375 (RII) object. When creating an RII object the QNE MUST select the 2376 value for the RII such that it is probabilistically unique within the 2377 given session. A RII object is typically set by the QNI. 2379 A number of choices are available when implementing this. 2380 Possibilities might include using a totally random value, or a node 2381 identifier together with a counter. If the value collides with one 2382 selected by another QNE for a different QUERY then RESPONSE messages 2383 may be incorrectly terminated, and not passed back to the node that 2384 requested them. 2386 The node that created the RII object MUST remember the value used in 2387 the RII to match back any RESPONSE it will receive. The node SHOULD 2388 use a timer to identify situations where it has taken too long to 2389 receive the expected RESPONSE. If the timer expires without receiving 2390 a RESPONSE it MAY perform a retransmission as discussed in Section 2391 5.2.4. 2393 If an intermediate QNE wants to request a response for an outgoing 2394 message, but the message already included an RII when it arrive, the 2395 QNE must not add a new RII object nor replace the old RII object, but 2396 may simply remember that RII to match the related RESPONSE it is 2397 interested in later. When it receives the RESPONSE, it forwards the 2398 RESPONSE upstream towards the RII originating node. Note that only 2399 the node that originally created the RII can set up a retransmission 2400 timer. Thus, if an intermediate QNE decides to use the RII already 2401 contained in the message, it MUST NOT set up a retransmission timer, 2402 but rely on the retransmission timer set up by the QNE that inserted 2403 the RII. 2405 When receiving a message containing an RII object the node MUST send 2406 a RESPONSE if either 2408 o The SCOPING flag is set to one ('next hop' scope), or 2410 o This QNE is the last one on the path for the given session. 2412 and the QNE keeps per-session state for the given session. 2414 A message contains at most one RII object that is unique within a 2415 session and different for each message, in order to allow responses 2416 to be matched back to requests (without incorrectly matching at other 2417 nodes). Downstream nodes that desire responses may keep track of 2418 this RII to identify the RESPONSE when it passes back through them. 2420 In the rare event that the QNE wants to request a response for a 2421 message that already included an RII, and this RII value conflicts 2422 with an existing RII value on the QNE, the node should interrupt the 2423 processing the message, and send an error message upstream to 2424 indicate an RII collision, and request a retry with a new RII value. 2426 5.3.3. BOUND_SESSION_ID 2428 As shown in the examples in Section 4, the QoS NSLP can relate 2429 multiple sessions together. It does this by including the SESSION_ID 2430 from one session in a BOUND_SESSION_ID object in messages in another 2431 session. 2433 When receiving a message with a BOUND_SESSION_ID object, a QNE MUST 2434 copy the BOUND_SESSION_ID object into all messages it sends for the 2435 same session. A QNE that stores per-session state MUST store the 2436 value of the BOUND_SESSION_ID. 2438 The BOUND_SESSION_ID is only indicative in nature. However, a QNE 2439 implementation MAY use BOUND_SESSION_ID information to optimize 2440 resource allocation, e.g. for bidirectional reservations. When 2441 receiving a tearing RESERVE for an aggregate reservation, it MAY use 2442 this information to initiate a tearing RESERVE for end-to-end 2443 sessions bound to the aggregate. 2445 5.3.4. REFRESH_PERIOD 2447 Refresh timer management values are carried by the REFRESH_PERIOD 2448 object which has local significance only. At the expiration of a 2449 "refresh timeout" period, each QNE independently examines its state 2450 and sends a refreshing RESERVE message to the next QNE peer where it 2451 is absorbed. This peer-to-peer refreshing (as opposed to the QNI 2452 initiating a refresh which travels all the way to the QNR) allows 2453 QNEs to choose refresh intervals as appropriate for their 2454 environment. For example, it is conceivable that refreshing 2455 intervals in the backbone, where reservations are relatively stable, 2456 are much larger than in an access network. The "refresh timeout" is 2457 calculated within the QNE and is not part of the protocol; however, 2458 it must be chosen to be compatible with the reservation lifetime as 2459 expressed by the REFRESH_PERIOD, and an assessment of the reliability 2460 of message delivery. 2462 The details of timer management and timer changes (slew handling and 2463 so on) are identical to the ones specified in Section 3.7 of RFC 2205 2464 [RFC2205]. 2466 There are two time parameters relevant to each QoS NSLP state in a 2467 node: the refresh period R between generation of successive refreshes 2468 for the state by the neighbor node, and the local state's lifetime L. 2469 Each RESERVE message may contain a REFRESH_PERIOD object specifying 2470 the R value that was used to generate this (refresh) message. This R 2471 value is then used to determine the value for L when the state is 2472 received and stored. The values for R and L may vary from peer to 2473 peer. This peer-to-peer refreshing (as opposed to the QNI initiating 2474 a refresh which travels all the way to the QNR) allows QNEs to choose 2475 refresh intervals as appropriate for their environment. For example, 2476 it is conceivable that refreshing intervals in the backbone, where 2477 reservations are relatively stable, are much larger than in an access 2478 network. 2480 In more detail (quoting directly from RFC2205): 2482 1. Floyd and Jacobson [_XREF_FJ94] have shown that periodic 2483 messages generated by independent network nodes can become 2484 synchronized. This can lead to disruption in network services as 2485 the periodic messages contend with other network traffic for link 2486 and forwarding resources. Since QoS NSLP sends periodic refresh 2487 messages, it must avoid message synchronization and ensure that 2488 any synchronization that may occur is not stable. For this 2489 reason, it is recommended that the the refresh timer should be 2490 randomly set to a value in the range [0.5R, 1.5R]. 2492 2. To avoid premature loss of state, L must satisfy L >= (K + 2493 0.5)*1.5*R, where K is a small integer. Then in the worst case, 2494 K-1 successive messages may be lost without state being deleted. 2495 To compute a lifetime L for a collection of state with different R 2496 values R0, R1, ..., replace R by max(Ri). 2498 Currently K = 3 is suggested as the default. However, it may be 2499 necessary to set a larger K value for hops with high loss rate. K 2500 may be set either by manual configuration per interface, or by 2501 some adaptive technique that has not yet been specified. 2503 3. Each RESERVE message carries a REFRESH_PERIOD object 2504 containing the refresh time R used to generate refreshes. The 2505 recipient node uses this R to determine the lifetime L of the 2506 stored state created or refreshed by the message. 2508 4. The refresh time R is chosen locally by each node. If the 2509 node does not implement local repair of reservations disrupted by 2510 route changes, a smaller R speeds up adaptation to routing 2511 changes, while increasing the QoS NSLP overhead. With local 2512 repair, a router can be more relaxed about R since the periodic 2513 refresh becomes only a backstop robustness mechanism. A node may 2514 therefore adjust the effective R dynamically to control the amount 2515 of overhead due to refresh messages. 2517 The current suggested default for R is 30 seconds. However, the 2518 default value Rdef should be configurable per interface. 2520 5. When R is changed dynamically, there is a limit on how fast it 2521 may increase. Specifically, the ratio of two successive values 2522 R2/R1 must not exceed 1 + Slew.Max. 2524 Currently, Slew.Max is 0.30. With K = 3, one packet may be lost 2525 without state timeout while R is increasing 30 percent per refresh 2526 cycle. 2528 6. To improve robustness, a node may temporarily send refreshes 2529 more often than R after a state change (including initial state 2530 establishment). 2532 7. The values of Rdef, K, and Slew.Max used in an implementation 2533 should be easily modifiable per interface, as experience may lead 2534 to different values. The possibility of dynamically adapting K 2535 and/or Slew.Max in response to measured loss rates is for future 2536 study. 2538 5.3.5. INFO_SPEC 2540 [FIXME: INFO_SPEC processing rules are still to be defined in more 2541 detail.] 2543 We must make a distinction between INFO_SPEC messages used to provide 2544 non-fatal information, and fatal error messages. Error messages must 2545 be generated even if no RII is included in the incoming message. 2547 5.3.6. QSPEC 2549 The contents of the QSPEC depends on the QoS model being used. There 2550 is ongoing work to standardised parts of the QSPEC across multiple 2551 QoS models [QoS-Template]. 2553 Upon reception, the complete QSPEC is passed to the Resource 2554 Management Function (RMF), along with other information from the 2555 message necessary for the RMF processing. 2557 A QNE that receives a QSPEC stack MUST only look at the top QSPEC in 2558 the stack. If this QSPEC is not understood by the RMF, the QNE MUST 2559 send an RESPONSE containing an INFO_SPEC and MUST NOT attempt to 2560 recover by inspecting the rest of the stack. 2562 Parameters of the QoS Model that is being signalled for are carried 2563 in the QSPEC object. A domain may have local policies regarding QoS 2564 model implementation, i.e. it may map incoming traffic to its own 2565 locally defined QoS Models. The QoS NSLP supports this by allowing 2566 QSPEC objects to be stacked. 2568 When a domain wants to apply a certain QoS Model to an incoming per- 2569 flow reservation request, each edge of the domain is configured to 2570 map the incoming QSPEC object to a local QSPEC object and push that 2571 object onto the stack of QSPEC objects (typically immediately 2572 following the Common Control Information, i.e. the first QSPEC that 2573 is found in the message). 2575 A QNE that knows it is the last QNE to understand a local QSPEC 2576 object (e.g. by configuration of the egress QNEs of a domain) MUST 2577 remove the topmost QSPEC object from the stack. It SHOULD update the 2578 underlying QoS Model parameters if needed. 2580 5.4. Message Processing Rules 2582 This section provides rules for message processing. Not all possible 2583 error situation are considered. A general rule for dealing with 2584 erroneous messages is that a node should evaluate the situation 2585 before deciding how to react. There are two ways to react to 2586 erroneous messages: 2588 a) Silently drop the message, or 2589 b) Drop the message, and reply with an error code the sender. 2591 The default behavior, in order to protect the QNE from a possible DoS 2592 attack, is to silently drop the message. However, if the QNE is able 2593 to authenticate the sender, e.g., through GIST, the QNE may send a 2594 proper error message back to sender in order to let it know that 2595 there is an inconsistency in the states of adjacent QNEs. 2597 Yet, there is a third possible mode of operation when receiving an 2598 unexpected or erroneous message. The QNE may consider the incoming 2599 message as fully accpetable, and operate as if there was no error in 2600 the processing. This may happen, for example, if the QNE knowns it 2601 has just rebooted and has lost its signaling states. Now, the QNE may 2602 try to act as if "nothing happened". Note that an implementation must 2603 carefully consider this behavior. 2605 5.4.1. RESERVE Messages 2607 The RESERVE message is used to manipulate QoS reservation state in 2608 QNEs. A RESERVE message may create, refresh, modify or remove such 2609 state. The format of a RESERVE message is repeated here for 2610 convenience: 2612 RESERVE = COMMON_HEADER 2613 RSN PACKET_CLASSIFIER [ RII ] 2614 [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] 2615 [ POLICY_DATA ] *2QSPEC 2617 RESERVE messages MUST only be sent towards the QNR. 2619 A QNE that receives a RESERVE message checks the message format. In 2620 case of malformed messages, the QNE MAY send a RESPONSE message with 2621 the appropriate INFO_SPEC. 2623 Before performing any state changing actions a QNE MUST determine 2624 whether the request is authorized. It SHOULD exercise its local 2625 policy in conjunction with the POLICY_DATA object to do this. 2627 When the RESERVE is authorized, a QNE checks the COMMON_HEADER flags. 2628 If the TEAR flag is set, the message is a tearing RESERVE which 2629 indicates complete QoS NSLP state removal (as opposed to a 2630 reservation of zero resources). On receiving such a RESERVE message 2631 the QNE MUST inform the RMF that the reservation is no longer 2632 required. The QNE SHOULD remove the QoS NSLP state. It MAY signal to 2633 GIST (over the API) that reverse path state for this reservation is 2634 no longer required. Depending on the QoS model, the tear message may 2635 include a QSPEC to further specify state removal. If the QoS model 2636 requires a QSPEC, and none is provided, the QNE should reply with an 2637 error message, and not remove the reservation. If the tearing 2638 RESERVE includes a QSPEC, but none is required by the QoS model, the 2639 QNE may silently discard the QSPEC and proceed as if it did not exit 2640 in the message. 2642 If the QNE has reservations which are bound to this session (they 2643 contained the SESSION_ID of this session in their BOUND_SESSION_ID 2644 object), it MUST send a NOTIFY message for each of these reservations 2645 with an appropriate INFO_SPEC. The QNE MAY elect to send RESERVE 2646 messages with the TEAR flag set for these reservations. 2648 The default behaviour of a QNE that receives a RESERVE with a 2649 SESSION_ID for which it already has state installed but with a 2650 different flow ID is to replace the existing reservation (and tear 2651 down the reservation on the old branch if the RESERVE is received 2652 with a different SII). 2654 In some cases, this may not be the desired behaviour. In that case, 2655 the QNI or a QNE may set the REPLACE flag in the common header to 2656 zero to indicate that the new session does not replace the existing 2657 one. 2659 A QNE that receives a RESERVE with the REPLACE flag set to zero but 2660 with the same SII, will indicate REPLACE=0 to the RMF (where it will 2661 be used for the resource handling). Furthermore, if the QNE mainains 2662 a QoS-NSLP state then it will also add the new flow ID in the QoS- 2663 NSLP state. If the SII is different, this means that the QNE is a 2664 merge point. In that case, in addition to the operations specified 2665 above, the value REPLACE=0 is also indicating that a tearing RESERVE 2666 SHOULD NOT be sent on the old branch. 2668 When a QNE receives a RESERVE message with an unknown SESSION_ID, it 2669 MAY send a NOTIFY message to its upstream peer, indicating the 2670 unknown SESSION_ID. If the message was meant as a refresh, the reply 2671 indicates a downstream route change to the upstream peer. The 2672 upstream peer SHOULD send a complete RESERVE on the new path (new 2673 SII). It identifies the old signalling association (old SII) and MAY 2674 start sending complete RESERVE messages for other SESSION_IDs linked 2675 to this association. 2677 At a QNE, resource handling is performed by the RMF. For sessions 2678 with the REPLACE flag set to zero, we assume that the QoS model 2679 includes directions to deal with resource sharing. This may include, 2680 adding the reservations, or taking the maximum of the two or more 2681 complex mathematical operations. 2683 This resource handling mechanism in the QoS Model is also applicable 2684 to sessions with different SESSION_ID but related through the 2685 BOUND_SESSION_ID object. Session replacement is not an issue here, 2686 but the QoS Model may specify whether to let the sessions that are 2687 bound together share resources on common links or not. 2689 Finally, it is possible that a RESERVE is received with no QSPEC at 2690 all. This is the case of a reduced refresh. In this case, rather 2691 than sending a refreshing RESERVE with the full QSPEC, only the 2692 SESSION_ID and the SII are sent to refresh the reservation. Note 2693 that this mechanism just reduces the message size (and probably eases 2694 processing). One RESERVE per session is still needed. 2696 If the REPLACE flag is set, the QNE SHOULD update the reservation 2697 state according to the QSPEC contained in the message. It MUST 2698 update the lifetime of the reservation. If the REPLACE flag is not 2699 set, a QNE SHOULD NOT remove the old reservation state if the SII 2700 which is passed by GIST over the API is different than the SII that 2701 was stored for this reservation. The QNE MAY elect to keep sending 2702 refreshing RESERVE messages. 2704 If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state 2705 installation action. It does so by sending a RESPONSE with an 2706 INFO_SPEC indicating that the reservation is installed at the QNE. 2708 If the SCOPING flag is set, or if the QNE is the last QNE on the path 2709 to the destination, the QNE MUST send a RESPONSE message. 2711 When a QNE receives a RESERVE message, its processing may involve 2712 sending out another RESERVE message. When sending a RESERVE message, 2713 the QNE may insert or remove 'local' QSPEC objects from the message. 2714 If any QSPEC is present, the first QSPEC MUST NOT be removed when 2715 sending on the RESERVE message. 2717 Upon transmission, a QNE SHOULD set the ACKNOWLEDGE flag. It MUST do 2718 so if it wishes to use the reduced overhead refresh mechanism 2719 described in Section 3.2.5. It MUST NOT send a reduced overhead 2720 refresh message (i.e. a RESERVE with a non-incremented RSN and no 2721 QSPEC) unless it has received a RESPONSE message for that RESERVE 2722 message. 2724 If the session of this message is bound to another session, then the 2725 RESERVE message MUST include the SESSION_ID of that other session in 2726 a BOUND_SESSION_ID object. 2728 In case of receiver-initiated reservations, the RESERVE message must 2729 follow the same path that has been followed by the QUERY message. 2730 Therefore, GIST is informed, over the QoS NSLP/GIST API, to pass the 2731 message upstream, i.e., by setting GIST "D" flag, see GIST [I-D.ietf- 2732 nsis-ntlp]. 2734 The QNE must create a new RESERVE and send it to its next peer, when: 2736 - A new resource set up was done, 2738 - A new resource set up was not done, but the QOSM still defines that 2739 a RESERVE must be propagated, 2741 - The RESERVE is a refresh and includes new MRI, or 2743 - If the R-bit is included in an arrived QUERY. 2745 5.4.2. QUERY Messages 2747 A QUERY message is used to request information about the data path 2748 without making a reservation. This functionality can be used to 2749 certain QoS models. 2751 The format of a QUERY message is as follows: 2753 QUERY = COMMON_HEADER 2754 [ RII ] PACKET_CLASSIFIER [ BOUND_SESSION_ID ] 2755 [ POLICY_DATA ] *2QSPEC 2757 When a QNE receives a QUERY message the QSPEC is passed to the RMF 2758 for processing. The RMF may return a modified QSPEC which is used in 2759 any QUERY or RESPONSE message sent out as a result of the QUERY 2760 processing. 2762 When processing a QUERY message, a QNE checks whether the R-bit is 2763 set. If the bit is set, the QUERY is used to install reverse path 2764 state. In this case, if the QNE is not the QNR, it creates a new 2765 QUERY message to send downstream. If the QUERY contained a QSPEC, 2766 this MUST be passed to the RMF where it MAY be modified by QoS Model 2767 specific QUERY processing. If the QNE is the QNR, the QNE creates a 2768 RESERVE message, which contains a QSPEC received from the RMF and 2769 which MAY be based on the received QSPEC. If this node was not 2770 expecting to perform a receiver-initiated reservation then an error 2771 MUST be sent back along the path. 2773 If an RII object is present, and if the QNE is the QNR or the SCOPING 2774 flag is set, the QNE MUST generate a RESPONSE message and pass it 2775 back along the reverse of the path used by the QUERY. 2777 In other cases, the QNE MUST generate a QUERY message which is then 2778 forwarded further along the path using the same MRI, Session ID and 2779 Direction as provided when the QUERY was received over the GIST API. 2780 The QSPEC to be used is that provided by the RMF as described 2781 previously. When generating a QUERY to send out to pass the query 2782 further along the path, the QNE MUST copy the RII object (if present) 2783 into the new QUERY message unchanged. A QNE that is also interested 2784 in the response to the query keeps track of the RII to identify the 2785 RESPONSE when it passes through it. 2787 Note that QUERY messages with the R-bit set should always be answered 2788 by the QNR. This feature may be used, e.g., following handovers, to 2789 set up new path state in GIST, and request the other party to send a 2790 RESERVE back on this new GIST path. 2792 5.4.3. RESPONSE Messages 2794 The RESPONSE message is used to provide information about the result 2795 of a previous QoS NSLP message, e.g. confirmation of a reservation or 2796 information resulting from a query. The RESPONSE message is 2797 impotent, it does not cause any state to be installed or modified. 2799 The format of a RESPONSE message is repeated here for convenience: 2801 RESPONSE = COMMON_HEADER 2802 [ RII / RSN ] PACKET_CLASSIFIER 2803 INFO_SPEC *2QSPEC 2805 A RESPONSE message MUST be sent where the QNE is the last node to 2806 process a RESERVE or QUERY message containing an RII object (based on 2807 scoping of the RESERVE or QUERY, or because this is the last node on 2808 the path). In this case, the RESPONSE MUST copy the RII object from 2809 the RESERVE or QUERY. 2811 In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE 2812 flag is set or when an error occurs while processing a received 2813 message. If the received message contains an RII object, this object 2814 MUST be put in the RESPONSE, as described above. If the RESPONSE is 2815 sent as a result of the receipt of a RESERVE message without an RII 2816 object, then the RSN of the received RESERVE message MUST be copied 2817 into the RESPONSE message. 2819 On receipt of a RESPONSE message containing an RII object, the QNE 2820 MUST attempt to match it to the outstanding response requests for 2821 that signalling session. If the match succeeds, then the RESPONSE 2822 MUST NOT be forwarded further along the path. If the QNE did not 2823 insert this RII itself, if must forward the RESPONSE to the next 2824 peer. Thus, forwarding should only stop if the QNE inserted the RII 2825 by itself. 2827 On receipt of a RESPONSE message containing an RSN object, the QNE 2828 MUST compare the RSN to that of the appropriate signalling session. 2829 If the match succeeds then the INFO_SPEC MUST be processed. The 2830 RESPONSE message MUST NOT be forwarded further along the path whether 2831 or not the match succeeds. If there is no match for RSN, the message 2832 should be silently dropped. 2834 On receipt of a RESPONSE message containing neither an RII nor an RSN 2835 object, the RESPONSE MUST NOT be forwarded further along the path. 2837 In the typical case RESPONSE messages do not change the states 2838 installed in intermediate QNEs. However, depending on the QoS model, 2839 there may be situations where states are affected, e.g., 2841 - if the RESPONSE includes an INFO_SPEC describing an error situation 2842 resulting in reservations to be removed, or 2844 - the QoS model allows a QSPEC to define [min,max] limits on the 2845 resources requested, and downstream QNEs gave less resources than 2846 their upstrem nodes, which means that the upstream nodes may 2847 release a 2848 part of the resource reservation. 2850 5.4.4. NOTIFY Messages 2852 NOTIFY messages are used to convey information to a QNE 2853 asynchronously. The format of a NOTIFY message is as follows: 2855 NOTIFY = COMMON_HEADER 2856 PACKET_CLASSIFIER INFO_SPEC *2QSPEC 2858 NOTIFY messages are impotent. They do not cause any state to be 2859 installed. However, if the notification indicates an error, the 2860 indicated state may be removed. The exact operation depends on the 2861 QoS model. NOTIFY message do do not directly cause other messages to 2862 be sent. NOTIFY messages are sent asynchronously, rather than in 2863 response to other messages. They may be sent in either direction 2864 (upstream or downstream). 2866 6. IANA considerations 2868 This section provides guidance to the Internet Assigned Numbers 2869 Authority (IANA) regarding registration of values related to the QoS 2870 NSLP, in accordance with BCP 26 RFC 2434 [RFC2434]. 2872 The QoS NSLP requires IANA to create a number of new registries. 2874 The QoS NSLP Message Type is a 16 bit value. The allocation of 2875 values for new message types requires standards action. This 2876 specification defines four QoS NSLP message types, which form the 2877 initial contents of this registry: RESERVE, QUERY, RESPONSE and 2878 NOTIFY. 2880 QoS NSLP Messages have a messages-specific 16 bit flags/reserved 2881 field in their header. The allocation policy for new flags is TBD. 2883 The QoS Model Identifier (QoS Model ID) is carried in a QSPEC object. 2884 The allocation policy for new QoS Model IDs is TBD. 2886 This specification defines a NSLP for use with GIST. Consequently, a 2887 new identifier must be assigned for it from GIST NSLP Identifier 2888 registry. 2890 This document also defines six new objects for the QoS NSLP: RII, 2891 RSN, REFRESH_PERIOD, BOUND_SESSION_ID, PACKET_CLASSIFIER, QSPEC and 2892 INFO_SPEC. Values are to be assigned for them from NSLP Object Type 2893 registry. 2895 In addition it defines a number of Error Codes for the QoS NSLP. 2896 These can be found in Section 5.1.3.6 and are to be assigned values 2897 from NSLP Error Code registry. 2899 Further consideration of IANA issues can be found in a separate draft 2900 [I-D.loughney-nsis-ext]. 2902 7. QoS use of GIST service interface 2904 This section describes the use of GIST service interface to implement 2905 QoS NSLP requirements on GIST. 2907 7.1. Example sender-initiated reservation 2909 We first describe the use of the service interface in a very basic 2910 scenario: message reception and transmission for a RESERVE message in 2911 a sender-initiated reservation. 2913 A QNE that wishes to initiate a sender-initiated reservation 2914 constructs a new RESERVE message to send downstream. The use of GIST 2915 service interface in this case is explained on Figure 35. Note that 2916 we assume the SII handling in GIST [I-D.ietf-nsis-ntlp] is extended 2917 to distinguish between own and peer SII. 2919 GIST QoS NSLP 2920 | | 2921 |<=====================================| 2922 | SendMessage{ | 2923 | NSLP-Data=RESERVE, | 2924 | Retain-State=TRUE, | 2925 | Size=X bytes, | 2926 | Message-Handle=NULL, | 2927 | NSLP-ID=QoS, | 2928 | Session-ID=SID_X, | 2929 | MRI=MRI, | 2930 | Direction=downstream, | 2931 | Own-SII-Handle=empty, | 2932 | Peer-SII-Handle=empty | 2933 | Transfer-attributes=default, | 2934 | Timeout=default, | 2935 | IP-TTL=default} | 2936 | | 2938 Figure 35: GIST service interface usage for 2939 sending a sender-initiated reservation 2941 Note that an explicit preference for a particular type of transport, 2942 such as reliable/unreliable, may change the values of some service 2943 interface parameters (e.g. Transfer-attributes=unreliable). 2945 The message is received by the peer QNE. The use of GIST service 2946 interface when receiving a RESERVE message for a sender-initiated 2947 reservation is explained on Figure 36. 2949 GIST QoS NSLP 2950 | | 2951 |=====================================>| 2952 | RecvMessage{ | 2953 | NSLP-Data=RESERVE, | 2954 | Size=X bytes, | 2955 | Message-Handle=GIST_X, | 2956 | NSLP-ID=QoS, | 2957 | Session-ID=SID_X, | 2958 | MRI=MRI, | 2959 | Direction=downstream, | 2960 | Peer-SII-Handle=UP_SII_X, | 2961 | Transfer-attributes=default, | 2962 | IP-TTL=TTL_X, | 2963 | Original-TTL=TTL_Y} | 2964 | | 2965 |<=====================================| 2966 | MessageReceived{ | 2967 | Message-Handle=GIST_X, | 2968 | Retain-State=TRUE | 2969 | | 2971 Figure 36: GIST service interface usage for message 2972 reception of sender-initiated reservation 2974 7.2. Session identification 2976 The QoS NSLP keeps message and reservation state per session. A 2977 session is identified by a Session Identifier (SESSION_ID). The 2978 SESSION_ID is the primary index for stored NSLP state and needs to be 2979 constant and unique (with a sufficiently high probability) along a 2980 path through the network. On Figure 35, QoS NSLP picks a value SID_X 2981 for Session-ID. This value is subsequently used by GIST and QoS NSLP 2982 to refer to this session. 2984 7.3. Support for bypassing intermediate nodes 2986 The QoS NSLP may want to restrict the handling of its messages to 2987 specific nodes. This functionality is needed to support layering 2988 (explained in Section 3.2.8), when only the edge QNEs of a domain 2989 process the message. This requires a mechanism at GIMPS level (which 2990 can be invoked by the QoS NSLP) to bypass intermediates nodes between 2991 the edges of the domain. 2993 The intermediate nodes are bypassed using multiple levels of the 2994 router alert option. In that case, internal routers are configured to 2995 handle only certain levels of router alerts. This is accomplished by 2996 marking the signaling messages, i.e., modifying the QoS-NSLP default 2997 NSLP-ID value to another NSLP-ID predefined value. The marking MUST 2998 be accomplished by the ingress edge by modifying the QoS-NSLP default 2999 NSLP-ID value to a NSLP-ID predefined value. The egress MUST stop 3000 this marking process by reassigning the QoS-NSLP default NSLP-ID 3001 value to the original RESERVE message. The exact operation of 3002 modifying the NSLP-ID must be specified in the relevant QoS model 3003 specification. 3005 7.4. Support for peer change identification 3007 There are several circumstances where it is necessary for a QNE to 3008 identify the adjacent QNE peer, which is the source of a signalling 3009 application message; e.g., it may be to apply the policy that "state 3010 can only be modified by messages from the node that created it" or it 3011 might be that keeping track of peer identity is used as a (fallback) 3012 mechanism for rerouting detection at the NSLP layer. 3014 This functionality is implemented in GIST service interface with SII- 3015 handle. As shown in the above example, we assume the SII- handling 3016 will support both own SII and peer SII. 3018 Keeping track of the SII of a certain reservation also provides a 3019 means for the QoS NSLP to detect route changes. When a QNE receives 3020 a RESERVE referring to existing state but with a different SII, it 3021 knows that its upstream peer has changed. It can then use the old 3022 SII to initiate a teardown along the old section of the path. This 3023 functionality is supported in GIST service interface when the peer's 3024 SII which is stored on message reception is passed to GIST upon 3025 message transmission. 3027 7.5. Support for stateless operation 3029 Stateless or reduced state QoS NSLP operation makes the most sense 3030 when some nodes are able to operate in a stateless way at GIST level 3031 as well. Such nodes should not worry about keeping reverse state, 3032 message fragmentation and reassembly (at GIST), congestion control or 3033 security associations. A stateless or reduced state QNE will be able 3034 to inform the underlying GIST of this situation. GIST service 3035 interface supports this functionality with the Retain-State attribute 3036 in the MessageReceived primitive. 3038 7.6. Last node detection 3040 There are situations in which a QNE needs to determine whether it is 3041 the last QNE on the data path (QNR), e.g. to construct and send a 3042 RESPONSE message. 3044 A number of conditions may result in a QNE determining that it is the 3045 QNR: 3047 o the QNE may be the flow destination 3049 o the QNE have some other prior knowledge that it should act as 3050 the QNR 3052 o the QNE may be the last NSIS-capable node on the path 3054 o the QNE may be the last NSIS-capable node on the path 3055 supporting the QoS NSLP 3057 Of these four conditions, the last two can only be detected by GIST. 3058 We rely on GIST to inform the QoS NSLP about these cases by providing 3059 a trigger to the QoS NSLP when it determines that it is the last NE 3060 on the path, which supports the QoS NSLP. GIST supports this by the 3061 MessageDeliverError primitive. The error type 'no next node found' 3062 which is given as an example can be used. It is expected that 3063 additional error codes need to be defined. 3065 7.7. Re-routing detection 3067 Route changes may be detected at GIST layer or the information may be 3068 obtained by GIST through local interaction with or notification from 3069 routing protocols or modules. GIST allows to pass such information 3070 over the service interface using the NetworkNotification primitive 3071 with the appropriate 'downstream route change' or 'upstream route 3072 change' notification. 3074 7.8. Priority of signalling messages 3076 The QoS NSLP will generate messages with a range of performance 3077 requirements for GIST. These requirements may result from a 3078 prioritization at the QoS NSLP (Section 3.2.9) or from the 3079 responsiveness expected by certain applications supported by the QoS 3080 NSLP. 3082 GIST design should be able to ensure that performance for one class 3083 of messages was not degraded by aggregation with other classes of 3084 messages. GIST service interface supports this with the 'priority' 3085 transfer attribute. 3087 7.9. Knowledge of intermediate QoS NSLP unaware nodes 3089 In some cases it is useful to know that a reservation has not been 3090 installed at every router along the path. It is not possible to 3091 determine this using only NSLP functionality. 3093 GIST should be able to provide information to the NSLP about whether 3094 the message has passed through nodes that did not provide support for 3095 this NSLP. 3097 GIST service interface supports this by keeping track of IP-TTL and 3098 Original-TTL in the RecvMessage primitive. A difference between the 3099 two indicates the number of QoS NSLP unaware nodes. 3101 The QSPEC template also includes a bit "" telling that 3102 one or more QOSM-aware QNE were encountered on the path from the QNI 3103 to the QNR [I-D.ietf-nsis-qspec]. 3105 7.10. NSLP Data Size 3107 When GIST passes the QoS NSLP data to the NSLP for processing, it 3108 must also indicate the size of that data. This is supported by the 3109 NSLP-Data-Size attribute. 3111 7.11. Notification of GIST 'D' flag value 3113 When GIST passes the QoS NSLP data to the NSLP for processing, it 3114 must also indicate the value of the 'D' (Direction) flag for that 3115 message. This is done in the Direction attribute of the SendMessage 3116 and RecvMessage primitives. 3118 7.12. NAT Traversal 3120 The QoS NSLP relies on GIST for NAT traversal. 3122 8. Assumptions on the QoS Model 3124 8.1. Resource sharing 3126 This specification assumes that resource sharing is possible between 3127 flows with the same SESSION_ID that originate from the same QNI or 3128 between flows with a different SESSION_ID that are related through 3129 the BOUND_SESSION_ID object. For flows with the same SESSION_ID, 3130 resource sharing is only applicable when the existing reservation is 3131 not just replaced (which is indicated by the REPLACE flag in the 3132 common header. 3134 The Resource Management Function (RMF) reserves resources for each 3135 flow. We assume that the QoS model supports resource sharing between 3136 flows. A QoS Model may elect to implement a more general behaviour 3137 of supporting relative operations on existing reservations, such as 3138 ADDING or SUBTRACTING a certain amount of resources from the current 3139 reservation. A QoS Model may also elect to allow resource sharing 3140 more generally, e.g. between all flows with the same DSCP. 3142 8.2. Reserve/commit support 3144 Reserve/commit behaviour means that the time at which the reservation 3145 is made may be different from the time when the reserved resources 3146 are actually set aside for the requesting session. This 3147 specification acknowledges the usefulness of such a mechanism but 3148 assumes that its implementation is opaque to QoS NSLP and is fully 3149 handled by the QoS Model. 3151 9. Security Considerations 3153 9.1. Introduction and Threat Overview 3155 The security requirement for the QoS NSLP is to protect the 3156 signalling exchange for establishing QoS reservations against 3157 identified security threats. For the signalling problem as a whole, 3158 these threats have been outlined in NSIS threats [RFC4081]; the NSIS 3159 framework [RFC4080] assigns a subset of the responsibility to GIST 3160 and the remaining threats need to be addressed by NSLPs. The main 3161 issues to be handled can be summarised as: 3163 Authorization: 3165 The QoS NSLP must assure that the network is protected against theft- 3166 of-service by offering mechanisms to authorize the QoS reservation 3167 requester. A user requesting a QoS reservation might want proper 3168 resource accounting and protection against spoofing and other 3169 security vulnerabilities which lead to denial of service and 3170 financial loss. In many cases authorization is based on the 3171 authenticated identity. The authorization model must provide 3172 guarantees that replay attacks are either not possible or limited to 3173 a certain extent. Authorization can also be based on traits which 3174 enables the user to remain anonymous. Support for user identity 3175 confidentiality can be accomplished. 3177 Message Protection: 3179 Signalling message content should be protected against modification, 3180 replay, injection and eavesdropping while in transit. Authorization 3181 information, such as authorization tokens, need protection. This 3182 type of protection at the NSLP layer is necessary to protect messages 3183 between NSLP nodes which includes end-to-middle, middle-to-middle and 3184 even end-to-end protection. 3186 Rate Limitation: 3188 QNEs should perform rate limiting on the refresh messages that they 3189 send. An attacker could send erroneous messages on purpose, forcing 3190 the QNE to constantly reply with an error message. Authentication 3191 mechanisms would help in figuring out if error situations should be 3192 reported to the sender, or silently ignored. If the sender is 3193 authenticated, the QNE should reply promptly. 3195 In addition to the above-raised issues we see the following 3196 functionality provided at the NSLP layer: 3198 Prevention of Denial of Service Attacks: 3200 GIST and QoS NSLP nodes have finite resources (state storage, 3201 processing power, bandwidth). The protocol mechanisms suggested 3202 in this document should try to minimise exhaustion attacks against 3203 these resources when performing authentication and authorization 3204 for QoS resources. 3206 To some extent the QoS NSLP relies on the security mechanisms 3207 provided by GIST which by itself relies on existing authentication 3208 and key exchange protocols. Some signalling messages cannot be 3209 protected by GIST and hence should be used with care by the QoS NSLP. 3210 An API must ensure that the QoS NSLP implementation is aware of the 3211 underlying security mechanisms and must be able to indicate which 3212 degree of security is provided between two GIST peers. If a level of 3213 security protection for QoS NSLP messages is required which goes 3214 beyond the security offered by GIST or underlying security 3215 mechanisms, additional security mechanisms described in this document 3216 must be used. The different usage environments and the different 3217 scenarios where NSIS is used make it very difficult to make general 3218 statements without reducing its flexibility. 3220 9.2. Trust Model 3222 For this version of the document we will rely on a model which 3223 requires trust between neighboring NSLP nodes to establish a chain- 3224 of-trust along the QoS signalling path. This model is simple to 3225 deploy, was used in previous QoS authorization environments (such as 3226 RSVP) and seems to provide sufficiently strong security properties. 3227 We refer to this model as the 'New Jersey Turnpike' model. 3229 On the New Jersey Turnpike, motorists pick up a ticket at a toll 3230 booth when entering the highway. At the highway exit the ticket is 3231 presented and payment is made at the toll booth for the distance 3232 driven. For QoS signalling in the Internet this procedure is roughly 3233 similar. In most cases the data sender is charged for transmitted 3234 data traffic where charging is provided only between neighboring 3235 entities. 3237 +------------------+ +------------------+ +------------------+ 3238 | Network | | Network | | Network | 3239 | X | | Y | | Z | 3240 | | | | | | 3241 | -----------> -----------> | 3242 | | | | | | 3243 | | | | | | 3244 +--------^---------+ +------------------+ +-------+----------+ 3245 | . 3246 | . 3248 | v 3249 +--+---+ Data Data +--+---+ 3250 | Node | ==============================> | Node | 3251 | A | Sender Receiver | B | 3252 +------+ +------+ 3254 Legend: 3256 ----> Peering relationship which allows neighboring 3257 networks/entities to charge each other for the 3258 QoS reservation and data traffic 3260 ====> Data flow 3262 ..... Communication to the end host 3264 Figure 37: New Jersey Turnpike Model 3266 The model shown in Figure 37 uses peer-to-peer relationships between 3267 different administrative domains as a basis for accounting and 3268 charging. As mentioned above, based on the peering relationship a 3269 chain-of-trust is established. There are several issues which come 3270 to mind when considering this type of model: 3272 o This model allows authorization on a request basis or on a per- 3273 session basis. Authorization mechanisms will be elaborated in 3274 Section 4.9. The duration for which the QoS authorization is 3275 valid needs to be controlled. Combining the interval with the 3276 soft-state interval is possible. Notifications from the networks 3277 also seem to be viable approach. 3279 o The price for a QoS reservation needs to be determined somehow 3280 and communicated to the charged entity and to the network where 3281 the charged entity is attached. Price distribution protocols are 3282 not covered in this version of the document. This model assumes, 3283 per default, that the data sender is authorizing the QoS 3284 reservation. Please note that this is only a simplification and 3285 further extensions are possible and left for a future version of 3286 this document. 3288 o This architecture seems to be simple enough to allow a scalable 3289 solution (ignoring reverse charging, multicast issues and price 3290 distribution). 3292 Charging the data sender as performed in this model simplifies 3293 security handling by demanding only peer-to-peer security protection. 3294 Node A would perform authentication and key establishment. The 3295 established security association (together with the session key) 3296 would allow the user to protect QoS signalling messages. The 3297 identity used during the authentication and key establishment phase 3298 would be used by Network X (see Figure 37) to perform the so-called 3299 policy-based admission control procedure. In our context this user 3300 identifier would be used to establish the necessary infrastructure to 3301 provide authorization and charging. Signalling messages later 3302 exchanged between the different networks are then also subject to 3303 authentication and authorization. The authenticated entity thereby 3304 is, however, the neighboring network and not the end host. 3306 The New Jersey Turnpike model is attractive because of its 3307 simplicity. S. Schenker et. al. [shenker-pricing] discuss various 3308 accounting implications and introduced the edge pricing model. The 3309 edge pricing model shows similarity to the model described in this 3310 section with the exception that mobility and the security 3311 implications itself are not addressed. 3313 9.3. Computing the authorization decision 3315 Whenever an authorization decision has to be made then there is the 3316 question which information serves as an input to the authorizing 3317 entity. The following information items have been mentioned in the 3318 past for computing the authorization decision (in addition to the 3319 authenticated identity): 3321 Price 3323 QoS objects 3325 Policy rules 3327 Policy rules include attributes like time of day, subscription to 3328 certain services, membership, etc. into consideration when computing 3329 an authorization decision. 3331 A detailed description of the authorization handling will be left for 3332 a future version of this document. The authors assume that the QoS 3333 NSLP needs to provide a number of attributes to support the large 3334 range of scenarios. 3336 10. Open Issues 3338 Some of the areas for further work in this draft are indicated with 3339 [FIXME] markers. 3341 In addition, a list of open issues is contained in an online issue 3342 tracker at http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp- 3343 issues 3345 11. Acknowledgements 3347 The authors would like to thank Eleanor Hepworth, Ruediger Geib, 3348 Roland Bless and Nemeth Krisztian for their useful comments. 3350 Bob Braden provided helpful comments and guidance which were 3351 gratefully received. 3353 12. Contributors 3355 This draft combines work from three individual drafts. The following 3356 authors from these drafts also contributed to this document: Robert 3357 Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia 3358 Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and 3359 Maarten Buechli (Dante) and Eric Waegeman (Alcatel). 3361 Yacine El Mghazli (Alcatel) contributed text on AAA. 3363 13. References 3365 13.1. Normative References 3367 [I-D.ietf-nsis-ntlp] Schulzrinne, H., and R. Hancock, "GIST: General 3368 Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-08 3369 (work in progress), September 2005. 3371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3372 Requirement Levels", BCP 14, RFC 2119, March 1997. 3374 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3375 Specifications: ABNF", RFC 2234, November 1997. 3377 13.2. Informative References 3379 [RFC4080] Hancock, R., "Next Steps in Signaling: Framework", RFC 3380 4080, December 2004. 3382 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 3383 NSIS", RFC 4081, October 2004. 3385 [I-D.ash-nsis-y1541-qosm] Ash, J., "Y.1541 QoS Model for Networks 3386 Using Y.1541 QoS Classes", draft-ietf-nsis-y1541-qosm-00 (work in 3387 progress), August 2005. 3389 [I-D.ietf-nsis-qspec] Ash, J., "QoS NSLP QSPEC Template", draft-ietf- 3390 nsis-qspec-06 (work in progress), October 2005. 3392 [I-D.ietf-nsis-rmd] Bader, A., "RMD-QOSM - The Resource Management in 3393 Diffserv QoS model", draft-ietf-nsis-rmd-03 (work in progress), June 3394 2005. 3396 [I-D.kappler-nsis-qosmodel-controlledload] Kappler, C., "A QoS Model 3397 for Signaling IntServ Controlled-Load Service with NSIS", draft- 3398 kappler-nsis-qosmodel-controlledload-01 (work in progress), May 2005. 3400 [I-D.loughney-nsis-ext] Loughney, J. "NSIS Extensibility Model", 3401 draft-loughney-nsis-ext-00 (work in progress), May 2005. 3403 [I-D.manner-lrsvp] Manner, J., "Localized RSVP", draft-manner- 3404 lrsvp-04 (work in progress), September 2004. 3406 [I-D.tschofenig-nsis-aaa-issues] Tschofenig, H., "NSIS 3407 Authentication, Authorization and Accounting Issues", draft- 3408 tschofenig-nsis-aaa-issues-01 (work in progress), March 2003. 3410 [I-D.tschofenig-nsis-qos-authz-issues] Tschofenig, H., "QoS NSLP 3411 Authorization Issues", draft-tschofenig-nsis-qos-authz-issues-00 3412 (work in progress), June 2003. 3414 [MEF.EthernetServicesModel] Metro Ethernet Forum, "Ethernet Services 3415 Model", letter ballot document , August 2003. 3417 [OSP] ETSI, "Telecommunications and internet protocol harmonization 3418 over networks (tiphon); open settlement protocol (osp) for inter- 3419 domain pricing, authorization, and usage exchange", Technical 3420 Specification 101 321, version 2.1.0. 3422 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 3423 Services in the Internet Architecture: an Overview", RFC 1633, June 3424 1994. 3426 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 3427 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3428 Specification", RFC 2205, September 1997. 3430 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 3431 Services", RFC 2210, September 1997. 3433 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3434 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 3436 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3437 and W. Weiss, "An Architecture for Differentiated Services", RFC 3438 2475, December 1998. 3440 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 3441 and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 3442 2961, April 2001. 3444 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 3445 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 3446 September 2001. 3448 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 3449 "Session Authorization Policy Element", RFC 3520, April 2003. 3451 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 3452 Session Set-up with Media Authorization", RFC 3521, April 2003. 3454 [RFC3583] Chaskar, H., "Requirements of a Quality of Service (QoS) 3455 Solution for Mobile IP", RFC 3583, September 2003. 3457 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3458 3726, April 2004. 3460 [_XREF_FJ94] Jacobson, V., "Synchronization of Periodic Routing 3461 Messages", IEEE/ACM Transactions on Networking , Vol. 2 , No. 2 , 3462 April 1994. 3464 [_XREF_OPWA95] Breslau, L., "Two Issues in Reservation 3465 Establishment", Proc. ACM SIGCOMM '95 , Cambridge , MA , August 1995. 3467 [shenker-pricing] Shenker, S., Clark, D., Estrin, D., and S. Herzog, 3468 "Pricing in computer networks: Reshaping the research agenda", Proc. 3469 of TPRC 1995, 1995. 3471 Authors' Addresses 3473 Jukka Manner 3474 Department of Computer Science University of Helsinki 3475 P.O. Box 26 (Teollisuuskatu 23) 3476 HELSINKI, FIN-00014 3477 Finland 3478 Phone: +358-9-191-44210 3479 EMail: jmanner@cs.helsinki.fi 3481 Sven Van den Bosch 3482 Alcatel 3483 Francis Wellesplein 1 3484 Antwerpen B-2018 3485 Belgium 3486 Email: sven.van_den_bosch@alcatel.be 3488 Georgios Karagiannis 3489 University of Twente/Ericsson 3490 P.O. Box 217 3491 Enschede 7500 AE 3492 The Netherlands 3493 Email: karagian@cs.utwente.nl 3495 Andrew McDonald 3496 Siemens/Roke Manor Research 3497 Roke Manor Research Ltd. 3498 Romsey, Hants SO51 0ZN 3499 UK 3500 Email: andrew.mcdonald@roke.co.uk 3502 Appendix A. Glossary 3504 AAA: Authentication, Authorization and Accounting 3506 EAP: Extensible Authentication Protocol 3508 MRI: Message Routing Information (see [I-D.ietf-nsis-ntlp]) 3509 NAT: Network Address Translator 3511 NSLP: NSIS Signaling Layer Protocol (see [RFC4080]) 3513 NTLP: NSIS Transport Layer Protocol (see [RFC4080]) 3515 OPWA: One Pass With Advertising 3517 OSP: Open Settlement Protocol 3519 PIN: Policy Ignorant Node 3521 QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2) 3523 QNI: the first node in the sequence of QNEs that issues a reservation 3524 request for a session (see Section 2) 3526 QNR: the last node in the sequence of QNEs that receives a 3527 reservation request for a session (see Section 2) 3529 QSPEC: Quality of Service Specification 3531 SII: Source Identification Information 3533 SIP: Session Initiation Protocol 3535 RII: Request Identification Information 3537 RMD: Resource Management for DiffServ 3539 RMF: Resource Management Function 3541 RSN: Reservation Sequence Number 3543 RSVP: Resource reSerVation Protocol (see [RFC2205]) 3545 Appendix B. Change History 3547 Note to RFC Editor: This section is to be removed before publication. 3549 Changes from -00 3551 * Additional explanation of RSN versus Session ID differences. 3552 (Session IDs still need to be present and aren't replaced by RSNs. 3553 Explain how QoS NSLP could react once it notes that it maintains 3554 stale state.) 3556 * Additional explanation of message types - why we don't just 3557 have RESERVE and RESPONSE. 3559 * Clarified that figure 1 is not an implementation restriction. 3561 Changes from -01 3562 * Significant restructuring. 3564 * Added more concrete details of message formats and processing. 3566 * Added description of layering/aggregation concepts. 3568 * Added details of authentication/authorisation aspects. 3570 Changes from -02 3572 * Addressed comments from early review. 3574 * Added text on receiver-initiated and bi-directional 3575 reservations. 3577 * Extended description of session binding. Added support for 3578 fate sharing. 3580 * Restructured message formats and processing section. 3582 * Clarified refresh reduction mechanism. 3584 * Added assumptions on QSM. 3586 * Added assumptions on operating environment. 3588 Changes from -03 3590 * Removed overlaps between sections. 3592 * Clarified document does not specify how to aggregate individual 3593 end-to-end flow from a resource point of view but rather how such 3594 an aggregate can be signalled for. 3596 * Made session binding purely informational. 3598 * Clarified QSPEC stacking. 3600 * Added object format for ERROR_SPEC object. 3602 * Made RII a separate object from RESPONSE_REQUEST and outside of 3603 the SCOPING object. Then removed RESPONSE_REQUEST and made 3604 SCOPING a flag rather than an object. 3606 * Closed open issue of "PATH" message functionality. An empty 3607 QUERY is used to install reverse state along the path. 3609 * Made all flag names positive. Removed NO_FATE_SHARING flag: 3610 fate sharing is not supported by the signalling. 3612 * Removed the open issue on one-sided bidirectional reservation. 3613 Clarified how it can be done, even for stateless or reduced state 3614 domains in an example. 3616 * Removed open issue on priority. Message priority will be 3617 handled over GIST API, reservation priority is an issue for the 3618 RMF. 3620 Changes from -04 3622 * Resolved a number of outstanding comments on clarifications 3623 (likelihood of transport type, bidirectional reservations, handle 3624 of RESERVE messages inside a domain in case of aggregation or 3625 reduced state operation) from the mailing list. 3627 * Introduced a default value for REFRESH_PERIOD. 3629 * Introduced explicit feedback mechanism in case of route 3630 changes. 3632 * State acknowledgment is now supported by means of an 3633 ACKNOWLEDGE flag. This is made the default case. 3635 * Changed section 7 to reflect the use of GIST service interface. 3637 Changes from -05 3639 * Modified definitions of QoS Model and NSLP/QSPEC relationships. 3640 Removed concepts of QoS Signalling Model (QSM) and QoS Signalling 3641 Policy (QSP). 3643 * Made changes to the policy control and authentication concepts. 3644 Removed old appendix on original POLICY_CONTROL object. 3646 * Added a glossary. 3648 * Added text on reservation collision handling. 3650 * Moved this list of changes to the last appendix to make it 3651 easier to remove at publication time. 3653 Changes from -06 3655 * Change of editorship, (Sven -> Jukka) and, as a consequence, 3656 change from XML editing to good old nroff. ;) 3658 * Renamed "Summary refresh" to "Reduced refresh", as the old 3659 seemed to be a somewhat unclear term, and the new follows the 3660 terminology of RFC2961. 3662 * Added some missing figure captions, and an introductory text to 3663 Fig. 2 3665 * Added some clarifications to Sections 3.2.2, 3.2.8.1, 4.8, 5.1, 3666 5.2.3, and 5.4.1 3668 * Removed some texts that makes requests about GIST. These should 3669 be handled e.g. through the open issues list, and not have these 3670 types of clearly open issues within the main text. 3672 * Added "[FIXME: ...]" entries in various place to be handled at 3673 some point. 3675 * Added discussion on using RII as a "Forced Refresh" mechanism 3676 that is needed to support changes in routing paths. Now any node 3677 that gets to know that a routing change has happened somewhere can 3678 force a repair of the installed reservation state. 3680 * Various editorial changes, and typo fixes, e.g., search-replace 3681 "QoS-NSLP" > "QoS NSLP" and "QSpec" > "QSPEC" 3683 * Updated sections on "QoS model stacking". 3685 * Added some additional notes on policy control interactions. 3687 * Added initial version of a packet classifier information object. 3689 Changes from -07 3691 * fixed text talking about the GIST API on message processing 3692 priorities 3694 * clarified a number of issues, especially on message processing, 3695 eg., RESPONSE message processing, and the use of RII 3697 * reformatted the COMMON_HEADER 3699 * reformatted and renamed the ERROR_SPEC to INFO_SPEC 3701 * Added a new flag to the QUERY message to indicate a receiver- 3702 initiated reservation is requested 3704 * Updated text and the specification of RSNs 3706 * Added text about retransmissions 3708 * Added text about default message processing when receicing an 3709 erroneous message 3711 Intellectual Property Statement 3713 The IETF takes no position regarding the validity or scope of any 3714 Intellectual Property Rights or other rights that might be claimed to 3715 pertain to the implementation or use of the technology described in 3716 this document or the extent to which any license under such rights 3717 might or might not be available; nor does it represent that it has 3718 made any independent effort to identify any such rights. Information 3719 on the procedures with respect to rights in RFC documents can be 3720 found in BCP 78 and BCP 79. 3722 Copies of IPR disclosures made to the IETF Secretariat and any 3723 assurances of licenses to be made available, or the result of an 3724 attempt made to obtain a general license or permission for the use of 3725 such proprietary rights by implementers or users of this 3726 specification can be obtained from the IETF on-line IPR repository at 3727 http://www.ietf.org/ipr. 3729 The IETF invites any interested party to bring to its attention any 3730 copyrights, patents or patent applications, or other proprietary 3731 rights that may cover technology that may be required to implement 3732 this standard. Please address the information to the IETF at ietf- 3733 ipr@ietf.org. 3735 Disclaimer of Validity 3737 This document and the information contained herein are provided on an 3738 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3739 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3740 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3741 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3742 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3743 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3745 Copyright Statement 3747 Copyright (C) The Internet Society (2005). This document is subject 3748 to the rights, licenses and restrictions contained in BCP 78, and 3749 except as set forth therein, the authors retain all their rights. 3751 Acknowledgment 3753 Funding for the RFC Editor function is currently provided by the 3754 Internet Society.