idnits 2.17.1 draft-ietf-nsis-qspec-01.txt: -(395): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 522. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 786), 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 are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 8) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 174 has weird spacing: '...taining param...' == 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 (October 2004) is 7126 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 380, but not defined == Missing Reference: 'RFC 2210' is mentioned on line 692, but not defined -- Looks like a reference, but probably isn't: '2212' on line 422 -- Looks like a reference, but probably isn't: '2215' on line 422 == Missing Reference: 'RFC 2212' is mentioned on line 711, but not defined == Missing Reference: 'RFC 2215' is mentioned on line 707, but not defined == Unused Reference: 'KEY' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'INTSERV' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'TRQ-QoS-SIG' is defined on line 556, 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-QSP' -- Possible downref: Non-RFC (?) normative reference: ref. 'TRQ-QoS-SIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' Summary: 12 errors (**), 0 flaws (~~), 14 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: April 2005 Ericsson 5 Cornelia Kappler 6 Siemens AG 8 October 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 The QoS NSLP protocol is used to signal QoS reservations and is 41 independent of a specific QoS model such as IntServ or DiffServ. 42 Rather, all information specific to QoS models is encapsulated in a 43 separate object, the QSpec. This draft defines a template for the 44 QSpec, which contains both the QoS description and control 45 information specific to a given QoS model. The QSpec format is 46 defined as are a number of generic and optional parameters. 47 Generic parameters provide a common language to be re-used in 48 several QoS models, which are derived initially from the IntServ 49 and DiffServ QoS models. Optional parameters aim to ensure the 50 extensibility of QoS NSLP to other QoS models. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . .4 57 3.1 Processing of QSpec. . . . . . . . . . . . . . . . . . . . . . 4 58 3.2 Generic Parameters. . . . . . . . . . . . . . . . . . . . . . .5 59 3.3 Extensibility. . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. QSpec Format Overview. . . . . . . . . . . . . . . . . . . . . .6 61 4.1 QSP Specific Control Information. . . . . . . . . . . . . . . .6 62 4.2 QoS Description. . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2.1 QoS Desired. . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2.2 QoS Available. . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.2.3 QoS Reserved. . . . . . . . . . . . . . . . . . . . . . . . .9 66 4.2.4 Minimum QoS. . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. Security Considerations. . . . . . . . . . . . . . . . . . . . .9 68 6. Open Issues. . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .10 70 8. Intellectual Property Considerations. . . . . . . . . . . . . .10 71 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . .11 72 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 11 73 Appendix A Example Qspecs. . . . . . . . . . . . . . . . . . . . .13 74 A.1 QSpec for Admission Control for DiffServ. . . . . . . . . . . 13 75 A.2 QSpec for IntServ Controlled Load Service. . . . . . . . . . .13 76 A.3 QSpec for IntServ Guaranteed Services. . . . . . . . . . . . .14 77 Appendix B QoS Models, QoS Signaling Policies and QSpecs. . . . . 14 78 Appendix C Mapping of QoS Desired, QoS Available, and QoS Reserved 79 of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ. . . . . . .15 80 Copyright Statement. . . . . . . . . . . . . . . . . . . . . . . .16 81 Disclaimer of Validity and Copyright Statement. . . . . . . . . . 16 83 1. Introduction 85 The QoS NSLP establishes and maintains state at nodes along the path 86 of a data flow for the purpose of providing forwarding resources 87 (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is 88 conceptually similar to RSVP [RSVP], and meets the requirements of 89 [NSIS-REQ]. 91 QoS NSLP can signal for different QoS Models, i.e. QoS provisioning 92 methods or QoS architectures. It should be able to support, for 93 example, IntServ and signaling for DiffServ admission control, and 94 satisfy the need of more complex control planes such as defined in 95 [Q.2630, Y.1541]. The use of QoS NSLP to signal for a specific QoS 96 Model is called a 'QoS Signaling Policy' (QSP). Examples of different 97 QSPs for NSIS are specified in [TRQ-QoS-SIG, INTSERV-QoS-SIG, RMD- 98 QoS-SIG]. For more information on QoS Models and QSPs see 99 Appendix B. 101 QSP-specific information is carried in the so-called QSpec object, 102 which travels in QoS-NSLP messages. The format of the QSpec object 103 is QSP specific. The QSpec is opaque to QoS NSLP. It contains two 104 types of information: QSP Control Information and a QoS Description. 106 The QSP control information contains information not related to the 107 actual resource management but rather to message processing. An 108 example of QSP control information is the scope of the QSpec. QSP 109 Control Information must not be confused with the Common Control 110 Information, which is a set of objects defined in QoS NSLP. Whereas 111 QSP Control Information is specific to the QSpec, Common Control 112 Information is specific to the QoS NSLP message. 114 The QoS Description is composed of objects corresponding to the 115 TSpec, RSpec and AdSpec objects specified in RSVP. This is, the 116 QSpec may contain a description of QoS desired and QoS reserved. It 117 can also collect information about available resources. Going beyond 118 RSVP functionality, the QoS Description also allows indicating a 119 range of acceptable QoS by defining an object denoting minimum QoS. 120 Usage of these objects is not bound to particular message types thus 121 allowing for flexibility. An object collecting information about 122 available resources may travel in any QoS NSLP message, for example 123 a QUERY message or a RESERVE message. 125 This draft provides a template for the QSpec, which is needed in 126 order to help defining individual QSPs and in order to promote 127 interoperability between QoS models. The applicability of the QSpec 128 is discussed in Section 3. The QSpec template is given in Section 4. 129 Section 5 gives security considerations. Appendix A proposes QSpecs 130 for the IntServ Controlled Load and Guaranteed Service QoS Models. 131 Appendix B explains in more detail the relation between QoS Models, 132 QSPs and QSpecs. It also explains the current understanding of the 133 content of a QSP. Appendix C explains how the objects defined for the 134 QSpec map onto the corresponding TSpec, AdSpec and RSpec of RSVP. 136 2. Terminology 138 Common NSLP Processing: Functions in a QNE that are related to NSLP 139 message processing (common for each QoS Model) 141 Generic Parameter: Parameter that MUST be understood by any QNE, and 142 SHOULD be used if applicable 144 Read-only Parameter: Parameter that is set by initiating or 145 responding QNE and is not changed during the processing of QSpec 146 along the path 148 Minimum QoS: Minimum QoS is a functionality that MAY be supported by 149 any QSP: Together with a description of desired QoS, it allows the 150 QNI to specify a QoS range, i.e. an upper and lower bound. If the 151 desired QoS is not available, QNFs are going to decrease the 152 reservation until the minimum QoS is hit. 154 Read-write Parameter: Parameter that can be changed during the 155 processing of QSpec by any QNE along the path 157 Optional Parameter: Parameter that SHOULD be used by QSPs if 158 applicable 159 QoS Description: Describes the actual QoS being reserved. May 160 contain the objects QoS Desired, QoS Available, QoS Reserved and 161 Minimum QoS. These objects are input or output parameters of the 162 Resource Management Function 164 QoS Available: Object containing parameters describing the 165 available resources. They are used to collect information along a 166 reservation path. 168 QoS Desired: Object containing parameters describing the desired 169 QoS and/or the traffic 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: Object containing parameters describing the reserved 175 resources and related QoS parameters (e.g. Slack Term) 177 QoS Signaling Policy (QSP): A signaling policy describing how to use 178 QoS NSLP to signal for a specific QoS Model 180 QSpec Control Information: Control information that is specific to a 181 QSpec, and processed in QSpec-specific NSLP Processing. 183 QSpec-specific NSLP Processing: Functions in a QNE that process QSP 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, for example, 190 scope of QSpec or token bucket. 192 QSpec 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. Applicability 201 3.1 Processing of QSpec 203 The QSpec is opaque to the QoS-NSLP processing. The QSpec control 204 information is interpreted and perhaps modified by the QSpec-specific 205 NSLP processing, and the QoS description is interpreted and may be 206 modified by the Resource Management Function (see Figure 1 and 207 description in [QoS-SIG]). 209 3.2 Generic Parameters 211 The QSpec template defines a format for the QSpec, as well as a 212 number of generic and optional QSpec parameters. Generic parameters 213 provide a common language for QSP developers to build their QSpecs 214 and are likely to be re-used in several QSPs. This eases comparing 215 different QSpecs and different QSPs - and possibly simplifies 216 mapping of one into another. Thus developers should avoid defining 217 proprietary parameters equivalent to the generic, standardized ones. 218 All parameters used in DiffServ and IntServ QSPs are generic 219 parameters. 221 A specific QSP may, however, only use a subset or perhaps none of 222 the generic QSpec parameters. For instance, it may only allow the 223 token bucket to be specified. Furthermore, a QSP may define 224 additional parameters. In any event, generic parameters SHOULD be 225 used by QSPs if applicable. 227 The Resource Management Function (RMF) in all QNEs must be able to 228 understand the generic parameters. This means a Resource Management 229 Function is not restricted in how the traffic conditioning of a 230 particular generic parameter is implemented. It MUST however be able 231 to provide a meaningful implementation of generic parameters. 232 Additionally, when QoS properties of a path are collected, a RMF 233 must be able to give a meaningful answer. For example, when a 234 RESERVE message carries a QSpec with a token bucket, the RMF must 235 be able to update the token bucket parameters according to what 236 it is able to provide, even if it does not implement a token 237 bucket. 239 A QSpec is specific to a QSP and is identified by a QSP ID carried 240 in QoS NSLP. However, as explained above, the generic parameters 241 contained in a QSpec are understood by any QNE, even if the 242 corresponding QSP is not known. Therefore a QNE SHOULD interpret the 243 generic parameters contained in a QSpec, even if it does not 244 understand the QSP. I.e. an unknown QSP should not lead to abortion 245 of the signaling message, or to not passing the QSpec to the RMF. 246 QoS NSLP provides the error code �Unknown QSP� to indicate only 247 generic parameters were interpreted. Hence, generic parameters 248 ease global intelligibility of QoS NSLP messages. 250 3.3 Extensibility 252 A specific QSP may need more parameters than the generic ones. The 253 QSpec Template allows additional types of parameters, namely 254 optional parameters. 256 Optional parameters are parameters that are likely to occur in many 257 QSPs, which however are necessary neither for the DiffServ nor the 258 IntServ QoS Model (because parameters needed for these QoS Models are 259 by definition generic parameters). Future versions of this draft will 260 define a number of optional parameters, e.g. for measuring delay. 262 Optional parameters SHOULD be used by QSPs if applicable to 263 facilitate interworking. However, QNEs outside the domain employing a 264 particular QSP cannot be expected to understand the optional 265 parameters. 267 4. QSpec Format Overview 269 QSpec = 271 As described above, the QSpec object contains the actual resource 272 description (QoS description) as well as QSpec control information. 273 Both QoS description and QSpec control information may contain 274 read-write and read-only objects. 276 Read-write objects can be changed by any QNE, including by QoS NSIS 277 functions along the signaling path, whereas read-only objects are 278 fixed by the initiating QNE and/or responding QNEs. An example of a 279 read-write object is the QoS Available, which is updated by 280 intermediate QNEs. An example of an read-only object is QoS Desired 281 as sent by theQNI. 283 4.1. QSP Specific Control Information 285 QSP specific control information is used for QSpec-specific control 286 information and for specific signaling functions not defined in QoS- 287 NSLP. It enables building a new signaling policy within a QoS-NSLP 288 signaling framework, see for example [RMD-QoS-SIG] and [RMD-QSP]. 290 Generic parameters: 292 - 294 read-write hop count field, limiting the scope of QSpec to a maximum 295 number of QoS-NSLP hops. must not be confused with the 296 scope of the QoS NSLP message carrying the QSpec. This scope would 297 be coded in the Common Control Information. 299 - = , | 302 Read-only parameter, indicating the desired start time and end time 303 of the service, i.e. when is the service available. The values for 304 and respectively 305 can be infinity, in which case the reservation can be ended by the 306 usual tearing RESERVE. The Service Schedule parameter has two-fold 307 use: 309 a. Reservation of resources for the immediate future when the full 310 flow ID is still being negotiated (e.g. port number may be negotiated 311 with SIP). In this case is set to zero. 313 b. Scheduling of reservations ahead of time to make sure resources 314 will be available, i.e. a Reserve / Commit functionality. An example 315 is reservation of resources for a video-conference. Also in this case 316 the full flow ID, e.g. port numbers, may not be known at the time of 317 reservation. 319 Hence, in both cases the QNI sends an incomplete RESERVE prompting 320 the Resource Management Function to set aside resources without 321 actually configuring the router(s). Router configuration is 322 triggered by a RESERVE containing the full flow ID. 324 It needs to be considered whether Service Schedule should be an 325 optional parameter because supporting it involves some overhead: the 326 RMF needs functionality to set aside resources in advance and 327 configure the router(s) later. Furthermore, for large advance 328 reservations, it may be necessary to "phase out" ongoing 329 reservations much earlier than the actual reservation in order to 330 make sure resources will be available. 332 Note that even reservations that are "scheduled" need to be 333 refreshed just as ongoing reservations. Refresh periods are specific 334 to a particular state in a particular QNE [QoS-SIG]. Hence it is 335 conceivable that QNEs decide locally to make the refresh period for 336 scheduled reservations considerably longer than that for ongoing 337 reservations. 339 4.2 QoS Description 341 The QoS Description is broken down into the following 342 objects: 344 = 345 347 Of these objects, QoS Desired and Minimum QoS are read-only, whereas 348 QoS Available and QoS Reserved are read-write. If it needs to be 349 Ensured that QoS Desired and Minimum QoS are indeed not changed 350 along the path, it is possible to apply selective protection of 351 these objects only. The verification is based on cryptographic 352 procedures. 354 On the QSpec template level, the only restriction on object usage is 355 that should always travel together with and/or . Otherwise there is no restriction 357 on how many of these objects a QSpec may carry, nor what type of 358 object is carried in what type of QoS NSLP message. For 359 example, in a receiver-initiated reservation scenario, the 360 initiating QNE may send a QUERY carrying a 361 object to probe the available resources on the path. The same QUERY 362 may carry a object. The responding QNE can re-use 363 the latter objects in the RESERVE message. The QoS NSLP and 364 particularly the QSPs prescribe how the objects in QSpecs are 365 interpreted and used, and therefore restrict this freedom. 367 The union of all the objects identified in this Section can 368 provide all functionality of the objects specified in RSVP IntServ. 369 QoS Desired may in fact just be a description of traffic to be 370 sent, but it may also include more parameters (e.g. delay) or 371 signal for more resources than those derived from an exact traffic 372 description (e.g. a token bucket with a higher peak rate). 373 Furthermore all objects can carry the same parameter types. Hence, 374 a QNI could send a RESERVE with QoS Desired contained a particular 375 Average bandwidth, and at the same time include a QoS Available 376 Object for querying availability of this same parameter. If QoS 377 Desired cannot be reserved, the QNR can use the information 378 Collected in QoS Available along the path to signal back to the 379 QNI a more promising value of QoS Desired. The details of such 380 Message exchanges are fixed in [QoS-Sig]. 382 4.2.1 384 = 386 These parameters describe the resources the QNI desires to reserve 387 and hence this is an read-only object. QoS Desired may be an accurate 388 description of the traffic the QNI is going to inject into the 389 network. It may however also ask for more (or less) resources. 391 Note that QoS Desired may also carry other parameters like desired 392 delay or loss parameters, however these are optional parameters and 393 not specified in this document. 395 = the share of the link�s bandwidth the flow is entitled to (see 396 RFC 2212) 398 =

399 as defined in [RFC 2210] 401 = 403 An application may like to reserve resources for packets with a 404 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 405 [DIFFSERV, DCLASS], or DiffServ-enabled traffic engineering (DS-TE) 406 class type [DS-TE]. 408 = 410 Reservation priority is an essential way to differentiate flows for 411 emergency services, ETS, E911, etc., and assign them a higher 412 priority than normal priority flows. Appropriate security measures 413 need to be taken to prevent abuse of this parameter. These are 414 read-only parameters. 416 4.2.2 418 = 420 These parameters describe the resources currently available on the 421 path and hence the object is read-write. They are defined in 422 [RFC 2210, 2212, 2215]. and are the 423 number of QSP aware and non QSP aware nodes along the path. Each QNE 424 must inspect this object. If resources available to this QNE are 425 less than what says currently, the QNE must adapt it 426 accordingly. Hence when the message arrives at the recipient of the 427 message, reflects the bottleneck of the resources 428 currently available on a path. It can be used in a QUERY message, 429 for example, to collect the available resources along a data path. 431 4.2.3 433 = 435 These parameters describe the QoS reserved by the QNEs down the 436 path. , , and are defined 437 above. is defined in [RFC 2212]. This is a read-write object. 439 4.2.4 441 = , , 442 , and are defined above 444 doesn't have an equivalent in RSVP. It allows the QNI 445 to define a range of acceptable QoS levels by including both the 446 desired QoS value and the minimum acceptable QoS in the same message. 447 It is an read-only object. The desired QoS is included with a and/or a object seeded to the desired QoS 449 value. The minimum acceptable QoS value is coded in the 450 object. As the message travels towards the QNR, 451 is updated by QNEs on the path. If its value drops below the value 452 of the reservation failed and can be aborted. When 453 this method is employed the QNR SHOULD signal back to 454 the QNI the value attained in the end, because the 455 reservation may need to be adapted accordingly. 457 5. Security Considerations 459 The Service Schedule parameter raises possibilities for Denial of 460 Service Attacks because an attacker could signal a QNE to set aside 461 resources without ever completing the reservation. This is prevented 462 by charging incomplete / pending reservations. 464 The priority parameter raises possibilities for Theft of Service 465 Attacks because users could claim an emergency priority for their 466 flows without real need, thereby effectively preventing serious 467 emergency calls to get through. Several options exist for countering 468 such attacks, for example 470 - only some user groups (e.g. the police) are authorized to set the 471 emergency priority bit 472 - any user is authorized to employ the emergency priority bit for 473 particular destination addresses (e.g. police) 475 6. Open Issues 477 a. Clarify the relationship of Common NSLP Processing, QSP-specific 478 NSLP Processing and the Resource Management Function. 480 b. Specify optional parameters proposed to support other QSPs. 482 c. Should Service Schedule be an optional parameter because of the 483 overhead it may introduce? 485 d. Are proprietary QSpec parameters required? 487 e. Is a flag needed to indicate when a QNE cannot process a given 488 generic parameter? 490 f. Should PHB explicitly signaled in PHB-DCLASS? 492 g. The bit-level format for the QoS objects and QoS parameters needs 493 to be defined 495 7. Acknowledgements 497 The authors would like to thank Robert Hancock, Sven van den 498 Bosch, and Hannes Tschofenig for their helpful suggestions. 500 8. Intellectual Property Considerations 502 The IETF takes no position regarding the validity or scope of any 503 Intellectual Property Rights or other rights that might be claimed 504 to pertain to the implementation or use of the technology described 505 in this document or the extent to which any license under such 506 rights might or might not be available; nor does it represent that 507 it has made any independent effort to identify any such rights. 508 Information on the procedures with respect to rights in RFC 509 documents can be found in BCP 78 and BCP 79. 511 Copies of IPR disclosures made to the IETF Secretariat and any 512 assurances of licenses to be made available, or the result of an 513 attempt made to obtain a general license or permission for the use 514 of such proprietary rights by implementers or users of this 515 specification can be obtained from the IETF on-line IPR repository 516 at http://www.ietf.org/ipr. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights that may cover technology that may be required to implement 521 this standard. Please address the information to the IETF at ietf- 522 ipr@ietf.org. 524 9. References 526 [DIFFSERV] S. Blake et. al., "An Architecture for Differentiated 527 Services", RFC 2475, December 1998. 528 [DS-TE] F. Le Faucheur et. al., Requirements for Support of 529 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 530 July 2003 531 [KEY] S. Bradner, "Key words for use in RFCs to Indicate Requirement 532 Levels", BCP 14, RFC 2119, March 1997 533 [INTSERV] B. Braden et. al., "Integrated Services in the Internet 534 Architecture: an Overview," RFC 1633, June 1994. 535 [INTSERV-QoS-SIG] C. Kappler, "A QoS Model for Signaling IntServ 536 Controlled-Load Service with NSIS," work in progress. 537 [NSIS-REQ] M. Brunner et. al., "Requirements for QoS Signaling 538 Protocols", work in progress. 539 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 540 Network Element Service", RFC 2211, Sept. 1997. 541 [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality 542 of Service," September 1997. 543 [RFC2215] S. Shenker and J. Wroclawski, "General Characterization 544 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 545 1997. 546 [RMD-QoS-SIG] A. Bader et. al., "RMD (Resource Management in 547 Diffserv) QoS-NSLP model", work in progress. 548 [RMD-QSP] A. Bader, L. Westberg, G. Karagiannis, C. Kappler and T. 549 Phelan, " RMD-QSP: An NSIS QoS Signaling Policy model for Networks 550 Using Resource Management in Diffserv (RMD)" 551 , work in progress. 552 [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) -- 553 Version 1 Functional Specification," RFC 2205, September 1997. 554 [RSVP-INTSERV] J. Wroclawski, "The Use of RSVP with IETF Integrated 555 Services", RFC 2210, September 1997. 556 [TRQ-QoS-SIG] J. Ash et. al., "NSIS Network Service Layer Protocol 557 QoS Signaling Proof-of-Concept," work in progress. 558 [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service 559 Signaling," work in progress. 560 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 561 Objectives for IP-Based Services," May 2002. 562 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 563 Protocol - Capability Set 3" Sep. 2003 564 [DCLASS] Bernet Y., Format of the RSVP DCLASS Object, RFC 2996, 565 November 2000 567 10. Authors' Addresses 569 Jerry Ash 570 AT&T 571 Room MT D5-2A01 572 200 Laurel Avenue 573 Middletown, NJ 07748, USA 574 Phone: +1-(732)-420-4578 575 Fax: +1-(732)-368-8659 576 Email: gash@att.com 577 Attila Bader 578 Traffic Lab 579 Ericsson Research 580 Ericsson Hungary Ltd. 581 Laborc u. 1 H-1037 582 Budapest Hungary 583 EMail: Attila.Bader@ericsson.com 585 Chuck Dvorak 586 AT&T 587 Room 2A37 588 180 Park Avenue, Building 2 589 Florham Park, NJ 07932 590 Phone: + 1 973-236-6700 591 Fax:+1 973-236-7453 592 E-mail: cdvorak@att.com 594 Yacine El Mghazli 595 Alcatel 596 Route de Nozay 597 91460 Marcoussis cedex 598 FRANCE 599 Phone: +33 1 69 63 41 87 600 Email: yacine.el_mghazli@alcatel.fr 602 Cornelia Kappler 603 Siemens AG 604 Siemensdamm 62 605 Berlin 13627 606 Germany 607 Email: cornelia.kappler@siemens.com 609 Georgios Karagiannis 610 University of Twente 611 P.O. BOX 217 612 7500 AE Enschede 613 The Netherlands 614 EMail: g.karagiannis@ewi.utwente.nl 616 Andrew McDonald 617 Siemens/Roke Manor Research 618 Roke Manor Research Ltd. 619 Romsey, Hants SO51 0ZN, UK 620 EMail: andrew.mcdonald@roke.co.uk 622 Al Morton 623 AT&T 624 Room D3-3C06 625 200 S. Laurel Avenue 626 Middletown, NJ 07748 627 Phone: + 1 732 420-1571 628 Fax: +.1 732 368-1192 629 E-mail: acmorton@att.com 630 Percy Tarapore 631 AT&T 632 Room D1-3D33 633 200 S. Laurel Avenue 634 Middletown, NJ 07748 635 Phone: + 1 732 420-4172 636 E-mail: tarapore@.att.com 638 Lars Westberg 639 Ericsson Research 640 Torshamnsgatan 23 641 SE-164 80 Stockholm, Sweden 642 EMail: Lars.Westberg@ericsson.com 644 Appendix A: Example QSpecs 646 Note the mere definition of QSpecs is not sufficient for determining 647 how to signal for DiffServ and IntServ respectively. Rather, the 648 full QSP needs to be defined. 650 A.1 QSpec for Admission Control for DiffServ 652 QSpec for Diffserv QSP in general may be provided in future versions 653 of this draft. A QSpec for a DiffServ QSP, RMD is partically 654 included in [RMD-QSP]. 656 A.2 QSpec for IntServ Controlled Load Service 658 The QoS Model for IntServ Controlled Load is defined in [RFC2211]. 659 The QSpec can be derived from usage of RSVP to signal for this QoS 660 Model, as defined in [RSVP-INTSERV] and [RFC2215]. 662 The QSpec for IntServ Controlled Load is composed of the objects 663 and , as well as . Which 664 object is present in a particular QSpec depends on the message 665 type (RESERVE, QUERY etc) in which the QSpec travels. Details must 666 be provided in a corresponding QSP. Parameters in the QSpec are as 667 follows: 669 = 671 = 672 = 674 = 676 An IntServ over Diffserv QSpec is 678 = 679 = 680 = 681 682 = 683 Or a simple QSpec for Diffserv requesting bandwidths for different 684 PHBs is 686 = 687 = 689 A.3 QSpec for IntServ Guaranteed Services 691 The QoS Model is defined in [RFC 2212]. The required parameters to 692 achieve guarantied service with RSVP are specified in [RFC 2210] and 693 [RFC 2215]. 695 The QSpec for guarantied services is the following: 697 = 699 = 701 This object contains token bucket parameters defined in [RFC 702 2210]. Equivalent to TSpec defined in RSVP. 704 = 707 These parameters are defined in [RFC 2212] and [RFC 2215]. This 708 object is equivalent to AdSpec of RSVP. 710 = 711 Requested Rate and Slack Term defined in [RFC 2212], equivalent to 712 RSpec of RSVP. 714 Note that the Guarantied Services QoS Model only works with receiver 715 initiated reservation signaling, because and are derived 716 from parameters contained in , and may be updated on 717 the return paths. 719 Appendix B: QoS Models, QoS Signaling Policies and QSpecs 721 This section gives a description of QoS Models, QSPs and QSpecs and 722 explains what is the relation between them. Once these descriptions 723 are contained in a stable form in the appropriate IDs this Appendix 724 will be removed. 726 QoS NSLP is a generic QoS Signaling Protocol that can signal for 727 many QoS Models. A QoS Model is a particular QoS provisioning method 728 or QoS architecture such a IntServ Controlled Load, Guaranteed 729 Service. DiffServ, or RMD for DiffServ. 731 The definition of the QoS Model is independent from the definition 732 of QoS NSLP. Existing QoS Models do not specify how to use QoS NSLP 733 to signal for them. Therefore, we need to define the QoS Signaling 734 Policy (QSP), specific to each QoS Model, which describes the QoS 735 Model specific signaling functions. QoS Signaling Policy are defined 736 for "Resource Management in DiffServ" in [RMD-QSP] and for IntServ 737 Controlled Load in [INTSERV-QoS-SIG]. 739 A QSP should include the following information: 741 - Role of QNEs in this QoS Model: 742 E.g. location, frequency, statefulness... 743 - QSpec Definition: 744 A QSP should specify the QSpec, including generic and optional 745 parameters. Furthermore it needs to explain how generic parameters 746 not used in this QSP are mapped onto parameters defined therein. 747 - Message Format 748 Objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY 749 - State Management 750 It describes how QSpec info is treated and interpreted in the 751 Resource Management Function and QSP specific processing. E.g. 752 admission control, scheduling, policy control, QoS parameter 753 accumulation (e.g. delay)? 754 - Operation and Sequence of Events 755 Usage of QoS-NSLP messages to signal the QoS Model. 757 Appendix C: Mapping of QoS Desired, QoS Available and QoS Reserved of 758 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 760 The union of QoS Desired, QoS Available and QoS Reserved can provide 761 all functionality of the objects specified in RSVP IntServ, however 762 it is difficult to provide an exact mapping. 764 In RSVP, the Sender TSpec specifies the traffic an application is 765 going to send (e.g. token bucket). The AdSpec can collect path 766 characteristics (e.g. delay). Both are issued by the sender. The 767 receiver sends the FlowSpec which includes a Receiver TSpec 768 describing the resources reserved using the same parameters as the 769 Sender TSpec, as well as a RSpec which provides additional IntServ 770 QoS Model specific parameters, e.g. Rate and Slack. 772 The RSVP TSpec/AdSpec/RSpec seem quite tailored to 773 receiver-initiated signaling employed by RSVP, and the IntServ 774 QoS Model. E.g. to the knowledge of the authors it is not possible 775 for the sender to specify a desired maximum delay except 776 implicitly and mutably by seeding the AdSpec accordingly. Likewise, 777 the RSpec is only meaningfully sent in the receiver-issued RSVP 778 RESERVE message. For this reason our debate at this point lead us 779 to a slightly different mapping of necessary functionality to 780 objects, which should result in more flexible signaling models. 782 Copyright Statement 784 Copyright (C) The Internet Society (2004). This document is subject 785 to the rights, licenses and restrictions contained in BCP 78, and 786 except as set forth therein, the authors retain all their rights. 788 Disclaimer of Validity 790 This document and the information contained herein are provided on 791 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 792 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 793 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 794 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 795 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.