idnits 2.17.1 draft-ietf-nsis-qspec-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1960. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (July 2005) is 6860 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: 'RFC 2212' is mentioned on line 969, but not defined == Missing Reference: 'RFC 2215' is mentioned on line 1003, but not defined == Missing Reference: 'RFC 2210' is mentioned on line 1353, but not defined == Missing Reference: 'S' is mentioned on line 996, but not defined == Missing Reference: 'MTU' is mentioned on line 1034, but not defined == Missing Reference: 'RFC 3170' is mentioned on line 1046, but not defined == Missing Reference: 'RFC 3181' is mentioned on line 1141, but not defined -- Looks like a reference, but probably isn't: '2215' on line 1353 -- Looks like a reference, but probably isn't: '2212' on line 1353 == Missing Reference: 'Ctot' is mentioned on line 1368, but not defined == Missing Reference: 'Dtot' is mentioned on line 1370, but not defined == Missing Reference: 'Csum' is mentioned on line 1372, but not defined == Missing Reference: 'Dsum' is mentioned on line 1374, but not defined == Missing Reference: 'QOS-SIG' is mentioned on line 1470, but not defined == Missing Reference: 'RFC2212' is mentioned on line 1607, but not defined == Missing Reference: 'RFC2434' is mentioned on line 1689, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'DSCP-REGISTRY' is defined on line 1709, but no explicit reference was found in the text == Unused Reference: 'PHBID-CODES-REGISTRY' is defined on line 1710, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 1717, but no explicit reference was found in the text == Unused Reference: 'RFC2215' is defined on line 1723, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1726, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV-CLASS' is defined on line 1745, but no explicit reference was found in the text == Unused Reference: 'RFC1633' is defined on line 1754, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DSCP-REGISTRY' -- Possible downref: Non-RFC (?) normative reference: ref. 'PHBID-CODES-REGISTRY' -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 2697 ** Downref: Normative reference to an Informational RFC: RFC 2698 Summary: 7 errors (**), 0 flaws (~~), 23 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Internet Draft NSIS Working Group Jerry Ash 2 Internet Draft AT&T 3 Attila Bader 4 Expiration Date: January 2006 Ericsson 5 Cornelia Kappler 6 Siemens AG 8 July 2005 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 BCP 79. 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 months 25 and may be updated, replaced, or obsoleted by other documents at any 26 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. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 26, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The QoS NSLP protocol is used to signal QoS reservations and is 44 independent of a specific QoS model (QOSM) such as IntServ or 45 DiffServ. Rather, all information specific to a QOSM is encapsulated 46 in a separate object, the QSPEC. This draft defines a template for 47 the QSPEC, which contains both the QoS description and QSPEC control 48 information. The QSPEC format is defined, as are a number of QSPEC 49 parameters. The QSPEC parameters provide a common language to be 50 re-used in several QOSMs. To a certain extent QSPEC parameters 51 ensure interoperability of QOSMs. Optional QSPEC parameters aim to 52 ensure the extensibility of QoS NSLP to other QOSMs in the future. 53 The node initiating the NSIS signaling adds an Initiator QSPEC that 54 must not be removed, thereby ensuring the intention of the NSIS 55 initiator is preserved along the signaling path. 57 Table of Contents 59 1. Conventions Used in This Document . . . . . . . . . . . . . . . 4 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. QSPEC Parameters, Processing, & Extensibility . . . . . . . . . 6 63 4.1 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 6 64 4.2 QSPEC Processing . . . . . . . . . . . . . . . . . . . . . 6 65 4.3 Example of NSLP QSPEC Operation . . . . . . . . . . . . . . 8 66 4.4 Treatment of QSPEC Parameters . . . . . . . . . . . . . . . 12 67 4.4.1 Mandatory and Optional QSPEC Parameters . . . . . . . 12 68 4.4.2 Read-only and Read-write QSPEC Parameters . . . . . . 12 69 4.5 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 12 70 5. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . . . 13 71 5.1 QSPEC Control Information . . . . . . . . . . . . . . . . . 13 72 5.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 14 73 5.2.1 QoS Desired . . . . . . . . . . . . . . . . . . . . . 14 74 5.2.2 QoS Available . . . . . . . . . . . . . . . . . . . . 15 75 5.2.3 QoS Reserved . . . . . . . . . . . . . . . . . . . . 18 76 5.2.4 Minimum QoS . . . . . . . . . . . . . . . . . . . . . 18 77 6. QSPEC Functional Specification . . . . . . . . . . . . . . . . 18 78 6.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 19 79 6.2 Parameter . . . . . . . . . . 20 80 6.3 Parameter . . . . . . . . . . . . . . . . . 20 81 6.4 Parameter . . . . . . . . . . . . . . . 21 82 6.5 & Parameters . . . . . . . . . . . . . . . 21 83 6.6 Parameters . . . . . . . . . . . . . . . . . 22 84 6.7 Parameters . . . . . . . . . . . . . . . . . . 23 85 6.7.1 Parameter . . . . . . . . . . . . . . . . 23 86 6.7.2 Parameter . . . . . . . . . . . . 23 87 6.7.3 Parameter . . . . . . . . . . . . . 24 88 6.8 Parameters . . . . . . . . . . . . . . . . . . . 24 89 6.8.1 & 90 Parameters . . . . . . . . . . . . . . . . . . . . . 24 91 6.8.2 Parameters . . . . . . . . . . 25 93 6.9 Parameter . . . . . . . . . . . . . . . . . 27 94 6.10 Parameter . . . . . . . . . . . . . . . . . 27 95 6.11 Parameter . . . . . . . . . . . . . . . . . . . 28 96 6.12 Parameters . . . . . . . . . . 29 97 6.13 Non-Support Flags . . . . . . .. . . . . . . . . . . . . . 29 98 6.14 Tunneled-Parameter Flags . . . . . .. . . . . . . . . . . 30 99 7. QSPEC Procedures & Examples . . . . . . . . . . . . . . . . . . 31 100 7.1 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 31 101 7.1.1 Sender-Initiated Reservations . . . . . . . . . . . . 31 102 7.1.2 Receiver-Initiated Reservations . . . . . . . . . . . 32 103 7.1.3 Resource Queries . . . . . . . . . . . . . . . . . . 33 104 7.1.4 Bidirectional Reservations . . . . . . . . . . . . . 33 105 7.1.5 Setting Optional Parameter Flags . . . . . . . . . . 33 106 7.2 QSPEC Examples . . . . . . . . . . . . . . . . . . . . . . 34 107 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 108 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 109 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 110 11. Normative References . . . . . . . . . . . . . . . . . . . . 36 111 12. Informative References . . . . . . . . . . . . . . . . . . . 36 112 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 113 Appendix A QoS Models and QSPECs . . . . . . . . . . . . . . . . . 39 114 Appendix B Mapping of QoS Desired, QoS Available, and QoS 115 Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ . . 39 116 Appendix C: Main Changes Since Last Version & Open Issues . . . . 40 117 C.1 Main Changes Since Version -04 . . . . . . . . . . 40 118 C.2 Open Issues . . . . . . . . . . . . . . . . . . . 40 119 Intellectual Property Statement . . . . . . . . . . . . . . . . . 40 120 Full Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 41 121 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . 41 123 1. Conventions Used in This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Introduction 131 The QoS NSLP establishes and maintains state at nodes along the path 132 of a data flow for the purpose of providing forwarding resources 133 (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is conceptually 134 similar to RSVP [RFC2205], and meets the requirements of [RFC3726]. 136 A QoS-enabled domain supports a particular QoS model (QOSM), which is 137 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 138 provisioning methods and a QoS architecture. It defines the behavior 139 of the resource management function (RMF), including inputs and 140 outputs, and how QSPEC information is interpreted on traffic 141 description, resources required, resources available, and control 142 information required by the RMF. A QOSM also specifies a set of 143 mandatory and optional QSPEC parameters that describe the QoS and how 144 resources will be managed by the RMF. QoS NSLP can support signaling 145 for different QOSMs, such as for IntServ, DiffServ admission control, 146 and those specified in [Y.1541-QOSM, INTSERV-QOSM, RMD-QOSM]. For 147 more information on QOSMs see Section 7.2 and Appendix A. 149 One of the major differences between RSVP and QoS-NSLP is that 150 QoS-NSLP supports signaling for different QOSMs along the data path, 151 all with one signaling message. For example, the data path may start 152 in a domain supporting DiffServ and end in a domain supporting 153 Y.1541. However, because some typical QoS parameters are 154 standardized and can be reused in different QOSMs, some degree of 155 interoperability between QOSMs exists. 157 The QSPEC travels in QoS-NSLP messages and is opaque to the 158 QoS NSLP. The content of the QSPEC is QOSM specific. Since 159 QoS-NSLP signaling operation can be different for different QOSMs, 160 the QSPEC contains two kinds of information, QSPEC control 161 information and QoS description. 163 QSPEC control information contains parameters that governs the RMF. 164 An example of QSPEC control information is how the excess traffic is 165 treated in the RMF queuing functions. 167 The QoS description is composed of QSPEC objects loosely 168 corresponding to the TSpec, RSpec and AdSpec objects specified in 169 RSVP. This is, the QSPEC may contain a description of QoS desired 170 and QoS reserved. It can also collect information about available 171 resources. Going beyond RSVP functionality, the QoS description 172 also allows indicating a range of acceptable QoS by defining a QSPEC 173 object denoting minimum QoS. Usage of these QSPEC objects is not 174 bound to particular message types thus allowing for flexibility. A 175 QSPEC object collecting information about available resources MAY 176 travel in any QoS-NSLP message, for example a QUERY message or a 177 RESERVE message. 179 3. Terminology 181 Mandatory QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 182 if applicable to the underlying QOSM and a QNE MUST interpret, if 183 populated. 185 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 186 any QNE. Together with a description of QoS Desired or QoS 187 Available, it allows the QNI to specify a QoS range, i.e. an upper 188 and lower bound. If the QoS Desired cannot be reserved, QNEs are 189 going to decrease the reservation until the minimum QoS is hit. 191 Optional QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 192 if applicable to the underlying QOSM, and a QNE SHOULD interpret if 193 populated and applicable to the QOSM(s) supported by the QNE. (A QNE 194 MAY ignore if it does not support a QOSM needing the optional QSPEC 195 parameter). 197 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 199 QNI: QoS NSIS Initiator, a node initiating QoS-NSLP signaling. 201 QNR: QoS NSIS Receiver, a node terminating QoS-NSLP signaling. 203 QoS Description: Describes the actual QoS in QSPEC objects QoS 204 Desired, QoS Available, QoS Reserved, and Minimum QoS. These QSPEC 205 objects are input or output parameters of the RMF. In a valid QSPEC, 206 at least one QSPEC object of the type QoS Desired, QoS Available or 207 QoS Reserved MUST be included. 209 QoS Available: QSPEC object containing parameters describing the 210 available resources. They are used to collect information along a 211 reservation path. 213 QoS Desired: QSPEC object containing parameters describing the 214 desired QoS for which the sender requests reservation. 216 QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g., 217 IntServ Controlled Load. A QOSM specifies a set of mandatory and 218 optional QSPEC parameters that describe the QoS and how resources 219 will be managed by the RMF. It furthermore specifies how to use QoS 220 NSLP to signal for this QOSM. 222 QoS Reserved: QSPEC object containing parameters describing the 223 reserved resources and related QoS parameters, for example, 224 bandwidth. 226 QSPEC Control Information: Control information that is specific to a 227 QSPEC, and contains parameters that govern the RMF. 229 QSPEC: QSPEC is the object of QoS-NSLP containing all QOSM-specific 230 information. 232 QSPEC parameter: Any parameter appearing in a QSPEC; includes both 233 QoS description and QSPEC control information parameters, for 234 example, bandwidth, token bucket, and excess treatment parameters. 236 QSPEC Object: Main building blocks of QoS Description containing a 237 QSPEC parameter set that is input or output of an RMF operation. 239 Resource Management Function (RMF): Functions that are related to 240 resource management, specific to a QOSM. It processes the QoS 241 description parameters and QSPEC control parameters. 243 Read-only Parameter: QSPEC Parameter that is set by initiating or 244 responding QNE and is not changed during the processing of the QSPEC 245 along the path. 247 Read-write Parameter: QSPEC Parameter that can be changed during the 248 processing of the QSPEC by any QNE along the path. 250 4. QSPEC Parameters, Processing, & Extensibility 252 4.1 QSPEC Parameters 254 The definition of a QOSM includes the specification of how the 255 requested QoS resources will be described and how they will be 256 managed by the RMF. For this purpose, the QOSM specifies a set of 257 QSPEC parameters that describe the QoS and QoS resource control in 258 the RMF. A given QOSM defines which of the mandatory and optional 259 QSPEC parameters it uses, and it MAY define additional optional QSPEC 260 parameters. Mandatory and optional QSPEC parameters provide a common 261 language for QOSM developers to build their QSPECs and are likely to 262 be re-used in several QOSMs. Mandatory and optional QSPEC parameters 263 are defined in this document, and additional optional QSPEC 264 parameters can be defined in separate documents. Specification of 265 additional optional QSPEC parameters requires standards action, as 266 defined in Section 4.5. 268 4.2 QSPEC Processing 270 The QSPEC is opaque to the QoS-NSLP processing. The QSPEC control 271 information and the QoS description are interpreted and MAY be 272 modified by the RMF in a QNE (see description in [QoS-SIG]). 274 A QoS-enabled domain supports a particular QOSM, e.g. DiffServ 275 admission control. If this domain supports QoS-NSLP signaling, its 276 QNEs MUST support the DiffServ admission control QOSM. The QNEs MAY 277 also support additional QOSMs. 279 A QoS NSLP message can contain a stack of at most 2. The first on 280 the stack is the Initiator QSPEC. This is a QSPEC provided by the 281 QNI, which travels end-to-end, and therefore the stack always has at 282 least depth 1. QSPEC parameters MUST NOT be deleted from or added to 283 the Initiator QSPEC. In addition, the stack MAY contain a Local 284 QSPEC stacked on top of the Initiator QSPEC. A QNE only considers 285 the topmost QSPEC. 287 At the ingress edge of a local QoS domain, a Local QSPEC MAY be 288 pushed on the stack in order to describe the requested resources in a 289 domain-specific manner. Also, the Local QSPEC is popped from the 290 stack at the egress edge of the local QoS domain. 292 This draft provides a template for the QSPEC, which is needed in 293 order to help define individual QOSMs and in order to promote 294 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 295 is composed of QSPEC control information and QoS description. QoS 296 description in turn is composed of up to four QSPEC objects (not all 297 of them need to be present), namely QoS Desired, QoS Available, QoS 298 Reserved and Minimum QoS. Each of these QSPEC Objects, as well as 299 QSPEC Control Information, consists of a number of mandatory and 300 optional QSPEC parameters. 302 +-------------+---------------------------------------+ 303 |QSPEC Control| QoS | 304 | Information | Description | 305 +-------------+---------------------------------------+ 307 \________________ ______________________/ 308 V 309 +----------+----------+---------+-------+ \ 310 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| > QSPEC 311 +----------+----------+---------+-------+ / Objects 313 \_______ ____/\____ ____/\___ _____/\___ ____/\__ ___/ 314 V V V V V 316 +-------------+... +-------------+... 317 |QSPEC Para. 1| |QSPEC Para. n| 318 +-------------+... +-------------+... 320 Figure 1: Structure of the QSPEC 322 The internal structure of each QSPEC object and the QSPEC control 323 information, with mandatory and optional parameters, is illustrated 324 in Figure 2. 326 +------------------+-----------------+---------------+ 327 | QSPEC/Ctrl Info | Mandatory QSPEC |Optional QSPEC | 328 | Object ID | Parameters | Parameters | 329 +------------------+-----------------+---------------+ 331 Figure 2: Structure of QSPEC Objects & Control Information 333 4.3 Example of NSLP/QSPEC Operation 335 This Section illustrates the operation and use of the QSPEC within 336 the NSLP. The example configuration in shown in Figure 3. 338 +----------+ /-------\ /--------\ /--------\ 339 | Laptop | | Home | | Cable | | DiffServ | 340 | Computer |-----| Network |-----| Network |-----| Network |----+ 341 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 342 \-------/ \--------/ \--------/ | 343 | 344 +-----------------------------------------------+ 345 | 346 | /--------\ +----------+ 347 | | "X"G | | Handheld | 348 +---| Wireless |-----| Device | 349 | XG QOSM | +----------+ 350 \--------/ 352 Figure 3: Example Configuration to Illustrate QoS-NSLP/QSPEC 353 Operation 355 In this configuration, a laptop computer and a handheld wireless 356 device are the endpoints for some application that has QoS 357 requirements. Assume initially that the two endpoints are stationary 358 during the application session, later we consider mobile endpoints. 359 For this session, the laptop computer is connected to a home network 360 that has no QoS support. The home network is connected to a 361 CableLabs-type cable access network with dynamic QoS (DQOS) support, 362 such as specified in the 'CMS to CMS Signaling Specification' [CMSS] 363 for cable access networks. That network is connected to a DiffServ 364 core network that uses the RMD QOSM [RMD-QOSM]. On the other side of 365 the DiffServ core is a wireless access network built on generation 366 "X" technology with QoS support as defined by generation "X". And 367 finally the handheld endpoint is connected to the wireless access 368 network. 370 We assume that the Laptop is the QNI and handheld device is the QNR. 372 The QNI will populate an Initiator QSPEC to achieve the QoS desired 373 on the path. In this example we consider two different ways to 374 perform sender-initiated signaling for QoS: 376 Case 1) The QNI sets , and possibly 377 QSPEC objects in the Initiator QSPEC, and initializes 378 to . Since this is a reservation in a 379 heterogenic network with different QOSMs supported in different 380 domains, each QNE on the path reads and interprets those parameters 381 in the Initiator QSPEC that it needs to implement the QOSM within its 382 domain (as described below). Each QNE along the path checks to see if 383 resources can be reserved, and if not, the QNE 384 reduces the respective parameter values in and 385 reserves these values. The minimum parameter values are given in 386 , if populated, otherwise zero if is not 387 included. If one or more parameters in fails to 388 satisfy the corresponding minimum values in Minimum QoS, the QNE 389 notifies the QNI and the reservation is aborted. Otherwise, the QNR 390 notifies the QNI of the for the reservation. 392 Case 2) The QNI populated the Initiator QSPEC with . 393 Since this is a reservation in a heterogenic network with different 394 QOSMs supported in different domains, each QNE on the path reads and 395 interprets those parameters in the Initiator QSPEC that it needs to 396 implement the QOSM within its domain (as described below). If a QNE 397 cannot reserve resources, the reservation fails. 399 In both cases, the QNI populates mandatory and optional QSPEC to 400 ensure correct treatment of its traffic in domains down the path. 401 Since the QNI does not know the QOSM used in downstream domains, it 402 includes values for those mandatory and optional QSPEC parameters it 403 cares about. Let us assume the QNI wants to achieve IntServ-like QoS 404 guarantees, and also is interested in what path latency it can 405 achieve. The QNI therefore includes in the QSPEC the QOSM ID for 406 IntServ Controlled Load Service. The QSPEC objects are populated with 407 all parameters necessary for IntServ Controlled Load and additionally 408 the parameter to measure path latency, as follows: 410 = 411 = 413 In both cases, each QNE on the path reads and interprets those 414 parameters in the Initiator QSPEC that it needs to implement the QOSM 415 within its domain. It may need additional parameters for its QOSM, 416 which are not specified in the Initiator QSPEC. If possible, these 417 parameters must be inferred from those that are present, according to 418 rules defined in the QOSM implemented by this QNE. 420 There are two possibilities when a RESERVE message is received at a 421 QNE at a domain border (we illustrate both possibilities in the 422 example): 424 - the QNE can stack a local QSPEC on top of the Initiator QSPEC (this 425 is new in QoS NSLP, RSVP does not do this). 427 - the QNE can tunnel the Initiator RESERVE message through its domain 428 and issue its own Local RESERVE message. For this new Local RESERVE 429 message, the QNE acts as the QNI, and the QSPEC in the domain is an 430 Initiator QSPEC. This procedure is also used by RSVP in making 431 aggregate reservations, in which case there is not a new intra-domain 432 (aggregate) RESERVE for each newly arriving interdomain (per-flow) 433 RESERVE, but the aggregate reservation is updated by the border QNE 434 (QNI) as need be. This is also how RMD works [RMD-QOSM]. 436 For example, at the RMD domain, a local RESERVE with its own RMD 437 Initiator QSPEC corresponding to the RMD-QOSM is generated based on 438 the original Initiator QSPEC according to the procedures described in 439 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. That is, the ingress QNE 440 to the RMD domain must map the QSPEC parameters contained in the 441 original Initiator QSPEC into the RMD QSPEC. The RMD QSPEC for 442 example needs and . is generated 443 from the parameter. Information on , 444 however, is not provided. According to the rules laid out in the RMD 445 QOSM, the ingress QNE infers from the fact that an IntServ Controlled 446 Load QOSM was signaled that the EF PHB is appropriate to set the parameter. These RMD QSPEC parameters are populated in the 448 RMD Initiator QSPEC generated within the RMD domain. 450 Furthermore, the node at the egress to the RMD domain updates on behalf of the entire RMD domain if it can. If it 452 cannot, it raises parameter-specific flags, warning the QNR that the 453 final value of these parameters in QoS Available is imprecise. 455 In the XG domain, the Initiator QSPEC is translated into a Local 456 QSPEC using a similar procedure as described above. The Local QSPEC 457 becomes the current QSPEC used within the XG domain, that is, the 458 it becomes the first QSPEC on the stack, and the Initiator QSPEC is 459 second. This saves the QNEs within the XG domain the trouble of 460 re-translating the Initiator QSPEC. At the egress edge of the XG 461 domain, the translated Local QSPEC is popped, and the Initiator QSPEC 462 returns to the number one position. 464 If the reservation was successful, eventually the RESERVE request 465 arrives at the QNR (otherwise the QNE at which the reservation failed 466 would have aborted the RESERVE and sent an error RESPONSE back to the 467 QNI). The QNR generates a positive RESPONSE with QSPEC objects - and for case 1 - additionally . The 469 parameters appearing in are the same as in , with values copied from in case 1, and with 471 the original values from in case 2. That is, it is not 472 necessary to transport the object back to the QNI since 473 the QNI knows what it signaled originally, and the information is not 474 useful for QNEs in the reverse direction. The object 475 should transport all necessary information, although the and objects may end up transporting some of 477 the same information. 479 Hence, the QNR populates the following QSPEC objects: 481 = 482 = 484 If the handheld device on the right of Figure 3 is mobile, and moves 485 through different "XG" wireless networks, then the QoS might change 486 on the path since different XG wireless networks might support 487 different QOSMs. As a result, QoS-NSLP/QSPEC processing will have to 488 renegotiate the on the path. From a QSPEC 489 perspective, this is like a new reservation on the new section of the 490 path and is basically the same as any other rerouting event - to the 491 QNEs on the new path it looks like a new reservation. That is, in 492 this mobile scenario, the new segment may support a different QOSM 493 than the old segment, and the QNI would now signal a new reservation 494 (explicitly, or implicitly with the next refreshing RESERVE message) 495 to account for the different QOSM in the XG wireless domain. Further 496 details on rerouting are specified in [QoS-SIG]. 498 4.4 Treatment of QSPEC Parameters 500 4.4.1 Mandatory and Optional QSPEC Parameters 502 Mandatory and optional QSPEC parameters are defined in this document 503 and are applicable to a number of QOSMs. Mandatory QSPEC parameters 504 are treated as follows: 506 o A QNI SHOULD populate mandatory QSPEC parameters if applicable to 507 the underlying QOSM. 508 o QNEs MUST interpret mandatory QSPEC parameters, if populated. 510 Optional QSPEC parameters are treated as follows: 512 o A QNI SHOULD populate optional QSPEC parameters if applicable to 513 the QOSM for which it is signaling. 515 o QNEs SHOULD interpret optional QSPEC parameters, if populated and 516 applicable to the QOSM(s) supported by the QNE. (A QNE MAY ignore 517 the optional QSPEC parameter if it does not support a QOSM needing 518 the optional QSPEC parameter). 520 4.4.2 Read-only and Read-write QSPEC Parameters 522 Both mandatory and optional QSPEC parameters can be read-only or 523 read-write. Read-write parameters can be changed by any QNE, whereas 524 read-only parameters are fixed by the QNI and/or QNR. For example in 525 a RESERVE message, all parameters in are read-write 526 parameters, which are updated by intermediate QNEs. Read-only 527 parameters are, for example, all parameters in as sent 528 by the QNI. 530 QoS description parameters can be both read-only or read-write, 531 depending on which QSPEC object, and which message, they appear in. 532 In particular, all parameters in and are 533 read-only for all messages. More details are provided in Sec. 7.1. 535 In the QSPEC Control Information Object, the property of being 536 read-write or read-only is parameter specific. 538 4.5 QSPEC Extensibility 540 Additional optional QSPEC parameters MAY need to be defined in the 541 future. Additional optional QSPEC parameters are defined in separate 542 Informational documents specific to a given QOSM. For example, 543 optional QSPEC parameters are defined in [RMD-QOSM] and 544 [Y.1541-QOSM]. 546 5. QSPEC Format Overview 548 QSPEC = 550 As described above, the QSPEC contains an identifier for the QOSM, 551 the actual resource description (QoS description) as well as QSPEC 552 control information. Note that all QSPEC parameters defined in the 553 following Sections are mandatory QSPEC parameters unless specifically 554 designated as optional QSPEC parameters. 556 Each optional QSPEC parameter has an associated 'non-support' flag. 557 If such a flag is set, at least one QNE along the data transmission 558 path between the QNI and QNR can not support the specified optional 559 parameter. 561 Each mandatory and optional QSPEC parameter has an associated 562 'tunneled parameter' flag. When a RESERVE message is tunneled 563 through a domain, QNEs inside the domain cannot update read-write 564 parameters. The egress QNE in a domain has two choices: Either it is 565 configured to have the knowledge to update the parameters correctly. 566 Or it cannot update the parameters. In this case it MUST set the 567 tunneled parameter flag to tell the QNI (or QNR) that the 568 information contained in the read-write parameter is most likely 569 incorrect (or a lower bound). 571 A QSPEC object ID identifies whether the object is or . As described below, the is further broken down into , , , and objects. A QSPEC 575 parameter ID is assigned to identify each QSPEC parameter defined 576 below. 578 A QOSM ID is included in the QSPEC and tells a QNE which parameters 579 to expect. This may simplify processing and error analysis. 580 Furthermore, it may be helpful for a QNE or a domain supporting more 581 than one QOSM to learn which QOSM the QNI would like to have in order 582 to use the most suitable QOSM. Note that the QSPEC parameters do not 583 uniquely define the QNI QOSM since more parameters than required by 584 the QNI QOSM can be included by the QNI. QOSM IDs are assigned by 585 IANA. 587 5.1. QSPEC Control Information 589 QSPEC control information is used for signaling QOSM RMF functions 590 not defined in QoS-NSLP. It enables building new RMF functions 591 required by a QOSM within a QoS-NSLP signaling framework, such as 592 specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. 594 = 595 597 Note that is a read-write parameter. , and are read-only 599 parameters. 601 identifies the particular QOSM being used by the QNI (the 602 QOSM ID is assigned by IANA)> 604 is an identifier for which QSPEC 605 procedures are used, as defined in Section 7.1. 607 is a flag bit telling the QNR (or QNI in a RESPONSE 608 message) whether or not a particular QOSM is supported by each QNE 609 in the path between the QNI and QNR. A QNE sets the 610 flag parameter if it does not support the relevant QOSM 611 specification. If the QNR finds this bit set, at least one QNE along 612 the data transmission path between the QNI and QNR can not support 613 the specified QOSM.In a local QSPEC, refers to the 614 QoS-NSLP peers of the local QOSM domain. 616 The parameter describes how the QNE will process 617 excess traffic, that is, out-of-profile traffic. Excess traffic MAY 618 be dropped, shaped and/or remarked. The excess treatment parameter is 619 initially set by the QNI and is read-only. 621 5.2 QoS Description 623 The QoS Description is broken down into the following QSPEC objects: 625 = 626 628 Of these QSPEC objects, QoS Desired, QoS Available and QoS Reserved 629 MUST be supported by QNEs. Minimum QoS MAY be supported. 631 5.2.1 633 = 634 636 These parameters describe the resources the QNI desires to reserve 637 and hence this is a read-only QSPEC object. The 638 resources that the QNI wishes to reserve are of course directly 639 related to the traffic the QNI is going to inject into the network. 640 Therefore, when used in the object, refers to traffic injected by the QNI into the network. 643 = 644 = link bandwidth needed by flow [RFC 2212, RFC 2215] 646 =

[RFC 2210] 648 Note that the Path MTU Discovery (PMTUD) working group is currently 649 specifying a robust method for determining the MTU supported over an 650 end-to-end path. This new method is expected to update RFC1191 and 651 RFC1981, the current standards track protocols for this purpose. 653 = 655 An application MAY like to reserve resources for packets with a 656 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 657 [RFC2475], or DiffServ-enabled MPLS traffic engineering (DSTE) class 658 type [RFC3564]. 660 = 661 663 is an essential way to differentiate flows for 664 emergency services, ETS, E911, etc., and assign them a higher 665 admission priority than normal priority flows and best-effort 666 priority flows. is the priority of the new 667 flow compared with the defending priority of previously admitted 668 flows. Once a flow is admitted, the preemption priority becomes 669 irrelevant. is used to compare with the 670 preemption priority of new flows. For any specific flow, its 671 preemption priority MUST always be less than or equal to the 672 defending priority. 674 Appropriate security measures need to be taken to prevent abuse of 675 the parameters, see Section 8 on Security Considerations. 677 , and are optional parameters 678 describing the desired path latency, path jitter and path bit error 679 rate respectively. Since these parameters are cumulative, an 680 individual QNE cannot decide whether the desired path latency, etc., 681 is available, and hence they cannot decide whether a reservation 682 fails. Rather, when these parameters are included in , 683 the QNI SHOULD also include corresponding parameters in a QSPEC object in order to facilitate collecting this 685 information. 687 5.2.2 689 = 690 691 693 When used in the object, refers 694 to traffic resources available at a QNE in the network. 696 , , , , , , 697 and are optional QSPEC parameters. As such, each of these 698 optional QSPEC parameters has an associated flag, that is, , , , , 700 , , and . If these flags are set, 701 then at least one QNE along the data transmission path between the 702 QNI and QNR can not support the specified optional parameter. This 703 means the value collected in the corresponding parameter is a lower 704 bound to the "real" value. A QNE MUST be able to set the optional 705 parameter flag if it does not support the optional parameter, and as 706 such the optional parameter flags are mandatory QSPEC parameters. 708 The Object collects information on the resources 709 currently available on the path when it travels in a RESERVE or QUERY 710 message and hence in this case this QSPEC object is read-write. Each 711 QNE MUST inspect all parameters of this QSPEC object, and if 712 resources available to this QNE are less than what a particular 713 parameter says currently, the QNE MUST adapt this parameter 714 accordingly. Hence when the message arrives at the recipient of the 715 message, reflects the bottleneck of the resources 716 currently available on a path. It can be used in a QUERY message, 717 for example, to collect the available resources along a data path. 719 When travels in a RESPONSE message, it in fact just 720 transports the result of a previous measurement performed by a 721 RESERVE or QUERY message back to the initiator. Therefore in this 722 case, is read-only. 724 The parameters and provide information, 725 for example, about the bandwidth available along the path followed by 726 a data flow. The local parameter is an estimate of the bandwidth the 727 QNE has available for packets following the path. Computation of the 728 value of this parameter SHOULD take into account all information 729 available to the QNE about the path, taking into consideration 730 administrative and policy controls on bandwidth, as well as physical 731 resources. The composition rule for this parameter is the MIN 732 function. The composed value is the minimum of the QNE's value and 733 the previously composed value. This quantity, when composed 734 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 735 minimal bandwidth link along the path from QNI to QNR. 737 The parameter accumulates the latency of the packet 738 forwarding process associated with each QNE, where the latency is 739 defined to be the smallest possible packet delay added by each QNE. 740 This delay results from speed-of-light propagation delay, from packet 741 processing limitations, or both. It does not include any variable 742 queuing delay which may be present. Each QNE MUST add the 743 propagation delay of its outgoing link, which includes the QNR adding 744 the associated delay for the egress link. Furthermore, the QNI MUST 745 add the propagation delay of the ingress link. The composition rule 746 for the parameter is summation with a clamp of 747 (2**32 - 1) on the maximum value. This quantity, when composed 748 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 749 minimal packet delay along the path from QNI to QNR. The purpose of 750 this parameter is to provide a minimum path latency for use with 751 services which provide estimates or bounds on additional path delay 752 [RFC 2212]. Together with the queuing delay bound, this parameter 753 gives the application knowledge of both the minimum and maximum 754 packet delivery delay. Knowing both the minimum and maximum latency 755 experienced by data packets allows the receiving application to know 756 the bound on delay variation and de-jitter buffer requirements. 758 The parameter accumulates the jitter of the packet 759 forwarding process associated with each QNE, where the jitter is 760 defined to be the nominal jitter added by each QNE. IP packet 761 jitter, or delay variation, is defined in RFC 3393 [RFC3393], Section 762 4.6 (Type-P-One-way-peak-to-peak-ipdv), where the suggested 763 evaluation interval is 1 minute. Note that the method to estimate 764 peak-to-peak IP delay variation without active measurements requires 765 more study. This jitter results from packet processing limitations, 766 and includes any variable queuing delay which may be present. Each 767 QNE MUST add the jitter of its outgoing link, which includes the QNR 768 adding the associated jitter for the egress link. Furthermore, the 769 QNI MUST add the jitter of the ingress link. The composition rule 770 for the parameter is summation of a large percentage of 771 the peak-to-peak variation with a clamp on the maximum value (note 772 that the methods of accumulation and estimation of nominal QNE jitter 773 are under study). This quantity, when composed end-to-end, informs 774 the QNR (or QNI in a RESPONSE message) of the nominal packet jitter 775 along the path from QNI to QNR. The purpose of this parameter is to 776 provide a nominal path jitter for use with services that provide 777 estimates or bounds on additional path delay [RFC 2212]. Together 778 with the and the queuing delay bound, this parameter 779 gives the application knowledge of the typical packet delivery delay 780 variation. 782 The parameter accumulates the bit error rate (BER) of the 783 packet forwarding process associated with each QNE, where the BER is 784 defined to be the smallest possible BER added by each QNE. Each QNE 785 MUST add the BER of its outgoing link, which includes the QNR adding 786 the associated BER for the egress link. Furthermore, the QNI MUST 787 add the BER of the ingress link. The composition rule for the 788 parameter is summation with a clamp on the maximum value 789 (this assumes sufficiently low BER values such that summation error 790 is not significant). This quantity, when composed end-to-end, 791 informs the QNR (or QNI in a RESPONSE message) of the minimal packet 792 BER along the path from QNI to QNR. As with , the method to 793 estimate requires more study. 795 , , , : Error terms C and D represent how the 796 element's implementation of the guaranteed service deviates from the 797 fluid model. These two parameters have an additive composition rule. 798 The error term C is the rate-dependent error term. It represents the 799 delay a datagram in the flow might experience due to the rate 800 parameters of the flow. The error term D is the rate-independent, 801 per-element error term and represents the worst case non-rate-based 802 transit time variation through the service element. If the 803 composition function is applied along the entire path to compute the 804 end-to-end sums of C and D ( and ) and the resulting 805 values are then provided to the QNR (or QNI in a RESPONSE message). 806 and are the sums of the parameters C and D between the 807 last reshaping point and the current reshaping point. 809 5.2.3 811 = 813 These parameters describe the QoS reserved by the QNEs along the data 814 path, and hence the QoS reserved QSPEC object is read-write. 816 , and are defined above. 818 = slack term, which is the difference between desired delay and 819 delay obtained by using bandwidth reservation, and which is used to 820 reduce the resource reservation for a flow [RFC 2212]. This is an 821 optional parameter. 823 5.2.4 825 = 827 does not have an equivalent in RSVP. It allows the QNI 828 to define a range of acceptable QoS levels by including both the 829 desired QoS value and the minimum acceptable QoS in the same message. 830 It is a read-only QSPEC object. The desired QoS is included with a 831 and/or a QSPEC object seeded to the 832 desired QoS value. The minimum acceptable QoS value MAY be coded in 833 the QSPEC object. As the message travels towards the 834 QNR, is updated by QNEs on the path. If its value 835 drops below the value of the reservation fails and is 836 aborted. When this method is employed, the QNR SHOULD signal back to 837 the QNI the value of attained in the end, because the 838 reservation MAY need to be adapted accordingly. 840 Future versions of this document will describe how can 841 be used by the QNI to send a discrete set of desired parameters. 843 6. QSPEC Functional Specification 845 This Section defines the encodings of the QSPEC parameters and QSPEC 846 control information defined in Section 5. We first give the general 847 QSPEC formats and then the formats of the QSPEC objects and 848 parameters. 850 Note that all QoS Description parameters can be either read-write or 851 read-only, depending on which object and which message they appear 852 in. 854 6.1 General QSPEC Formats: 856 Note: This section is in a draft state and further work is needed to 857 define exact formats of objects. 859 Type: QSPEC 860 Length: Variable 861 Value: This object contains a 2 byte QOSM ID and variable length 862 QSPEC information, which is QOSM specific. 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | QOSM ID | Length (bytes) | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Object ID | Parameter ID | Length (bytes)|Parameter Value| 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 // Parameter Value // 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Object ID | Parameter ID | Length (bytes)|Parameter Value| 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 // Parameter Value // 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 Object ID: 879 0: control information 880 1: QoS Desired 881 2: QoS Available 882 3: QoS Reserved 883 4: Min QoS 885 Alternatively, in order to make the coding more efficient, QOSMs may 886 define one or more optional 'container QSPEC parameter', which 887 contain several sub-parameters. However, optional parameters that are 888 expected to be used by several QOSMs (as e.g. the optional parameter defined in this document) SHOULD be defined as 890 individual parameters, i.e. not inside a container QSPEC parameter. 892 For example, a container QSPEC parameter might be defined as follows: 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Object ID = 0 | Parameter ID | Length = 5 | Para 1 | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 |Para 2 |S|M| Para 5 |U|B| Para 8 | Empty | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 where "Para n" is the nth sub-parameter, and S, M, U and B are flags. 903 The individual parameters in the container can be parsed out as 904 needed by the RMF. By using the container the relative overhead of 905 the QSPEC header to the payload can be decreased considerably when a 906 QOSM uses many short parameters. 908 6.2 Parameter 910 Object ID = 0 911 Parameter ID = 0 912 Length = 1 byte 913 Mandatory QSPEC Parameter 915 Parameter Values: 917 0 1 2 3 4 5 6 7 918 +-+-+-+-+-+-+-+-+ 919 |QSPEC Procedure| 920 | Identifier | 921 +-+-+-+-+-+-+-+-+ 923 QSPEC Procedure Identifier: This is an identifier for which QSPEC 924 procedures are used, as defined in Section 7.1. Allowed values are 925 as follows: 926 0: Sender-Initiated Reservations, as defined in Section 7.1.1 927 1: Receiver-Initiated Reservations, as defined in Section 7.1.2 928 2: Resource Queries, as defined in Section 7.1.3 929 3: Bidirectional Reservations, as defined in Section 7.1.4 931 6.3 Parameter 933 Object ID = 0 934 Parameter ID = 1 935 Length = 1 byte 936 Mandatory QSPEC Parameter 938 Parameter Values: 940 0 1 2 3 4 5 6 7 941 +-+-+-+-+-+-+-+-+ 942 | NON QOSM Hop | 943 +-+-+-+-+-+-+-+-+ 944 NON QOSM Hop: This field is set to 1 if a non QOSM-aware QNE is 945 encountered on the path from the QNI to the QNR. 947 6.4 Parameter 949 Object ID = 0 950 Parameter ID = 2 951 Length = 1 byte 952 Mandatory QSPEC Parameter 954 Parameter Values: 956 0 1 2 3 4 5 6 7 957 +-+-+-+-+-+-+-+-+ 958 | Excess | 959 | Treatment | 960 +-+-+-+-+-+-+-+-+ 962 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 963 traffic. Allowed values are as follows: 964 0: drop 965 1: shape 966 2: remark 967 The excess treatment parameter is set by the QNI. 969 6.5 & Parameters [RFC 2212, RFC 2215] 971 The parameter MUST be nonnegative and is measured in 972 bytes per second and has the same range and suggested representation 973 as the bucket and peak rates of the . can 974 be represented using single-precision IEEE floating point. The 975 representation MUST be able to express values ranging from 1 byte per 976 second to 40 terabytes per second. For values of this parameter only 977 valid non-negative floating point numbers are allowed. Negative 978 numbers (including "negative zero"), infinities, and NAN's are not 979 allowed. 981 A QNE MAY export a local value of zero for this parameter. A network 982 element or application receiving a composed value of zero for this 983 parameter MUST assume that the actual bandwidth available is unknown. 985 Object ID = 1-4 986 Bandwidth Parameter ID = 3 987 Slack Term Parameter ID = 4 988 Length = 4 bytes 989 Bandwidth is Mandatory QSPEC Parameter 990 Slack Term is Optional QSPEC Parameter 991 Parameter Values: 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Bandwidth (32-bit IEEE floating point number) | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Slack Term [S] (32-bit integer) | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 Slack term S MUST be nonnegative and is measured in microseconds. 1000 The Slack term, S, can be represented as a 32-bit integer. Its value 1001 can range from 0 to (2**32)-1 microseconds. 1003 6.6 Parameters [RFC 2215] 1005 The parameters are represented by three floating 1006 point numbers in single-precision IEEE floating point format followed 1007 by two 32-bit integers in network byte order. The first floating 1008 point value is the rate (r), the second floating point value is the 1009 bucket size (b), the third floating point is the peak rate (p), the 1010 first integer is the minimum policed unit (m), and the second integer 1011 is the maximum datagram size (MTU). 1013 Note that the two sets of parameters can be 1014 distinguished, as could be needed for example to support DiffServ 1015 applications (see Section 7.2). 1017 Object ID = 1-4 1018 Token Bucket #1 Parameter ID = 5 1019 Token Bucket #2 Parameter ID = 6 1020 Length = 20 bytes 1021 Mandatory QSPEC Parameters 1023 Parameter Values: 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Token Bucket Size [b] (32-bit IEEE floating point number) | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Peak Data Rate [p] (32-bit IEEE floating point number) | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Minimum Policed Unit [m] (32-bit integer) | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Maximum Packet Size [MTU] (32-bit integer) | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 When r, b, p, and R terms are represented as IEEE floating point 1038 values, the sign bit MUST be zero (all values MUST be non-negative). 1039 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 1040 than 162 (i.e., positive 35) are discouraged, except for specifying a 1041 peak rate of infinity. Infinity is represented with an exponent of 1042 all ones (255) and a sign bit and mantissa of all zeroes. 1044 6.7 Parameters 1046 6.7.1 Parameter [RFC 3170] 1048 As prescribed in RFC 3170, the encoding for a single PHB is the 1049 recommended DSCP value for that PHB, left-justified in the 16 bit 1050 field, with bits 6 through 15 set to zero. 1052 Object ID = 1-4 1053 PHB Class Parameter ID = 7 1054 Length = 2 bytes 1055 Mandatory QSPEC Parameter 1057 Parameter Values: 1059 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1060 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1061 | DSCP | 0 0 0 0 0 0 0 0 0 0 | 1062 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1064 The registries needed to use RFC 3140 already exist, see [DSCP- 1065 REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs to be 1066 created for this purpose. 1068 6.7.2 Parameter [Y.1541] 1070 Y.1541 QoS classes are defined as follows: 1072 Object ID = 1-4 1073 Y.1541 QoS Class Parameter ID = 8 1074 Length = 1 byte 1075 Mandatory QSPEC Parameter 1077 Parameter Values: 1079 0 1 2 3 4 5 6 7 1080 +-+-+-+-+-+-+-+-+ 1081 | Y.1541 | 1082 | QoS Class | 1083 +-+-+-+-+-+-+-+-+ 1085 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 1086 allowed are 0, 1, 2, 3, 4, 5. 1088 Class 0: 1089 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1090 Real-time, highly interactive applications, sensitive to jitter. 1091 Application examples include VoIP, Video Teleconference. 1093 Class 1: 1094 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1095 Real-time, interactive applications, sensitive to jitter. 1096 Application examples include VoIP, Video Teleconference. 1098 Class 2: 1099 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 1100 10^-3. Highly interactive transaction data. Application examples 1101 include signaling. 1103 Class 3: 1104 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 1105 10^-3. Interactive transaction data. Application examples include 1106 signaling. 1108 Class 4: 1109 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 1110 10^-3. Low Loss Only applications. Application examples include 1111 short transactions, bulk data, video streaming. 1113 Class 5: 1114 Mean delay unspecified, delay variation unspecified, loss ratio 1115 unspecified. Unspecified applications. Application examples include 1116 traditional applications of default IP networks. 1118 6.7.3 Parameter [RFC3564] 1120 DSTE class type is defined as follows: 1122 Object ID = 1-4 1123 DSTE Class Type Parameter ID = 9 1124 Length = 1 byte 1125 Mandatory QSPEC Parameter 1127 Parameter Values: 1129 0 1 2 3 4 5 6 7 1130 +-+-+-+-+-+-+-+-+ 1131 | DSTE | 1132 | Class Type | 1133 +-+-+-+-+-+-+-+-+ 1135 DSTE Class Type: Indicates the DSTE class type. Values currently 1136 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 1138 6.8 Priority Parameters 1140 6.8.1 & Parameters 1141 [RFC 3181] 1143 Object ID = 1-4 1144 Preemption Priority Parameter ID = 10 1145 Defending Priority Parameter ID = 11 1146 Length = 2 bytes (unsigned) 1147 Mandatory QSPEC Parameter 1149 Parameter Values: 1151 0 1 2 3 1152 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 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | Preemption Priority | Defending Priority | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Preemption Priority: The priority of the new flow compared with the 1158 defending priority of previously admitted flows. Higher values 1159 represent higher priority. 1161 Defending Priority: Once a flow is admitted, the preemption priority 1162 becomes irrelevant. Instead, its defending priority is used to 1163 compare with the preemption priority of new flows. 1165 6.8.2 Parameter [PRIORITY-RQMTS, SIP-PRIORITY] 1167 Object ID = 1-4 1168 Admission Priority Parameter ID = 12 1169 RPH Namespace Parameter ID = 13 1170 RPH Priority Parameter ID = 14 1171 Length = 4 bytes 1172 Mandatory QSPEC Parameter 1174 Parameter Values: 1175 0 1 2 3 1177 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 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 + Admission | RPH Namespace | RPH Priority | 1180 + Priority | | | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 High priority flows, normal priority flows, and best-effort priority 1184 flows can have access to resources depending on their admission 1185 priority value, as described in [PRIORITY-RQMTS], as follows: 1187 Admission Priority: 1 byte 1189 0 - high priority flow 1190 1 - normal priority flow 1191 2 - best-effort priority flow 1193 [SIP-PRIORITY] defines a resource priority header (RPH) with 1194 parameters "RPH Namespace" and "RPH Priority" combination, 1195 applicable only to flows with high reservation priority, as follows: 1197 RPH Namespace: 2 bytes 1199 0 - dsn 1200 1 - drsn 1201 2 - q735 1202 3 - ets 1203 4 - wps 1205 RPH Priority: 1 byte 1206 Each namespace has a finite list of relative priority-values. Each 1207 is listed here in the order of lowest priority to highest priority: 1209 4 - dsn.routine 1210 3 - dsn.priority 1211 2 - dsn.immediate 1212 1 - dsn.flash 1213 0 - dsn.flash-override 1215 5 - drsn.routine 1216 4 - drsn.priority 1217 3 - drsn.immediate 1218 2 - drsn.flash 1219 1 - drsn.flash-override 1220 0 - drsn.flash-override-override 1222 4 - q735.4 1223 3 - q735.3 1224 2 - q735.2 1225 1 - q735.1 1226 0 - q735.0 1228 4 - ets.4 1229 3 - ets.3 1230 2 - ets.2 1231 1 - ets.1 1232 0 - ets.0 1234 4 - wps.4 1235 3 - wps.3 1236 2 - wps.2 1237 1 - wps.1 1238 0 - wps.0 1240 Note that SIP nodes can send multiple NameSpace.Priority tupple 1241 values in the same message, in part because end nodes may not know 1242 what Namespace "domain" it resides in, nor which Namespace "domains" 1243 it may traverse. Therefore multiple 1244 parameters MAY be sent in a given QSPEC, which is turn contain 1245 multiple RPH Namespace/Priority combinations. 1247 Note that additional work is needed to communicate these flow 1248 priority values to bearer-level network elements 1249 [VERTICAL-INTERFACE]. 1251 6.9 Parameter [RFC 2210, 2215] 1253 Object ID = 1-4 1254 Path Latency Parameter ID = 15 1255 Length = 4 bytes 1256 Optional QSPEC Parameter 1258 Parameter Values: 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Path Latency (32-bit integer) | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 The composition rule for the parameter is summation 1267 with a clamp of (2**32 - 1) on the maximum value. The latencies are 1268 reported in units of one microsecond. An individual QNE can advertise 1269 a latency value between 1 and 2**28 (somewhat over two minutes) and 1270 the total latency added across all QNEs can range as high as 1271 (2**32)-2. If the sum of the different elements delays exceeds 1272 (2**32)-2, the end-to-end advertised delay SHOULD be reported as 1273 indeterminate. A QNE that cannot accurately predict the latency of 1274 packets it is processing MUST raise the Path Latency Flag and either 1275 leave the value of Path Latency as is, or add its best estimate of 1276 its lower bound. A raised Path Latency Flag indicates the value of 1277 Path Latency is a lower bound of the real Path Latency. The 1278 distinguished value (2**32)-1 is taken to mean indeterminate latency 1279 because the composition function limits the composed sum to this 1280 value, it indicates the range of the composition calculation was 1281 exceeded. 1283 6.10 Parameter 1285 Object ID = 1-4 1286 Path Jitter Parameter ID = 16 1287 Length = 4 bytes 1288 Optional QSPEC Parameter 1290 Parameter Values: 1292 0 1 2 3 1293 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 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Path Jitter (32-bit integer) | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 The composition rule for the parameter is summation 1298 with a clamp of (2**32 - 1) on the maximum value. The jitters are 1299 reported in units of one microsecond. An individual QNE can advertise 1300 a jitter value between 1 and 2**28 (somewhat over two minutes) and 1301 the total jitter added across all QNEs can range as high as 1302 (2**32)-2. If the sum of the different elements delays exceeds 1303 (2**32)-2, the end-to-end advertised jitter SHOULD be reported as 1304 indeterminate. A QNE that cannot accurately predict the jitter of 1305 packets it is processing MUST raise the Path Jitter Flag and either 1306 leave the value of Path Jitter as is, or add its best estimate of its 1307 lower bound. A raised Path Jitter Flag indicates the value of Path 1308 Jitter is a lower bound of the real Path Jitter. The distinguished 1309 value (2**32)-1 is taken to mean indeterminate jitter. A QNE which 1310 cannot accurately predict the jitter of packets it is processing 1311 SHOULD set its local parameter to this value. Because the 1312 composition function limits the composed sum to this value, receipt 1313 of this value at a network element or application indicates that the 1314 true path jitter is not known. This MAY happen because one or more 1315 network elements could not supply a value, or because the range of 1316 the composition calculation was exceeded. 1318 6.11 Parameter 1320 Object ID = 1-4 1321 Path BER Parameter ID = 17 1322 Length = 4 bytes 1323 Optional QSPEC Parameter 1325 Parameter Values: 1327 0 1 2 3 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Path Bit Error Rate (32-bit integer) | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 The composition rule for the parameter is summation with 1334 a clamp of 10^-2 on the maximum value. The BERs are reported in 1335 units of 10^-11. An individual QNE can advertise a BER value between 1336 1 and 2**28 and the total BER added across all QNEs can range as high 1337 as (2**32)-2. If the sum of the different elements delays exceeds 1338 (2**32)-2, the end-to-end advertised BER SHOULD be reported as 1339 indeterminate. A QNE that cannot accurately predict the BER of 1340 packets it is processing MUST raise the Path BER Flag and either 1341 leave the value of Path BER as is, or add its best estimate of its 1342 lower bound. A raised Path BER Flag indicates the value of Path BER 1343 is a lower bound of the real Path BER. The distinguished value 1344 (2**32)-1 is taken to mean indeterminate BER. A QNE which cannot 1345 accurately predict the BER of packets it is processing SHOULD set its 1346 local parameter to this value. Because the composition function 1347 limits the composed sum to this value, receipt of this value at a 1348 network element or application indicates that the true path BER is 1349 not known. This MAY happen because one or more network elements 1350 could not supply a value, or because the range of the composition 1351 calculation was exceeded. 1353 6.12 Parameters [RFC 2210, 2212, 2215] 1355 Object ID = 1-4 1356 Ctot Parameter ID = 18 1357 Dtot Parameter ID = 19 1358 Csum Parameter ID = 20 1359 Dsum Parameter ID = 21 1360 Length = 4 bytes 1361 Optional QSPEC Parameters 1363 Parameter Values: 1365 0 1 2 3 1366 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 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | End-to-end composed value for C [Ctot] (32-bit integer) | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | End-to-end composed value for D [Dtot] (32-bit integer) | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Since-last-reshaping point composed C [Csum] (32-bit integer) | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 The error term C is measured in units of bytes. An individual QNE 1378 can advertise a C value between 1 and 2**28 (a little over 250 1379 megabytes) and the total added over all QNEs can range as high as 1380 (2**32)-1. Should the sum of the different QNEs delay exceed 1381 (2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The 1382 error term D is measured in units of one microsecond. An individual 1383 QNE can advertise a delay value between 1 and 2**28 (somewhat over 1384 two minutes) and the total delay added over all QNEs can range as 1385 high as (2**32)-1. Should the sum of the different QNEs delay 1386 exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1. 1388 6.13 Non-Support Flags 1390 Object ID = 1-4 1391 Path Latency Non-Support Flag Parameter ID = 22 1392 Path Latency Non-Support Flag Parameter ID = 23 1393 Path Latency Non-Support Flag Parameter ID = 24 1394 Ctot Non-Support Flag Parameter ID = 25 1395 Dtot Non-Support Flag Parameter ID = 26 1396 Csum Non-Support Flag Parameter ID = 27 1397 Dsum Non-Support Flag Parameter ID = 28 1398 Slack Term Non-Support Flag Parameter ID = 29 1399 Length = 1 byte 1400 Mandatory QSPEC Parameters 1402 Parameter Values: 1404 General format for the Non-Support Flag: 1406 0 1 2 3 4 5 6 7 1407 +-+-+-+-+-+-+-+-+ 1408 | Non-Support | 1409 | Flag | 1410 +-+-+-+-+-+-+-+-+ 1412 This field is set to 1 if a QNE is encountered that does not support 1413 the QSPEC parameter on the path from the QNI to the QNR. 1415 6.14 Tunneled-Parameter Flags 1417 Object ID = 1-4 1418 Tunneled-Parameter Flag Parameter ID = 30 1419 Tunneled-Parameter Flag Parameter ID = 31 1420 Tunneled-Parameter Flag Parameter ID = 32 1421 Tunneled-Parameter Flag Parameter ID = 33 1422 Token Bucket Rate Tunneled-Parameter Flag Parameter ID = 34 1423 Token Bucket Size Tunneled-Parameter Flag Parameter ID = 35 1424 Peak Data Rate Tunneled-Parameter Flag Parameter ID = 36 1425 Minimum Policed Unit Tunneled-Parameter Flag Parameter ID = 37 1426 Maximum Packet Size Tunneled-Parameter Flag Parameter ID = 38 1427 PHB Class Tunneled-Parameter Flag Parameter ID = 39 1428 Y.1541 QoS Class Tunneled-Parameter Flag Parameter ID = 40 1429 DSTE Class Type Tunneled-Parameter Flag Parameter ID = 41 1430 Preemption Priority Tunneled-Parameter Flag Parameter ID = 42 1431 Defending Priority Tunneled-Parameter Flag Parameter ID = 43 1432 Admission Priority Tunneled-Parameter Flag Parameter ID = 44 1433 RPH Namespace Tunneled-Parameter Flag Parameter ID = 45 1434 RPH Priority Tunneled-Parameter Flag Parameter ID = 46 1435 Path Latency Tunneled-Parameter Flag Parameter ID = 47 1436 Path Jitter Tunneled-Parameter Flag Parameter ID = 48 1437 Path BER Tunneled-Parameter Flag Parameter ID = 49 1438 Ctot Tunneled-Parameter Flag Parameter ID = 50 1439 Dtot Tunneled-Parameter Flag Parameter ID = 51 1440 Csum Tunneled-Parameter Flag Parameter ID = 52 1441 Dsum Tunneled-Parameter Flag Parameter ID = 53 1442 Length = 1 byte 1443 Mandatory QSPEC Parameters 1445 Parameter Values: 1447 General format for the Tunneled-Parameter Flag: 1449 0 1 2 3 4 5 6 7 1450 +-+-+-+-+-+-+-+-+ 1451 | Tunneled- | 1452 | Parameter Flag| 1453 +-+-+-+-+-+-+-+-+ 1455 This field is set as follows: When a RESERVE message is tunneled 1456 through a domain, QNEs inside the domain cannot update read-write 1457 parameters. The egress QNE in a domain MUST set the tunneled- 1458 parameter flag to tell the QNI (or QNR) that the information 1459 contained in the read-write parameter is most likely incorrect (or a 1460 lower bound). 1462 7. QSPEC Procedures & Examples 1464 7.1 QSPEC Procedures 1466 While the QSPEC template aims to put minimal restrictions on usage of 1467 QSPEC objects in , interoperability between QNEs and 1468 between QOSMs must be ensured. We therefore give below an exhaustive 1469 list of QSPEC object combinations for the message sequences described 1470 in QoS NSLP [QOS-SIG]. A specific QOSM may impose more restrictions 1471 on the QNI or QNR freedom. 1473 7.1.1 Sender-Initiated Reservations 1475 Here the QNI issues a RESERVE, which is replied to by a RESPONSE. 1476 This response is generated either by the QNR or, in case the 1477 reservation was unsuccessful, by a QNE. The following possibilities 1478 for QSPEC object usage exist: 1480 | RESERVE | RESPONSE 1481 --------------------------------------------------------------- 1482 a.| QoS Desired | QoS Reserved 1483 b.| QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 1484 c.| QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 1486 a.) If only QoS Desired is included in the RESERVE, the implicit 1487 assumption is that exactly these resources must be reserved. If this 1488 is not possible the reservation fails. The parameters in QoS 1489 Reserved are copied from the parameters in QoS Desired. 1491 b.) When QoS Available is included in the RESERVE also, some 1492 parameters will appear only in QoS Available and not in QoS Desired. 1493 It is assumed that the value of these parameters is collected for 1494 informational purposes only (e.g. path latency). 1496 However, some parameters in QoS Available can be the same as in QoS 1497 Desired. For these parameters the implicit message is that the QNI 1498 would be satisfied by a reservation with lower parameter values than 1499 specified in QoS Desired. For these parameters, the QNI seeds the 1500 parameter values in QoS Available to those in QoS Desired (except for 1501 cumulative parameters such as ). 1503 Each QNE adapts the parameters in QoS Available according to its 1504 current capabilities. Reservations in each QNE are hence based on 1505 current parameter values in QoS Available (and additionally those 1506 parameters that only appear in QoS Desired). The drawback of this 1507 approach is that, if the resulting resource reservation becomes 1508 gradually smaller towards the QNR, QNEs close to the QNI have an 1509 oversized reservation, possibly resulting in unnecessary costs for 1510 the user. Of course, in the RESPONSE the QNI learns what the actual 1511 reservation is (from the QoS RESERVED object) and can immediately 1512 issue a properly sized refreshing RESERVE. The advantage of the 1513 approach is that the reservation is performed in half-a-roundtrip 1514 time. 1516 The parameter types included in QoS Reserved in RESPONSE must be the 1517 same as those in QoS Desired in RESERVE. For those parameters that 1518 were also included in QoS Available in RESERVE, their value is copied 1519 into QoS Desired. For the other parameters, the value is copied from 1520 QoS Desired (the reservation would fail if the corresponding QoS 1521 could not be reserved). 1523 The parameters in the QoS Available QSPEC object in the RESPONSE are 1524 copied with their values from the QoS Available QSPEC object in the 1525 RESERVE. Note that the parameters in QoS Available are read-write 1526 in the RESERVE message, whereas they are read-only in the RESPONSE. 1528 c.) this case is handled as case (b), except that the reservation 1529 fails when QoS Available becomes less than Minimum QoS for one 1530 parameter. If a parameter appears in QoS Available but not in 1531 Minimum QoS it is assumed that the minimum value for this parameter 1532 is that given in QoS Available. 1534 7.1.2 Receiver-Initiated Reservations 1536 Here the QNR issues a QUERY which is replied to by the QNI with a 1537 RESERVE if the reservation was successful. The QNR in turn sends a 1538 RESPONSE to the QNI. 1540 QUERY | RESERVE | RESPONSE 1541 --------------------------------------------------------------------- 1542 a. QoS Des. | QoS Des. | QoS Res. 1543 b. QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 1544 c. QoS Avail. | QoS Des. | QoS Res. 1546 a.) and b.) The idea is that the sender (QNR in this scenario) needs 1547 to inform the receiver (QNI in this scenario) about the QoS it 1548 desires. To this end the sender sends a QUERY message to the 1549 receiver including a QoS Desired QSPEC object. If the QoS is 1550 negotiable it additionally includes a (possibly zero) Minimum QoS, as 1551 in Case b. 1553 The RESERVE message includes QoS Available if the sender signaled QoS 1554 is negotiable (i.e. it included Minimum QoS). If the Minimum QoS 1555 received from the sender is non-zero, the QNR also includes Minimum 1556 QoS. 1558 c. This is the "RSVP-style" scenario. The sender (QNR) issues a QUERY 1559 with QoS Available to collect path properties, and the QoS Desired in 1560 the RESERVE issued by the receiver (QNI) is populated from the 1561 parameter values in QoS Available from the QUERY message. The 1562 advantage of this model is that the situation of over-reservation in 1563 QNEs close to the QNI as described above does not occur. On the 1564 other hand, the QUERY may find, for example, a particular bandwidth 1565 is not available. When the actual reservation is performed, however, 1566 the desired bandwidth may meanwhile have become free. That is, the 1567 'RSVP style' may result in a smaller reservation than necessary. 1569 7.1.3 Resource Queries 1571 Here the QNI issues a QUERY in order to investigate what resources 1572 are currently available. The QNR replies with a RESPONSE. 1574 QUERY | RESPONSE 1575 -------------------------------------------- 1576 QoS Available | QoS Available 1578 Note QoS Available when traveling in the QUERY is read-write, whereas 1579 in the RESPONSE it is read-only. 1581 7.1.4 Bidirectional Reservations 1583 On a QSPEC level, bidirectional reservations are no different from 1584 uni-directional reservations, since QSPECs for different directions 1585 never travel in the same message. 1587 7.1.5 Setting Optional Parameter Flags 1589 An optional parameter is always accompanied by an optional parameter 1590 flag in all objects. For example, if the QNI populates an optional 1591 parameter in QoS Desired, it MUST also populate the optional 1592 parameter flag in . Hence, if a QNE wants to check 1593 for support of optional parameters, it MUST include a 1594 object and the optional parameter flags are only in that object. If 1595 a QNE does not support the optional parameter, it MUST set the 1596 optional parameter flag in the QoS Available object. Optional 1597 parameter flags SHOULD only travel in the object, and 1598 are generally not included in the QoS Desired, Minimum QoS and QoS 1599 Reserved objects. 1601 7.2 QSPEC Examples 1603 This Section provides an example QSPEC for DiffServ admission 1604 control. The QSPEC for IntServ controlled load service is 1605 specified in [INTSERV-QOSM] (note that the QOSMs for IntServ 1606 Controlled Load Service and IntServ Guaranteed Service are defined in 1607 [RFC2211] and [RFC2212], respectively). 1609 The QSPEC for DiffServ admission control may be composed, for 1610 example, of the QSPEC objects and , as 1611 well as . Which QSPEC object is present in a 1612 particular QSPEC depends on the message type (RESERVE, QUERY etc) in 1613 which the QSPEC travels. Parameters in the QSPEC for DiffServ 1614 requesting bandwidth for different PHBs are as follows: 1616 Example QSPEC for the DiffServ EF PHB [RFC3297]: 1618 = 1619 = 1620 = 1621 = 1622 = 1623 = 1624 = 1626 In general, the EF PHB is a property of the service that is NOT 1627 dependent on the input traffic characteristics. A server of rate R 1628 and latency E that is compliant with the EF PHB must deliver at least 1629 the configured service rate R with at most latency E for any traffic 1630 characterization. Therefore, strictly speaking, there is no specific 1631 traffic descriptor required to deliver the EF PHB (which by 1632 definition is a local per-hop characterization). However, in order 1633 to deliver a reasonable end-to-end delay, it is typically assumed 1634 that EF traffic is shaped at the ingress. A typical assumption is 1635 that input traffic at any ingress is constrained by a single rate 1636 token bucket. Therefore, a single rate token bucket is sufficient 1637 to signal in QoS-NSLP/QSPEC for the DiffServ-QOSM. 1639 Example QSPEC for the DiffServ AFxy PHB [RFC2597]: 1641 = 1642 = 1643 = 1644 = 1645 1646 = 1647 = 1648 = 1650 QNEs process two sets of token bucket parameters to implement the 1651 DiffServ AF QOSM, one token bucket for the average (CBS) traffic and 1652 one token bucket for the burst (EBS) traffic. These 2 token buckets 1653 are sufficient to cover most of the ways in which one would 1654 distinguish among 3 levels of drop precedence at the queuing 1655 mechanics level, as described in the Appendix to [RFC2597]. 1657 QoS-NSLP/QSPEC can support signaling the parameters required for the 1658 DiffServ marker elements described in [RFC2697] and [RFC2698]. 1659 [RFC2697] defines a Single Rate Three Color Marker (srTCM), which 1660 can be used as component in a DiffServ traffic conditioner [RFC2475, 1661 RFC2474]. The srTCM meters a traffic stream and marks its packets 1662 according to three traffic parameters, Committed Information Rate 1663 (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be 1664 either green, yellow, or red. A packet is marked green if it does 1665 not exceed the CBS, yellow if it does exceed the CBS, but not the 1666 EBS, and red otherwise. 1668 RFC 2697 and RFC 2698 provide specific procedures, where in essence, 1669 RFC 2697 is using two token buckets that run at the same rate. 1671 8. Security Considerations 1673 The priority parameter raises possibilities for Theft of Service 1674 Attacks because users could claim an emergency priority for their 1675 flows without real need, thereby effectively preventing serious 1676 emergency calls to get through. Several options exist for countering 1677 such attacks, for example 1679 - only some user groups (e.g. the police) are authorized to set the 1680 emergency priority bit 1682 - any user is authorized to employ the emergency priority bit for 1683 particular destination addresses (e.g. police) 1685 9. IANA Considerations 1687 This section provides guidance to the Internet Assigned Numbers 1688 Authority (IANA) regarding registration of values related to the 1689 QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 1691 [QoS-SIG] requires IANA to create a new registry for QoS Signaling 1692 Model Identifiers. The QoS Signaling Model Identifier (QOSM ID) is 1693 a 4 byte value carried in a QSPEC. The allocation policy for 1694 new QOSM IDs is TBD. 1696 This document also defines 53 objects and parameters for the QSPEC 1697 Template, as detailed in Section 6. Values are to be assigned for 1698 them from the NTLP Object Type registry. 1700 10. Acknowledgements 1702 The authors would like to thank (in alphabetical order) David Black, 1703 Anna Charny, Xiaoming Fu, Robert Hancock, Chris Lang, Dave Oran, Tom 1704 Phelan, Hannes Tschofenig, and Sven van den Bosch, for their very 1705 helpful suggestions. 1707 11. Normative References 1709 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 1710 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 1711 [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service 1712 Signaling," work in progress. 1713 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1714 Requirement Levels", BCP 14, RFC 2119, March 1997. 1715 [RFC2205] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) 1716 -- Version 1 Functional Specification," RFC 2205, September 1997. 1717 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1718 Services", RFC 2210, September 1997. 1719 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 1720 Network Element Service", RFC 2211, Sept. 1997. 1721 [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality 1722 of Service," September 1997. 1723 [RFC2215] S. Shenker and J. Wroclawski, "General Characterization 1724 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 1725 1997. 1726 [RFC2474] Nichols, K., et. al., "Definition of the Differentiated 1727 Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, 1728 December 1998. 1729 [RFC2475] S. Blake et. al., "An Architecture for Differentiated 1730 Services", RFC 2475, December 1998. 1731 [RFC2597] J. Heinanen, et. al., "Assured Forwarding PHB Group," RFC 1732 2597, June 1999. 1733 [RFC2697] J. Heinanen, R. Guerin, "A Single Rate Three Color Marker," 1734 RFC 2697, September 1999. 1735 [RFC2698] J. Heinanen, R. Guerin, "A Two Rate Three Color Marker," 1736 RFC 2698, September 1999. 1737 [RFC3297] A. Charny, et. al., "Supplemental Information for the New 1738 Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)," 1739 RFC 3297, March 2002. 1741 12. Informative References 1743 [CMSS] "PacketCable (TM) CMS to CMS Signaling Specification, 1744 PKT-SP-CMSS-103-040402, April 2004. 1745 [DIFFSERV-CLASS] Baker, F., et. al., "Configuration Guidelines 1746 for DiffServ Service Classes," work in progress. 1747 [INTSERV-QOSM] C. Kappler, "A QoS Model for Signaling IntServ 1748 Controlled-Load Service with NSIS," work in progress. 1749 [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority Levels 1750 for IP Networks and Services," T1A1/2003-196 R3, November 2004. 1751 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 1752 Protocol - Capability Set 3" Sep. 2003 1754 [RFC1633] B. Braden et. al., "Integrated Services in the Internet 1755 Architecture: an Overview," RFC 1633, June 1994. 1756 [RFC3393] C. Demichelis, P. Chimento, "IP Packet Delay Variation 1757 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 1758 [RFC3564] F. Le Faucheur et. al., Requirements for Support of 1759 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 1760 July 2003 1761 [RFC3726] M. Brunner et. al., "Requirements for Signaling Protocols", 1762 RFC 3726, April 2004. 1763 [RMD-QOSM] A. Bader, et. al., " RMD-QOSM: An NSIS QoS Signaling 1764 Policy Model for Networks 1765 Using Resource Management in DiffServ (RMD)," work in progress. 1766 [SIP-PRIORITY] H. Schulzrinne, J. Polk, "Communications Resource 1767 Priority for the Session Initiation Protocol(SIP)." work in 1768 progress. 1769 [VERTICAL-INTERFACE] M. Dolly, P. S. Tarapore, S. Sayers, 1770 "Discussion on Associating of Control Signaling Messages with Media 1771 Priority Levels," T1S1.7 & PRQC, October 2004. 1772 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives 1773 for IP-Based Services," May 2002. 1774 [Y.1541-QOSM] J. Ash, et. al., "Y.1541-QOSM -- Y.1541 QoS Model for 1775 Networks Using Y.1541 QoS Classes," work in progress. 1777 13. Authors' Addresses 1779 Jerry Ash 1780 AT&T 1781 Room MT D5-2A01 1782 200 Laurel Avenue 1783 Middletown, NJ 07748, USA 1784 Phone: +1-(732)-420-4578 1785 Fax: +1-(732)-368-8659 1786 Email: gash@att.com 1788 Attila Bader 1789 Traffic Lab 1790 Ericsson Research 1791 Ericsson Hungary Ltd. 1792 Laborc u. 1 H-1037 1793 Budapest Hungary 1794 EMail: Attila.Bader@ericsson.com 1796 Chuck Dvorak 1797 AT&T 1798 Room 2A37 1799 180 Park Avenue, Building 2 1800 Florham Park, NJ 07932 1801 Phone: + 1 973-236-6700 1802 Fax:+1 973-236-7453 1803 E-mail: cdvorak@att.com 1804 Yacine El Mghazli 1805 Alcatel 1806 Route de Nozay 1807 91460 Marcoussis cedex 1808 FRANCE 1809 Phone: +33 1 69 63 41 87 1810 Email: yacine.el_mghazli@alcatel.fr 1812 Cornelia Kappler 1813 Siemens AG 1814 Siemensdamm 62 1815 Berlin 13627 1816 Germany 1817 Email: cornelia.kappler@siemens.com 1819 Georgios Karagiannis 1820 University of Twente 1821 P.O. BOX 217 1822 7500 AE Enschede 1823 The Netherlands 1824 EMail: g.karagiannis@ewi.utwente.nl 1826 Andrew McDonald 1827 Siemens/Roke Manor Research 1828 Roke Manor Research Ltd. 1829 Romsey, Hants SO51 0ZN 1830 UK 1831 EMail: andrew.mcdonald@roke.co.uk 1833 Al Morton 1834 AT&T 1835 Room D3-3C06 1836 200 S. Laurel Avenue 1837 Middletown, NJ 07748 1838 Phone: + 1 732 420-1571 1839 Fax: +.1 732 368-1192 1840 E-mail: acmorton@att.com 1842 Percy Tarapore 1843 AT&T 1844 Room D1-3D33 1845 200 S. Laurel Avenue 1846 Middletown, NJ 07748 1847 Phone: + 1 732 420-4172 1848 E-mail: tarapore@.att.com 1850 Lars Westberg 1851 Ericsson Research 1852 Torshamnsgatan 23 1853 SE-164 80 Stockholm, Sweden 1854 EMail: Lars.Westberg@ericsson.com 1856 Appendix A: QoS Models and QSPECs 1858 This Appendix gives a description of QoS Models and QSPECs and 1859 explains what is the relation between them. Once these descriptions 1860 are contained in a stable form in the appropriate IDs this Appendix 1861 will be removed. 1863 QoS NSLP is a generic QoS signaling protocol that can signal for many 1864 QOSMs. A QOSM is a particular QoS provisioning method or QoS 1865 architecture such as IntServ Controlled Load or Guaranteed Service, 1866 DiffServ, or RMD for DiffServ. 1868 The definition of the QOSM is independent from the definition of QoS 1869 NSLP. Existing QOSMs do not specify how to use QoS NSLP to signal 1870 for them. Therefore, we need to define the QOSM specific signaling 1871 functions, as [RMD-QOSM], [INTSERV-QOSM], and [Y.1541-QOSM]. 1873 A QOSM SHOULD include the following information: 1875 - Role of QNEs in this QOSM: 1876 E.g. location, frequency, statefulness... 1877 - QSPEC Definition: 1878 A QOSM SHOULD specify the QSPEC, including QSPEC parameters. 1879 Furthermore it needs to explain how QSPEC parameters not used in this 1880 QOSM are mapped onto parameters defined therein. 1881 - Message Format 1882 QSPEC objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY 1883 - State Management 1884 It describes how QSPEC info is treated and interpreted in the 1885 RMF and QOSM specific processing. E.g. 1886 admission control, scheduling, policy control, QoS parameter 1887 accumulation (e.g. delay). 1888 - Operation and Sequence of Events 1889 Usage of QoS-NSLP messages to signal the QOSM. 1891 Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved of 1892 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 1894 The union of QoS Desired, QoS Available and QoS Reserved can provide 1895 all functionality of the objects specified in RSVP IntServ, however 1896 it is difficult to provide an exact mapping. 1898 In RSVP, the Sender TSpec specifies the traffic an application is 1899 going to send (e.g. token bucket). The AdSpec can collect path 1900 characteristics (e.g. delay). Both are issued by the sender. The 1901 receiver sends the FlowSpec which includes a Receiver TSpec 1902 describing the resources reserved using the same parameters as the 1903 Sender TSpec, as well as a RSpec which provides additional IntServ 1904 QoS Model specific parameters, e.g. Rate and Slack. 1906 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 1907 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 1908 knowledge of the authors it is not possible for the sender to specify 1909 a desired maximum delay except implicitly and mutably by seeding the 1910 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 1911 the receiver-issued RSVP RESERVE message. For this reason our 1912 discussion at this point leads us to a slightly different mapping of 1913 necessary functionality to objects, which should result in more 1914 flexible signaling models. 1916 Appendix C: Main Changes Since Last Version & Open Issues 1918 C.1 Main Changes Since Version -04 1920 - fixed in Sec. 5 and 6.2 as discussed at Interim Meeting 1921 - discarded QSPEC parameter (Maximum packet size) since MTU 1922 discovery is expected to be handled by procedure currently defined 1923 by PMTUD WG 1924 - added "container QSPEC parameter" in Sec. 6.1 to augment encoding 1925 efficiency 1926 - added the 'tunneled QSPEC parameter flag' to Sections 5 and 6 1927 - revised Section 6.2.2 on SIP priorities 1928 - added QSPEC procedures for "RSVP-style reservation", resource 1929 queries and bidirectional reservations in Sec. 7.1 1930 - reworked Section 7.2 1932 C.2 Open Issues 1934 - include error handling 1935 - have coding checked by independent expert 1936 - coding of QSPEC Procedure ID 1938 Intellectual Property Statement 1940 The IETF takes no position regarding the validity or scope of any 1941 Intellectual Property Rights or other rights that might be claimed to 1942 pertain to the implementation or use of the technology described in 1943 this document or the extent to which any license under such rights 1944 might or might not be available; nor does it represent that it has 1945 made any independent effort to identify any such rights. Information 1946 on the procedures with respect to rights in RFC documents can be 1947 found in BCP 78 and BCP 79. 1949 Copies of IPR disclosures made to the IETF Secretariat and any 1950 assurances of licenses to be made available, or the result of an 1951 attempt made to obtain a general license or permission for the use of 1952 such proprietary rights by implementers or users of this 1953 specification can be obtained from the IETF on-line IPR repository at 1954 http://www.ietf.org/ipr. 1956 The IETF invites any interested party to bring to its attention any 1957 copyrights, patents or patent applications, or other proprietary 1958 rights that may cover technology that may be required to implement 1959 this standard. Please address the information to the IETF at 1960 ietf-ipr@ietf.org. 1962 Disclaimer of Validity 1964 This document and the information contained herein are provided on an 1965 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1966 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1967 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1968 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1969 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1970 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1972 Copyright Statement 1974 Copyright (C) The Internet Society (2005). This document is subject 1975 to the rights, licenses and restrictions contained in BCP 78, and 1976 except as set forth therein, the authors retain all their rights.