idnits 2.17.1 draft-ietf-nsis-qspec-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 983. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1321), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 5) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (December 2004) is 7072 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 381, but not defined == Missing Reference: 'RFC 2212' is mentioned on line 1181, but not defined == Missing Reference: 'RFC 2210' is mentioned on line 1171, but not defined -- Looks like a reference, but probably isn't: '2212' on line 901 -- Looks like a reference, but probably isn't: '2215' on line 901 == Missing Reference: 'R' is mentioned on line 609, but not defined == Missing Reference: 'S' is mentioned on line 611, but not defined == Missing Reference: 'RFC 2215' is mentioned on line 1177, but not defined == Missing Reference: 'M' is mentioned on line 636, but not defined == Missing Reference: 'RFC 3181' is mentioned on line 773, but not defined == Missing Reference: 'Ctot' is mentioned on line 906, but not defined == Missing Reference: 'Dtot' is mentioned on line 908, but not defined == Missing Reference: 'Csum' is mentioned on line 910, but not defined == Missing Reference: 'Dsum' is mentioned on line 912, but not defined == Missing Reference: 'RFC2434' is mentioned on line 944, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'KEY' is defined on line 989, but no explicit reference was found in the text == Unused Reference: 'INTSERV' is defined on line 1014, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFFSERV') -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' Summary: 10 errors (**), 0 flaws (~~), 19 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jerry Ash 3 Internet Draft AT&T 4 Attila Bader 5 Expiration Date: June 2005 Ericsson 6 Cornelia Kappler 7 Siemens AG 9 December 2004 11 QoS-NSLP QSPEC Template 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of RFC 3668. 20 Internet-Drafts are Working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any 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/1id-abstracts.html. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 The QoS NSLP protocol is used to signal QoS reservations and is 43 independent of a specific QoS model such as IntServ or DiffServ. 44 Rather, all information specific to QoS models is encapsulated in a 45 separate object, the QSPEC. This draft defines a template for the 46 QSPEC, which contains both the QoS description and control 47 information specific to a given QoS model. The QSPEC format is 48 defined as are a number of generic and optional parameters. 49 Generic parameters provide a common language to be re-used in 50 several QoS models, which are derived initially from the IntServ 51 and DiffServ QoS models. Optional parameters aim to ensure the 52 extensibility of QoS NSLP to other QoS models. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1 Processing of QSPEC . . . . . . . . . . . . . . . . . . . . . 5 60 3.2 Generic Parameters . . . . . . . . . . . . . . . . . . . . . 6 61 3.3 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . . 6 63 4.1 QSP Specific Control Information . . . . . . . . . . . . . . 7 64 4.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2.1 QoS Desired . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2.2 QoS Available . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.2.3 QoS Reserved . . . . . . . . . . . . . . . . . . . . . . 10 68 4.2.4 Minimum QoS . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. QSPEC Functional Specification . . . . . . . . . . . . . . . 11 70 5.1 Parameter . . . . . . . . . . . . . . . . . . . 11 71 5.2 Parameter . . . . . . . . . . . . . . . 11 72 5.3 & Parameters . . . . . . . . . . . 11 73 5.4 & Parameters . . . . . . . . . . . . . . . . . . . 12 74 5.5 Parameters . . . . . . . . . . . . . . . . . 12 75 5.6 Parameters . . . . . . . . . . . . . . . . . . 12 76 5.6.1 Parameter . . . . . . . . . . . . . . . . . . 12 77 5.6.2 Parameter . . . . . . . . . . . . . . 14 78 5.6.3 Parameter . . . . . . . . . . . . . . . 15 79 5.7 Parameters . . . . . . . . . . . . . . . . . . . 15 80 5.7.1 & Parameters . 15 81 5.7.2 Parameter . . . . . . . . . . . . 15 82 5.8 Parameters . . . . . . . . . . . . . . . . 16 83 5.8.1 Parameters . . . . . . . . . . . . 16 84 5.8.2 Parameter . . . . . . . . . . . . . . . . . 17 85 5.8.3 Parameters . . . . . . . . . 17 86 6. Security Considerations . . . . . . . . . . . . . . . . . . 18 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 89 9. Intellectual Property Considerations . . . . . . . . . . . . 18 90 10. Normative References . . . . . . . . . . . . . . . . . . . 19 91 11. Informative References . . . . . . . . . . . . . . . . . . 19 92 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 20 93 Appendix A Example Qspecs . . . . . . . . . . . . . . . . . . . 21 94 A.1 QSPEC for Admission Control for DiffServ . . . . . . . . . 21 95 A.2 QSPEC for IntServ Controlled Load Service . . . . . . . . . 21 96 A.3 QSPEC for IntServ Guaranteed Services . . . . . . . . . . . 22 97 Appendix B Example of NSLP QSPEC Operation . . . . . . . . . . 22 98 Appendix C QoS Models, QoS Signaling Policies and QSPECs . . . 24 99 Appendix D Mapping of QoS Desired, QoS Available, and QoS Reserved 100 of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ . . . . . 24 101 Full Copyright Notice . . . . . . . . . . . . . . . . . . . . . 25 102 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 25 104 1. Introduction 106 The QoS NSLP establishes and maintains state at nodes along the path 107 of a data flow for the purpose of providing forwarding resources 108 (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is 109 conceptually similar to RSVP [RSVP], and meets the requirements of 110 [NSIS-REQ]. 112 QoS NSLP can signal for different QoS Models, i.e. QoS provisioning 113 methods or QoS architectures. It should be able to support, for 114 example, IntServ and signaling for DiffServ admission control, and 115 satisfy the need of more complex control planes such as defined in 116 [Q.2630, Y.1541]. The use of QoS NSLP to signal for a specific QoS 117 Model is called a 'QoS Signaling Policy' (QSP). Examples of different 118 QSPs for NSIS are specified in [Y.1541-QSP, INTSERV-QSP, RMD-QSP]. 119 For more information on QoS Models and QSPs see Appendix B. 121 QSP-specific information is carried in the so-called QSPEC object, 122 which travels in QoS-NSLP messages. The format of the QSPEC object 123 is QSP specific. The QSPEC is opaque to QoS NSLP. It contains two 124 types of information: QSP Control Information and a QoS Description. 126 The QSP control information contains information not related to the 127 actual resource management but rather to message processing. An 128 example of QSP control information is the scope of the QSPEC. QSP 129 Control Information must not be confused with the Common Control 130 Information, which is a set of objects defined in QoS NSLP. Whereas 131 QSP Control Information is specific to the QSPEC, Common Control 132 Information is specific to the QoS NSLP message. 134 The QoS Description is composed of objects corresponding to the 135 TSpec, RSpec and AdSpec objects specified in RSVP. This is, the QSPEC 136 may contain a description of QoS desired and QoS reserved. It can 137 also collect information about available resources. Going beyond RSVP 139 functionality, the QoS Description also allows indicating a range of 140 acceptable QoS by defining an object denoting minimum QoS. Usage 141 of these objects is not bound to particular message types thus 142 allowing for flexibility. An object collecting information about 143 available resources may travel in any QoS NSLP message, for example 144 a QUERY message or a RESERVE message. 146 This draft provides a template for the QSPEC, which is needed in 147 order to help defining individual QSPs and in order to promote 148 interoperability between QoS models. 150 2. Terminology 152 Common NSLP Processing: Functions in a QNE that are related to NSLP 153 message processing (common for each QoS Model) 155 Generic-Mandatory Parameter: Parameter for which QNEs MUST provide 156 meaningful interpretations. 158 Generic-Optional Parameter: QSPEC parameter for which QNEs SHOULD 159 provide meaningful interpretations when applicable to the underlying 160 technology. 162 Minimum QoS: Minimum QoS is a functionality that MAY be supported by 163 any QSP: Together with a description of desired QoS, it allows the 164 QNI to specify a QoS range, i.e. an upper and lower bound. If the 165 desired QoS is not available, QNFs are going to decrease the 166 reservation until the minimum QoS is hit. 168 QoS Description: Describes the actual QoS being reserved. May 169 contain the objects QoS Desired, QoS Available, QoS Reserved and 170 Minimum QoS. These objects are input or output parameters of the 171 Resource Management Function 173 QoS Available: Object containing parameters describing the 174 available resources. They are used to collect information along a 175 reservation path. 177 QoS Desired: Object containing parameters describing the desired 178 QoS and/or the traffic for which the sender request reservation. 180 QoS Model: A methodology to achieve QoS for a traffic flow, e.g. 181 IntServ Controlled Load. 183 QoS Reserved: Object containing parameters describing the reserved 184 resources and related QoS parameters (e.g. Slack Term) 186 QoS Signaling Policy (QSP): A signaling policy describing how to use 187 QoS NSLP to signal for a specific QoS Model 189 QSPEC Control Information: Control information that is specific to a 190 QSPEC, and processed in QSPEC-specific NSLP Processing. 192 QSPEC-specific NSLP Processing: Functions in a QNE that process QSP 193 Control Information and are specific to each QoS Model. 195 QSPEC: QSPEC is the object of QoS-NSLP containing all QoS Model 196 specific information. 198 QSPEC parameter: any parameter appearing in a QSPEC, for example, 199 scope of QSPEC or token bucket. 201 QSPEC object: Main building blocks of QoS Description containing 202 a parameter set that is input or output of a Resource Management 203 Function operation. 205 QSP-Specific Parameter: QSPEC parameter defined for a specific QSP 206 and for which QNEs SHOULD provide meaningful interpretations when 207 applicable to the underlying technology. 209 Resource Management Function: Functions that are related to resource 210 management, specific to a QoS Model. It processes QoS Description. 212 Read-only Parameter: Parameter that is set by initiating or 213 responding QNE and is not changed during the processing of the QSPEC 214 along the path 216 Read-write Parameter: Parameter that can be changed during the 217 processing of the QSPEC by any QNE along the path 219 3. Applicability 221 3.1 Processing of QSPEC 223 The QSPEC is opaque to the QoS-NSLP processing. The QSPEC control 224 information is interpreted and perhaps modified by the QSPEC-specific 226 NSLP processing, and the QoS description is interpreted and may be 227 modified by the Resource Management Function (see Figure 1 and 228 description in [QoS-SIG]). 230 A domain that wishes to support QoS NSLP signaling decides on a 231 number of QoS Signaling Policies (QSPs) that will be supported by its 232 nodes. A QSP is a way of using QoS NSLP to achieve QoS reservations 233 over the domain. Examples of QSPs are IntServ, DiffServ, RMD, UMTS, 234 etc. 236 The definition of a QSP includes the specification of how the 237 Requested QoS resources will be described in the network and how they 239 will be managed by the Resource Management Function (RMF). For this 240 purpose, the QSP specifies a set of QoS specification (QSPEC) 241 parameters that describe the QoS traffic and a QoS resource control. 242 QSPEC parameters are conceptually organized in three levels: 243 generic-mandatory parameters, generic-optional parameters, and 244 QSP-specific parameters. These parameters form a tree structure with 245 increasing specificity from the root to the leaves, and are carried 246 in the QSPEC object in a QoS NSLP message. 248 In order to provide end-to-end interoperability, generic QSPEC 249 parameters are defined in a QSPEC template discussed in this 250 document. Generic-mandatory parameters MUST be understood by all QoS 252 NSLP compliant nodes. Generic-optional parameters SHOULD be used if 253 they are appropriate for the QSP in use in a certain domain. 254 Specification of additional generic QSPEC parameters requires 255 standards action, as defined in this document. QSP-specific 256 parameters are defined in separate QSP (informational) documents. 258 A QoS NSLP message can contains a stack of 1+n QSPECs. The top of the 259 Stack is the Initiator QSPEC. This is an immutable QSPEC provided by 260 the QNI which travels end-to-end, and therefore the stack always has 261 at least depth 1. In addition, the stack may contain n local QSPECs, 262 where n is the level of nested QSP regions in a domain. A QNE only 263 considers the topmost QSPEC at each of its interfaces. 265 The Initiator QSPEC contains up to three parts: generic mandatory 266 parameters, generic optional parameters and QSP-specific parameters 267 for up to two QSPs. The second set of QSP-specific parameters can be 268 used, for example, in a remote access network. Local QSPECs have a 269 structure similar to the Initiator QSPEC, except they can only 270 contain QSP-specific parameters for a single QSP. They may be 271 pushed on the stack at the edge of a domain in order to describe the 272 requested resources in a domain-specific manner. Also, the local 273 QSPECs are popped from the stack at the edge of the domain. In most 274 cases, we expect the stack to be no deeper than 2. 276 3.2 Generic Parameters 278 The QSPEC template defines a format for the QSPEC, as well as a 279 number of generic-mandatory and generic-optional QSPEC parameters. 280 Generic parameters provide a common language for QSP developers to 281 build their QSPECs and are likely to be re-used in several QSPs. 282 All parameters used in DiffServ and IntServ QSPs are generic 283 parameters. A QSPEC is specific to a QSP and is identified by a QSP 284 ID carried in QoS NSLP. 286 As stated above, we define generic-mandatory parameters, 287 generic-optional parameters, and QSP-specific parameters. A QNI MUST 288 populate and a QNE resource management function (RMF)MUST provide a 289 meaningful interpretation of all generic-mandatory parameters for a 290 given QSP. A QNI SHOULD populate and a QNE RMF SHOULD provide a 291 meaningful interpretation of a generic-optional parameter if the 292 underlying technology supports it. A specific QSP may, however, only 294 use a subset or perhaps none of the generic-mandatory or 295 generic-optional QSPEC parameters. Furthermore, a QSP may define 296 additional parameters called QSP-specific parameters, which are 297 defined in separate Informational documents specific to a given QSP. 299 3.3 Extensibility 301 Additional generic-mandatory or generic-optional may need to be 302 defined in the future. This can be done by modification of this 303 document. Additional QSP-specific parameters are defined in separate 304 Informational documents specific to a given QSP. 306 4. QSPEC Format Overview 308 QSPEC = 310 As described above, the QSPEC object contains the actual resource 311 description (QoS description) as well as QSPEC control information. 312 Both QoS description and QSPEC control information may contain 313 read-write and read-only objects. 315 Read-write objects can be changed by any QNE, including by QoS NSIS 316 functions along the signaling path, whereas read-only objects are 317 fixed by the initiating QNE and/or responding QNEs. An example of a 318 read-write object is the QoS Available, which is updated by 319 intermediate QNEs. An example of a read-only object is QoS Desired 320 as sent by the QNI. 322 4.1. QSP Specific Control Information 324 QSP specific control information is used for QSPEC-specific control 325 information and for specific signaling functions not defined in QoS- 326 NSLP. It enables building a new signaling policy within a QoS-NSLP 327 signaling framework, see for example [RMD-QSP]. 329 Generic-Optional Parameter: 331 This read-write hop count field limits the maximum number of QoS-NSLP 332 hops. must not be confused with the scope of the QoS NSLP 333 message carrying the QSPEC. This scope would be coded in the Common 334 Control Information. 336 Generic-Optional Parameter: 338 This read-write parameter describes how the QNE will process excess 339 traffic, that is, out-of-profile traffic. Excess traffic may be 340 dropped, shaped and/or remarked. The excess treatment parameter is 341 initially set by the QNI and adjusted as needed by QNEs. 343 4.2 QoS Description 345 The QoS Description is broken down into the following objects: 347 = 348 350 Of these objects, QoS Desired and Minimum QoS are read-only, whereas 351 QoS Available and QoS Reserved are read-write. If it needs to be 352 ensured that QoS Desired and Minimum QoS are indeed not changed along 353 the path, it is possible to apply selective protection of these 354 objects only. The verification is based on cryptographic procedures. 356 On the QSPEC template level, the only restriction on object usage is 357 that should always travel together with 358 and/or . Otherwise there is no restriction on how many 359 of these objects a QSPEC may carry, nor what type of object is 360 carried in what type of QoS NSLP message. For example, in a 361 receiver-initiated reservation scenario, the initiating QNE may send 362 a QUERY carrying a object to probe the available 363 resources on the path. The same QUERY may carry a 364 object. The responding QNE can re-use the latter objects in the 365 RESERVE message. The QoS NSLP and particularly the QSPs prescribe 366 how the objects in QSPECs are interpreted and used, and therefore 367 restrict this freedom. 369 The union of all the objects identified in this Section can provide 370 all functionality of the objects specified in RSVP IntServ. QoS 371 Desired may in fact just be a description of traffic to be sent, but 372 it may also include more parameters (e.g. delay) or signal for more 373 resources than those derived from an exact traffic description (e.g. 374 a token bucket with a higher peak rate). Furthermore all objects can 375 carry the same parameter types. Hence, a QNI could send a RESERVE 376 with QoS Desired contained a particular Average bandwidth, and at the 377 same time include a QoS Available Object for querying availability of 378 this same parameter. If QoS Desired cannot be reserved, the QNR can 379 use the information Collected in QoS Available along the path to 380 signal back to the QNI a more promising value of QoS Desired. The 381 details of such Message exchanges are defined in [QoS-Sig]. 383 4.2.1 385 = 387 Generic-Mandatory Parameters: 389 Generic-Optional Parameters: 391 These parameters describe the resources the QNI desires to reserve 392 and hence this is a read-only object. QoS Desired may be an accurate 393 description of the traffic the QNI is going to inject into the 394 network. It may however also ask for more (or less) resources. 396 = link bandwidth flow is entitled to [RFC 2212] 398 =

[RFC 2210] 400 = 402 An application may like to reserve resources for packets with a 403 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 404 [DIFFSERV, DCLASS], or DiffServ-enabled MPLS traffic engineering 405 (DSTE) class type [DSTE]. 407 = 408 410 is an essential way to differentiate flows for 412 emergency services, ETS, E911, etc., and assign them a higher 413 admission priority than normal priority flows and best-effort 414 priority flows. is the priority of the new 415 flow compared with the defending priority of previously admitted 416 flows. Once a flow was admitted, the preemption priority becomes 417 irrelevant. is used to compare with the 418 preemption priority of new flows. For any specific flow, its 419 preemption priority must always be less than or equal to the 420 defending priority. 422 Appropriate security measures need to be taken to prevent abuse of 423 the parameters. These are read-only parameters. 425 4.2.2 427 = 430 Generic-Mandatory Parameters: 431 433 Generic-Optional Parameters: 434 436 These parameters describe the resources currently available on the 437 path and hence the object is read-write. They are defined in 438 [RFC 2210, 2212, 2215]. 440 is a flag bit telling the QNR (or QNI in a RESPONSE 441 message) whether or not a completely reservation-capable path exists 442 between the QNI and QNR. If the QNR finds this bit set, at least one 443 QNE along the data transmission path between the QNI and QNR can not 444 provide QoS control services at all. If this bit is set, the values 445 of all other parameters in the are unreliable. 447 indicates the number of hops in the NSLP aware network 448 which support a given QSP. The QNE MUST support and characterize the 450 service in conformance with the relevant QSP specification, and if it 452 does not it must correctly set the flag parameter. The 453 composition rule for this parameter is to increment the counter by 454 one at each QSP-aware hop. This quantity, when composed from the QNI 456 to QNR informs the QNR (or QNI in a RESPONSE message) of the number 457 of QSP-aware QNEs traversed along the path. 459 The parameter provides information about the 460 bandwidth available along the path followed by a data flow. The 461 local parameter is an estimate of the bandwidth the QNE has available 462 for packets following the path. Computation of the value of this 463 parameter should take into account all information available to the 464 QNE about the path, taking into consideration administrative and 465 policy controls on bandwidth, as well as physical resources. The 466 composition rule for this parameter is the MIN function. The composed 468 value is the minimum of the QNE's value and the previously composed 469 value. This quantity, when composed end-to-end, informs the QNR (or 470 QNI in a RESPONSE message) of the minimal bandwidth link along the 471 path from QNI to QNR. 473 The parameter accumulates the latency of the packet 474 forwarding process associated with each QNE, where the latency is 475 defined to be the smallest possible packet delay added by each QNE. 476 This delay results from speed-of-light propagation delay, from packet 477 processing limitations, or both. It does not include any variable 478 queuing delay which may be present. Each QNE MUST add the 479 propagation delay of its outgoing link, which includes the QNR adding 480 the associated delay for the egress link. Furthermore, the QNI MUST 481 add the propagation delay of the ingress link. The composition rule 482 for the parameter is summation with a clamp of 483 (2**32 - 1) on the maximum value. This quantity, when composed 484 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 485 minimal packet delay along the path from QNI to QNR. The purpose of 486 this parameter is to provide a minimum path latency for use with 487 services which provide estimates or bounds on additional path delay 488 [RFC 2212]. Together with the queuing delay bound, this parameter 489 gives the application knowledge of both the minimum and maximum 490 packet delivery delay. Knowing both the minimum and maximum 491 latency experienced by data packets allows the receiving application 492 to know the bound on delay variation and de-jitter buffer 493 requirements. 495 Error terms C and D represent how the element's implementation of the 496 guaranteed service deviates from the fluid model. These two 497 parameters have an additive composition rule. The error term C is 498 the rate-dependent error term. It represents the delay a datagram in 499 the flow might experience due to the rate parameters of the flow. 500 The error term D is the rate-independent, per-element error term and 501 represents the worst case non-rate-based transit time variation 502 through the service element. If the composition function is applied 503 along the entire path to compute the end-to-end sums of C and D (Ctot 504 and Dtot) and the resulting values are then provided to the QNR (or 505 QNI in a RESPONSE message). Csum and Dsum are the sums of the 506 parameters C and D between the last reshaping point and the current 507 reshaping point. 509 Each QNE must inspect this object. If resources available to this QNE 510 are less than what says currently, the QNE must adapt 511 it accordingly. Hence when the message arrives at the recipient of 512 the message, reflects the bottleneck of the resources 513 currently available on a path. It can be used in a QUERY message, 514 for example, to collect the available resources along a data path. 516 4.2.3 518 = 520 These parameters describe the QoS reserved by the QNEs down the 521 path. , , and are defined 522 above. 524 Generic-Optional Parameter: = slack term: difference between 525 desired delay and delay obtained by using reservation level R (used 526 to reduce resource reservation for flow) [RFC 2212]. This is a 527 read-write parameter. 529 4.2.4 531 = 533 does not have an equivalent in RSVP. It allows the QNI 534 to define a range of acceptable QoS levels by including both the 535 desired QoS value and the minimum acceptable QoS in the same message. 536 It is an read-only object. The desired QoS is included with a and/or a object seeded to the desired QoS 538 value. The minimum acceptable QoS value is coded in the 540 object. As the message travels towards the QNR, 541 is updated by QNEs on the path. If its value drops below the value 542 of the reservation failed and can be aborted. When 543 this method is employed the QNR SHOULD signal back to the QNI the 544 value attained in the end, because the reservation 545 may need to be adapted accordingly. 547 5. QSPEC Functional Specification 549 This Section defines the encodings of the QSPEC parameters and 550 control information defined in Section 4. 552 5.1 Parameter 554 0 1 2 3 4 5 6 7 555 +-+-+-+-+-+-+-+-+ 556 | Hop Count | 557 +-+-+-+-+-+-+-+-+ 559 Hop Count: 8 bits 560 Indicates the maximum number of NSLP hops between the QNI and 561 QNR. Values of the composed parameter will range from 1 to 255, 562 limited by the bound on IP hop count. 564 5.2 Parameter 566 0 1 2 3 4 5 6 7 567 +-+-+-+-+-+-+-+-+ 568 | Excess | 569 | Treatment | 570 +-+-+-+-+-+-+-+-+ 572 Excess Treatment: 8 bits 573 Indicates how the QNE should process out-of-profile traffic. 574 Allowed values are as follows: 575 0: drop 576 1: shape 577 2: remark 578 The excess treatment parameter is initially set by the QNI and 579 adjusted as needed by QNEs. 581 5.3 & Parameters [RFC 2210, 2215] 583 0 1 584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | NON QSP Hop | QSP Hops | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 NON QSP Hop: 8 bits 590 This field is set to 1 if a non QSP-aware QNE is encountered on 591 the path from the QNI to the QNR. 593 QSP Hops: 8 bits 594 Indicates the number of QSP hops between the QNI and QNR. Values 596 of the composed parameter will range from 1 to 255, limited by 597 the bound on IP hop count. 599 5.4 & Parameters [RFC 2212] 601 The rate R MUST be nonnegative and is measured in bytes per second 602 and has the same range and suggested representation as the bucket and 604 peak rates of the . The rate term R can be represented 605 using single-precision IEEE floating point. Slack term S MUST be 606 hnonnegative and is measured in microseconds. 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Data Rate [R] (32-bit IEEE floating point number) | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Slack Term [S] (32-bit integer) | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 The Slack term, S, can be represented as a 32-bit integer. Its value 615 can range from 0 to (2**32)-1 microseconds. 617 5.5 Parameters [RFC 2215] 619 The parameters are represented by three floating point 620 numbers in single-precision IEEE floating point format followed by 621 two 32-bit integers in network byte order. The first floating point 622 value is the rate (r), the second floating point value is the bucket 623 size (b), the third floating point is the peak rate (p), the first 624 integer is the minimum policed unit (m), and the second integer is 625 the maximum datagram size (M). 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Token Bucket Size [b] (32-bit IEEE floating point number) | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Peak Data Rate [p] (32-bit IEEE floating point number) | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Minimum Policed Unit [m] (32-bit integer) | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Maximum Packet Size [M] (32-bit integer) | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 When r, b, p, and R terms are represented as IEEE floating point 640 values, the sign bit MUST be zero (all values MUST be non-negative). 641 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 642 than 162 (i.e., positive 35) are discouraged, except for specifying a 643 peak rate of infinity. Infinity is represented with an exponent of 644 all ones (255) and a sign bit and mantissa of all zeroes. 646 5.6 Parameters 648 5.6.1 Parameter [DIFFSERV-CLASS] 650 Encoding of the DiffServ per-hop-behavior (PHB) class if as follows: 652 0 1 2 3 4 5 6 7 653 +-+-+-+-+-+-+-+-+ 654 | PHB Class | 655 +-+-+-+-+-+-+-+-+ 657 PHB Class: 8 bits 658 Indicates the PHB class. Values currently allowed are 0, 1, 2, 659 3, ..., 20. 661 Encoding of the PHB Class parameter is taken from [DIFFSERV-CLASS]: 663 ------------------------------------------------------------------ 664 | Service |PHB Class| DSCP | Application | 665 | Class Name | (Name) | Value | Examples | 666 |===============+=========+=============+==========================| 667 |Administrative |0 (CS7) | 111000 | Heartbeats | 668 |---------------+---------+-------------+--------------------------| 669 |Network Control|1 (CS6) | 110000 | Network routing | 670 |---------------+---------+-------------+--------------------------| 671 |Telephony |2 (EF) | 101110 | IP Telephony bearer | 672 |---------------+---------+-------------+--------------------------| 673 |Signaling |3 (CS5) | 101000 | IP Telephony signaling | 674 |---------------+---------+-------------+--------------------------| 675 |Multimedia |4 (AF41) | 100010 | H.323/V2 video | 676 |Conferencing |5 (AF42) | 100100 | conferencing (elastic) | 677 | |6 (AF43) | 100110 | | 678 |---------------+---------+-------------+--------------------------| 679 |Real-time |7 (CS4) | 100000 | Video conferencing and | 680 |Interactive | | | Interactive gaming | 681 |---------------+---------+-------------+--------------------------| 682 |Multimedia |8 (AF31) | 011010 | Streaming video and | 683 |Streaming |9 (AF32) | 011100 | audio on demand | 684 | |10 (AF33)| 011110 | | 685 |---------------+---------+-------------+--------------------------| 686 |Broadcast Video|11 (CS3) | 011000 |Broadcast TV & live events| 687 |---------------+---------+-------------+--------------------------| 688 |Low Latency |12 (AF21)| 010010 |Client/server transactions| 689 |Data |13 (AF22)| 010100 |Web-based ordering | 690 | |14 (AF23)| 010110 | | 691 |---------------+---------+-------------+--------------------------| 692 |OAM |15 (CS2) | 010000 | Non-critical OAM&P | 693 |---------------+---------+-------------+--------------------------| 694 |High Throughput|16 (AF11)| 001010 | Store and forward | 695 |Data |17 (AF12)| 001100 | applications | 696 | |18 (AF13)| 001110 | | 697 |---------------+---------+-------------+--------------------------| 698 |Standard |19 (DF, | 000000 | Undifferentiated | 699 | | CS0) | | applications | 700 |---------------+---------+-------------+--------------------------| 701 |Low Priority |20 (CS1) | 001000 | Any flow that has no BW | 702 |Data | | | assurance | 703 ------------------------------------------------------------------ 705 5.6.2 Parameter [Y.1541] 707 Y.1541 QoS classes are defined as follows: 709 0 1 2 3 4 5 6 7 710 +-+-+-+-+-+-+-+-+ 711 | Y.1541 | 712 | QoS Class | 713 +-+-+-+-+-+-+-+-+ 715 Y.1541 QoS Class: 8 bits 716 Indicates the Y.1541 QoS Class. Values currently allowed are 0, 717 1, 2, 3, 4, 5. 719 Class 0: 720 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10-3. 721 Real-time, highly interactive applications, sensitive to jitter. 722 Application examples include VoIP, Video Teleconference. 724 Class 1: 725 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10-3. 726 Real-time, interactive applications, sensitive to jitter. 727 Application examples include VoIP, Video Teleconference. 729 Class 2: 730 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 731 10-3. 732 Highly interactive transaction data. 733 Application examples include signaling. 735 Class 3: 736 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 737 10-3. 738 Interactive transaction data. 739 Application examples include signaling. 741 Class 4: 742 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 10-3. 744 Low Loss Only applications. 745 Application examples include Short Transactions, Bulk Data, Video 746 Streaming. 748 Class 5: 749 Mean delay unspecified, delay variation unspecified, loss ratio 750 unspecified. 751 Unspecified applications. 752 Application examples include traditional applications of default IP 753 Networks. 755 5.6.3 Parameter [DSTE] 757 DSTE class type is defined as follows: 759 0 1 2 3 4 5 6 7 760 +-+-+-+-+-+-+-+-+ 761 | DSTE | 762 | Class Type | 763 +-+-+-+-+-+-+-+-+ 765 DSTE Class Type: 8 bits 766 Indicates the DSTE class type. Values currently allowed are 0, 1, 768 2, 3, 4, 5, 6, 7. 770 5.7 Priority Parameters 772 5.7.1 & Parameters 773 [RFC 3181] 775 0 1 2 3 776 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Preemption Priority | Defending Priority | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Preemption Priority: 16 bits (unsigned) 782 The priority of the new flow compared with the defending priority 783 of previously admitted flows. Higher values represent higher 784 priority. 786 Defending Priority: 16 bits (unsigned) 788 5.7.2 Parameter [SIP-PRIORITY] 790 0 1 791 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Reservation | Reservation | 794 | Priority | Priority | 795 | Namespace | | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 High priority flows, normal priority flows, and best-effort priority 799 flows can have access to resources depending on their {"Namespace", 800 "Reservation Priority"} combination as follows: 802 Reservation Priority Namespace: 8 bits 803 0 - dsn high priority 804 1 - drsn high priority 805 2 - q735 high priority 806 3 - ets high priority 807 4 - wps high priority 808 5 - normal priority 809 6 - best-effort priority 811 Reservation Priority: 8 bits 812 Each namespace has a finite list of relative priority-values. Each 813 is listed here in the order of lowest priority to highest priority: 815 4 - dsn.routine 816 3 - dsn.priority 817 2 - dsn.immediate 818 1 - dsn.flash 819 0 - dsn.flash-override 821 5 - drsn.routine 822 4 - drsn.priority 823 3 - drsn.immediate 824 2 - drsn.flash 825 1 - drsn.flash-override 826 0 - drsn.flash-override-override 828 4 - q735.4 829 3 - q735.3 830 2 - q735.2 831 1 - q735.1 832 0 - q735.0 834 4 - ets.4 835 3 - ets.3 836 2 - ets.2 837 1 - ets.1 838 0 - ets.0 840 4 - wps.4 841 3 - wps.3 842 2 - wps.2 843 1 - wps.1 844 0 - wps.0 846 0 - normal.0 848 0 - best.effort.0 850 Note that additional work is needed to communicate these flow 851 priority values to bearer-level network elements 852 [VERTICAL-INTERFACE]. 854 5.8 Parameters 856 5.8.1 Parameter [RFC 2215] 858 0 1 2 3 859 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Path b/w estimate (32-bit IEEE floating point number) | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Values of this parameter are measured in bytes per second. The 865 representation MUST be able to express values ranging from 1 byte per 866 second to 40 terabytes per second. For values of this parameter only 867 valid non-negative floating point numbers are allowed. Negative 868 numbers (including "negative zero"), infinities, and NAN's are not 869 allowed. 871 A QNE MAY export a local value of zero for this parameter. A 872 network element or application receiving a composed value of zero for 873 this parameter must assume that the actual bandwidth available is 874 unknown. 876 5.8.2 Parameter [RFC 2210, 2215] 878 0 1 2 3 879 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Minimum path latency (32-bit integer) | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 The composition rule for the parameter is summation 885 with a clamp of (2**32 - 1) on the maximum value. The latencies are 886 reported in units of one microsecond. An individual QNE can advertise 887 a latency value between 1 and 2**28 (somewhat over two minutes) and 888 the total latency added across all QNEs can range as high as 889 (2**32)-2. If the sum of the different elements delays exceeds 890 (2**32)-2, the end-to-end advertised delay should be reported as 891 indeterminate. The distinguished value (2**32)-1 is taken to mean 892 indeterminate latency. A QNE which cannot accurately predict the 893 latency of packets it is processing should set its local parameter 894 to this value. Because the composition function limits the composed 895 sum to this value, receipt of this value at a network element or 896 application indicates that the true path latency is not known. This 897 may happen because one or more network elements could not supply a 898 value, or because the range of the composition calculation was 899 exceeded. 901 5.8.3 Parameters [RFC 2210, 2212, 2215] 903 0 1 2 3 904 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | End-to-end composed value for C [Ctot] (32-bit integer) | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | End-to-end composed value for D [Dtot] (32-bit integer) | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Since-last-reshaping point composed C [Csum] (32-bit integer) | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 The error term C is measured in units of bytes. An individual QNE 916 can advertise a C value between 1 and 2**28 (a little over 250 917 megabytes) and the total added over all QNEs can range as high as 918 (2**32)-1. Should the sum of the different QNEs delay exceed 919 (2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The 920 error term D is measured in units of one microsecond. An individual 921 QNE can advertise a delay value between 1 and 2**28 (somewhat over 922 two minutes) and the total delay added over all QNEs can range as 923 high as (2**32)-1. Should the sum of the different QNEs delay 924 exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1. 926 6. Security Considerations 928 The priority parameter raises possibilities for Theft of Service 929 Attacks because users could claim an emergency priority for their 930 flows without real need, thereby effectively preventing serious 931 emergency calls to get through. Several options exist for countering 932 such attacks, for example 934 - only some user groups (e.g. the police) are authorized to set the 935 emergency priority bit 937 - any user is authorized to employ the emergency priority bit for 938 particular destination addresses (e.g. police) 940 7. IANA Considerations 942 This section provides guidance to the Internet Assigned Numbers 943 Authority (IANA) regarding registration of values related to the 944 QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 946 [QoS-SIG] requires IANA to create a new registry for QoS Signaling 947 Policy Identifiers. The QoS Signaling Policy Identifier (QSP ID) is 948 a 32 bit value carried in a QSPEC object. The allocation policy for 949 new QSP IDs is TBD. 951 This document also defines 24 objects for the QSPEC Template, as 952 Detailed in Section 5. Values are to be assigned for them from the 953 GIMPS Object Type registry. 955 8. Acknowledgements 957 The authors would like to thank Robert Hancock, Sven van den 958 Bosch, Hannes Tschofenig, and Tom Phelan for their very helpful 959 suggestions. 961 9. Intellectual Property Considerations 963 The IETF takes no position regarding the validity or scope of any 964 Intellectual Property Rights or other rights that might be claimed 965 to pertain to the implementation or use of the technology described 966 in this document or the extent to which any license under such 967 rights might or might not be available; nor does it represent that 968 it has made any independent effort to identify any such rights. 969 Information on the procedures with respect to rights in RFC 970 documents can be found in BCP 78 and BCP 79. 972 Copies of IPR disclosures made to the IETF Secretariat and any 973 assurances of licenses to be made available, or the result of an 974 attempt made to obtain a general license or permission for the use 975 of such proprietary rights by implementers or users of this 976 specification can be obtained from the IETF on-line IPR repository 977 at http://www.ietf.org/ipr. 979 The IETF invites any interested party to bring to its attention any 980 copyrights, patents or patent applications, or other proprietary 981 rights that may cover technology that may be required to implement 982 this standard. Please address the information to the IETF at ietf- 983 ipr@ietf.org. 985 10. Normative References 987 [DIFFSERV] S. Blake et. al., "An Architecture for Differentiated 988 Services", RFC 2475, December 1998. 989 [KEY] S. Bradner, "Key words for use in RFCs to Indicate Requirement 990 Levels", BCP 14, RFC 2119, March 1997 991 [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service 992 Signaling," work in progress. 993 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 994 Network Element Service", RFC 2211, Sept. 1997. 995 [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality 996 of Service," September 1997. 997 [RFC2215] S. Shenker and J. Wroclawski, "General Characterization 998 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 999 1997. 1000 [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) -- 1001 Version 1 Functional Specification," RFC 2205, September 1997. 1002 [RSVP-INTSERV] J. Wroclawski, "The Use of RSVP with IETF Integrated 1003 Services", RFC 2210, September 1997. 1005 11. Informative References 1007 [DCLASS] Bernet Y., Format of the RSVP DCLASS Object, RFC 2996, 1008 November 2000 1009 [DIFFSERV-CLASS] Baker, F., et. al., "Configuration Guidelines 1010 for DiffServ Service Classes," work in progress. 1011 [DSTE] F. Le Faucheur et. al., Requirements for Support of 1012 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 1013 July 2003 1014 [INTSERV] B. Braden et. al., "Integrated Services in the Internet 1015 Architecture: an Overview," RFC 1633, June 1994. 1016 [INTSERV-QSP] C. Kappler, "A QoS Model for Signaling IntServ 1017 Controlled-Load Service with NSIS," work in progress. 1018 [NSIS-REQ] M. Brunner et. al., "Requirements for QoS Signaling 1019 Protocols", work in progress. 1020 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 1021 Protocol - Capability Set 3" Sep. 2003 1022 [RMD-QSP] A. Bader, L. Westberg, G. Karagiannis, C. Kappler and T. 1023 Phelan, " RMD-QSP: An NSIS QoS Signaling Policy model for Networks 1024 Using Resource Management in Diffserv (RMD)," work in progress. 1025 [SIP-PRIORITY] H. Schulzrinne, J. Polk, "Communications Resource 1026 Priority for the Session Initiation Protocol(SIP)." work in 1027 progress. 1028 [VERTICAL-INTERFACE] M. Dolly, P. S. Tarapore, S. Sayers, 1029 "Discussion on Associating of Control Signaling Messages with Media 1030 Priority Levels," T1S1.7 & PRQC, October 2004. 1031 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1032 Objectives for IP-Based Services," May 2002. 1033 [Y.1541-QSP] J. Ash, et. al., "NSIS Network Service Layer Protocol 1034 QoS Signaling Proof-of-Concept," work in progress. 1036 12. Authors' Addresses 1038 Jerry Ash 1039 AT&T 1040 Room MT D5-2A01 1041 200 Laurel Avenue 1042 Middletown, NJ 07748, USA 1043 Phone: +1-(732)-420-4578 1044 Fax: +1-(732)-368-8659 1045 Email: gash@att.com 1047 Attila Bader 1048 Traffic Lab 1049 Ericsson Research 1050 Ericsson Hungary Ltd. 1051 Laborc u. 1 H-1037 1052 Budapest Hungary 1053 EMail: Attila.Bader@ericsson.com 1055 Chuck Dvorak 1056 AT&T 1057 Room 2A37 1058 180 Park Avenue, Building 2 1059 Florham Park, NJ 07932 1060 Phone: + 1 973-236-6700 1061 Fax:+1 973-236-7453 1062 E-mail: cdvorak@att.com 1064 Yacine El Mghazli 1065 Alcatel 1066 Route de Nozay 1067 91460 Marcoussis cedex 1068 FRANCE 1069 Phone: +33 1 69 63 41 87 1070 Email: yacine.el_mghazli@alcatel.fr 1072 Cornelia Kappler 1073 Siemens AG 1074 Siemensdamm 62 1075 Berlin 13627 1076 Germany 1077 Email: cornelia.kappler@siemens.com 1079 Georgios Karagiannis 1080 University of Twente 1081 P.O. BOX 217 1082 7500 AE Enschede 1083 The Netherlands 1084 EMail: g.karagiannis@ewi.utwente.nl 1086 Andrew McDonald 1087 Siemens/Roke Manor Research 1088 Roke Manor Research Ltd. 1089 Romsey, Hants SO51 0ZN 1090 UK 1091 EMail: andrew.mcdonald@roke.co.uk 1092 Al Morton 1093 AT&T 1094 Room D3-3C06 1095 200 S. Laurel Avenue 1096 Middletown, NJ 07748 1097 Phone: + 1 732 420-1571 1098 Fax: +.1 732 368-1192 1099 E-mail: acmorton@att.com 1101 Percy Tarapore 1102 AT&T 1103 Room D1-33 1104 200 S. Laurel Avenue 1105 Middletown, NJ 07748 1106 Phone: + 1 732 420-4172 1107 E-mail: tarapore@.att.com 1109 Lars Westberg 1110 Ericsson Research 1111 Torshamnsgatan 23 1112 SE-164 80 Stockholm, Sweden 1113 EMail: Lars.Westberg@ericsson.com 1115 Appendix A: Example QSPECs 1117 Note the mere definition of QSPECs is not sufficient for determining 1118 how to signal for DiffServ and IntServ respectively. Rather, the 1119 full QSP needs to be defined. 1121 A.1 QSPEC for Admission Control for DiffServ 1123 QSPEC for Diffserv QSP in general may be provided in future versions 1124 of this draft. A QSPEC for a DiffServ QSP is included in [RMD-QSP]. 1126 A.2 QSPEC for IntServ Controlled Load Service 1128 The QoS Model for IntServ Controlled Load is defined in [RFC2211]. 1129 The QSPEC can be derived from usage of RSVP to signal for this QoS 1130 Model, as defined in [RSVP-INTSERV] and [RFC2215]. 1132 The QSPEC for IntServ Controlled Load is composed of the objects 1133 and , as well as . Which 1134 object is present in a particular QSPEC depends on the message 1135 type (RESERVE, QUERY etc) in which the QSPEC travels. Details must 1136 be provided in a corresponding QSP. Parameters in the QSPEC are as 1137 follows: 1139 = 1141 = 1142 = 1143 1144 = 1146 An IntServ over Diffserv QSPEC is 1147 = 1148 = 1149 = 1150 1151 = 1153 Or a simple QSPEC for Diffserv requesting bandwidths for different 1154 PHBs is 1156 = 1157 = 1159 A.3 QSPEC for IntServ Guaranteed Services 1161 The QoS Model is defined in [RFC 2212]. The required parameters to 1162 achieve guarantied service with RSVP are specified in [RFC 2210] and 1163 [RFC 2215]. 1165 The QSPEC for guarantied services is the following: 1167 = 1169 = 1171 This object contains token bucket parameters defined in [RFC 2210]. 1172 (equivalent to TSpec defined in RSVP). 1174 = 1175 1177 These parameters are defined in [RFC 2212] and [RFC 2215]. This 1178 object is equivalent to AdSpec of RSVP. 1180 = 1181 Requested Rate and Slack Term defined in [RFC 2212], equivalent to 1182 RSpec of RSVP. 1184 Note that the Guarantied Services QoS Model only works with receiver 1185 initiated reservation signaling, because and are derived 1186 from parameters contained in , and may be updated on 1187 the return paths. 1189 Appendix B: Example of NSLP QSPEC Operation 1191 This Appendix illustrates the operation and use of the QSPEC within 1192 the NSLP. The example configuration looks like this: 1194 +----------+ /-------\ /--------\ /--------\ 1195 | Laptop | | Home | | Cable | | Diffserv | 1196 | Computer |-----| Network |-----| Network |-----| Network |----+ 1197 +----------+ | No QSP | | DQOS QSP | | RMD QSP | | 1198 \-------/ \--------/ \--------/ | 1199 | 1200 +-----------------------------------------------+ 1201 | 1202 | /--------\ +----------+ 1203 | | "X"G | | Handheld | 1204 +---| Wireless |-----| Device | 1205 | XG QSP | +----------+ 1206 \--------/ 1208 In this configuration, a laptop computer and a handheld wireless 1209 device are the end points for some application that has QoS 1210 requirements. Assume that the two end points are stationary during 1211 the application session. For this session, the laptop computer is 1212 connected to a home network that has no QoS support. The home 1213 network is connected to a CableLabs-type cable access network with 1214 DQOS support. That network is connected to a Diffserv core network 1215 that uses RMD. On the other side of the Diffserv core is a wireless 1216 access network built on generation "X" technology with QoS support as 1217 defined by generation "X". And finally the handheld endpoint is 1218 connected to the wireless access network. 1220 We assume that the Laptop is the QNI and Handheld Device is the QNR, 1221 and the QNEs in between all implement NSLP/QSPEC. There are two ways 1222 to signal the flow: 1224 Option A. The Laptop-QNI discovers which QSPs are supported on the 1225 data path by sending a QUERY message along the data path. The 1226 RESPONSE message indicates the preferred QSP supported in the domains 1228 along the path. The Laptop-QNI then knows that the RMD-QSP and 1229 XG-QSP are in the path and stacks the appropriate generic parameters 1230 needed by the RMD-QSPEC and XG-QSPEC in the RESERVE message. It can 1231 also stack the QSP-specific parameters need by the XG-QSP in a second 1232 QSPEC to be used only within the XG-QSP domain. 1234 Option B. The QNI creates a reservation request and includes the 1235 initiator QSPEC with the generic parameters. Each QNE extracts the 1236 generic parameters it needs to implement the QSP within the domain. 1237 For example, in the RMD domain the parameter is extracted, or 1238 alternatively it is translated based on parameters. 1239 On the other hand, at the XG network ingress, a 'Local QoS Model' 1240 and Local-QSPEC corresponding to the XG-QSP are generated according 1241 to the procedures described in Section 4.5 of [QoS-SIG]. That is, 1242 the XG-QNI must map between the two resource descriptions and 1243 construct the appropriate second 'local' QSPEC object to be pushed on 1244 top. This top QSPEC becomes the current QSPEC used within the XG-QSP 1245 domain, that is, the translated QSPEC becomes the first QSPEC, and 1246 the original initiator QSPEC is second. This saves the XG-QNEs the 1247 trouble of re-translating the initiator QSPEC. At the egress edge of 1248 the XG-QSP domain, the translated QSPEC is popped, and the initiator 1249 QSPEC returns to the number 1 position. (Note that stand-along QNEs 1250 simply forward the initiator QSPEC, and the translated QSPEC (if any) 1251 is only used within the QNE. Eventually the RESERVE request arrives 1252 at the QNR. 1254 Appendix C: QoS Models, QoS Signaling Policies and QSPECs 1256 This Appendix gives a description of QoS Models, QSPs and QSPECs and 1257 explains what is the relation between them. Once these descriptions 1258 are contained in a stable form in the appropriate IDs this Appendix 1259 will be removed. 1261 QoS NSLP is a generic QoS Signaling Protocol that can signal for 1262 many QoS Models. A QoS Model is a particular QoS provisioning method 1263 or QoS architecture such a IntServ Controlled Load, Guaranteed 1264 Service. DiffServ, or RMD for DiffServ. 1266 The definition of the QoS Model is independent from the definition 1267 of QoS NSLP. Existing QoS Models do not specify how to use QoS NSLP 1268 to signal for them. Therefore, we need to define the QoS Signaling 1269 Policy (QSP), specific to each QoS Model, which describes the QoS 1270 Model specific signaling functions. QoS Signaling Policy are defined 1271 for "Resource Management in DiffServ" in [RMD-QSP] and for IntServ 1272 Controlled Load in [INTSERV-QSP]. 1274 A QSP should include the following information: 1276 - Role of QNEs in this QoS Model: 1277 E.g. location, frequency, statefulness... 1278 - QSPEC Definition: 1279 A QSP should specify the QSPEC, including generic and optional 1280 parameters. Furthermore it needs to explain how generic parameters 1281 not used in this QSP are mapped onto parameters defined therein. 1282 - Message Format 1283 Objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY 1284 - State Management 1285 It describes how QSPEC info is treated and interpreted in the 1286 Resource Management Function and QSP specific processing. E.g. 1287 admission control, scheduling, policy control, QoS parameter 1288 accumulation (e.g. delay)? 1289 - Operation and Sequence of Events 1290 Usage of QoS-NSLP messages to signal the QoS Model. 1292 Appendix D: Mapping of QoS Desired, QoS Available and QoS Reserved of 1293 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 1295 The union of QoS Desired, QoS Available and QoS Reserved can provide 1296 all functionality of the objects specified in RSVP IntServ, however 1297 it is difficult to provide an exact mapping. 1299 In RSVP, the Sender TSpec specifies the traffic an application is 1300 going to send (e.g. token bucket). The AdSpec can collect path 1301 characteristics (e.g. delay). Both are issued by the sender. The 1302 receiver sends the FlowSpec which includes a Receiver TSpec 1303 describing the resources reserved using the same parameters as the 1304 Sender TSpec, as well as a RSpec which provides additional IntServ 1305 QoS Model specific parameters, e.g. Rate and Slack. 1307 The RSVP TSpec/AdSpec/RSpec seem quite tailored to 1308 receiver-initiated signaling employed by RSVP, and the IntServ 1309 QoS Model. E.g. to the knowledge of the authors it is not possible 1310 for the sender to specify a desired maximum delay except 1311 implicitly and mutably by seeding the AdSpec accordingly. Likewise, 1312 the RSpec is only meaningfully sent in the receiver-issued RSVP 1313 RESERVE message. For this reason our debate at this point lead us 1314 to a slightly different mapping of necessary functionality to 1315 objects, which should result in more flexible signaling models. 1317 Full Copyright Statement 1319 Copyright (C) The Internet Society (2004). This document is subject 1320 to the rights, licenses and restrictions contained in BCP 78 and 1321 except as set forth therein, the authors retain all their rights. 1323 This document and the information contained herein are provided on an 1324 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1325 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1326 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1327 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1328 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1329 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1331 Disclaimer of Validity 1333 This document and the information contained herein are provided on 1334 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1335 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1336 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1337 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1338 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.