idnits 2.17.00 (12 Aug 2021) /tmp/idnits15720/draft-ietf-nsis-qos-nslp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 599 instances of too long lines in the document, the longest one being 6 characters in excess of 72. 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 2003) is 6792 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 section? '1' on line 60 looks like a reference -- Missing reference section? '2' on line 1214 looks like a reference -- Missing reference section? '3' on line 1206 looks like a reference -- Missing reference section? '4' on line 1008 looks like a reference -- Missing reference section? '5' on line 374 looks like a reference -- Missing reference section? '6' on line 382 looks like a reference -- Missing reference section? '7' on line 409 looks like a reference -- Missing reference section? '8' on line 1235 looks like a reference -- Missing reference section? '9' on line 374 looks like a reference -- Missing reference section? '11' on line 534 looks like a reference -- Missing reference section? '10' on line 396 looks like a reference -- Missing reference section? '12' on line 971 looks like a reference -- Missing reference section? '13' on line 1134 looks like a reference -- Missing reference section? '14' on line 1214 looks like a reference -- Missing reference section? '15' on line 1235 looks like a reference -- Missing reference section? '16' on line 1226 looks like a reference -- Missing reference section? '17' on line 1235 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group 3 Internet Draft Sven Van den Bosch (Editor) 4 Alcatel 5 Georgios Karagiannis 6 Univ. of Twente/Ericsson 7 Andrew McDonald 8 Siemens/Roke Manor Research 10 Document: draft-ietf-nsis-qos-nslp-01.txt 11 Expires: April 2004 October 2003 13 NSLP for Quality-of-Service signaling 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This draft describes an NSIS Signaling Layer Protocol (NSLP) for 38 signaling QoS reservations in the Internet. It is in accordance with 39 the framework and requirements developed in NSIS. 41 Together with the NTLP, it provides functionality similar to RSVP and 42 extends it. The QoS-NSLP is independent of the underlying QoS 43 specification or architecture and provides support for different 44 reservation models. It is simplified by the elimination of support 45 for multicast flows. 47 NSLP for Quality-of-Service signaling October 2003 49 This version of the draft focuses on the basic protocol structure. It 50 identifies the different message types and describes the basic 51 operation of the protocol to create, refresh, modify and teardown a 52 reservation or to obtain information on the characteristics of the 53 associated data path. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC-2119 [1]. 61 Table of Contents 63 1. Introduction...................................................3 64 1.1 Scope and background........................................3 65 1.2 Model of operation..........................................3 66 1.3 Terminology.................................................6 67 2. Protocol design principles.....................................7 68 2.1 Basic protocol structure....................................7 69 2.2 QoS model...................................................8 70 2.3 Authentication and authorization............................9 71 2.4 Control Information.........................................9 72 2.5 Nested protocol operation..................................10 73 2.6 Protocol extensibility.....................................11 74 2.7 Implementation flexibility for scalability.................11 75 3. Basic message types...........................................12 76 3.1 RESERVE....................................................12 77 3.2 QUERY......................................................14 78 3.3 RESPONSE...................................................15 79 3.4 NOTIFY.....................................................15 80 4. Basic outline of operation....................................16 81 4.1 Making a reservation.......................................16 82 4.2 Refreshing a reservation...................................17 83 4.3 Sending a response.........................................18 84 4.4 Performing a query.........................................19 85 4.5 Tearing down a reservation.................................20 86 5. IANA section..................................................20 87 6. Requirements for the NSIS Transport Layer Protocol (NTLP).....21 88 6.1 Support for stateless operation............................21 89 6.2 Support for Source Identification Information (SII)........21 90 6.3 Last node detection........................................22 91 6.4 Re-routing detection.......................................22 92 6.5 Performance requirements...................................22 93 7. Open issues...................................................23 94 7.1 Refinements of this version................................23 95 7.2 Content for next (-01) version.............................23 96 7.3 Content for future (-0x) versions..........................24 97 NSLP for Quality-of-Service signaling October 2003 99 8. Security Considerations.......................................26 100 9. Change History................................................26 101 10. Appendix A: A strawman QSpec template........................26 102 References.......................................................27 103 Acknowledgments..................................................30 104 Contributors.....................................................30 105 Contact information..............................................30 106 Full Copyright Statement.........................................30 108 1. Introduction 110 1.1 Scope and background 112 This document defines a Quality of Service (QoS) NSIS Signaling Layer 113 Protocol (NSLP), henceforth referred to as the "QoS-NSLP". This 114 protocol establishes and maintains state at nodes along the path of a 115 data flow for the purpose of providing some forwarding resources for 116 that flow. It is intended to satisfy the QoS-related requirements of 117 [2]. This QoS-NSLP is part of a larger suite of signaling protocols, 118 whose structure is outlined in [3]; this defines a common NSIS 119 Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out many 120 aspects of signaling message delivery. 122 The design of QoS-NSLP is conceptually similar to RSVP [4], and uses 123 soft-state peer-to-peer refresh messages as the primary state 124 management mechanism. Although there is no backwards compatibility at 125 the level of protocol messages, interworking with RSVP at a signaling 126 application gateway would be possible in some circumstances. QoS-NSLP 127 extends the set of reservation mechanisms to meet the requirements of 128 [2], in particular support of sender or receiver-initiated 129 reservations, as well as a type of bi-directional reservation and 130 support of reservations between arbitrary nodes, e.g. edge-to-edge, 131 end-to-access, etc. On the other hand, there is no support for IP 132 multicast. 134 QoS-NSLP does not mandate any specific 'QoS Model', i.e. a particular 135 QoS provisioning method or QoS architecture; this is similar to (but 136 stronger than) the decoupling between RSVP and the IntServ 137 architecture [5]. It should be able to carry information for various 138 QoS models; the specification of Integrated Services for use with 139 RSVP given in [6] could form the basis of one QoS model. 141 1.2 Model of operation 142 NSLP for Quality-of-Service signaling October 2003 144 This section presents a logical model for the operation of the QoS- 145 NSLP and associated provisioning mechanisms within a single node. It 146 is adapted from the discussion in section 1 of [4]. The model is 147 shown in Figure 1. 148 +---------------+ 149 | Local | 150 |Applications or| 151 |Management (e.g| 152 |for aggregates)| 153 +---------------+ 154 ^ 155 ^ 156 V 157 V 158 +----------+ +----------+ +---------+ 159 | QoS-NSLP | | Resource | | Policy | 160 |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control | 161 +----------+ +----------+ +---------+ 162 . ^ | * ^ 163 | V . * ^ 164 +----------+ * ^ 165 | NTLP | * ^ 166 |Processing| * V 167 +----------+ * V 168 | | * V 169 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 170 . . * V 171 | | * ............................. 172 . . * . Traffic Control . 173 | | * . +---------+. 174 . . * . |Admission|. 175 | | * . | Control |. 176 +----------+ +------------+ . +---------+. 177 <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> 178 | Packet | | Interface | .+----------+ +---------+. 179 ===>|Processing|====| Selection |===.| Packet |====| Packet |.==> 180 | | |(Forwarding)| .|Classifier| Scheduler|. 181 +----------+ +------------+ .+----------+ +---------+. 182 ............................. 183 <.-.-> = signaling flow 184 =====> = data flow (sender -->receiver) 185 <<<>>> = control and configuration operations 186 ****** = routing table manipulation 188 Figure 1: QoS-NSLP in a Node 190 This diagram shows an example implementation scenario where QoS 191 conditioning is performed on the output interface. However, this does 192 NSLP for Quality-of-Service signaling October 2003 194 not limit the possible implementations. For example, in some cases 195 traffic conditioning may be performed on the incoming interface, or 196 it may be split over the input and output interfaces. 198 From the perspective of a single node, the request for QoS may result 199 from a local application request, or from processing an incoming QoS- 200 NSLP message. 202 - The 'local application case' includes not only user 203 applications (e.g. multimedia applications) but also network 204 management (e.g. initiating a tunnel to handle an aggregate, 205 or interworking with some other reservation protocol - such as 206 RSVP). In this sense, the model does not distinguish between 207 hosts and routers. 209 - The 'incoming message' case requires NSIS messages to be 210 captured during input packet processing and handled by the 211 NTLP. Only messages related to QoS are passed to the QoS-NSLP. 212 The NTLP may also generate triggers to the QoS-NSLP (e.g. 213 indications that a route change has occurred). 215 The QoS request is handled by a local 'resource management' function, 216 which coordinates the activities required to grant and configure the 217 resource. 219 - The grant processing involves two local decision modules, 220 'policy control' and 'admission control'. Policy control 221 determines whether the user has administrative permission to 222 make the reservation. Admission control determines whether the 223 node has sufficient available resources to supply the 224 requested QoS. 226 - If both checks succeed, parameters are set in the packet 227 classifier and in the link layer interface (e.g., in the 228 packet scheduler) to obtain the desired QoS. Error 229 notifications are passed back to the request originator. The 230 resource management function may also manipulate the 231 forwarding tables at this stage, to select (or at least pin) a 232 route; this must be done before interface-dependent actions 233 are carried out (including forwarding outgoing messages over 234 any new route), and is in any case invisible to the operation 235 of the protocol. 237 Policy control is expected to make use of a AAA service external to 238 the node itself. Some discussion can be found in [7] and [8]. More 239 generally, the processing of policy and resource management functions 240 may be outsourced to an external node leaving only 'stubs' co-located 241 with the NSLP; this is not visible to the protocol operation, 242 NSLP for Quality-of-Service signaling October 2003 244 although it may have some influence on the detailed design of 245 protocol messages to allow the stub to be minimally complex. 247 The group of user plane functions, which implement QoS for a flow 248 (admission control, packet classification, and scheduling) is 249 sometimes known as 'traffic control'. 251 Admission control, packet scheduling, and any part of policy control 252 beyond simple authentication have to be implemented using specific 253 definitions for types and levels of QoS; we refer to this as a QoS 254 model. Our assumption is that the QoS-NSLP is independent of the QoS 255 model, that is, QoS parameters (e.g. IntServ service elements) are 256 interpreted only by the resource management and associated functions, 257 and are opaque to the QoS-NSLP itself. QoS Models are discussed 258 further in section 2.2. 260 The final stage of processing for a resource request is to indicate 261 to the QoS-NSLP protocol processing that the required resources have 262 been configured. The QoS-NSLP may generate an acknowledgement message 263 in one direction, and may propagate the resource request forwards in 264 the other. Message routing is (by default) carried out by the NTLP 265 module. Note that while Figure 1 shows a unidirectional data flow, 266 the signaling messages can pass in both directions through the node, 267 depending on the particular message and orientation of the 268 reservation. 270 1.3 Terminology 272 The terminology defined in [3] applies to this draft. In addition, 273 the following terms are used: 275 - edge QNE - a QNE that is located at the boundary of an 276 administrative domain, e.g., Diffserv. 278 - egress QNE - an edge QNE that handles the traffic as it leaves 279 the domain. 281 - ingress QNE - an edge QNE that handles the traffic as it 282 enters the domain. 284 - interior QNE - a QNE that is part of an administrative domain, 285 e.g., Diffserv, and is not an edge QNE. 287 - QNE - an NSIS Entity (NE), which supports the QoS-NSLP. 289 - QNI - the first node in the sequence of QNEs that issues a 290 reservation request. 292 NSLP for Quality-of-Service signaling October 2003 294 - QNR - the last node in the sequence of QNEs that receives a 295 reservation request. 297 - QoS-NSLP stateful operation - mode of operation where per-flow 298 reservation states are created, maintained and used. 300 - QoS-NSLP reduced-state operation - mode of operation where 301 reservation states with a coarser granularity (e.g. per-class) 302 are created, maintained and used. 304 - QoS-NSLP stateless operation - mode of operation where 305 reservation state is not needed and not created. 307 - reduced state QNE - a QNE that supports the QoS NSLP reduced 308 state operation. 310 - Source or message source - QoS NSLP messages are sent peer-to- 311 peer. This means that a QNE considers its adjacent stateful 312 upstream or downstream peer to be the source of a QoS NSLP 313 message. I.e. the source of a QoS NSLP message is not 314 necessarily the QNI. 316 - Stateful QNE - a QNE that supports the QoS NSLP stateful 317 operation. 319 - Stateless QNE - a QNE that supports the QoS NSLP stateless 320 operation. 322 2. Protocol design principles 324 2.1 Basic protocol structure 326 Messages are normally passed from the NSLP to the NTLP via an API, 327 which also specifies the signaling application (as QoS-NSLP), the 328 flow/session identifier, and an indication of the intended direction 329 - towards data sender or receiver. On reception, the NTLP provides 330 the same information to the QoS-NSLP. 332 The protocol specifies four message types (RESERVE, QUERY, RESPONSE 333 and NOTIFY) and two objects (QSpec and Policy object). 335 - Each protocol message includes header information that 336 identifies the message type and determines which objects it 337 may carry. 339 NSLP for Quality-of-Service signaling October 2003 341 - A protocol message also contains Control Information (CI); 342 this is a group of objects that qualify and/or restrict the 343 action that a QNE may perform on the QoS message. Control 344 Information is always associated to a QSpec, i.e. CI and QSpec 345 always come in pairs. This is important when we have locally 346 valid objects e.g. for reduced state operation, because both a 347 CI and a QSpec will be added. 349 - QSpec object: The QoS parameters defined by the QoS model are 350 carried in a QSpec object. It describes the QoS that is being 351 reserved. 353 - Policy object: The Policy object authenticates and authorizes 354 the requester of the QoS reservation. 356 This memo intends to define message types and control information for 357 the QoS-NSLP (generic to all QoS models). It also introduces the QoS 358 model (section 2.2) and Policy object (section 2.3). However, a 359 detailed description of these objects will need to be provided in 360 separate documents. 362 2.2 QoS model 364 A QoS model is a defined mechanism for achieving QoS as a whole. The 365 specification of a QoS model includes a description of its QoS 366 parameter information, as well as how that information should be 367 treated or interpreted in the network. In that sense, the QoS model 368 goes beyond the QoS-NSLP protocol level in that it could also 369 describe underlying assumptions, conditions and/or specific 370 provisioning mechanisms appropriate for it. 372 A QoS model provides a specific set of parameters to be carried in 373 the QSpec, or restricts the values these parameters can take. 374 Integrated Services [5], Differentiated Services[9] and RMD [11] are 375 all examples of QoS models. There is no restriction on the number of 376 QoS models. QoS models may be local, meaning that they are private to 377 one network, implementation or vendor specific or global, meaning 378 that they must be implementable by different networks and vendors. 380 The QSpec contains a set of parameters and values describing the 381 requested resources. It is opaque to the QoS-NSLP and similar in 382 purpose to the TSpec, RSpec and AdSpec specified in [4,6]. At each 383 QNE, its content is interpreted by the resource management function 384 for the purposes of policy control and traffic control (including 385 admission control and configuration of the packet classifier and 386 scheduler). 388 NSLP for Quality-of-Service signaling October 2003 390 Different QoS models may share a common set of QoS parameters. 391 Standardizing a QSpec template would allow for a consistent 392 specification of common QoS parameters in different QoS models. It 393 would simplify the introduction of new QoS models as well as greatly 394 increasing interoperability. Other examples of QoS description for 395 which a template was standardized are e.g. the MEF Ethernet Service 396 definition [10]. The QSpec template is envisaged to be useful for 397 specifying a wide range of QoS descriptions. It would, for instance, 398 need to support both qualitative and quantitative QoS specifications 399 in order to provide for terminals that are not willing or capable to 400 quantitatively describe the traffic behavior they require. A strawman 401 QSpec template is described in Appendix A. In addition to 402 standardizing a QSpec template, individual QoS models could be 403 standardized, but we would expect them to have local significance 404 only. 406 2.3 Authentication and authorization 408 Future versions of this document will contain a discussion on the 409 Policy object, based on [7,8]. 411 2.4 Control Information 413 Any QoS-NSLP message may contain a set of objects for conveying 414 information about how these messages should be handled. This set of 415 objects is collectively known as Control Information (CI). 417 Control Information can have a local scope (Local Control Information 418 or LCI) or global scope. 420 The ability of a QNE to explicitly request a RESPONSE to its messages 421 (section 2.4.1) and the ability to limit the scope of a message are 422 both examples of Control Information (section 2.4.2). Future versions 423 of the draft may include more examples of Control 424 Information objects. 426 2.4.1ResponseRequest 428 Some QNEs may require explicit responses to messages they send. A 429 QUERY message (section 3.2), for instance, will always cause a 430 RESPONSE message (section 3.3) to be sent. The QNE that generates a 431 RESERVE message (section 3.1) may explicitly request that it triggers 432 a RESPONSE. 434 NSLP for Quality-of-Service signaling October 2003 436 If a RESPONSE message is required or desired, the QNE inserts a 437 ResponseRequest object in the message. The exact format of this 438 object will be determined in a future version of this specification. 440 In order to be able to match a response back to the corresponding 441 request , the ResponseRequest object contains Response Identification 442 Information (RII). The RII is inserted by the QNE that requests the 443 response and is copied into the corresponding RESPONSE message. QNEs 444 that receive a RESPONSE containing their own RII should not forward 445 the message further. 447 The ResponseRequest object also contains a flag to indicate whether 448 it is requesting a response from the next node (a 'local' response), 449 or a response from the QNR. More general ways of specifying scoping 450 information will be investigated in future versions of this document. 452 Note that if an intermediate QNE desires a RESPONSE as well, it 453 should not change the RII or add another ResponseRequest since the 454 RESPONSE will pass through it anyway. 456 2.4.2Message and object scoping 458 QoS-NSLP supports locally defined QoS model specifications by means 459 of local QSpecs and local Control Information. Messages containing 460 such local information need to be scoped, i.e. it should be possible 461 to restrict the forwarding of such a message to the domain in which 462 it is applicable. It may also be needed to scope individual objects 463 in the message. 465 One example of message scoping uses the RII to limit the forwarding 466 of a RESPONSE to the QNE that requested it. Another example might be 467 controlling the scope of a tearing RESERVE. 469 The two scopes of "single QoS-NSLP hop" and "whole path" appear to be 470 useful concepts. In case no scoping information is specified, the 471 default case of "whole path" must be assumed. It is still to be 472 determined what the best way(s) of specifying more flexible scoping 473 information, such as per-domain are. 475 2.5 Nested protocol operation 477 For various reasons an operator may want to use a different type of 478 QoS specification (i.e. a different QoS model) within its network. 479 This may be done, for example, in order for QNEs to be able to store 480 less reservation state. In order to allow some local selection of 481 which QoS Model to use without destroying all end-to-end aspects of 482 NSLP for Quality-of-Service signaling October 2003 484 the signaling, QoS-NSLP allows a nesting of QoS Models by 'stacking' 485 more than one pair of Control Information / QSpec object within a 486 message. 488 The details of this operation will be covered in future versions of 489 this draft. This nested operation would allow localized QSpec objects 490 and control information to be used along parts of the path. It also 491 has dependencies on the scoping facilities provided by the protocol. 493 2.6 Protocol extensibility 495 QoS-NSLP is designed in modular way making it possible to support 496 different QoS models and other future extensions of the protocol. 497 Extensions can be provided by specifying new QoS models and their 498 usage or defining new QoS-NSLP objects (similar to the current QSpec 499 and Policy object) and their usage. 501 In QoS-NSLP the basic operation mechanism of the protocol is clearly 502 separated from the control and traffic information being transported. 503 This logical separation makes it possible to develop a variety of new 504 QoS models within one protocol frame. Each of the QoS-NSLP message 505 types can carry, for each supported QoS Model, QoS descriptions by 506 using object templates. This memo discusses a template for the QoS 507 specification (QSpec). A future version will also cover the Policy 508 object. 510 A new QoS model is specified by defining the internal content of the 511 template objects and by defining how QoS provisioning is done in 512 different nodes. Another important aspect of defining a new QoS model 513 is the specification of the associated CI used in these templates, 514 which allow particular setting in different nodes. 516 A QoS model may have internal structure into different components, 517 some of which may have application limited to particular nodes while 518 being opaque to others. 520 2.7 Implementation flexibility for scalability 522 The QoS-NSLP protocol supports QoS architectures in which some QNEs 523 may not be able or willing to store per-session state. A stateless 524 operation is conceivable, in which QNEs interior to a domain store 525 neither NSLP nor NTLP state. They rather e.g. just send and receive 526 messages to provide information on currently available resources, and 527 react upon overload detection. Also reduced-state operation is 528 conceivable, in which QNEs do not store full per session (per-flow or 529 per-aggregate) state in both NSLP and NTLP, but rather, e.g. one per- 530 NSLP for Quality-of-Service signaling October 2003 532 class state in NSLP and no state in NTLP. Examples of how QoS can be 533 achieved with stateless and reduced-state operation are described in 534 RMD [11]. 536 Stateless and reduced state operation is only applicable under 537 certain circumstances. Stateless or reduced state QNEs are not able 538 to perform message bundling, message fragmentation and reassembly (at 539 the NSLP) or congestion control. They are not able to establish and 540 maintain security associations with their neighbors, which means they 541 can only be applied in a trusted environment. For these reasons, a 542 typical application of stateless or reduced state QNEs is for 543 signaling within a single domain where the edges of the domain are 544 stateful QNEs. 546 Stateless and reduced state QoS-NSLP operation makes the most sense 547 when (some nodes of) the underlying NTLP is (are) able to operate in 548 a stateless way as well. Such nodes should not worry about keeping 549 reverse path state, message fragmentation and reassembly (at the 550 NTLP), congestion control or security associations. A stateless or 551 reduced state QNE will be able to inform the underlying NTLP of this 552 situation. We rely on the NTLP design to allow for a mode of 553 operation that can take advantage of this information (section 6.1). 555 3. Basic message types 557 The QoS-NSLP contains four message types: RESERVE, QUERY, RESPONSE 558 and NOTIFY. 560 These messages have different conceptual properties; the 561 fundamental properties of the message determine how it should be 562 analyzed from the perspective of re-ordering, loss, end-to-end 563 reliability and so on. It is important for applications to know 564 whether NSLP messages can be repeated, discarded or merged and so on 565 (e.g. for edge mobility support, rerouting, etc). Indeed, the 566 ordering of messages that don't manipulate state at QNEs matters 567 little, whereas the way that messages that manipulate state are 568 interleaved matters very much. Therefore NSLP is designed such that 569 the message type identifies whether a message is manipulating state 570 (in which case it is idempotent) or not (it is impotent). 572 3.1 RESERVE 574 The RESERVE message is used to manipulate QoS reservation state in 575 QNEs. A RESERVE message may create, refresh, modify or remove such 576 state. 578 NSLP for Quality-of-Service signaling October 2003 580 The RESERVE message opaquely transports a QSpec object, describing 581 the desired service level and a Policy object, authorizing the 582 requestor of the service. It also carries the lifetime of the 583 reservation (most likely in the Control Information part). Each node 584 may insert a local QSpec object and or local Control Information 585 (LCI) provided it has a way of scoping this information (e.g. at the 586 boundary of a domain). 588 In some cases, a QNE needs to be able to distinguish between newly 589 created, modified state or refreshed state based on the RESERVE 590 message alone (not in combination with state information obtained 591 from previous messages). Therefore, one or more additional flags that 592 provide this differentiation may be needed. Future versions of this 593 draft will describe how such flag(s) will be provided and used. 595 In order to clearly distinguish between a RESERVE message that sets 596 the reserved resources to zero and a RESERVE message that tears down 597 QoS-NSLP state completely, a tear bit should be foreseen. Note that 598 the potential initiation of (reverse path) state removal at the NTLP 599 is a separate issue. This will be signaled over the API between NTLP 600 and QoS-NSLP. 602 RESERVE messages are sent peer-to-peer. This means that a QNE 603 considers its adjacent upstream or downstream peer to be the source 604 of the RESERVE message. Note that two nodes that are adjacent at the 605 QoS-NSLP layer may in fact be separated by several NTLP hops. A QoS- 606 NSLP node may want to be able to detect changes in its QoS-NSLP 607 peers, or send a message to an explicitly identified node, e.g. for 608 tearing down a reservation on an old path. This functionality can be 609 provided by keeping track of a Source Identification Information 610 (SII) object that is similar in nature to the RSVP_HOP object 611 described in [4]. We assume such an SII (section 6.2) to be available 612 as a service from the NTLP. 614 The RESERVE message is idempotent; the resultant effect is the same 615 whether a message is received once or many times. In addition, the 616 ordering of RESERVE messages matters - an old RESERVE message does 617 not replace a newer one. Both of these features are required for 618 protocol robustness - messages may be re-ordered on route (e.g. 619 because of mobility, or at intermediate NTLP nodes) or spuriously 620 retransmitted. 622 In order to tackle these issues, the RESERVE message contains a 623 Reservation Sequence Number (RSN). An RSN is an incrementing sequence 624 number that indicates the order in which state modifying actions are 625 performed by a QNE. The RSN has local significance only, i.e. between 626 QNEs. Attempting to make an identifier that was unique in the context 627 of a session identifier but the same along the complete path would be 628 NSLP for Quality-of-Service signaling October 2003 630 very hard. Since RESERVEs can be sent by any node on the path that 631 maintains reservation state (e.g. for path repair) we would have the 632 difficult task of attempting to keep the identifier synchronized 633 along the whole path. The ordering only matters between a pair of 634 nodes maintaining reservation state, i.e. stateful QNEs. This means 635 that we can instead make the Reservation Sequence Number unique just 636 between a pair of neighboring stateful QNEs. Note that an alternative 637 might be for the NTLP to guarantee in-order delivery between the NSLP 638 peers. 640 A Flow Identifier groups together state items for a single flow. The 641 RSN is one of these state items, and is used to identify reordering 642 of messages and to allow the use of partial refresh messages. The 643 state items for a number of flows can be linked together and 644 identified as part of a single reservation using a Session 645 Identifier. The identifiers play complementary roles in the 646 management of QoS NSLP state. 648 The sender of a RESERVE message may want to receive some confirmation 649 from a downstream node. For this purpose the RESERVE message may 650 contain a ResponseRequest object (section 2.4.1). 652 3.2 QUERY 654 A QUERY message is used to request information about the data path 655 without making a reservation. This functionality can be used to 656 'probe' the network for path characteristics or for support of 657 certain QoS models. The information obtained from a QUERY may be used 658 in the admission control process of a QNE (e.g. in case of 659 measurement-based admission control). Note that a QUERY does not 660 change existing reservation state, nor does it cause state to be 661 installed in nodes other than the one that generated the QUERY. 663 A QUERY message contains a ResponseRequest object containing Response 664 Identification Information (RII) that allows matching back RESPONSE 665 to the QUERY request. It is transported unchanged along the data path 666 and may be used to scope the RESPONSE to a QUERY message (section 667 3.3). 669 The QUERY message can gather information along the data path in a 670 number of objects. Some of these objects may be part of the QoS 671 model. Others may be generic to the QoS-NSLP protocol. 673 A QUERY message may be scoped. If scoping information is present, 674 this means that the QUERY is not supposed to go down the entire path 675 to the QNR but rather that is has a maximum number of QNE hops it can 676 travel. Else, the default case (whole path) is assumed. It is 677 NSLP for Quality-of-Service signaling October 2003 679 currently an open issue what the best way of message scoping is 680 (section 7.1) 682 3.3 RESPONSE 684 The REPONSE message is used to provide information about the result 685 of a previous QoS-NSLP message, e.g. confirmation, error or 686 information resulting from a query. The RESPONSE message is impotent, 687 it does not cause any state to be installed or modified. 689 A QNE may want to receive a RESPONSE message to inform it that the 690 reservation has been successfully installed. The RESERVE message may 691 contain a ResponseRequest object for this purpose. Such a 692 ResponseRequest object can be used to request an explicit 693 confirmation of the state manipulation signaled in the RESERVE 694 message. 696 The forwarding of the RESPONSE message along the path does not 697 necessarily imply the existence of NTLP reverse-path state at every 698 node. For example, the NTLP may have a mechanism to pass a message 699 directly from the egress to the ingress of a region of QNEs that do 700 not store per-flow reverse-path state. 702 If a QNE or the QNR is unable to provide the requested information or 703 if the response is negative, the RESPONSE message may be used to 704 carry an error message. 706 A QUERY always causes a RESPONSE to be sent. Therefore, a QUERY 707 message will always contain a ResponseRequest object. A RESERVE may 708 cause a RESPONSE to be sent if this is explicitly requested or when 709 an error occurs. 711 3.4 NOTIFY 713 NOTIFY messages are used to convey information to a QNE. NOTIFY 714 messages are impotent (they do not cause a change in state directly). 716 NOTIFY messages differ from RESPONSEs in that they need not refer to 717 any particular state or previously received message. They are sent 718 asynchronously. The NOTIFY message itself does not trigger or mandate 719 any action in the receiving QNE. 721 The information conveyed by a NOTIFY message is typically related to 722 error conditions. One example would be notification to an upstream 723 peer about state being torn down. 725 NSLP for Quality-of-Service signaling October 2003 727 4. Basic outline of operation 729 4.1 Making a reservation 731 To make a new reservation, the QNI builds a RESERVE message 732 containing a QSpec specifying the resources required and a Policy 733 object containing user identification and authorization information. 734 It initializes a Reservation Sequence Number (RSN) counter for the 735 flow and provides the initial value in the RESERVE message. This 736 message is passed to the NTLP, which delivers it to the next QNE. A 737 ResponseRequest object may be introduced if a confirmation of 738 successful reservation is desired. 740 At the next QNE the RESERVE message is examined. Policy control and 741 admission control decisions are made. The node performs appropriate 742 actions based on the content of any QSpec object in the message. The 743 QoS NSLP generates a new RESERVE message based on the one it 744 received. This is passed to the NTLP, which forwards it to the next 745 QNE. 747 The same processing is performed at further QNEs on the path, up to 748 the QNR. 750 At the QNR, having determined that it is the last QNE (section 6.3) 751 on the path, the attempt to send a further RESERVE message is 752 aborted. The NR may rely on information obtained from the NTLP to 753 determine that it is the last node (section 6.3). 755 A QNE may want to store per-flow state for a number of reasons. It 756 may be that per-flow reservations are required to provide better 757 granularity of reserved resources. Some additional functions can also 758 be provided by the NSLP by storing NSLP state. 760 If the QNE wishes to be able to detect changes in the neighboring QNE 761 (i.e. that a future RESERVE message did not come from the same node 762 as the one that sent this RESERVE), then it records the identity of 763 that node (e.g. SII). The SII on the outgoing message is defined by 764 the NTLP. 766 If the QNE also wants to detect re-ordered or duplicated RESERVE 767 messages then it must also store the Reservation Sequence Number. 768 When an NSLP node that maintains per-flow reservation state (and may 769 generate refreshes) generates a RESERVE message to forward on to the 770 next peer it must replace the Reservation Sequence Number in the 771 message it received with one of its own. If the NSLP does not 772 maintain any per-flow reservation state (and thus cannot generate new 773 NSLP for Quality-of-Service signaling October 2003 775 RESERVE messages (refreshes, tears, etc) on its own) then it can use 776 the RSN from the RESERVE message it received, rather than maintaining 777 its own sequence numbers. By managing the sequence numbers in this 778 manner, the source of the RESERVE does not need to determine how the 779 next NSLP node will process the message. 781 Layering approaches (as outlined in section 2.5) can be used by an 782 ingress QNE to translate end-to-end NSLP messages into a form which 783 is particularly suited to the local network, where it is expected 784 that interior nodes will benefit from this. For example, where only 785 per-class state or no state is stored by nodes (as for stateless or 786 reduced-state operation in section 2.7). At the egress of the region, 787 this local QSpec can be removed. 789 4.2 Refreshing a reservation 791 Since the NSIS protocol suite normally takes a soft-state approach to 792 managing reservation state in QNEs, the state created by a RESERVE 793 message must be periodically refreshed. Reservation state is deleted 794 if no new RESERVE messages arrive before the expiration of the 795 reservation lifetime. The Reservation lifetime is indicated in the 796 RESERVE message when the reservation is made. Maintaining the 797 reservation beyond this lifetime can be done by sending a RESERVE 798 message with the same QSpec and Policy objects as the original 799 message that created the reservation and by indicating that it is 800 refreshing existing state. Note that a refreshing RESERVE should not 801 increment the Reservation Sequence Number. 803 At the expiration of a "refresh timeout" period, each QNE 804 independently examines its state and sends a refreshing RESERVE 805 message to the next QNE peer where it is absorbed. This peer-to-peer 806 refreshing (as opposed to the QNI initiating a refresh which travels 807 all the way to the QNR) allows QNEs to choose refresh intervals as 808 appropriate for their environment. For example, it is conceivable 809 that refreshing intervals in the backbone, where reservations are 810 relatively stable, are much larger than in an access network. The 811 "refresh timeout" is calculated within the QNE and is not part of the 812 protocol; however, it must be chosen to be compatible with the 813 reservation lifetime, and an assessment of the reliability of message 814 delivery. 816 The details of timer management and timer changes (slew handling and 817 so on) are left for future versions of this document. 819 If a RESPONSE has been received to acknowledge that reservation state 820 has been installed, then an abbreviated form of refreshing RESERVE 821 message ('summary refresh') can be sent which references the 822 NSLP for Quality-of-Service signaling October 2003 824 reservation using the Reservation Sequence Number, rather than 825 including the full reservation specification. Note that this 826 functionality requires an explicit acknowledgment of state 827 installation to ensure that the RSN reference will be understood. It 828 is up to a QNE that receives a ResponseRequest to decide whether it 829 wants to accept summary refreshes and provide this explicit 830 acknowledgment. For example, reduced state QNEs that cannot support 831 summary refreshes would not send this acknowledgement. 833 It is currently an open point which parts of the RESERVE message are 834 reused by the summary refresh. A summary refresh containing only the 835 RSN seems to be the minimal case of a broad spectrum of varying 836 amounts of data that we send in an update. Future versions of this 837 document will attempt to identify some objects as 'needing refresh'. 839 When a QNE receives a partial refresh message it compares the RSN 840 against that of the currently installed reservation. If it matches 841 then the state is refreshed. If the RSN in the message is less than 842 that of the currently installed state (i.e. it refers to 'old' state) 843 then the message is discarded (possibly the messages got reordered 844 between the nodes). If the RSN in the message is greater than that of 845 the currently installed state then an error MUST be signalled back. 846 It means that the peer QNE believes that state is installed when it 847 is not. If not informed it would continue to attempt to refresh the 848 non-existent state. A partial refresh containing either an unknown 849 session identifier or flow identifier MUST also be responded to with 850 an error message (this is likely to occur following a rerouting 851 event). 853 4.3 Sending a response 855 A QNE sending a RESERVE message may also request a RESPONSE message 856 to be sent back to it. To do this it includes a ResponseRequest 857 object with a RII object in it. 859 When a node processes a received RESERVE message it should examine it 860 to see if it contains a local ResponseRequest object. If it does, 861 then a RESPONSE message is generated, and the contents of this object 862 are copied into it. The local ResponseRequest object is removed from 863 the RESERVE message being sent out. 865 At the QNR, the processing of local ResponseRequest objects is 866 carried out normally (this may happen before this QNE has determined 867 that it is the QNR). If the RESERVE message received by the QNR 868 contained a ResponseRequest object, then a RESPONSE message is 869 created with the contents of the ResponseRequest object copied into 870 it. 872 NSLP for Quality-of-Service signaling October 2003 874 On receiving a RESPONSE message a QNE should check the contents of 875 the ResponseRequest object echoed back to see if it contains an 876 identifier supplied by it (the RII). If it does, then it should 877 inspect the contents of the message and send it no further. This 878 should always be the case for local ResponseRequest objects. If one 879 of these is received with an incorrect identifier, then the RESPONSE 880 must be discarded. 882 For other QNR responses, the QNE may inspect the message and then 883 must pass it back to the NTLP to be sent on. 885 When a RESPONSE message reaches the edge of a stateless domain, the 886 egress QNE will map/interchange the control information used by the 887 "end to end" and "local" scope QoS model types. The generated LCI 888 information will be encapsulated into the RESPONSE message. By using 889 the stored SII of the ingress QNE the RESPONSE message will be sent 890 to the particular ingress QNE node. 892 Stateless and reduced state interior QNEs are not using the RESPONSE 893 message. 895 When the RESPONSE message is received by the ingress QNE node, the 896 LCI information is used by the "local" scope QoS model. Afterwards, 897 the LCI information is removed from the RESPONSE message, which is 898 sent towards the QNI. 900 4.4 Performing a query 902 In order to perform a query along a path, a QNE constructs a QUERY 903 message. The message must contain a ResponseRequest object in the 904 same manner as described above to allow it to match any received 905 RESPONSE messages back to the original QUERY. The QUERY message may 906 contain general QoS NSLP query elements, as well as objects specific 907 to a given QoS model. The message is then passed to the NTLP to be 908 passed along the path. 910 A QNE (including the QNR) receiving a QUERY message should inspect it 911 and manipulate the general query objects and QoS model specific query 912 objects as required. It then passes it to the NTLP for further 913 forwarding unless it knows it is the QNR. 915 At the QNR, a RESPONSE message is generated. Into this is copied the 916 ResponseRequest object, and other general and QoS model specific 917 information from the QUERY message. It is then passed to the NTLP to 918 be forwarded peer-to-peer back along the path. 920 NSLP for Quality-of-Service signaling October 2003 922 Each QNE receiving the RESPONSE message should inspect the 923 ResponseRequest object to see if it contains an RII supplied by it. 924 If it does not then it simply passes the message back to the NTLP 925 unless it is a local RESPONSE. If it does, it uses the RII to match 926 the RESPONSE back to the original QUERY, and performs any appropriate 927 action based on the result of the query. 929 4.5 Tearing down a reservation 931 Although the use of soft state means that it is not necessary to 932 explicitly tear down an old reservation, it is RECOMMENDED that QNIs 933 send a teardown request as soon as a reservation is no longer needed. 934 A teardown deletes reservation state and travels towards the QNR from 935 its point of initiation. A teardown message may be initiated either 936 by an application in a QNI or by a QNE along the route as the result 937 of a state timeout or service preemption. Once initiated, a teardown 938 message must be forwarded QNE peer - to - QNE peer without delay. 940 A QNE can remove a reservation by building a RESERVE message with the 941 'tear' indicator set to inform the next-hop QNE to remove the 942 reservation state that it may hold. The tearing RESERVE is passed to 943 the NTLP to be forwarded along the NEs up to the next-hop QNE. It is 944 currently an open issue whether the tearing RESERVE will 945 automatically tear down state in each NE. The next-hop QNE either 946 tears down the corresponding reservation and passes on the tearing 947 RESERVE, or, if it already has torn down the reservation, discards 948 the message. 950 In addition, the QNE should construct a NOTIFY message and attempt to 951 send it back to the QNE that requested the reservation originally. 952 The NOTIFY message will inform the other QNE that a reservation has 953 been removed. On receipt of such a NOTIFY message a QNE should 954 determine an appropriate course of action. This may include removing 955 its own reservation state, and passing the NOTIFY message back 956 further along the path. 958 The attempt to send a NOTIFY message may be abandoned if the NTLP is 959 not able to route the message along the reverse-path (e.g. because it 960 has not stored the necessary state). In case of a stateless or 961 reduced state domain, the ingress QNE of the domain will be notified 962 by the egress QNE, which has kept track of its SII. The ingress QNE 963 can then send the NOTIFY message further upstream. It can also 964 initiate a scoped tearing RESERVE message towards the egress QNE. 966 5. IANA section 967 NSLP for Quality-of-Service signaling October 2003 969 This section provides guidance to the Internet Assigned Numbers 970 Authority (IANA) regarding registration of values related to the QoS- 971 NSLP, in accordance with BCP 26 [12]. 973 Future versions of this draft will identify name spaces in QoS-NSLP 974 that require registration and contain recommendations for 975 registration policies. 977 6. Requirements for the NSIS Transport Layer Protocol (NTLP) 979 For the moment this section will merely describe what we assume 980 and/or request to be available from the NTLP. This section will later 981 be updated to describe the eventual interface when NTLP work gets 982 finalized. 984 6.1 Support for stateless operation 986 Stateless or reduced state QoS-NSLP operation makes the most sense 987 when (some nodes of) the underlying NTLP is (are) able to operate in 988 a stateless way as well. Such nodes should not worry about keeping 989 reverse state, message fragmentation and reassembly (at the NTLP), 990 congestion control or security associations. A stateless or reduced 991 state QNE will be able to inform the underlying NTLP of this 992 situation. We rely on the NTLP design to allow for a mode of 993 operation that can take advantage of this information. 995 6.2 Support for Source Identification Information (SII) 997 There are several circumstances where it is necessary for a QNE to 998 identify the adjacent QNE peer, which is the source of a signaling 999 application message; for example, it may be to apply the policy that 1000 "state can only be modified by messages from the node that created 1001 it". 1003 We rely on the NTLP to provide this functionality. By default, all 1004 outgoing QoS-NSLP messages are tagged like this at the NTLP layer, 1005 and this is propagated to the next QNE, where it can be used as an 1006 opaque identifier for the state associated with the message; we call 1007 this the Source Identification Information (SII). The SII is 1008 logically similar to the RSVP_HOP object of [4]; however, any IP (and 1009 possibly higher level) addressing information is not interpreted in 1010 the QoS-NSLP. Indeed, the intermediate NTLP nodes could enforce 1011 topology hiding by masking the content of the SII (provided this is 1012 done in a stable way). 1014 NSLP for Quality-of-Service signaling October 2003 1016 Keeping track of the SII of a certain reservation also provides a 1017 means for the QoS-NSLP to detect route changes. When a QNE receives a 1018 RESERVE referring to existing state but with a different SII, it 1019 knows that its upstream peer has changed. It can then use the old SII 1020 to send initiate a teardown along the old section of the path. This 1021 functionality would require the NTLP to be able to route based on the 1022 SII. We would like this functionality to be available as a service 1023 from the NTLP. 1025 6.3 Last node detection 1027 There are situations in which a QNE needs to determine whether it is 1028 the last QNE on the data path (QNR), e.g. to construct and send a 1029 RESPONSE message. 1031 A number of conditions may result in a QNE determining that it is the 1032 QNR: 1034 - the QNE may be the flow destination 1036 - the QNE have some other prior knowledge that it should act as 1037 the QNR 1039 - the QNE may be the last NSIS-capable node on the path 1041 - the QNE may be the last NSIS-capable node on the path 1042 supporting the QoS NSLP 1044 Of these four conditions, the last two can only be detected by the 1045 NTLP. We rely on the NTLP to inform the QoS-NSLP about these cases by 1046 providing a trigger to the QoS-NSLP when it determines that it is the 1047 last NE on the path, which supports the QoS-NSLP. It requires the 1048 NTLP to have an error message indicating that no more NSLPs of a 1049 particular type are available on the path. 1051 6.4 Re-routing detection 1053 This trigger is provided when the NTLP detects that the route taken 1054 by a flow (which the QoS-NSLP has issued signaling messages for) has 1055 changed. 1057 6.5 Performance requirements 1059 The QoS-NSLP will generate messages with a range of performance 1060 requirements for the NTLP. These requirements may result from a 1061 NSLP for Quality-of-Service signaling October 2003 1063 prioritization at the QoS-NSLP (section 7.3.4) or from the 1064 responsiveness expected by certain applications supported by the QoS- 1065 NSLP. 1067 The NTLP design should be able to ensure that performance for one 1068 class of messages was not degraded by aggregation with other classes 1069 of messages. The different classes of performance requirements will 1070 be listed in future versions of this document. 1072 7. Open issues 1074 7.1 Refinements of this version 1076 Some topics raised in this document would benefit from more detailed 1077 discussion. These include: 1078 - description of the operation under re-routing conditions 1079 - description of the modification operation 1080 - description of the operation under error conditions 1081 - detailed discussion of message timer 1082 - detailed discussion of control information, more particularly 1083 message scoping 1084 - detailed discussion on the impact of a tearing RESERVE on state 1085 teardown at the NTLP 1087 7.2 Content for next (-02) version 1089 In addition to refining the discussion of topics currently described 1090 in this document, we intend the next version of this document to 1091 discuss the following issues. 1093 7.2.1 Sender/Receiver-initiated operation 1095 A sender-initiated reservation is made when the QNI for that flow is 1096 located upstream of the QNR with respect to the data path of the flow 1097 that is being signaled for. A receiver-initiated reservation is then 1098 made when the QNI is located downstream of the QNR with respect to 1099 the data path of the flow that is being signaled for. Note however, 1100 that the actual QoS-NSLP entities that initiate these signaling 1101 procedures can be anywhere along the data path, not just at the 1102 endpoints. 1104 There are signaling scenarios in which the receiver-initiated 1105 approach is more advantageous, while in others the sender-initiated 1106 NSLP for Quality-of-Service signaling October 2003 1108 approach is required. QoS-NSLP stateless operation, for example, is 1109 only possible when the sender-initiated approach is applied. 1111 The next version of this draft will describe the use of sender- 1112 initiated and receiver-initiated reservations in the protocol. Note 1113 that the solution of this issue will also impact the way bi- 1114 directional reservations are supported (see Section 7.3.3). 1116 7.2.2 Message formats 1118 This version of the draft describes the functionality provided by the 1119 QoS-NSLP messages. Encoding this functionality into a message format 1120 is left for the next version. 1122 7.2.3Message flows 1124 This version of the draft briefly describes basic protocol operation. 1125 Future versions of this draft will include message flow diagrams for 1126 informative purposes (potentially in an appendix). 1128 7.3 Content for future (-0x) versions 1130 7.3.1 Aggregation 1132 Future versions of this document will describe the use of aggregation 1133 to reduce the signaling overhead (message bundling) and the routing 1134 state (similar to [13]). 1136 7.3.2 Tunnel management 1138 Future versions of this document will describe the use of QoS-NSLP 1139 over tunnels and the associated tunnel management. 1141 7.3.3 Bi-directional/proxy operation 1143 A future version of this draft will discuss the use of bi-directional 1144 reservations, i.e. combining the reservations for a pair of coupled 1145 flows going in opposite directions. The main difficulty here is that 1146 the two flows, although between the same end points, may traverse 1147 different paths across the Internet. 1149 Two proposals for tackling this are: 1151 NSLP for Quality-of-Service signaling October 2003 1153 - generate both a sender initiated and a receiver-initiated 1154 reservation at the QNI (section 7.2.1), and allow them to be bundled 1155 together by the NTLP (the bundle can be split if the paths diverge). 1156 - generate a sender-initiated reservation that includes a request for 1157 the QNR to generate a sender-initiated reservation for the flow in 1158 the other direction. 1160 Both methods make some assumption about the flow routing. The first 1161 method requires that both flows pass through the same QNI. The second 1162 assumes that the QNR for one direction is on the path of the flow in 1163 the other direction. 1165 A future version will also include discussion on the operation of 1166 QoS-NSLP with (path-coupled) proxies. 1168 7.3.4 Priority and preemption 1170 The QoS-NSLP will generate messages with different priority. 1171 Prioritization at the level of the QoS-NSLP includes reservation 1172 priority and message priority. 1174 Reservation priority enables some reservations to be setup even if 1175 resources would normally not be available (e.g. for emergency 1176 services). This requires a priority indication in the message. Note 1177 that such an indication may be restricted to the QoS model scope, 1178 although every QoS model is expected to need this functionality. 1179 Whether resources are freed by means of pre-emption (the act of 1180 tearing down an existing reservation to free resource for a new one) 1181 or whether high-priority resources should be pre-provisioned is an 1182 implementation issue for the Resource Management Function. 1184 Message priority allows QoS-NSLP messages to be processed and 1185 forwarded in a different order than in which they arrived. This may 1186 be needed to ensure responsiveness to reservation requests or 1187 modifications (e.g. a reservation caused by a mobility event of an 1188 in-service session may need to be handled faster than a query or a 1189 new reservation request). This kind of prioritization should then be 1190 supported in the QoS-NSLP message set and may pose requirements on 1191 the NTLP (section 6.5). 1193 Future versions of this document will describe the support and use of 1194 prioritization for the QoS-NSLP. 1196 7.3.5 Network Address Translation (NAT) 1197 NSLP for Quality-of-Service signaling October 2003 1199 Since the QoS-NSLP is used for requesting resources for data flows, 1200 the messages inevitably involve IP addresses and, possibly, port 1201 numbers. However, the addresses/ports of the data flow can be 1202 modified by Network Address Translators (NATs) along the path. It is 1203 hoped that some (or all) of this problem can be pushed down into the 1204 NTLP, so that only generic NSIS-awareness is required at the NAT, 1205 rather than requiring specific support for QoS-NSLP (as described in 1206 section 5.3 of [3]). Future versions of this document may contain 1207 additional discussion on this issue. 1209 7.3.6 Security components 1211 7.3.7 Mobility 1213 A future version of this draft will provide details on mobility 1214 support in QoS-NSLP, following the requirements in [2], [14]. A 1215 number of issues are associated with mobility support, such as 1216 localizing the new reservation to the new segment of the path, 1217 removing reservation state along the old segment of the path, 1218 recognizing a RESERVE message for an already established reservation 1219 although the IP address of the mobile node changed, possible 1220 concealment of QoS-NSLP messages due to IP-in-IP tunneling utilized 1221 in mobile IP, etc. Some of these issues can be solved by employing a 1222 session ID that is independent of the IP address, in addition to the 1223 flow ID (this has security implications, see [15]), and by supporting 1224 the SII and reservation sequence numbers. Some mobility support will 1225 be provided by NTLP, such as detection of route changes. More details 1226 are discussed in [16]. 1228 8. Security Considerations 1230 The security of the NSLP is provided by a combination of security 1231 functions at the NTLP and NSLP. Subsequent versions of this draft 1232 will need to contain a specification of the NSLP security features, 1233 and how these interact with those at the NTLP. 1235 Some consideration of the problems can be found in [17][15][8] 1237 9. Change History 1239 10. Appendix A: A strawman QSpec template 1240 NSLP for Quality-of-Service signaling October 2003 1242 This appendix describes a strawman QSpec template. The QSpec template 1243 could include objects and fields for conveying the following 1244 information: 1246 - QSpec ID: This would allow IANA reservation of well known 1247 QSpec parameter combinations 1249 - Traffic Envelope and traffic conformance (similar to RSVP's 1250 TSpec) 1252 - Excess treatment: what happens to non-conforming traffic of a 1253 certain reservation (may be dropped but could be remarked as 1254 well) 1256 - Offered guarantees: this may be delay, jitter, loss or 1257 throughput, both qualitatively (low delay) and quantitatively 1258 (delay < 100ms, optionally even with quantiles 1259 Note that the specification may support ranges of acceptable 1260 values 1262 - Service schedule: for when is the service requested: this 1263 would allow a RESERVE/COMMIT functionality 1265 - Reliability: what percentage of the time do you expect to get 1266 the offered guarantee (this will allow e.g. a local resource 1267 management function to map the traffic to an APS protected 1268 link) 1270 - Monitoring requirements: what information do you require about 1271 the reservation. This is related to the AdSpec functionality 1272 and may contain parameters or sub object to be used in QUERY. 1274 Note that Flow identification information is also needed but that 1275 this is not assumed to be part of the QSpec template but rather 1276 available over the API between NTLP and QoS-NSLP. 1278 It is not the intention that all QoS models support all fields and 1279 sub objects defined here. The definition of a QoS model entails a 1280 selection of one or more of these fields and/or sub objects. For 1281 instance, one QoS model could only allow QSpec ID and DSCP to be 1282 specified. 1284 References 1286 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1287 Levels", BCP 14, RFC 2119, March 1997 1288 NSLP for Quality-of-Service signaling October 2003 1290 2 M. Brunner, Ed., "Requirements for QoS signaling protocols." 1291 draft-ietf-nsis-req-09.txt, August 2003. 1293 3 R. Hancock, Ed., "Next Steps in Signaling: Framework", draft-ietf- 1294 nsis-fw-03.txt (work in progress), June 2003. 1296 4 Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 1297 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1298 Specification", RFC 2205, September 1997. 1300 5 Braden, B., Clark, D. and S. Shenker, "Integrated Services in the 1301 Internet Architecture: an Overview", RFC 1633, June 1994. 1303 6 Wroclawski, J., "The Use of RSVP with IETF Integrated Services", 1304 RFC 2210, September 1997. 1306 7 Tschofenig, H., "NSIS Authentication, Authorization and Accounting 1307 Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress), 1308 March 2003. 1310 8 Tschofenig, H., Buechli, M., Van den Bosch, S. and H. Schulzrinne, 1311 "QoS NSLP Authorization Issues", draft-tschofenig-nsis-qos-authz- 1312 issues-00 (work in progress), June 2003. 1314 9 S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An 1315 Architecture for Differentiated Services", RFC 2475, December 1316 1998. 1318 10 Metro Ethernet Forum, "Ethernet Services Model," letter ballot 1319 document, August 2003. 1321 11 Westberg, L., "Resource Management in Diffserv (RMD) Framework", 1322 draft-westberg-rmd-framework-04 (work in progress), September 1323 2003. 1325 12 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1326 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1328 13 Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, 1329 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 1330 September 2001. 1332 14 H. Chaskar, "Requirements of a QoS solution for Mobile IP," RFC 1333 3583, Sept. 2003. 1335 NSLP for Quality-of-Service signaling October 2003 1337 15 H. Tschofenig, H. Schulzrinne, et al., "Security implications of 1338 the session identifier" Internet Draft, June 2003. 1340 16 X. Fu, H. Schulzrinne, H. Tschofenig "Mobility Support in NSIS", 1341 Internet Draft, June 2003. 1343 17 H. Tschofenig and D. Kroeselberg, "Security Threats for NSIS", 1344 draft-ietf-nsis-threats-02.txt (work in progress), June 2003. 1346 Acknowledgments 1347 This section will contain acknowledgments. 1349 Contributors 1351 This draft combines work from three individual drafts. The following 1352 authors from these drafts also contributed to this document: Robert 1353 Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia 1354 Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and 1355 Maarten Buechli (Dante) and Eric Waegeman (Alcatel). 1357 Contact information 1359 Georgios Karagiannis 1360 University of Twente 1361 P.O. BOX 217 1362 7500 AE Enschede 1363 The Netherlands 1364 email: karagian@cs.utwente.nl 1366 Andrew McDonald 1367 Roke Manor Research 1368 Old Salisbury Lane 1369 Romsey 1370 Hampshire 1371 SO51 0ZN 1372 United Kingdom 1373 email: andrew.mcdonald@roke.co.uk 1375 Sven Van den Bosch 1376 Alcatel 1377 Francis Wellesplein 1 1378 B-2018 Antwerpen 1379 Belgium 1380 email: sven.van_den_bosch@alcatel.be 1382 Full Copyright Statement 1384 Copyright (C) The Internet Society (2003). All Rights Reserved. This 1385 document and translations of it may be copied and furnished to 1386 others, and derivative works that comment on or otherwise explain it 1387 or assist in its implementation may be prepared, copied, published 1388 NSLP for Quality-of-Service signaling October 2003 1390 and distributed, in whole or in part, without restriction of any 1391 kind, provided that the above copyright notice and this paragraph are 1392 included on all such copies and derivative works. However, this 1393 document itself may not be modified in any way, such as by removing 1394 the copyright notice or references to the Internet Society or other 1395 Internet organizations, except as needed for the purpose of 1396 developing Internet standards in which case the procedures for 1397 copyrights defined in the Internet Standards process must be 1398 followed, or as required to translate it into languages other than 1399 English. 1401 The limited permissions granted above are perpetual and will not be 1402 revoked by the Internet Society or its successors or assigns. This 1403 document and the information contained herein is provided on an "AS 1404 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1405 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1406 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1407 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1408 OR FITNESS FOR A PARTICULAR PURPOSE.