idnits 2.17.1 draft-ietf-nsis-qspec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 630. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 868), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 209 has weird spacing: '... by the reso...' == Line 212 has weird spacing: '...ew, the comm...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 2004) is 7162 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: 'QOS-SIG' is mentioned on line 203, but not defined == Missing Reference: 'RFC 2210' is mentioned on line 785, but not defined -- Looks like a reference, but probably isn't: '2212' on line 519 -- Looks like a reference, but probably isn't: '2215' on line 519 == Missing Reference: 'RFC 2212' is mentioned on line 804, but not defined == Missing Reference: 'RFC 2215' is mentioned on line 800, but not defined == Unused Reference: 'KEY' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'INTSERV' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'TRQ-QoS-SIG' is defined on line 663, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFFSERV') ** Downref: Normative reference to an Informational RFC: RFC 3564 (ref. 'DS-TE') ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'INTSERV') -- Possible downref: Non-RFC (?) normative reference: ref. 'INTSERV-QoS-SIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'NSIS-REQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'RMD-QoS-SIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'RMD-QSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'TRQ-QoS-SIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jerry Ash 2 Internet Draft AT&T 3 Attila Bader 4 Expiration Date: March 2005 Ericsson 5 Cornelia Kappler 6 Siemens AG 8 September 2004 10 QoS-NSLP QSpec Template 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of RFC 3668. 19 Internet-Drafts are Working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 31 Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This draft describes a QSpec template for the QoS NSIS Signaling 41 Layer Protocol (QoS NSLP) for signaling QoS reservations in the 42 Internet. A QSpec is transported in QoS-NSLP messages and is opaque 43 to QoS NSLP. It contains the QoS Signaling Model (QSM) Control 44 Information and QoS Description parameters. Control Information is, 45 for example, the scope of a particular QSpec. QoS Description 46 parameters are primary input and output parameters of the Resource 47 Management Function. They include descriptions of the QoS desired 48 and the QoS reserved. QoS Description parameters can also be used 49 for collecting information about resource availability along the 50 path and for signaling a range of acceptable QoS. The QSpec template 51 defines generic parameters that are common to many QSMs. 52 Particularly they are derived from the IntServ and DiffServ QoS 53 Models. They should be used by all QSMs if applicable and must be 54 understood by all QNEs. By identifying the generic parameters we aim 55 to ensure interoperability between different QSMs. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Processing of QSpec . . . . . . . . . . . . . . . . . . . . . . 5 62 4. QSpec Template . . . . . . . . . . . . . . . . . . . . . . . . .6 63 4.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . . .6 64 4.2 QSpec Format Overview . . . . . . . . . . . . . . . . . . . . .8 65 4.2.1 QSM Specific Control Information . . . . . . . . . . . . . . 8 66 4.2.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 10 67 4.2.2.1 QoS Desired . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.2.2.2 QoS Available . . . . . . . . . . . . . . . . . . . . . . 12 69 4.2.2.3 QoS Reserved . . . . . . . . . . . . . . . . . . . . . . .12 70 4.2.2.4 Minimum QoS . . . . . . . . . . . . . . . . . . . . . . . 12 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . .13 72 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . .13 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Intellectual Property Considerations . . . . . . . . . . . . . 14 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .16 77 Appendix A Example Qspecs . . . . . . . . . . . . . . . . . . . . 17 78 A.1 QSpec for Admission Control for DiffServ . . . . . . . . . . .17 79 A.2 QSpec for IntServ Controlled Load Service . . . . . . . . . . 18 80 A.3 QSpec for IntServ Guaranteed Load Service . . . . . . . . . . 18 81 Appendix B QoS Models, QoS Signaling Models and QSpecs . . . . . .19 82 Disclaimer of Validity and Copyright Statement . . . . . . . . . .20 84 1. Introduction 86 The QoS NSLP establishes and maintains state at nodes along the path 87 of a data flow for the purpose of providing forwarding resources 88 (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is 89 conceptually similar to RSVP [RSVP], and meets the requirements of 90 [NSIS-REQ]. 92 QoS NSLP can signal for different QoS Models, i.e. QoS provisioning 93 methods or QoS architectures. It should be able to support, for 94 example, IntServ and signaling for DiffServ admission control, and 95 satisfy the need of more complex control planes such as defined in 96 [Q.2630, Y.1541]. The usage of QoS NSLP to signal for a specific 97 QoS Model is called 'QoS Signaling Model'. Examples of different 98 QSMs for NSIS are specified in [TRQ-QoS-SIG, INTSERV-QoS-SIG, RMD- 99 QoS-SIG]. For more information on QoS Models and QSMs see the 100 Appendix. 102 QSM-specific information is carried in the so-called QSpec object, 103 which travels in QoS-NSLP messages. The format of the QSpec object 104 is QSM specific. The QSpec is opaque to QoS NSLP. It contains two 105 types of information: QSM Control Information and a QoS Description. 107 The QSM control information contains information not related to the 108 actual resource management but rather to message processing. An 109 example of QSM control information is the scope of the QSpec. QSM 110 Control Information must not be confused with the Common Control 111 Information, which is a set of objects defined in QoS NSLP. Whereas 112 QSM Control Information is specific to the QSpec, Common Control 113 Information is specific to the QoS NSLP message. 115 The QoS Description can have sub-objects corresponding to the TSpec, 116 RSpec and AdSpec objects specified in RSVP. This is, the QSpec may 117 contain a description of QoS desired and QoS reserved. It can also 118 collect information about available resources. Going beyond RSVP 119 functionality, the QoS Description also allows indicating a range of 120 acceptable QoS by defining a sub-object denoting minimum QoS. Usage 121 of these sub-objects is not bound to particular message types thus 122 allowing for flexibility. An object collecting information about 123 available resources may travel in any QoS NSLP message, for example 124 a QUERY message or a RESERVE message. 126 This draft provides a template for QSpec, which is needed in order 127 to help defining individual QSMs and in order to promote 128 interoperability between QSMs. 129 The processing of QSpec is described in more detail in Section 2. 130 The proposed QSpec template is given in Section 3, including an 131 applicability statement. Appendix A proposes preliminary QSpecs for 132 the IntServ Controlled Load and Guaranteed Service QoS Models. 133 Appendix B explains in more detail the relation between QoS Models, 134 QSMs and QSpecs. It also explains the current understanding of the 135 content of a QSM. 137 2. Terminology 139 Common NSLP Processing: Functions in a QNE that are related to NSLP 140 message processing (common for each QoS model) 142 Generic Parameter: Parameter that MUST be understood by any QNE, and 143 SHOULD be used if applicable 145 Immutable Parameter: Parameter that is set by initiating or 146 responding QNE and is not changed during the processing of QSpec 147 along the path 149 Minimum QoS: Minimum QoS is a functionality that MAY be supported by 150 any QSM: Together with a description of desired QoS, it allows the 151 QNI to specify a QoS range, i.e. an upper and lower bound. If the 152 desired QoS is not available, QNFs are going to decrease the 153 reservation until the minimum QoS is hit. 155 Mutable Parameter: Parameter that can be changed during the 156 processing of QSpec by any QNE along the path 158 Optional Parameter: Parameter that SHOULD be used by QSMs if 159 applicable 161 QoS Description: Container of the QSpec sub-objects, which describes 162 QoS. These parameters are input or output parameters of Resource 163 Management Function 165 QoS Available: Parameters describing the available resources. They 166 are used to collect information along a reservation path. 168 QoS Desired: The description of the desired QoS and/or the traffic 169 for which the sender request reservation. 171 QoS Model: A methodology to achieve QoS for a traffic flow, e.g. 172 IntServ Controlled Load. 174 QoS Reserved: Describes the reserved resources and related QoS 175 parameters (e.g. Slack Term) 177 QoS Signaling Model (QSM): A signaling model describing how to use 178 QoS NSLP to signal for a specific QoS Model 180 QSM Control Information: Control information that is specific to 181 QSM, and processed in QSM-specific NSLP Processing. 183 QSM-specific NSLP Processing: Functions in a QNE that process QSM 184 Control Information and are specific to each QoS Model. 186 QSpec: QSpec is the object of QoS-NSLP containing all QoS Model 187 specific information. 189 (QSpec) parameter: any parameter appearing in a QSpec, e.g. scope of 190 QSpec or token bucket. 192 QSpec sub-object: Main building blocks of QoS Description containing 193 a parameter set that is input or output of a Resource Management 194 Function operation. 196 Resource Management Function: Functions that are related to resource 197 management, specific to a QoS Model. It processes QoS Description. 199 3. Processing of QSpec 201 The model of QoS-NSLP message processing is illustrated in Figure 1. 202 A QoS-NSLP message is interpreted in the common NSLP processing of a 203 QNE as described in [QOS-SIG]. The QSpec, however, is opaque to QoS- 204 NSLP, which means that it is not processed in the common NSLP 205 processing but handed over to the QSM-specific NSLP processing and 206 then to the Resource Management Function (RMF). The QSM control 207 information is interpreted and perhaps modified by the QSM-specific 208 NSLP processing, and the QoS description is interpreted and may be 209 modified by the resource management function. Both, QSM-specific 210 NSLP processing and the RMF, may advise the common NSLP processing 211 on how to proceed with the signaling, e.g. to tear down a preempted 212 reservation. From an implementation point of view, the common NSLP 213 processing is the same in each NSIS capable router, whereas QSM- 214 specific NSLP processing and the RMF are QSM specific. Note that 215 the QSM-specific NSLP processing box is an addition to the QoS-NSLP 216 processing model of [QoS-SIG] suggested in this document. 218 +---------------+ 219 | Local | 220 |Applications or| 221 |Management (e.g| 222 |for aggregates)| 223 +---------------+ 224 ^ 225 ^ 226 V 227 +-------------+ +------------+----------+ +---------+ 228 |Common NSLP | |QSM-specific| Resource | | Policy | 229 | Processing +<<>>>| NSLP |Mgmt. Fct.|<<>| Control | 230 | | | Processing | | | | 231 +-------------+ +------------+----------+ +---------+ 232 . ^ | * ^ 233 | V . * ^ 234 +----------+ * ^ 235 | GIMPS | * ^ 236 |Processing| * V 237 +----------+ * V 238 | | * V 239 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 240 . . * V 241 | | * ............................. 242 . . * . Traffic Control . 243 | | * . +---------+. 244 . . * . |Admission|. 245 | | * . | Control |. 246 +----------+ +------------+ . +---------+. 247 -| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> 248 | Packet | | Interface | .+----------+ +---------+ 249 =>|Processing|====| Selection |===.| Packet |====| Packet |.=> 250 | | |(Forwarding)| .|Classifier| Scheduler|. 251 +----------+ +------------+ .+----------+ +---------+. 253 Figure 1. Model of QoS-NSLP Processing in a QNE 255 4. QSpec Template 257 4.1. Applicability 259 The QSpec template defines a format for the QSpec, as well as a 260 number of generic and optional QSpec parameters. Generic parameters 261 provide a common language for QSM developers to build their QSpecs 262 and are likely to be re-used in several QSMs. 264 This eases comparing different QSpecs and different QSMs - and 265 possibly simplifies mapping of one into another. Thus developers 266 should avoid defining parameters similar to the generic, 267 standardized ones. All parameters used in DiffServ and IntServ QSMs 268 are generic parameters. 270 A specific QSM may, however, only use a subset or perhaps none of 271 the generic QSpec parameters. For instance, it may only allow the 272 token bucket to be specified. Furthermore, a QSM may define 273 additional parameters. 275 All QNEs must be able to understand the generic parameters. It is 276 important to note this does not imply they must also implement all 277 generic parameters (e.g. token bucket). However they must be able to 278 provide a meaningful mapping to locally used parameters. 280 Hence, to summarize, generic parameters SHOULD be used by QSMs if 281 applicable. Generic parameters MUST be understood by any QNE. QNEs 282 do not need to implement generic parameters. They MUST however be 283 able to provide a meaningful mapping from generic parameters onto 284 local parameters. If they translate generic parameters into local 285 ones they must raise an appropriate flag (tbd). 287 Optional parameters SHOULD be used by QSMs if applicable, and 288 defining optional parameters facilitates interworking. However, 289 QNEs outside the domain employing a particular QSM cannot be 290 expected to understand the optional parameters. 292 A QSpec is specific to a QSM and is identified by a QSM ID carried 293 in QoS NSLP. However, as explained above, the generic parameters 294 contained in a QSpec are understood by any QNE, even if the 295 corresponding QSM is not known. Therefore a QNE SHOULD interpret the 296 generic parameters contained in a QSpec, even if it does not 297 understand the QSM. QoS NSLP provides appropriate error codes to 298 attach to the QSpec which indicate such a translation took place. 299 Hence, generic parameters ease global intelligibility of QoS NSLP 300 messages. 302 It needs to be investigated whether a minimal set of generic QSpec 303 parameters MUST even be implemented in any QNE: this may be 304 important for true interoperability of QSMs. The set of QSpec 305 parameters that MUST be supported could be a subset of the generic 306 ones defined here. 308 This version of the QSpec Template Draft only defines generic 309 parameters. Examples for optional parameters will be provided in the 310 future. 312 4.2. QSpec Format Overview 314 QSpec = 316 As described above, the QSpec object contains the actual resource 317 description (QoS description) as well as QSM control information. 318 Both QoS description and QSM control information may contain mutable 319 and immutable parameters. 321 Mutable parameters can be changed by any QNE, including by QoS NSIS 322 functions along the signaling path, whereas immutable parameters are 323 fixed by the initiating QNE and/or responding QNEs. An example of a 324 mutable parameter is the path's MTU, an example of an immutable 325 parameter is a token bucket describing the traffic to be sent. 327 4.2.1. QSM Specific Control Information 329 QSM specific control information is used for QSpec-specific control 330 information and for specific signaling functions not defined in QoS- 331 NSLP. It enables building a new signaling model within a QoS-NSLP 332 signaling framework, see for example [RMD-QoS-SIG] and [RMD-QSM]. 334 Generic parameters: 336 - 338 mutable hop count field, limiting the scope of QSpec to a maximum 339 number of QoS-NSLP hops. must not be confused with the 340 scope of the QoS NSLP message carrying the QSpec. This scope would 341 be coded in the Common Control Information. 343 - = , | 346 immutable parameter, indicating the desired start time and end time 347 of the service, i.e. when is the service available. The values for 348 and respectively 349 can be infinity, in which case the reservation can be ended by the 350 usual tearing RESERVE. The Service Schedule parameter has two-fold 351 use: 353 a. Reservation of resources for the immediate future when the full 354 flow ID (e.g. port number) is still being negotiated. In this time 355 is set to zero. 357 b. Scheduling of reservations ahead of time to make sure resources 358 will be available. An example is reservation of resources for a 359 video-conference. Also in this case the full flow ID may not be 360 known at the time of reservation. 362 Hence, in both cases the QNI sends an incomplete RESERVE prompting 363 the Resource Management Function to set aside resources without 364 actually configuring the router(s). Router configuration is 365 triggered by a RESERVE containing the full flow ID. Appropriate 366 security measures need to be taken to prevent Denial of Service 367 abuse of this functionality (tbd). 369 It needs to be considered whether Service Schedule should be an 370 optional parameter because supporting it involves some overhead: the 371 RMF needs functionality to set aside resources in advance and 372 configure the router(s) later. Furthermore, for large advance 373 reservations, it may be necessary to "phase out" ongoing 374 reservations much earlier than the actual reservation in order to 375 make sure resources will be available. 377 Note that even reservations that are "scheduled" need to be 378 refreshed just as ongoing reservations. Refresh periods are specific 379 to a particular state in a particular QNE [QoS-SIG]. Hence it is 380 conceivable that QNEs decide locally to make the refresh period for 381 scheduled reservations considerably longer than that for ongoing 382 reservations. 384 - Flag indicating unsuccessful reservation in stateless/reduced 385 state QNEs 387 Since in case of stateless/reduced state QoS-NSLP operation interior 388 nodes do not store per flow information edge nodes should be 389 notified about unsuccessful reservation, see further specification 390 in [RMD-QSM]. 392 - Flag indicating severe congestion in stateless/reduced state QNEs 394 Similarly to unsuccessful reservation, in case of sever congestion 395 this flag may be set in refresh messages. Note that severe 396 congestion notification can be done also by data remarking, see more 397 details in [RMD-QSM]. 399 Note that stateless/reduced state operation mode is used in some 400 DiffServ based QoS signaling models, see for example [RMD-QSM]. 401 These control fields are needed because interior routers do not 402 store per flow QoS-NSLP states and they are used for notifying edge. 404 4.2.2 QoS Description 406 The QoS Description objects are broken down into the following 407 categories: 409 = 410 412 On the QSpec template level, the only restriction on object usage is 413 that should always travel together with and/or . Otherwise there is no restriction 415 on how many of these sub-objects a QSpec may carry, nor what type of 416 sub-object is carried in what type of QoS NSLP message. For 417 example, in a receiver-initiated reservation scenario, the 418 initiating QNE may send a QUERY carrying a sub- 419 object to probe the available resources on the path. The same QUERY 420 may carry a sub-object. The responding QNE can re-use 421 the latter objects in the RESERVE message. The QoS NSLP and 422 particularly the QSMs prescribe how the sub-objects in QSpecs are 423 interpreted and used, and therefore restrict this freedom. 425 The union of all the sub-objects identified in this Section can 426 provide all functionality of the objects specified in RSVP IntServ, 427 however it is difficult to provide an exact mapping. 429 In RSVP, the Sender TSpec specifies the traffic an application is 430 going to send (e.g. token bucket). The AdSpec can collect path 431 characteristics (e.g. delay). Both are issued by the sender. The 432 receiver sends the FlowSpec which includes a Receiver TSpec 433 describing the resources reserved using the same parameters as the 434 Sender TSpec, as well as a RSpec which provides additional IntServ 435 QoS Model specific parameters, e.g. Rate and Slack. 437 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver- 438 initiated signaling employed by RSVP, and the IntServ QoS Model. 439 E.g. to the knowledge of the authors it is not possible for the 440 sender to specify a desired maximum delay except implicitly and 441 mutably by seeding the AdSpec accordingly. Likewise, the RSpec is 442 only meaningfully sent in the receiver-issued RSVP RESERVE message. 443 For this reason our debate at this point let us to a slightly 444 different mapping of necessary functionality to sub-objects, which 445 should result in more flexible signaling models. 447 Particularly, we settled for defining a "QoS Desired" rather than a 448 "Traffic Specification". QoS Desired may in fact just be a 449 description of traffic to be sent, but it may also include more 450 parameters (e.g. delay) or signal for resources than those derived 451 from an exact traffic description (e.g. a token bucket with a higher 452 peak rate). Furthermore we consider to allow all sub-objects 453 carrying the same parameter types (to be detailed in future versions 454 of this draft). Hence, a QNI could send a RESERVE with QoS Desired 455 containing a particular average bandwidth, and at the same time 456 include a QoS Available sub-object for querying availability of this 457 same parameter. If QoS Desired cannot be reserved, the QNR can use 458 the information collected in QoS Available along the path to signal 459 back to the QNI a more promising value of QoS Desired. The details 460 of such message exchanges need to be fixed elsewhere. 462 4.2.2.1 464 = 466 These parameters describe the traffic the QNI is going to inject 467 into the reservation and hence it is immutable. 469 = reserved rate desired 471 =

472 as defined in [RFC 2210] 474 = 476 An application may like to reserve resources for packets with a 477 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 478 [DIFFSERV], or DiffServ-enabled 479 traffic engineering (DS-TE) class type [DS-TE]. 481 = 483 Reservation priority is an essential way to differentiate flows for 484 emergency services, ETS, E911, etc., and assign them a higher 485 priority than normal priority flows. Appropriate security measures 486 need to be taken to prevent abuse of this parameter. These are 487 immutable parameters. 489 There has been some debate whether such priority parameters should 490 be generic to all NSLPs, generic to QoS-NSLP, or generic to QSMs, 491 that is, where they should be defined. It is beyond the scope of 492 this document whether the priorities defined here are also useful in 493 other NSLPs. However, we believe in the context of QoS-NSLP that 494 priority is best placed in the QSM and QSpec. The reason is that the 495 resource management function seems to function more efficiently if 496 priority state is held there rather than in common QoS-NSLP 497 processing of messages (see Figure 1). Only the resource management 498 function knows that resources are not sufficient and that it may be 499 necessary to preempt a reservation. If preemption state was 500 associated with QoS-NSLP state rather than with resource management 501 state, the resource management function would need to negotiate with 502 the common QoS-NSLP processing until the two work out what 503 reservation to preempt. 505 Note that although we locate priority parameters with the QSM, the 506 fact that we make them generic parameters could be seen as a 507 recommendation to implement them in all QNEs (see discussion above). 509 Note that QoS Desired may carry parameters like desired delay or 510 loss parameters, however these are optional parameters and not 511 specified in this document. 513 4.2.3.2 515 = 518 These parameters describe the resources currently available on the 519 path and are defined in [RFC 2210, 2212, 2215]. Each QNE must 520 inspect this object. If resources available to this QNE are less 521 than what says currently, the QNE must adapt it 522 accordingly. Hence when the message arrives at the recipient of the 523 message, reflects the bottleneck of the resources 524 currently available on a path. It can be used in a QUERY message, 525 for example, to collect the available resources along a data path. 527 4.2.3.3 529 = 531 These parameters describe the QoS reserved by the QNEs down the 532 path. are defined in Sec. 533 4.2.2.1 above. are defined in [RFC 2212]. These are mutable 534 parameters. 536 4.2.3.4 538 = 539 doesn't have an equivalent in RSVP. It allows the QNI 540 to define a range of acceptable QoS levels by including both the 541 desired QoS value and the minimum acceptable QoS in the same 542 message. The desired QoS is included with a and/or a 543 subobject seeded to the desired QoS value. The 544 minimum acceptable QoS value is coded in the 545 subobject. As the message travels towards the QNR, 546 is updated by QNEs on the path. If its value drops below the value 547 of the reservation failed and can be aborted. When 548 this method is employed it is important that the QNR signals back to 549 the QNI the value attained in the end, because the 550 reservation may need to be adapted accordingly. 552 5. Security Considerations 554 The Service Schedule and Priority parameters raise possibilities for 555 Denial of Service Attacks. How to deal with this will be handled in 556 future versions of this draft. 558 6. Open Issues 560 a. A detailed discussion of QSM development guidelines needs to be 561 provided. 563 b. A more detailed specification of the generic parameters needs to 564 be given. 566 c. The relationship of common NSLP processing, QSM-specific NSLP 567 processing and resource management function, as well as how their 568 tasks differ needs, to be described more clearly. For example, how 569 do QSM-specific NSLP processing and the RMF influence message 570 processing in common NSLP processing? 572 d. Should/can we request that QNEs MUST implement a subset of 573 generic parameters? 575 e. May a node compose a QSpec containing more parameters than 576 defined in the QSM it is signaling for, e.g. for later use by other 577 nodes? 579 f. The following optional parameters have been proposed to support 580 other QSMs, and need to be discussed for inclusion in the next 581 revisions of the draft: 583 i) adding the individual parameters: 584 , , , and 585 to all of the QoS Description categories: 586 588 ii) Generalize the priority parameter as follows: 590 = 593 Where and are as specified in 594 RFC 3209. 596 g. Do we need an explicit Traffic Specification, or is a that may not exactly describe the issued traffic 598 acceptable? 600 h. Should Service Schedule be an optional parameter because of the 601 overhead it may introduce? 603 7. Acknowledgements 605 The authors would like to thank Robert Hancock and Sven van den 606 Bosch for their helpful suggestions. 608 8. Intellectual Property Considerations 610 The IETF takes no position regarding the validity or scope of any 611 Intellectual Property Rights or other rights that might be claimed 612 to pertain to the implementation or use of the technology described 613 in this document or the extent to which any license under such 614 rights might or might not be available; nor does it represent that 615 it has made any independent effort to identify any such rights. 616 Information on the procedures with respect to rights in RFC 617 documents can be found in BCP 78 and BCP 79. 619 Copies of IPR disclosures made to the IETF Secretariat and any 620 assurances of licenses to be made available, or the result of an 621 attempt made to obtain a general license or permission for the use 622 of such proprietary rights by implementers or users of this 623 specification can be obtained from the IETF on-line IPR repository 624 at http://www.ietf.org/ipr. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights that may cover technology that may be required to implement 629 this standard. Please address the information to the IETF at ietf- 630 ipr@ietf.org. 632 9. References 634 [DIFFSERV] S. Blake et. al., "An Architecture for Differentiated 635 Services", RFC 2475, December 1998. 636 [DS-TE] F. Le Faucheur et. al., Requirements for Support of 637 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 638 July 2003 639 [KEY] S. Bradner, "Key words for use in RFCs to Indicate Requirement 640 Levels", BCP 14, RFC 2119, March 1997 641 [INTSERV] B. Braden et. al., "Integrated Services in the Internet 642 Architecture: an Overview," RFC 1633, June 1994. 643 [INTSERV-QoS-SIG] C. Kappler, "A QoS Model for Signaling IntServ 644 Controlled-Load Service with NSIS," work in progress. 645 [NSIS-REQ] M. Brunner et. al., "Requirements for QoS Signaling 646 Protocols", work in progress. 647 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 648 Network Element Service", RFC 2211, Sept. 1997. 649 [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality 650 of Service," September 1997. 651 [RFC2215] S. Shenker and J. Wroclawski, "General Characterization 652 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 653 1997. 654 [RMD-QoS-SIG] A. Bader et. al., "RMD (Resource Management in 655 Diffserv) QoS-NSLP model", work in progress. 656 [RMD-QSM] A. Bader, L. Westberg, G. Karagiannis, C. Kappler and T. 657 Phelan, "Resource Management for DiffServ QoS Signaling Model" 658 , work in progress. 659 [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) -- 660 Version 1 Functional Specification," RFC 2205, September 1997. 661 [RSVP-INTSERV] J. Wroclawski, "The Use of RSVP with IETF Integrated 662 Services", RFC 2210, September 1997. 663 [TRQ-QoS-SIG] J. Ash et. al., "NSIS Network Service Layer Protocol 664 QoS Signaling Proof-of-Concept," work in progress. 665 [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service 666 Signaling," work in progress. 667 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 668 Objectives for IP-Based Services," May 2002. 669 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 670 Protocol - Capability Set 3" Sep. 2003 672 10. Authors' Addresses 674 Jerry Ash 675 AT&T 676 Room MT D5-2A01 677 200 Laurel Avenue 678 Middletown, NJ 07748, USA 679 Phone: +1-(732)-420-4578 680 Fax: +1-(732)-368-8659 681 Email: gash@att.com 683 Attila Bader 684 Traffic Lab 685 Ericsson Research 686 Ericsson Hungary Ltd. 687 Laborc u. 1 H-1037 688 Budapest Hungary 689 EMail: Attila.Bader@ericsson.com 691 Chuck Dvorak 692 AT&T 693 Room 2A37 694 180 Park Avenue, Building 2 695 Florham Park, NJ 07932 696 Phone: + 1 973-236-6700 697 Fax:+1 973-236-7453 698 E-mail: cdvorak@att.com 700 Yacine El Mghazli 701 Alcatel 702 Route de Nozay 703 91460 Marcoussis cedex 704 FRANCE 705 Phone: +33 1 69 63 41 87 706 Email: yacine.el_mghazli@alcatel.fr 708 Cornelia Kappler 709 Siemens AG 710 Siemensdamm 62 711 Berlin 13627 712 Germany 713 Email: cornelia.kappler@siemens.com 715 Georgios Karagiannis 716 University of Twente 717 P.O. BOX 217 718 7500 AE Enschede 719 The Netherlands 720 EMail: g.karagiannis@ewi.utwente.nl 722 Andrew McDonald 723 Siemens/Roke Manor Research 724 Roke Manor Research Ltd. 725 Romsey, Hants SO51 0ZN 726 UK 727 EMail: andrew.mcdonald@roke.co.uk 729 Al Morton 730 AT&T 731 Room D3-3C06 732 200 S. Laurel Avenue 733 Middletown, NJ 07748 734 Phone: + 1 732 420-1571 735 Fax: +.1 732 368-1192 736 E-mail: acmorton@att.com 738 Percy Tarapore 739 AT&T 740 Room D1-3D33 741 200 S. Laurel Avenue 742 Middletown, NJ 07748 743 Phone: + 1 732 420-4172 744 E-mail: tarapore@.att.com 746 Lars Westberg 747 Ericsson Research 748 Torshamnsgatan 23 749 SE-164 80 Stockholm, Sweden 750 EMail: Lars.Westberg@ericsson.com 752 Appendix A: Example QSpecs 754 Note the mere definition of QSpecs is not sufficient for determining 755 how to signal for DiffServ and IntServ respectively. Rather, the 756 full QSM needs to be defined. 758 A.1 QSpec for Admission Control for DiffServ 760 QSpec for Diffserv QSM in general may be provided in future versions 761 of this draft. A QSpec for a DiffServ QSM, RMD is partically 762 included in [RMD-QSM]. 764 A.2 QSpec for IntServ Controlled Load Service 766 The QoS Model for IntServ Controlled Load is defined in [RFC2211]. 767 The QSpec can be derived from usage of RSVP to signal for this QoS 768 Model, as defined in [RSVP-INTSERV] and [RFC2215]. 770 The QSpec for IntServ Controlled Load is composed of the subobjects 771 and , as well as . Which 772 sub-object is present in a particular QSpec depends on the message 773 type (RESERVE, QUERY etc) in which the QSpec travels. Details must 774 be provided in a corresponding QSM. Parameters in the QSpec are as 775 follows: 777 = 778 = 780 = 782 A.3 QSpec for IntServ Guaranteed Services 784 The QoS Model is defined in [RFC 2212]. The required parameters to 785 achieve guarantied service with RSVP are specified in [RFC 2210] and 786 [RFC 2215]. 788 The QSpec for guarantied services is the following: 790 = 792 = 794 This sub-object contains token bucket parameters defined in [RFC 795 2210]. Equivalent to TSpec defined in RSVP. 797 = 800 These parameters are defined in [RFC 2212] and [RFC 2215]. This sub- 801 object is equivalent to AdSpec of RSVP. 803 = 804 Requested Rate and Slack Term defined in [RFC 2212], equivalent to 805 RSpec of RSVP. 807 Note that the Guarantied Services QoS Model only works with receiver 808 initiated reservation signaling, because and are derived 809 from parameters contained in , and may be updated on 810 the return paths. 812 Appendix B: QoS Models, QoS Signaling Models and QSpecs 814 This section gives a description of QoS models, QSMs and QSpecs and 815 explains what is the relation between them. Once these descriptions 816 are contained in a stable form in the appropriate IDs this Appendix 817 will be removed. 819 QoS NSLP is a generic QoS Signaling Protocol that can signal for 820 many QoS Models. A QoS Model is a particular QoS provisioning method 821 or QoS architecture such a IntServ Controlled Load, Guaranteed 822 Service. DiffServ, or RMD for DiffServ. 824 The definition of the QoS Model is independent from the definition 825 of QoS NSLP. Existing QoS Models do not specify how to use QoS NSLP 826 to signal for them. Therefore, we need to define the QoS Signaling 827 Models (QSMs), specific to each QoS Model, which describes the QoS 828 Model specific signaling functions. QoS Signaling Model are defined 829 for "Resource Management in DiffServ" in [RMD-QSM] and for IntServ 830 Controlled Load in [INTSERV-QoS-SIG]. 832 A QSM should include the following information: 834 - Role of QNEs in this QoS Model: 835 E.g. location, frequency, statefulness... 837 - QSpec Definition: 838 A QSM should specify the QSpec, including generic and optional 839 parameters. Furthermore it needs to explain how generic parameters 840 not used in this QSM are mapped onto parameters defined therein. 842 - Message Format 843 Objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY 845 - State Management 846 It describes how QSpec info is treated and interpreted in the 847 Resource Management Function and QSM specific processing. E.g. 848 admission control, scheduling, policy control, QoS parameter 849 accumulation (e.g. delay)� 851 - Operation and Sequence of Events 852 Usage of QoS-NSLP messages to signal the QoS model. 854 Disclaimer of Validity 856 This document and the information contained herein are provided on 857 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 858 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 859 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 860 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 861 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 862 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 864 Full Copyright Statement 866 Copyright (C) The Internet Society (2004). This document is subject 867 to the rights, licenses and restrictions contained in BCP 78, and 868 except as set forth therein, the authors retain all their rights.